Cardano scripts for XPort crosschain.
This repository contains the scripts for implementing the XPort cross-chain protocol on the Cardano blockchain. XPort is a protocol used for transmitting messages between Cardano and various other blockchains, such as Ethereum, etc. The contracts description is here
When third-party applications integrate XPort, the following rules must be followed:
Third-party applications need to follow the message format defined by the XPort protocol as follows
data CrossMsgData = CrossMsgData
{
taskId :: BuiltinByteString
, sourceChainId :: Integer
, sourceContract :: MsgAddress
, targetChainId :: Integer
, targetContract :: MsgAddress
, gasLimit :: Integer
, functionCallData :: FunctionCallData
}deriving (Show, Prelude.Eq)
data MsgAddress = ForeignAddress BuiltinByteString | LocalAddress Address deriving (Show, Prelude.Eq)
data FunctionCallData = FunctionCallData
{
functionName :: BuiltinByteString
, functionArgs :: BuiltinByteString
}deriving (Show, Prelude.Eq)- taskId:Unique identifier for the message. Note that for outbound TX scenario, the taskId is a fixed empty string, and the final value will be generated based on the outbound Tx hash by offchain agent.
- sourceChainId:The source blockchain id of the message.
- sourceContract:The contract address of the initiator of the message.
- targetChainId:The destination blockchain id of the message.
- targetContract:The contract address of the destination of this message.
- gasLimit: The upper limit of gas required for the message to be executed on the target chain. Note that for inbound TX scenario, it has no meaning.
- functionCallData:Message execution parameters,including:
- functionName:The name of the function that executes the message on the target chain, encoded in ascii. Note that it is fixed string of wmbReceive.
- functionArgs:The parameters of the calling function, encoded in cbor. Note that Note that it is content is business specific and DApp can customize it accordingly.
The Xport system will mint an InboundToken to the address of the third-party contract (targetContract, as DAppIn) specified in the message.
The InBound TX structure will basically contain:
- Token MintFlag with InBoundToken, where the token name must be the scriptHash of the targetcontract addresst.
- Input CheckToken@InBoundMintCheck, which ensures the storeman MPC proof check.
- Output InBoundToken@DAppIn with CrossMsgData datum.
This InBoundToken@DAppIn shall be consumed by targetContract/DAppIn and burnt for business execution.
The third-party application (sourceContract, as DAppOut) will mint an OutboundToken for message crosschain.
The OutBound TX structure will basically contain:
- Token Mint Flag with OutBoundToken, where the mint policy shall check that input UTXO@DAppOut matches output OutBoundToken@XPort.
- Input UTXO@DAppOut, which ensure correct output OutBoundToken@XPort.
- Output OutBoundToken@XPort with CrossMsgData datum.
- To match codec between Cardano and EVM, the functionArgs shall be encoded with CBOR and its EVM peer shall encode/decode CBOR accordingly.
- To support concurrency, the functionArgs can contain a array of multiple messages as business intent.
- Based on the demo contract in the msg-demo, the following figure illustrates Inbound Tx and Outbound Tx
For XPort crosschain in EVM, you can check EVM XPort accordingly.
https://github.com/wanchain/message-bridge-contracts/blob/feat/non-evm/contracts/WmbGateway.sol