Bridge

Bridge

This page explains how to bridge the Branded Stablecoins from one chain to another to a specified recipient address.

Note that this functionality does not limit the Branded Stablecoins from being bridged via third party bridging providers. The vault tokens can be bridged just like any other ERC20 tokens if a third party bridge supports it. However, the vault tokens have a native bridging capability on supported chains with a reduced cost.

Transaction Flow

1. Wallet A has some balance of the BoringVault token on chain A.

2. In order to bridge the BoringVault token from chain A to chain B, Wallet A must call Teller.bridge(...) function.

   1. The bridge function is payable, meaning it must be called with an accompanying value field to send the native coin of the blockchain as a bridge fee payment.

   2. To determine how much value to send in this transaction, use the Teller.previewFee function, which has an identical interface to the bridge function.

3. Take the uint256 fee return value from the previewFee query, then send the fee as the value field of the transaction when calling bridge.

4. Once the Teller.bridge(...) function succeeds, the BoringVault token will arrive at chain B after some delay, depending on which cross chain messaging protocol is being used for the implementation.

Functions

struct BridgeData {
    uint32 chainSelector;
    address destinationChainReceiver;
    ERC20 bridgeFeeToken;
    uint64 messageGas;
    bytes data;
}

function previewFee(
    uint256 shareAmount, 
    BridgeData calldata data
    ) external view returns (uint256 fee) {
    return _quote(shareAmount, data);
}

function bridge {
   uint256 shareAmount,
   BridgeData calldata data
} public payable requiresAuth returns (bytes32 messageId)

• shareAmount

  • The amount of BoringVault tokens you wish to bridge.

• BridgeData data

  • chainSelector

    • Identifier of the chain, but note that this is not equivalent to a chainId. This identifier depends on what crosschain bridging protocol is being used for the BoringVault token.

    • For LayerZero implementation, the chainSelector must use LayerZero Endpoint IDs.

    • For Hyperlane implementation, the chainSelector must use Hyperlane Domain Identifiers.

  • destinationChainReceiver

    • The address that will receive the bridged funds.

  • bridgeFeeToken

    • The token you are using to pay the bridging fee.

    • Must be 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE in order to indicate that the native token of the chain is being used to pay the bridging fees.

  • messageGas

    • The gas limit enforced upon the transaction that lands on the destination chain. This should be between 300K to 500K gas for most usecases.

  • data

    • Can be arbitrary data, but should be empty bytes "" for most usecases. Exists for potential future backwards compatibility with the receiving function on the destination contract.

See Example Code