XCM support in Smart Contracts

TODO: Add scenarios?

I'm diving this into three parts: Tokens, Queries and Fees.

Tokens

In order to operate with ERC20 tokens, a user needs to call specific functions in its origin smart contract, for example, for transferring it.
In XCM, assets are operated upon by means of the TransactAsset trait.
In order for XCM to recognize we are dealing with an ERC20, we would need to create an asset transactor to handle them.

This asset transactor has to match ERC20s based on their id. A possible one is the following: [PalletInstance(<pallet-revive index>), AccountKey20 { id }] where id is the contract's address.
Then, different XCM instructions need to call functions in the contract, like TransferAsset, DepositAsset and WithdrawAsset.

TransferAsset would call transfer.
With WithdrawAsset and DepositAsset we could call something like burn and mint respectively or we could transfer to a checking account.

Acala has one for this purpose which we could use as a reference.

We probably need the same for ERC721 but I'm less familiar with that standard.
We could make use of the traits for NFTs.

Queries

This could be further split into receiving and sending.

Sending

In order to send a query we need a host function for contracts that calls pallet-xcm's new_query function to store a Query.

Scenarios

Both scenarios assume that a new query is created using the XCM precompile. Then, an XCM message (e.g.: Xcm(vec![Transact {...}, ReportTransactStatus(QueryResponseInfo {queryId …}])) should be sent to the destination chain, essentially linking a queryId to some bytes that are meant to be executed.

Perform a remote call and get the result of the execution

We need to have a way of getting the result of the execution of a remote call. This should return a response with the result. In case of failing, the response should contain the actual error.

Query external data / Call view functions

Allow the smart contracts on Asset Hub to query data on external consensus systems. This might be a call to a specific pallet or a view function in a smart contract. We should be able to send PVQ blobs using the new ReportQuery instruction.

Receiving

A message is received by the runtime to respond to a query with some query id.
This will match the query id of the query created previously.

We need a host function in contracts that calls pallet-xcm's take_response to poll for the response, this could result in an callback, which could be handled by a function in the contract.

Fees

Pallet-revive charges an additional fee for storage deposits.
We can use the new fees register to charge this fee.
We need some place to charge them, be it in CallDispatcher for Transact or in the new instruction EvmCall if we decide to go for it.

The EvmCall instruction would be easier since we already know we have to deal with these storage deposits.

The fees register can also be exposed to the transactor to charge storage deposits.

Storage deposits need to be charged in this way, but regular gas cost could be charged up-front with PayFees, as part of execution costs.
An open question I have is if we should separate them or treat them in the same way.

We would need to make sure the DryRunApi can successfully dry-run a program with EVM calls.
We already have calls for execution fees and delivery fees in XcmPaymentApi. Do we just add another one for EVM storage deposits?

Should we just have a more powerful DryRunApi that returns all fees: execution, delivery, EVM storage deposits, etc.

athei

2025/02/20 16:49:44

We need to create an asset transactor for ERC20s like the one https://github.com/AcalaNetwork/Acala/blob/0cec34dc23720a29fc0460f5c09da5e57fdd624b/modules/currencies/src/lib.rs#L432 Acala has https://github.com/open-web3-stack/open-runtime-module-library/blob/bbb326ff02d6aa1792eab4cda30125e86f130c75/xcm-support/src/currency_adapter.rs#L148. We probably need the same for ERC721 but I'm less familiar with that standard. We could make use of the traits for NFTs https://github.com/paritytech/polkadot-sdk/pull/5620.

I don't understand how this is related to contracts. Can you add some explanation? I lack the context to understand.

Francisco Aguirre

2025/02/20 18:14:08

I added a bit more context. We basically need this transactor to call functions of the contract when some XCM instructions get executed

2025/02/20 16:52:43

An open question I have is if we should separate them or treat them in the same way.

Both are charged from the origin of an transaction. Both are transferred away from the origin. So if it makes things easier I suggest to treat them the same. There is also the thing to consider that as of right now we always charge the storage deposits as the chains `Currency`. So this code has to be refactored if we want to allow using other assets as well.

2025/02/20 18:15:57

I saw this: https://github.com/paritytech/polkadot-sdk/blob/b9b73eb2758edc8af140fea60fdc51f890eefc48/substrate/frame/revive/src/storage/meter.rs#L56 which was meant for tests but it decouples taking the storage deposit fee from the account. Is that right? If that's the case, we could maybe use it for charging it with the funds in the XCM program. (Edited)

2025/02/21 09:16:16

Yes it abstracts the actual interaction with the `Currency` away. Used for testing only as of right now. I guess we can provide another impl there that charges the amount differently.

2025/02/21 09:13:13

This asset transactor has to match ERC20s based on their id. A possible one is the following: [PalletInstance(<pallet-revive index>), AccountKey20 { id }] where id is the contract's address.

This is necessary even if those are emulated ERC20s which in reality are just assets on pallet_assert, right? Because people might want to address them via pallet_revive and not via pallet_asset?

2025/02/21 13:38:50

If people reference them via their contract address then we would use this transactor. Although it's better if they could just reference them via their "canonical" id, which is `[PalletInstance(50), GeneralIndex(whatever)]`. I think we could still do that. In a smart contract you transfer pallet-asset assets as if you were calling another contract, but you don't need to do anything XCM-related. Then, if another chain wants to send some USDT for example to a contract on the Hub they would reference it as usual.

2025/02/28 16:37:08

With WithdrawAsset and DepositAsset we could call something like burn and mint respectively or we could transfer to a checking account.

@athei Is there a way to have these functions `mint` and `burn` only be callable from the Runtime? If not then we can transfer to a checking account

Alberto Gallini

2025/03/25 09:30:48

Expanding on the use cases, I see blockchains as services that offer both data (like a secure, decentralized database) and computation (through smart contracts), using data from their own state or external sources. XCM should be the standard for on-chain communication, letting dApps securely use services from other chains (like digital identity, AI data, or social media data ... ). I think we should focus on these three main use cases: 1.Reading data from another blockchain service. 2.Writing data to another blockchain. 3. Exchanging fungible and non-fungible tokens. 'new_query' and 'take_response' need to handle all of these. Because the communication is loosely coupled, we don't have a session context. But polling should ensure the asynchronous communication happens within a timeout, or fail to guarantee a certain SLA, and allow for error handling.

XCM support in Smart Contracts

Tokens

Queries

Sending

Scenarios

Perform a remote call and get the result of the execution

Query external data / Call view functions

Receiving

Fees

Read more

DOT as Universal Fee Token

Upgrading a parachain in chopsticks

Changing the DOT reserve from the Relay Chain to Asset Hub

XCM fee estimation