Web3 · Engineering
Cross-Chain Bridges & Interoperability
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.
- NEAR + Solanachains bridged in productionlive NEAR-Solana bridge
- 4Hacken audit rounds clearedNeemo Finance contracts
- Move + EVMplus Solana and NEARchains we ship on
In short
What is Cross-Chain Bridges & Interoperability?
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
Concrete artefacts, not capabilities
- 01
Lock-and-mint or burn-and-mint contracts on both source and destination chains.
- 02
Relayer or attestation layer with replay protection and message ordering.
- 03
Message verification logic auditors can read against a stated trust model.
- 04
Liveness monitoring for stuck transfers, relayer health, and supply reconciliation.
- 05
Threat model and audit-ready spec for the full cross-chain message path.
Key concepts
Key terms, defined
- 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
Engagement phases
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.
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.
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.
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
What we build on
- SolidityEVM
- RustSolana
- NEAR SDKNEAR
- AnchorSolana
- FoundryTesting
- WormholeMessaging
- LayerZeroMessaging
- TenderlyMonitoring
- SolidityEVM
- RustSolana
- NEAR SDKNEAR
- AnchorSolana
- FoundryTesting
- WormholeMessaging
- LayerZeroMessaging
- TenderlyMonitoring
Scope
When this fits and when it doesn't
| This fits when | This doesn't fit when |
|---|---|
| You need assets or messages to move between two specific chains with a stated trust model. | You want an existing bridge forked and redeployed with no verification or threat review. |
| You treat the bridge as the highest-risk surface and budget for an external audit accordingly. | A general-purpose messaging protocol already covers your route and needs only integration. |
| Your team can review a trust model and message spec, not just a feature backlog. | The primary need is in-chain contract work, not cross-chain transfer or message passing. |
Related work
Shipped engagements
- Live project
NEAR-Solana bridge: live token project
We built a production cross-chain bridge connecting NEAR and Solana for a live token project, delivered on a tight timeline.
View live project - Live project
Neemo Finance: staking contracts, four audit rounds
Astar-network staking contract suite engineered for Neemo Finance that cleared four separate Hacken audit rounds before mainnet.
View live project
Related services
Adjacent engagements
- Web3
Smart Contract Development
Solidity, Vyper, and Move contracts engineered for third-party audit, with tests and monitoring.
- Web3
DeFi Protocol Development
Lending, perpetuals, yield, and vault infrastructure spec'd for third-party audit.
- Product Studio
MVP Development
Zero-to-launch product builds - founder-led scope through first paying users.
Frequently asked questions
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.
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.
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.
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.
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.
Last reviewed · Reviewed by Metaborong engineering team
Tell us what you are building.
We build what large agencies under-deliver and freelancers can't architect, across Web3 protocols, AI agents, and SaaS products. Tell us what you are building. We will tell you how we would approach it, no pitch deck, no fluff, no commitment required.