xERC20
Process Overview
The XERC20 open token standard for a multi-chain ERC20 which can be transferred across chains with no slippage and without compromising security. Token issuers can control the chains their token is deployed to and set rate limits on a per-bridge basis - making the token natively multichain without compromises.
The process of setting up XERC20 infrastructure can be found in this guide; token issuers should contact our team once they would like their XERC20 to be supported by Everclear and provide a list of chains they would like to be supported (where the XERC20 token exists).
XERC20
bridging should only be used once:
XERC20 infrastructure deployed by the token issuer
XERC20 token approved on the Hub
XERC20 token status stored on Spokes (as per request from token issuer)
The process of bridging an XERC20 with the Spoke is as follows:
User approves the Spoke contract to pull
XERC20
from walletUser calls
newIntent
, funds are pulled from wallet to Spoke contract, and tokens are burned via theXERC20Module
Intents are transported from Spoke to clearing chain periodically when the queue size is more than a threshold of items or the oldest item in the queue is more than threshold of minutes
Clearing chain receives intent and adds to the invoice queue if it’s the only intent for the xERC20 tickerHash on Hub OR adds the intent to the deposit queue
Invoice and deposit queues are processed every epoch. As the
XERC20
does not need to be matched with another invoice, a settlement is automatically created and added to the settlement queueThe settlement queue is processed on the Hub and transported to the Spoke contract when the queue size is more than a threshold of item or the oldest item in the queue is more than threshold of minutes
Spoke contract receives SettlementMessage’s and calls the
XERC20Module
contract to mint tokens to the recipient
If the minting limit has been reached, the XERC20Module
will store the amount and recipient. The tokens can be minted when the limit resets by calling mintDebt
.
Creating an xERC20 Intent
As a user, you will need to interact with the Spoke contract on the origin domain to create a new intent that will be processed by the netting system.
newIntent
called on Spoke
contract
newIntent
called on Spoke
contractThe entry point to bridge an XERC20 is newIntent on the Spoke contract of the origin domain. The destinations
field can be defined as a single item or an array - the Hub will select the first supported domain to bridge to so we recommend solely providing a supported domain.
The maxFee
must be set to 0 as maxFee
is not applicable to the XERC20 order type. The ttl
must be set to 0 to indicate the order should be routed via the native XERC20 route.
When the Spoke
contract completes the newIntent
call, the intent will be added to the intentQueue
, and periodically sent to the Hub
contract on the clearing chain - depending on the configuration of the max queue size and age for the origin domain.
An intent can be created by interacting directly with the contract. The following is a simple example sending 100 xTOKEN via the XERC20 route from Sepolia Testnet to BNB Testnet.
Domain Ids will correspond to standard chain Ids.
Monitoring Intents
The status of an intent can be fetched from the Subgraph which will update the intent on each domain as they are being processed. Token issuers should be able to query the Subgraph using the intentId
to monitor the progress it has made through the system whilst users bridging via the UI will be able to find all of the required information there.
For token issuers, intents created on the Spoke
contract will be added to the origin domain Subgraph as an OriginIntent
entity. The status of the processing on the hub domain will be added to the Subgraph as a HubIntent
entity. The settlement of the intent will be added to the destination domain Subgraph under IntentSettleEvent
entity.
There are 3 statuses used for OriginIntent
entities:
NONE: does not exist
ADDED: signifies added to the message queue
DISPATCHED: signifies the batch containing the message has been sent
There are 9 statuses used for HubIntent
entities:
NONE: does not exist
ADDED: intent has been added to the Hub
DEPOSIT_PROCESSED: has been added to the depositQueue
FILLED: deposit has purchased an invoice in the queue
COMPLETED: has been added to settlement queue on Hub
INVOICED: has been added to the invoiceQueue
SETTLED: settlement has been sent from Hub to Spoke
UNSUPPORTED: the asset is not supported on the origin/destination domains or the wrong output asset has been provided
UNSUPPORTED_RETURNED: the unsupported intent has been returned to the origin domain
The existence of the IntentSettleEvent
entity for an intentId implies it has been settled on the destination domain.
1 - Monitoring intent status
The Subgraph can be queried on the origin domain to pull information about the intent using the intentId
; Id will remain the same across the domains. Schema for OriginIntent
:
For example, if the origin domain Subgraph was being queried to fetch the status of an intent, it could be constructed as follows using its intentId
:
2 - Monitoring purchase status
The Subgraph on the hub domain can be queried to pull information about the intent’s processing status using the intentId
. Schema for HubIntent
:
For example, if the hub domain Subgraph was queried to fetch the status of the intent, it could be constructed as follows using its intentId
:
3 - Monitoring settlement status
The Subgraph on the destination domain can be queried to pull information about the settlement using the intentId
. Schema for IntentSettledEvent
:
For example, if the destination domain Subgraph was queried to fetch the status of the settlement, it could be constructed as follows using its intentId
:
Last updated