Swaps via Vault smart contract

Overview

The Vault smart contract, besides holding assets, acts as an entry point for starting a swap without requiring a deposit address. Furthermore, for cross-chain messaging swaps, the Vault will call the destination address with a particular function signature.

Simple swap

To make a swap the user needs to call swap on the Vault of the source chain, specifying the parameters described in the table below. In the case of swapping ERC-20 tokens an approval is required.

    // Swap native token
    function xSwapNative(
        uint32 dstChain,
        bytes calldata dstAddress,
        uint32 dstToken,
        bytes calldata cfParameters
    ) external payable;
 
    // Swap ERC20 token
    function xSwapToken(
        uint32 dstChain,
        bytes calldata dstAddress,
        uint32 dstToken,
        IERC20 srcToken,
        uint256 amount,
        bytes calldata cfParameters
    ) external;

Swap + call a receiver with cross-chain messaging

Chainflip supports cross-chain messaging, calling a smart contract on the destination chain and passing a message between chains. The smart contract call looks very similar to the previous ones but with some added parameters.

For more information see Cross-Chain Messaging. The swap could have originated in any supported chain, irrespective of whether the chain supports smart contracts.

    // Swap native token
    function xCallNative(
        uint32 dstChain,
        bytes calldata dstAddress,
        uint32 dstToken,
        bytes calldata message,
        uint256 gasAmount,
        bytes calldata cfParameters
    ) external payable;
 
    // Swap ERC20 token
    function xCallToken(
        uint32 dstChain,
        bytes calldata dstAddress,
        uint32 dstToken,
        bytes calldata message,
        uint256 gasAmount,
        IERC20 srcToken,
        uint256 amount,
        bytes calldata cfParameters
    ) external;

Receive a destination asset + call a receiver

Chainflip's Vault will transfer the destination token amount to the specified address either within the same call (for native token) or by transfering the ERC20 token to it. Then it will call the destination address with the following parameters:

In order for a contract to be a valid receiver it must implement the Solidity function signature below on the destination address.

function cfReceive(
    uint32 srcChain,
    bytes calldata srcAddress,
    bytes calldata message,
    address token,
    uint256 amount
) external payable;

It's the receiver's responsability to correctly implement the function's interface and to ensure the call doesn't revert. If the receiver can't garantee that the receiving logic won't revert, it is recommended to use try/catch-like structure to handle the reversion. This is to avoid the full transaction reverting and therefore the tokens failing to be transferred.

Here is an example of the function with the adequate access control:

contract CFReceiver {
 
    function cfReceive(
        uint32 srcChain,
        bytes calldata srcAddress,
        bytes calldata message,
        address token,
        uint256 amount
    ) external payable {
        require(msg.sender == cfVault, "CFReceiver: caller not CF Vault");
    }
 
    ...
}

You can find an example of a receiver contract that can be inherited here (opens in a new tab).

Chain and Asset Notation

Chainflip uses it's own notation for chain and token within the the smart contracts. These are the values for the source and destination chains and assets parameters described above. The same values apply for the the corresponding testnets (e.g. Ethereum mainnet and Sepolia share the same value).

Supported Assets

Supported Chains