Skip to main content
The Omnibridge is a multi-chain asset bridge that facilitates secure and efficient asset transfers between different blockchain networks. It solves key challenges in cross-chain communication by leveraging Chain Signatures and its decentralized Multi-Party Computation (MPC) service to enable trustless cross-chain asset transfers.

​
Supported Chains

Omnibridge launches with a hybrid architecture, utilizing different verification methods based on chain-specific requirements and technical constraints. This approach allows support for multiple chains from day one while progressively transitioning to full Chain Signatures integration.

Ethereum

Light client + Chain Signatures

Bitcoin

Light client + Chain Signatures

Solana

Wormhole + Chain Signatures

Base

Wormhole + Chain Signatures

BNB Chain

Wormhole + Chain Signatures

Arbitrum

Wormhole + Chain Signatures

​
How Omnibridge Works

Omnibridge introduces an elegant solution using Chain Signatures. Instead of running light clients on each destination chain, it leverages Chain Signature’s MPC Service to enable secure cross-chain message verification without the overhead of traditional light client verification.
This approach reduces verification times from hours to minutes while significantly reducing gas costs across all supported chains.

​
The Problem with Traditional Bridges

A light client is a smart contract that lets one blockchain verify events happening on another blockchain. Traditional bridges like Rainbow Bridge require:
  • Storing extensive block data (e.g., two weeks of Ethereum blocks)
  • Maintaining updated validator lists and stakes
  • Verifying signatures (e.g., ED25519) that weren’t designed for the target chain
  • High gas costs and slow transaction times (4-8 hours for NEAR to Ethereum)
Some chains, such as Bitcoin, don’t even support smart contracts, making it technically impossible to implement a traditional light client approach.

​
Chain Signatures Solution

Instead of maintaining complex light clients on destination chains, Chain Signatures introduces a fundamentally different approach based on three core components:
1

Deterministic Address Derivation

Every NEAR account can mathematically derive addresses on other chains through derivation paths. This ensures the same NEAR account always controls the same set of addresses across all supported chains.
2

Bridge Smart Contract

A central contract on NEAR coordinates with the MPC network to generate secure signatures for cross-chain transactions. This contract handles token locking and requests signatures for outbound transfers.
3

MPC Service

A decentralized network of nodes that jointly sign transactions without ever reconstructing a full private key. Security comes from threshold cryptography - no single node or small group can create valid signatures alone.

​
Transfer Flow

Here’s how transfers are processed from NEAR to other chains:

​
Transfer Lifecycle

1

Initiation

User calls the token contract with:
  • Amount to transfer
  • Destination chain and address
  • Fee preferences (pay in token or NEAR)
2

Token Lock/Burn

For native NEAR tokens: locked in bridge contractFor bridged tokens: burned
3

MPC Signing

Bridge contract requests signature generation. MPC nodes jointly generate and aggregate the signature while maintaining threshold security.
4

Destination Chain Execution

Bridge Token Factory on destination chain verifies the MPC signature and mints equivalent tokens.

​
Token Standards and NEP-141

NEAR’s NEP-141 fungible token standard has built-in composability through transfer-and-call functionality that sets it apart from Ethereum’s ERC-20. When a token transfer happens using ft_transfer_call, the token contract:
  1. First transfers the tokens
  2. Automatically calls the specified ft_on_transfer method on the receiver contract
  3. The receiver contract can reject the transfer, causing tokens to be refunded
This atomic behavior ensures the integrity and safety of bridge operations by preventing partial execution states.

​
Bridge Token Factory Pattern

At the core of Omnibridge is the Bridge Token Factory contract on NEAR that serves as both a token factory and custodian.

​
For Bridged Tokens (from other chains)

  • Deploys new token contracts when bridging tokens for the first time
  • Mints tokens when receiving valid transfer messages
  • Burns tokens when initiating transfers back to the origin chain

​
For Native NEAR Tokens

  • Acts as custodian by locking tokens during transfers
  • Releases tokens when receiving valid transfer messages
  • Manages token operations through the NEP-141 standard

​
Return Flow: Other Chains to NEAR

The reverse flow varies based on the source chain:
Uses NEAR light client for maximum security:
  1. Burn tokens on Ethereum
  2. Submit proof to NEAR
  3. Verify proof through light client
  4. Release tokens to recipient

​
Chain-to-Chain Transfers (via NEAR)

For transfers between two non-NEAR chains (e.g., Ethereum to Solana), the bridge uses NEAR as an intermediary routing layer.
From the user’s perspective, this appears as a single operation. The off-chain relayer infrastructure handles the intermediate NEAR routing automatically.

​
Security Model

Omnibridge requires different trust assumptions depending on the chain connection:
  • NEAR Protocol security (2/3+ honest validators)
  • MPC network security (2/3+ honest nodes)
  • No single entity controls enough MPC nodes to forge signatures
  • Correct implementation of the signing protocol
  • Light client correctness and security
  • Finality assumptions (sufficient block confirmations)
  • Chain-specific consensus assumptions
  • Security of the underlying protocol (e.g., Wormhole Guardian network)
  • Verification by NEAR network participants (validators and full nodes)

​
Relayer Network

Relayers are permissionless infrastructure operators who monitor for bridge events and execute cross-chain transactions.

What Relayers CAN'T Do

  • Forge transfers
  • Steal funds
  • Censor transactions
  • Front-run for profit
  • Create security assumptions

What Relayers DO

  • Execute valid transfers
  • Collect predetermined fees
  • Provide operational infrastructure
  • Compete for faster execution
Multiple relayers can operate simultaneously, creating competition for faster execution and lower fees. Users can also self-relay to bypass relayer fees entirely.

​
Fast Transfers

Standard cross-chain transfers can take time due to finality and verification requirements. Fast Transfers allow relayers to expedite this process by fronting liquidity.
1

User Initiation

User sends a FastFinTransferMsg specifying the destination and fee.
2

Relayer Execution

Relayer detects the request and instantly transfers the equivalent amount (minus fees) to the user on the destination chain from their own funds.
3

Settlement

The bridge later reimburses the relayer once the original transfer is fully verified and finalized.
Fast transfers are ideal for users who prioritize speed over cost, as relayers may charge a premium for the liquidity and convenience.

​
Fee Structure

Bridge fees are unified and processed on NEAR, with components including:
  • Destination chain gas costs
  • Source chain storage costs
  • Relayer operational costs
  • MPC signing costs

​
Fee Payment Options

  • Native tokens of source chain
  • The token being transferred
Fees dynamically adjust based on gas prices across different chains to ensure reliable execution.

​
Multi-Token Support (ERC1155)

Omnibridge supports the ERC1155 standard, enabling the transfer of multiple token types within a single contract.

​
Address Derivation

To maintain consistency across chains, bridged ERC1155 tokens use a deterministic address derivation scheme: 
Deterministic Address = keccak256(tokenAddress + tokenId)
This ensures that each tokenId within an ERC1155 contract maps to a unique, consistent address on the destination chain.

​
Resources

Omnibridge Repository

Main codebase and documentation

JavaScript SDK

SDK for JavaScript/TypeScript integration

Rust SDK

SDK for Rust integration

​
Next Steps

Implementation Details

Explore technical architecture and code examples

Development Roadmap

Learn about upcoming features and improvements

Build docs developers (and LLMs) love

Get started for freeTalk to us