Detailed Instructions

The process begins when a user, such as Alice, calls a specific function on a cross-chain bridge smart contract deployed on the source chain (e.g., Ethereum). This function, often named lock or deposit, takes the asset to be transferred and a destination address as parameters. The contract securely locks or burns the original assets, preventing double-spending. For fungible tokens, this typically involves transferring the tokens to the bridge's escrow contract. The contract then emits a standardized event log containing the transaction details, which acts as the cryptographic proof for the next step.

• Sub-step 1: Alice approves the bridge contract (address: 0x1234...) to spend 10 ETH on her behalf using the approve function.
• Sub-step 2: Alice calls bridge.lock(10, "0x5678...", "avalanche"), specifying amount, destination address, and target chain.
• Sub-step 3: The Ethereum smart contract locks the 10 ETH and emits a Locked event with a unique depositId (e.g., 0xabcd1234...).

Tip: Always verify the official contract address for the bridge to avoid interacting with malicious clones. The event log is immutable and serves as the single source of truth for relayers.

Detailed Instructions

Off-chain relayers (which can be permissionless nodes or a permissioned federation) continuously monitor the source chain's event logs via RPC nodes. When a relayer detects the specific Locked event from the bridge contract, it must generate a cryptographic proof of the transaction's inclusion and validity. For Ethereum-based chains, this is typically a Merkle Proof demonstrating the event log is part of a block that was finalized. The relayer packages this proof along with the event data into a structured message. The exact proof mechanism varies; some bridges use light client proofs that verify block headers, while others rely on simpler multi-signature attestations from a committee of relayers.

• Sub-step 1: A relayer node queries the Ethereum RPC endpoint for new logs from the bridge contract address using a filter.
• Sub-step 2: Upon finding the log, it fetches the block header and constructs a Merkle proof via eth_getProof.
• Sub-step 3: The relayer serializes the proof and event data into a payload, often signing it with its private key for accountability.

codeCopy
// Example payload structure a relayer might prepare
{
  "depositId": "0xabcd1234...",
  "sender": "0xAlice...",
  "amount": "10000000000000000000",
  "destinationChain": "avalanche",
  "recipient": "0x5678...",
  "blockNumber": 19283746,
  "merkleProof": ["0xhash1", "0xhash2", ...],
  "relayerSignature": "0xsig..."
}

Tip: The security of the entire bridge hinges on the integrity and decentralization of the relayer network. A malicious majority can forge proofs.

Detailed Instructions

The relayer now submits the packaged payload to the counterpart bridge contract on the destination chain (e.g., Avalanche). This contract contains the verification logic. For a Merkle proof, it will verify that the event log is indeed part of a block that is considered final on the source chain. This often involves checking a light client state stored on-chain, which holds the canonical block headers of the source chain. If using a multi-signature scheme, the contract checks that a sufficient threshold of trusted signatures from the relayer set approves the payload. Only after successful verification does the contract mark the transaction as valid and ready for minting. Failed verifications revert the transaction, costing the relayer gas.

• Sub-step 1: The relayer calls destBridge.verifyAndExecute(payload) on Avalanche, paying the gas fee in AVAX.
• Sub-step 2: The contract's verify function reconstructs the Merkle tree root from the proof and compares it to the stored block header root for block 19283746.
• Sub-step 3: It also checks that the block is old enough (has sufficient confirmations, e.g., 15 blocks) to prevent chain reorganization issues.

Tip: The gas cost for this step is usually borne by the relayer, who is later reimbursed via fees embedded in the user's initial transaction or via a reward system.

Detailed Instructions

After the proof is verified, the bridge contract on the destination chain executes the final step: minting an equivalent representation of the asset for the recipient. If the source asset was locked, the destination contract mints a wrapped token (e.g., wETH on Avalanche). If the source asset was burned (common for native tokens), the destination contract mints the native equivalent. The contract logic ensures the amount matches exactly what was locked and that the same depositId cannot be used twice (preventing replay attacks). Finally, the tokens are transferred to the recipient's specified address, completing the cross-chain transaction. The entire state is recorded on-chain, providing transparency.

• Sub-step 1: The contract's execute function mints 10 wETH (contract: 0xavaxWeth...) by calling wETH.mint(recipient, amount).
• Sub-step 2: It updates an internal mapping processedDeposits[depositId] = true to prevent reuse.
• Sub-step 3: It emits a Minted event, allowing the recipient's wallet or indexer to detect the completion.

codeCopy
// Simplified contract logic snippet
function verifyAndExecute(Payload calldata _payload) external {
  require(!processedDeposits[_payload.depositId], "Already processed");
  require(verifyMerkleProof(_payload), "Invalid proof");
  processedDeposits[_payload.depositId] = true;
  IWrappedToken(wrappedTokenAddr).mint(_payload.recipient, _payload.amount);
  emit Minted(_payload.depositId, _payload.recipient, _payload.amount);
}

Tip: The recipient should always verify the token contract address on the destination chain. Wrapped assets are IOU representations and their value depends on the security and solvency of the bridge.