diff --git a/docs/chain-abstraction/omnibridge/implementation.md b/docs/chain-abstraction/omnibridge/implementation.md index 75f43cee6a8..4e37e56e9d2 100644 --- a/docs/chain-abstraction/omnibridge/implementation.md +++ b/docs/chain-abstraction/omnibridge/implementation.md @@ -162,21 +162,17 @@ Uses NEAR light client for maximum security: * Verifying proof through light client * Releasing tokens to recipient -### 2. Solana +### 2. Supported Non-EVM Chains (e.g., Solana) -Currently using Wormhole for: +Utilize established message passing protocols (such as Wormhole) for: * Message passing between chains * Transaction verification * Integration with NEAR token factory system -### 3. Other Chains +### 3. Other EVM Chains -Initially using Wormhole for: - -* Message passing between chains -* Transaction verification -* Will transition to Chain Signatures +Utilize a combination of light clients (where efficient) and message passing protocols to ensure secure verification of inbound transfers. --- @@ -207,10 +203,10 @@ Omni Bridge requires different trust assumptions depending on the chain connecti * Finality assumptions (e.g., sufficient block confirmations) * Chain-specific consensus assumptions -#### For interim Wormhole connections: +#### For Message Passing connections: -* Wormhole Guardian network security -* We acknowledge this is a temporary trust assumption until Chain Signatures integration is complete +* Security of the underlying message passing protocol (e.g., Wormhole Guardian network) +* Verified by NEAR network participants (e.g., validators and full nodes) --- @@ -230,6 +226,37 @@ The relayer's role is purely operational - executing valid transfers and collect --- +## 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. + +### How it Works + +1. **User Initiation:** A user sends a `FastFinTransferMsg` specifying the destination and fee. +2. **Relayer Execution:** A 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. + +:::tip +Fast transfers are ideal for users who prioritize speed over cost, as relayers may charge a premium for the liquidity and convenience. +::: + +--- + +## Multi-Token Support (ERC1155) + +Omni Bridge 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. + +### Key Functions +* **`initTransfer1155`**: Initiates a transfer for a specific ERC1155 token ID. +* **`logMetadata1155`**: Registers metadata for a specific token ID, ensuring it is recognized by indexers and wallets. + +--- + ## Fee Structure Bridge fees are unified and processed on NEAR, with components including: diff --git a/docs/chain-abstraction/omnibridge/roadmap.md b/docs/chain-abstraction/omnibridge/roadmap.md index 661c34f37b2..73d5c340aca 100644 --- a/docs/chain-abstraction/omnibridge/roadmap.md +++ b/docs/chain-abstraction/omnibridge/roadmap.md @@ -8,29 +8,27 @@ description: "Explore the Omni Bridge roadmap, including hybrid architecture lau Omni Bridge launches with a hybrid architecture, utilizing different verification methods based on chain-specific requirements and technical constraints. This approach allows us to support multiple chains from day one while progressively transitioning to full Chain Signatures integration. ## Supported Chains -Initial launch includes: - -- **Ethereum** - _(Light client + Chain Signatures)_ -- **Bitcoin** - _(Light client + Chain Signatures)_ -- **Solana** - _(Wormhole + Chain Signatures)_ -- **Base** - _(Wormhole + Chain Signatures)_ -- **Arbitrum** - _(Wormhole + Chain Signatures)_ - -## Migration Path - -1. **Phase 1: Hybrid Operation** (ongoing) -- ETH/BTC: Light client verification -- Other chains: Wormhole message passing -- All NEAR outbound: Chain Signatures - -During this phase, cross-chain messages follow different verification paths depending on direction and chain. NEAR outbound transfers already utilize Chain Signatures, while inbound transfers vary by source chain. - -2. **Phase 2: Full Chain Signatures** -- Progressive transition of all chains -- Removal of Wormhole dependency -- Enhanced decentralization - -Phase 2 represents our move to a unified verification model. Each chain will transition to Chain Signatures verification as implementation and audits complete, gradually removing the hybrid architecture's complexity. +The bridge currently supports the following networks: + +- **EVM Chains:** + - Ethereum + - Base + - Arbitrum + - BNB Chain + - Polygon (PoS) +- **Non-EVM Chains:** + - Bitcoin + - Solana + - Zcash + +## Architecture Overview + +Omni Bridge utilizes **Chain Signatures** as its primary verification mechanism for outbound transfers from NEAR. Incoming transfers rely on chain-specific verification methods, including light clients for maximum security where available. + +### Verification Methods +- **Ethereum & Bitcoin:** Light Client verification for inbound transfers. +- **Other Chains:** Message passing protocols verified by the NEAR network. +- **Outbound (All Chains):** Chain Signatures (MPC) for secure transaction signing. ## Future Development 1. **Protocol Improvements**