# Cross-Chain Bridge Development Cross-chain bridge development and interoperability: secure asset and message transfer between chains. We built a live NEAR-to-Solana bridge. Canonical: https://www.metaborong.com/services/web3/cross-chain-bridge-development Service: web3/cross-chain-bridge-development ## Overview Bridges hold more value than almost anything else in crypto, and they are the surface attackers hit first, because a single flaw in message verification can drain both sides at once. Cross-chain bridge development is the engineering practice of building the lock-and-mint contracts, relayers, and message verification that move assets and data between two chains while proving every transfer is genuine. ## What is it? Cross-chain bridge development is a blockchain interoperability practice for protocol teams that moves assets and data between chains through verified messages. The security model and message verification are engineered before code, because bridges are the highest-risk surface in crypto. We built a live NEAR-Solana cross-chain bridge. Our contract work has cleared four Hacken audit rounds. ## What we deliver - Lock-and-mint or burn-and-mint contracts on both source and destination chains. - Relayer or attestation layer with replay protection and message ordering. - Message verification logic auditors can read against a stated trust model. - Liveness monitoring for stuck transfers, relayer health, and supply reconciliation. - Threat model and audit-ready spec for the full cross-chain message path. ## Key concepts **Lock-and-mint**: Lock-and-mint is a bridge pattern where an asset is locked in a contract on the source chain and an equivalent wrapped token is minted on the destination chain. Burning the wrapped token releases the original. Supply on both sides must reconcile exactly, or the wrapped token loses its backing. **Attestation**: Attestation is the signed claim that a source-chain event actually happened, produced by relayers, validators, or an oracle network. The destination chain verifies these signatures before minting. The trust model of a bridge is largely the question of who attests and how many of them must collude to forge a transfer. **Replay protection**: Replay protection prevents a single valid cross-chain message from being processed more than once. Each message carries a unique nonce that the destination chain records and rejects on a second submission. Without it, an attacker resubmits one legitimate mint instruction repeatedly to drain reserves. **Liveness**: Liveness is the property that a bridge keeps processing transfers rather than stalling. A bridge can be safe yet unusable if relayers go offline or messages get stuck mid-flight. Monitoring tracks pending transfers, relayer health, and reconciliation so operators catch a halt before users do. ## How we work 1. **Trust model & spec** We decide who is allowed to attest that a source-chain event happened, and how many of them must collude before a forged transfer is possible. That choice, whether relayer set, validator quorum, or external network, defines the bridge security model. We write it as a spec with the lock-and-mint or burn-and-mint flow, message format, and nonce scheme named before any code. 2. **Contracts & messaging** We build the source and destination contracts and the messaging layer that carries signed events between them. Replay protection is enforced with per-message nonces the destination records and rejects on reuse. Supply accounting is reconciled on both sides so locked collateral always backs minted tokens. Every external call and verification branch is written for an auditor to trace end to end. 3. **Adversarial testing** We test the message path against the threat model, not just the happy case. Forged attestations, replayed nonces, reordered messages, and a halted relayer are each exercised as failing tests before they pass. Fork tests run the contracts against live chain state. A second engineer audits the verification logic line by line against the named adversary before any external review. 4. **Deploy & monitor** Deployment runs from a reviewed script across both chains, with admin roles transferred to your multisig. We monitor pending transfers, relayer health, and supply reconciliation so a stalled or diverging bridge is caught early. We respond to incidents on a defined SLA and document every privileged call. The live NEAR-Solana bridge shipped on a tight timeline through this process. ## Tech stack Solidity (EVM), Rust (Solana), NEAR SDK (NEAR), Anchor (Solana), Foundry (Testing), Wormhole (Messaging), LayerZero (Messaging), Tenderly (Monitoring) ## When this fits ### Fits when - You need assets or messages to move between two specific chains with a stated trust model. - You treat the bridge as the highest-risk surface and budget for an external audit accordingly. - Your team can review a trust model and message spec, not just a feature backlog. ### Does not fit when - You want an existing bridge forked and redeployed with no verification or threat review. - A general-purpose messaging protocol already covers your route and needs only integration. - The primary need is in-chain contract work, not cross-chain transfer or message passing. ## FAQ ### What makes bridges the highest-risk part of crypto? A bridge holds the locked collateral backing every wrapped token it has minted, so it concentrates value the way a vault does. The destination chain mints based on attestations that a source-chain event happened. If an attacker forges an attestation, replays a message, or breaks the verification logic, they can mint unbacked tokens and drain the locked reserves. That is why we engineer the trust model and message verification before any other code. ### What is the difference between lock-and-mint and burn-and-mint? Lock-and-mint locks the original asset on the source chain and mints a wrapped version on the destination, releasing the lock when the wrapped token is burned. Burn-and-mint burns a native token on one chain and mints the native token on the other, with no wrapped representation. Lock-and-mint suits bridging an existing asset to a new chain; burn-and-mint suits a token that is natively issued on several chains. We choose per asset and document why. ### How do you prevent a message from being replayed? Every cross-chain message carries a unique nonce. The destination chain records each processed nonce and rejects any second submission of the same one, so a valid mint instruction cannot be replayed to drain reserves. We test this directly: replayed nonces, reordered messages, and forged attestations are each written as failing tests that must be rejected before the contracts pass internal audit. ### Which chains have you built a bridge between? We built a live cross-chain bridge connecting NEAR and Solana for a token project, delivered on a tight timeline, with assets traded on NEAR through REF Finance. More broadly we ship contracts across EVM chains, Solana in Rust, NEAR, and Move on Aptos, so we can reason about the verification model on both sides of a route rather than treating one chain as a black box. ### Do you run the security audit yourselves? No, the external audit is always a separate firm. We engineer for audit and run an internal pass where a second engineer reviews the verification logic line by line against the threat model, but the external auditor is the signal investors and users trust on a bridge. Our contract work has cleared four Hacken rounds through this process, and we coordinate the engagement with the firm you choose.