Counter
smart contract residing in one chain, where the integer property (counter
) is stored and can be incremented by a call initiated by and only by the Incrementor
contract from another chain. In other words, when we perform some action against the Incrementor
contract, it initiates a cross-chain transaction (a submission, in terms of the deBridge protocol) which is being started on one chain, relayed to, and then executed on another chain; during this cross-chain transaction, a Counter
contract is called. The following image presents a high-level overview of a cross-chain transaction we are going to achieve:debridge-finance/debridge-cross-chain-dapp-example.git
.Counter
contractdeBridgeGate
smart contract only, and second, this call should occur only during the cross-chain transaction originating from the Incrementor
smart contract at the specific address on another chain. How can this be achieved?nativeSender
) - i.e. an entity that actually initiated the transaction by calling the deBridgeGate
contract on the origin chain. When the cross-chain transaction is being relayed, the deBridgeGate
contract on the destination chain temporarily exposes the state of the transaction it currently handles via its properties and then calls a target smart contract (whose address is also a part of a payload) through its helper intermediary. It means that the contract on the target address may access this data.Counter
must know the deBridgeGate
contract's address on the current chain, so it is reasonable to inject it via a constructor:receiveIncrementCommand
method using a modifier. The first obvious check we must perform is to ensure this method is called by the deBridgeGate
's helper intermediary - a CallProxy
contract responsible for performing actual calls (the deBridgeGate
contract doesn't make calls directly for security considerations):deBridgeGate
handles some cross-chain transactions relayed from another chain.Counter
contract, for example like this:trustedCrossChainCaller
is defined as bytes
rather than the address
): this happens because the deBridgeGate
smart contract stores the byte representation of the native sender address to ensure future compatibility with non-EVM chains (e.g. Solana).Incrementor
contract and get its address, we may let the Counter
contract know about it by calling the addChainSupport
method.Counter
contract starts storing the caller's address, the cross-chain transaction is allowed to originate from, we may reuse this data and add the additional validation logic to the modifier:receiveIncrementCommand
method, it becomes properly protected from unauthorized calls and ready to receive commands from the trusted contract on another chain:Incrementor
contractCounter
contract and know its interface, we may design the Incrementor
contract, which is responsible for initiating the cross-chain call to Counter
's receiveIncrementCommand()
. First things first, we must let the Incrementor
know where the Counter
contract actually resides, so we inject it with the chain ID and address of the Counter
contract, and we also specify the address of the deBridgeGate
contract as well:Incrementor
, so let its interface be as simple as follows:deBridgeGate
's send()
method β the only entry point to initiate a transaction. It accepts plenty of non-trivial variables and structs. Let's overview all of them to make our submission happen.send()
method is marked as payable (meaning that it accepts ether during a call) and it is necessary to bypass enough ether to cover the protocol fee (or global fixed native fee, according to the internal definition) taken in the native currency of the chain. How much? deBridge tries to stick to around one dollar fee, so the fee varies from chain to chain: for example, at the time of writing the fee on Ethereum is 0.001 ETH and the fee on Polygon is 0.5 MATIC. You are advised to retrieve the actual fee amount by reading deBridgeGate
's globalFixedNativeFee
property either on-chain:SubmissionAutoParamsTo
struct (see its definition), so it is important to understand each.executionFee
(or included gas) is the amount of the bridged tokens you are allowing the deBridgeGate
to give as an incentive to a third party in return for successful claim transaction execution on the destination chain. In other words, this is a prepayment for potential gas expenses on the target chain, that will be transferred by the protocol. DeBridge runs its own Claimer service (as a part of the deBridge infrastructure), but in fact, anyone can run such service on its own without any security implications, because executionFee
distribution is a part of the protocol smart contract. This is an advanced topic that runs out of scope of this document, so for the sake of simplicity just set this value to zero.flags
is a bitmask of toggles affecting the behavior of the gate. The following flags are important to be set in our case:REVERT_IF_EXTERNAL_FAIL
tells the CallProxy
to revert the whole claim transaction in case the call to the receiver address (the callee contract on the destination chain; it is the Counter
contract in our case) fails. Select the proper behavior wisely, ensuring it is aligned with the design of the callee contract: for example, the contract may fail deliberately and irretrievably so it may be reasonable to handle this call gracefully and mark the whole cross-chain transaction as succeeded. Keep in mind that once the claim transaction succeeds it submissionId
is marked as used, so you cannot replay the transaction on the destination chain.PROXY_WITH_SENDER
tells the CallProxy
to expose the address that initiated the cross-chain transaction (submission) on the origin chain. Again, choose wisely: as for our case, the Counter
contract expects this data, so we need to ensure it's presented on the destination chain.fallbackAddress
is the address on the destination chain where the bridged funds will be transferred to in case the call to the receiver address fails AND REVERT_IF_EXTERNAL_FAIL
is not set. Since we don't bridge any funds (only the calldata), this field is not very important though it is mandatory to set it. Mind that this address must be packed into bytes.data
is the field for the calldata
to execute on the destination chain. Not a big deal if the contracts reside on different chains: we can encode the call using the interface of the contract to call. In our case, we can import the interface of the Counter
(ICrossChainCounter
) and use it with the encodeWithSelector
to produce valid instructions aligned with the interface of Counter
's receiveIncrementCommand
method:autoParams
struct with settings that suit our needs:autoParams
struct either on-chain (as in the example above) or off-chain using ethers.js or web3.js.send()
argssend()
method._tokenAddress
is the address of the ERC-20 token contract whose tokens you are willing to bridge additionally along with the calldata
. If you are willing to bridge the native currency (e.g. ETH from Ethereum), use the zero address (address(0)
)._amount
is the amount of tokens (of the contract specified in the first arg) you are willing to bridge. Dealing with bridged assets is an advanced topic which out of the scope of this document, so in this example, it is enough to set this arg to zero. The following things are worth mentioning: first, the gate cuts a small 0.1% fee off the bridged asset; second, if you bridge the native currency of the origin blockchain, you must not forget to supply an additional amount to cover the protocol fee, but not include it in this arg value; third, the aforementioned executionFee
(included gas) is counted in the currency of this bridged asset, so its decimals must be in sync with this asset; fourth, ERC-20 tokens should not be transferred in/out explicitly, use allowance and safeTransferFrom
instead._chainIdTo
sets the destination chain ID. Consider looking at chainlist.org for known chain IDs, see the list of supported chains in our docs, or query deBridgeGate.getChainToConfig
on-chain property for programmatic access to the list of chains supported by deBridge._receiver
defines the address on the destination chain to receive bridged assets (if any) and be called by the CallProxy
contract in case the call data is given. In the given example, we must set this arg to the address of the Counter
smart contract._permit
allows the caller to specify EIP-2612-compliant signed approval for the deBridgeGate
contract to transfer the tokens specified in the first arg. Not applicable here._useAssetFee
allows paying the protocol fee in the currency of the asset being bridged rather than the native currency of the blockchain. Not applicable here._referralCode
is used to mark the submission with your own code, which will be used later._autoParams
is the encoded autoParams
struct we've crafted in the previous chapter._chainIdTo
, _receiver
and _autoParams
. The snippet that actually makes a call to the deBridgeGate
contract may look like this:deBridgeGate
is made within a blockchain, the cross-chain transaction is being initiated.Incrementor
in our case) submits a new cross-chain call, the deBridgeGate
contract emits a Sent
event containing all necessary details about the cross-chain call, including the submissionId
β the global cross-chain identifier of such a call. The submissionId
is the important thing to identify our submission, so we must capture it either by parsing the event manually or using deSDK which does this action for us:deBridgeGate.claim()
method on the destination chain must be crafted using the data from taken from various sources, which isn't an easy task, so there is deSDK which takes the burden of data preparation:deBridgeGate.claim()
method, and finally sign and broadcast your transaction and wait for the Claimed
event. This will indicate a successful submission completion.REVERT_IF_EXTERNAL_FAIL
flag. We recommend using professional transaction simulation services (offered by Tenderly or Blocknative) rather than calling your RPC's eth_estimateGas
endpoint.debridge-hardhat
plugin for Hardhat to test your contracts on the emulated environment