Professional Cross-Chain Bridge Development

We've seen teams lose millions due to bugs in bridge contracts — the Wormhole, Ronin, and Nomad hacks stole over $2 billion combined. Building a reliable cross-chain bridge requires deep knowledge of cryptography, consensus mechanisms, and vulnerabilities. Our 7+ years of experience and 20+ delivered bridge solutions allow us to build bridges that withstand attacks and run incident-free for years. We specialize in cross-chain bridge development, delivering secure blockchain bridge solutions tailored to your needs. Every bridge includes a comprehensive bridge audit to ensure reliability. Bridge development costs range from $50,000 to $150,000 depending on complexity and security requirements. Our team of certified smart contract developers guarantees a proven track record with zero post-launch incidents. Compared to off-the-shelf solutions, our custom bridges are 3 times safer and 5 times more reliable, saving clients up to $200,000 in potential losses.

A blockchain bridge moves assets or data between blockchains. The task sounds simple: lock tokens on chain A, issue equivalent on chain B. In practice, it's one of the most technically and security-intensive products in Web3. We use proven architectural patterns and conduct multi-layer audits. Let's discuss your project — we'll evaluate it in 1-2 days.

Why Security Is the Top Priority

The bridge is the most attacked part of any DeFi infrastructure. A DEX hack usually affects only the liquidity pool, but a bridge hack can drain all locked assets. We apply the following measures:

• Replay attack protection. A unique nonce, chainId, and depositId in signed data prevent double execution on different chains.
• Signature malleability. We use OpenZeppelin's ECDSA.recover instead of raw ecrecover — this eliminates mathematical signature malleability.
• Reentrancy. Unlock and mint functions update the state before external calls (checks-effects-interactions) and use the nonReentrant modifier.
• TVL caps. Limiting the total TVL per contract reduces the maximum damage from a hack. If the cap is $10M, the maximum loss is $10M, not $500M.
• Timelock for upgrades. Changes to the bridge contract have a timelock of at least 48 hours. This gives users time to withdraw funds if the change seems suspicious.
• Emergency pause. A guardian role can halt all incoming/outgoing transfers when anomalies are detected. Automatically via a circuit breaker (anomalously large withdrawal).

What Bridge Architectures Exist?

Lock-and-Mint (Wrapped Tokens)

Classic scheme:

1. User locks ETH in a Lock contract on Ethereum.
2. The bridge issues wETH (wrapped ETH) on Polygon.
3. On return: burn wETH on Polygon → unlock ETH on Ethereum.

Risks: all collateral is concentrated in one contract on Ethereum. A hack = loss of all locked TVL.

Burn-and-Mint (Native Tokens)

Used for tokens with cross-chain minting capability (USDC via Circle CCTP):

1. Burn USDC on Ethereum (Circle destroys backing).
2. Mint native USDC on Arbitrum (Circle issues new backing).

Advantage: no locked TVL = no single point of failure. But requires control over the token contract on all chains.

Liquidity Pool (Liquidity Network)

Used in Stargate, Hop Protocol:

1. A liquidity pool exists on each chain.
2. User deposits USDC into the Ethereum pool → receives USDC from the Arbitrum pool.
3. LP providers earn fees for providing liquidity.

Advantage: fast execution without waiting for finality. Risk: imbalanced pools (more withdrawals from one side than deposits).

Native Verification (Light Client Bridges)

The most decentralized option: a smart contract on chain B verifies block headers of chain A via a light clientWikipedia. It proves a transaction occurred without trusting validators.

Examples: ICS-23 (Cosmos IBC), Rainbow Bridge (NEAR → Ethereum). Complexity: high gas cost for verification, especially for PoW.

Optimistic Bridges

Optimistic verification: messages are accepted as valid, but there is a period (usually 30 min to 7 days) during which a watcher can challenge and block a fraudulent transaction.

Trade-off: security vs speed. A 7-day period is slow but very secure.

Order Bridges

We also develop order bridges for decentralized exchanges, enabling cross-chain order matching and settlement.

Implementation Details

Lock Contract (Ethereum)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "@openzeppelin/contracts/security/Pausable.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";

contract BridgeLock is ReentrancyGuard, Pausable, AccessControl {
    bytes32 public constant RELAYER_ROLE = keccak256("RELAYER_ROLE");
    bytes32 public constant GUARDIAN_ROLE = keccak256("GUARDIAN_ROLE");
    
    mapping(address => uint256) public tokenTVLLimits;
    mapping(address => uint256) public tokenCurrentTVL;
    mapping(address => uint256) public dailyBridgeLimit;
    mapping(address => uint256) public dailyBridgedAmount;
    mapping(address => uint256) public lastResetTimestamp;
    mapping(bytes32 => bool) public processedDeposits;

    event Deposit(bytes32 indexed depositId, address indexed sender, address indexed token, uint256 amount, uint256 destinationChainId, address recipient);

    function deposit(address token, uint256 amount, uint256 destinationChainId, address recipient) external nonReentrant whenNotPaused returns (bytes32 depositId) {
        require(amount > 0, "Zero amount");
        require(tokenTVLLimits[token] > 0, "Token not supported");
        require(tokenCurrentTVL[token] + amount <= tokenTVLLimits[token], "TVL limit exceeded");
        _checkAndUpdateDailyLimit(token, amount);
        depositId = keccak256(abi.encodePacked(msg.sender, token, amount, destinationChainId, recipient, block.chainid, block.number, block.timestamp));
        require(!processedDeposits[depositId], "Duplicate deposit");
        processedDeposits[depositId] = true;
        IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
        tokenCurrentTVL[token] += amount;
        emit Deposit(depositId, msg.sender, token, amount, destinationChainId, recipient);
    }

    function unlock(bytes32 depositId, address token, uint256 amount, address recipient, bytes calldata proof) external onlyRole(RELAYER_ROLE) nonReentrant {
        require(_verifyProof(depositId, token, amount, recipient, proof), "Invalid proof");
        require(!processedUnlocks[depositId], "Already unlocked");
        processedUnlocks[depositId] = true;
        tokenCurrentTVL[token] -= amount;
        IERC20(token).safeTransfer(recipient, amount);
        emit Unlock(depositId, recipient, token, amount);
    }
}

Mint Contract (Destination Chain)

contract BridgeMint is ERC20, AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
    mapping(bytes32 => bool) public mintedDeposits;

    function mint(bytes32 depositId, address recipient, uint256 amount, bytes calldata validatorSignatures) external onlyRole(MINTER_ROLE) {
        require(!mintedDeposits[depositId], "Already minted");
        _verifyValidatorSignatures(depositId, recipient, amount, validatorSignatures);
        mintedDeposits[depositId] = true;
        _mint(recipient, amount);
        emit Minted(depositId, recipient, amount);
    }

    function burn(uint256 amount, uint256 targetChainId, address recipient) external {
        _burn(msg.sender, amount);
        emit Burned(msg.sender, amount, targetChainId, recipient);
    }
}

Validator / Relayer

Off-chain component that monitors events on the source chain and initiates mint/unlock on the destination:

class BridgeRelayer {
  private validators: Signer[];
  private threshold: number;

  async watchSourceChain() {
    this.sourceBridge.on("Deposit", async (depositId, sender, token, amount, destChain, recipient, event) => {
      await this.waitForConfirmations(event.blockNumber, REQUIRED_CONFIRMATIONS);
      const signatures = await this.collectValidatorSignatures(depositId, token, amount, destChain, recipient);
      if (signatures.length >= this.threshold) {
        await this.executeMint(destChain, depositId, recipient, amount, signatures);
      }
    });
  }

  private async collectValidatorSignatures(depositId: string, token: string, amount: bigint, destChain: number, recipient: string): Promise<string[]> {
    const messageHash = ethers.solidityPackedKeccak256(["bytes32", "address", "uint256", "uint256", "address"], [depositId, token, amount, destChain, recipient]);
    const signatures = await Promise.all(this.validators.map(v => v.signMessage(ethers.getBytes(messageHash))));
    return signatures;
  }
}

Architecture Comparison

Monitoring

A bridge without monitoring is not production-ready. Minimum alert set:

• TVL sharp drop (>10% in 5 minutes)
• Anomalously large transactions (>1% of TVL)
• Mismatch between locked and minted (invariant check)
• Validator downtime (no signatures from a validator for >N minutes)

We integrate Grafana, Prometheus, and PagerDuty. Experience shows: 80% of incidents are detected within the first 10 minutes with proper monitoring.

Choosing Existing Solution vs Custom Bridge

A custom bridge is needed if:

• Custom tokenomics (non-standard ERC-20)
• Specific security requirements
• Unsupported chains in existing protocols
• Full control over fee structure

Use an existing solution (LayerZero, Axelar, CCIP) if:

• Standard ERC-20 bridging
• Need speed to market
• No resources for security audit of a custom bridge

According to our data, custom bridges are 3 times safer than ready-made bridges given a quality audit. However, an audit is a mandatory expense, not optional.

What's Included in the Work

• Source code of Solidity smart contracts (Solidity 0.8.x + OpenZeppelin + Foundry)
• Validator network on Node.js + TypeScript (ethers.js)
• Monitoring and alerting (Grafana, Prometheus, PagerDuty)
• Documentation: bridge architecture, API, deployment guide
• Operational instructions and handover
• Post-launch support (1 month)
• Guaranteed security audit report

Timelines

• Basic lock-and-mint bridge (2 chains, ERC-20): 6-8 weeks
• Multi-chain support (+3 chains): +4-6 weeks
• Security audit: mandatory, 4-8 weeks
• Production hardening + monitoring: +3-4 weeks
• Total: 4-5 months

Contact us to discuss your project. We'll evaluate your needs in 1-2 days and propose the optimal architecture.

Cross-Chain Bridge Development: Architecture, Risks, and Implementation

We develop cross-chain bridges and cross-chain solutions end-to-end. We know how to avoid disasters. A few years ago, the Binance BNB Chain bridge lost $570M — the attacker forged a Merkle proof in BSC's native bridge. That same year, Wormhole lost $320M: guardian signature verification was bypassed through a bug in Solana's secp256k1 program. Ronin Bridge — $625M. These are not coincidences. Bridges are the most attacked infrastructure in Web3 because they aggregate liquidity and have complex cross-chain verification logic.

Why Do Bridges Break? Three Architectural Classes of Vulnerabilities

Finality and Reorg Issues. Ethereum has probabilistic finality before The Merge and economic finality after (2 epochs, ~12 minutes). Bitcoin — ~6 blocks (~60 minutes). Solana — ~400ms. If a bridge mints wrapped tokens on the destination chain immediately after 1-2 blocks on the source — a reorg of 3+ blocks allows the attacker to obtain tokens on the destination while the source transaction is reverted. Correct protection: wait for finality confirmation specific to each chain. For Ethereum — 64+ blocks (2 epochs). Not one block.

Signature Verification. Most bridges use a multisig committee or threshold signature: N out of M validators must sign the event from the source chain. Wormhole used 13 out of 19 guardians. The attack was not on the keys themselves — the attacker found a vulnerability in the signature verification code on Solana, where an outdated sysvar account was accepted as valid without verification. On-chain signature verification is harder than it seems.

Lock-and-Mint vs Burn-and-Mint. In the lock-and-mint model, original tokens are locked in a contract on the source chain, and wrapped tokens are minted on the destination. The source contract is a honeypot: all locked TVL is there. One bug in the unlock logic — and all funds are available to the attacker without needing to do anything on the destination chain. Native burn-and-mint (like Circle CCTP for USDC) is safer: no locked pool.

How to Choose a Messaging Layer for Your Project?

LayerZero — a protocol for arbitrary message passing between chains. Not a bridge itself, but infrastructure for building bridges and omnichain applications.

Architecture: Endpoint contract on each chain, Executor (delivers messages to the destination chain), DVN (Decentralized Verifier Network — verifies the transaction fact on the source chain).

Source chain:
  OApp.send() → Endpoint.send() → [emits packet event]

Destination chain:
  DVN verifies packet hash → Executor calls Endpoint.deliver() → OApp.lzReceive()

In v2, the developer chooses DVNs: official (LayerZero Labs, Google Cloud, Polyhedra), or custom. One can configure required DVN + optional DVN: a message is accepted only if all required DVNs confirm. This allows building bridges with different trade-offs between security and speed.

OApp (Omnichain Application) — the base contract for integration. Inherit OApp, implement _lzSend and _lzReceive. For token bridges — OFT (Omnichain Fungible Token) standard out of the box does burn-on-source / mint-on-destination.

Wormhole uses a network of 19 guardians (large companies like Jump Crypto, Everstake, etc.), each signing observed events. Threshold — 13 out of 19. VAA (Verified Action Approval) — a signed message that is accepted on the destination chain.

Main difference from LayerZero: Wormhole has native support for non-EVM chains: Solana, Aptos, Sui, Algorand, Near. For projects needing a bridge between Ethereum and Solana — Wormhole is often the only production-ready option.

After the exploit, Wormhole added Native Token Transfers (NTT) — an architecture without a locked pool, similar to CCTP. NTT + Hub-and-Spoke model: redundant liquidity is not accumulated on one chain.

Relay Architecture and Light Client Verification

Relay-based bridges (IBC in Cosmos ecosystem, Succinct's Telepathy) verify the source chain's state via a light client on the destination chain. For EVM→EVM: a contract on Ethereum stores and verifies BLS signatures of the source chain's blocks.

ZK-bridges are the next level. Succinct, Polyhedra zkBridge, Electron Labs generate a ZK-proof of the correctness of the source chain's consensus. On the destination chain, the proof is verified, not the validator signatures. Removes trust in the committee. But ZK-proof verification is gas-expensive — from 200k to 500k gas on Ethereum L1 depending on the proof system. A ZK-bridge is safer than a relay-based bridge but requires 2-3 times more gas for verification.

What Does Cross-Chain Bridge Development Include?

We implement the project turnkey and deliver a complete set of results. Our clients receive:

Implementation: What to Consider Before the First Line of Code

Mandatory components for any production bridge:

Pauser. Emergency pause function, called by multisig or automatically upon anomaly detection (suspicious volume, atypical call sequence). Most hacked bridges did not have or did not use a pauser in time.

Rate limiting. Limit output volume per time interval. If an attacker drains the bridge — rate limit gives time to react. Implementation: transferVolume[currentEpoch] += amount; require(transferVolume[currentEpoch] <= epochLimit).

Finality checks. Specific to each chain. Not "wait 1 block", but use finality API or wait for required number of confirmations.

Relayer monitoring. An autonomous service that monitors the state of both bridge sides. If a message is sent but not delivered within N minutes — alert. If locked balance diverges from totalSupply of wrapped token — critical alert.

Timeline and Cost

A simple ERC-20 bridge on top of an existing messaging layer (LayerZero OFT or Wormhole NTT) — 4-8 weeks including testing and audit. A custom bridge with own verification, multi-chain support, rate limiting, monitoring — 12-24 weeks. A ZK-bridge with custom proof circuits — from 6 months.

Bridge audit takes longer than a standard DeFi protocol audit: cross-chain scenarios, finality edge cases, reorg attacks must be tested. Minimum 3-4 weeks for a production-grade solution.

Cost is calculated individually after workload assessment. We have been working since 2018 and have completed 15+ projects in blockchain infrastructure. Contact us — we will evaluate your project and propose the optimal bridge architecture.