Execute Contract

In a cross-chain bridge, the executor contract (Executor) plays a crucial role. The executor contract for token cross-chain mainly provides two core methods for users to call:

  1. bridge_proposal: Cross-Chain Proposal

  2. bridge_finish: Cross-Chain Completion (Optional)

1. Cross-Chain Proposal Contract Interface

1.1. On the Endless chain, the interface for sending a cross-chain proposal is defined as follows:

public entry fun bridge_proposal(
        sender: &signer,
        source_token: address,
        to_chain: vector<u8>,
        to_contract: vector<u8>,
        to_who: vector<u8>,
        all_amount: u128,
        upload_gas_fee: u128
    )

public entry fun bridge_proposal_with_extra_data(
        sender: &signer,
        source_token: address,
        to_chain: vector<u8>,
        to_contract: vector<u8>,
        to_who: vector<u8>,
        all_amount: u128,
        upload_gas_fee: u128,
        extra_data: vector<u8>
    )

1.1.1. Parameter Description

  1. sender: &signer - A reference to the signer of the message. Used to verify the sender’s identity and permissions, and to pay the gas fee.

  2. source_token: address - The address of the token to be bridged across chains.

  3. to_chain: vector<u8> - The identifier of the target chain, represented as a byte vector.

  4. to_contract: vector<u8> - The target contract address on the destination chain, represented as a byte vector.

  5. to_who: vector<u8> - The recipient address on the destination chain, represented as a byte vector.

  6. all_amount: u128 - The total amount of tokens to be bridged, represented as an unsigned 128-bit integer.

  7. upload_gas_fee: u128 - The gas fee required to send the message, represented as an unsigned 128-bit integer.

  8. extra_data: vector<u8> - Additional data beyond the basic 128-bit structure, used for extensibility and advanced features. Represented as a byte vector.

1.2. The cross-chain proposal method and ABI on Sepolia, BSC, and Nile networks are as follows:

1.2.1. Parameter Description

  1. source_token:The token to be bridged across chains.

  2. to_chain:Information about the target chain.

  3. to_who:The recipient address on the target chain.

  4. receiver:The execution contract address on the target chain.

  5. all_amount:The amount of tokens to bridge.

  6. upload_gas_fee:

    • The gas fee required on the target chain (can be estimated before the cross-chain operation).

1.3. Cross-Chain Proposal Method Definition and IDL on Solana Chain

1.3.1. Parameter Description

  1. ctx: Context<Proposal> The context object containing all information related to the current transaction, including account states and permissions. This parameter ensures that the function executes within the correct context.

  2. to_chain: Chain An enum type representing the destination chain. Specifies which blockchain network the proposal is being sent to (e.g., Ethereum, Binance Smart Chain, etc.).

  3. _to_token: [u8; 32] A 32-byte array representing the target token. This parameter defines the token type to be bridged on the destination chain.

  4. to_who: [u8; 32] A 32-byte array representing the recipient address on the target chain. This specifies the address that will receive the bridged assets.

  5. all_amount: u64 An unsigned 64-bit integer representing the total amount of tokens to bridge. Indicates the number of assets the user intends to transfer.

  6. upload_gas_fee: u64 An unsigned 64-bit integer representing the upload fee. This is the amount the sender must pay to submit the proposal, ensuring they have sufficient balance to proceed.

2. Cross-Chain Completion Contract Interface

2.1. The cross-chain completion interface is defined as follows on the Endless chain:

2.1.1. Parameter Description

  1. sender:The on-chain sender, representing the originator of the message.

  2. msg_header:The message header, containing the header information of the message.

  3. msg_body:The message body, containing the main content of the message.

  4. multisig:The result of the BLS aggregated signature.

  5. pks:The indexes of public keys used to generate the aggregated signature.

2.2. The message consumption method and ABI on Sepolia, BSC, and Nile chains are defined as follows:

2.2.1. Parameter Description

  1. message:(Type: Types.Message) Structure

    • msg_header:Message header, of type Types.MessageHeader

    • msg_type:Message type (uint8)

    • nonce:Message sequence number (uint64)

    • from_chain:Source chain information (Types.Chain)

      1. chain_type:Chain type (uint8)

      2. chain_id:Chain ID (uint64)

    • sender:Sender address (bytes32)

    • to_chain:Destination chain information (Types.Chain)

      1. chain_type:Chain type (uint8)

      2. chain_id:Chain ID (uint64)

    • receiver:Receiver address (bytes32)

    • upload_gas_fee:Upload gas fee (uint128)

    • msg_body:Message body (bytes)

  2. signature:Array of message signatures (bytes[])

2.3. The cross-chain completion method definition and IDL on the Solana chain are as follows:

2.3.1. Parameter Description

  1. ctx: Context<Consumption> The context object containing all information related to the current transaction, including account states and permissions. This parameter ensures the function executes within the correct context.

  2. msg_header: MsgHeader The message header struct containing metadata about the message, such as sender address, timestamp, message type, etc. This provides the basic information of the message.

  3. msg_body: MsgBody The message body struct containing the actual data to be confirmed. This can be any type of data, e.g., transaction details or instructions.

  4. _accum_pk: Vec<u8> A byte vector representing the aggregated public keys, usually used to verify the message signature. This parameter may contain multiple public keys to ensure message authenticity.

  5. signatures: Vec<[u8; 65]> A vector of signature byte arrays, each 65 bytes long. This stores signatures for the message, used to verify the message’s origin and integrity.

Last updated