Bridge

// This is a duplicate of features/bridges.md. Please keep only one copy in the future.

Bridges (Cross-Chain)

JuliaOS provides modules for facilitating communication and asset transfers between different blockchain networks. This is crucial for agents or strategies that operate across multiple ecosystems (e.g., arbitrage between Ethereum and Solana).

Concept

A cross-chain bridge allows users or applications to lock an asset on one chain and receive a representation of that asset (a wrapped token) or a different asset on another chain. This typically involves:

• Source Chain Contract: Where the original asset is locked or burned.

• Target Chain Contract: Where the wrapped asset is minted or the corresponding asset is released.

• Messaging/Verification Layer: A mechanism to securely communicate the lock/burn event from the source chain to the target chain (e.g., relayers, oracle networks, light clients, guardian networks like Wormhole's).

Supported Bridges in JuliaOS

JuliaOS integrates with specific bridge protocols, primarily handled by the Node.js/TypeScript packages in /packages/bridges/:

• Relay Bridge:

  • A custom-built bridge likely relying on a centralized or semi-centralized relayer service.

  • Monitors events on source/target chains and submits corresponding transactions.

  • Currently supports Base Sepolia and Solana (as per README).

  • Pros: Simpler implementation, potentially faster for specific chain pairs.

  • Cons: Relies on the relayer's availability and security; less decentralized.

  • Use Case: Testing, development, specific trusted environments.

• Wormhole Bridge:

  • Integrates with the established Wormhole protocol.

  • Uses a network of Guardians to observe events and produce signed attestations (VAAs - Verified Action Approvals).

  • Supports a wide range of chains (Ethereum, Solana, BSC, Polygon, Avalanche, Arbitrum, Optimism, Base, Fantom, etc.).

  • Pros: High security (VAA verification), wide chain support, decentralized guardian network.

  • Cons: More complex flow (requires fetching VAA, submitting it on target chain), potentially higher latency than a direct relay.

  • Use Case: Production applications requiring robust security and broad interoperability.

How it Works in JuliaOS

1. Initiation: A user (via CLI) or application (via JS/TS/Python API) requests a cross-chain transfer, specifying source/target chains, token, amount, and addresses.

2. Backend Call: The request is typically routed to the Julia backend via the Bridge.jl module (e.g., bridges.wormhole.transfer command).

3. Bridge Package Execution: The Julia backend likely delegates the core bridge logic to the corresponding Node.js package (@juliaos/bridges/wormhole or @juliaos/bridges/relay - assumed names).

   • The Node.js package interacts with the source chain contract to lock/burn assets.

   • It then waits for the necessary confirmation/attestation (e.g., waits for relayer action, or waits for Wormhole VAA).

   • For Wormhole, it may provide functions to fetch the VAA.

4. Completion:

   • Relay: The relayer submits the transaction on the target chain.

   • Wormhole: The user/application needs to fetch the VAA (using a bridge function) and submit it to the Wormhole contract on the target chain to release/mint assets.

5. Status Tracking: Functions are provided to check the status of the transfer (e.g., getStatus, getVAA).

Using Bridges

• CLI: The Cross-Chain (CLI) guide details user interaction.

• Programmatic (JS/TS): Use the specific bridge classes (RelayBridge, WormholeBridge) from the @juliaos/bridges package. See Node.js API.

• Programmatic (Python): Functionality might be exposed via the JuliaOS client, potentially calling backend bridge commands.

See also: Adding New Bridges