Update Omnibridge Docs

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:

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**