Glacis Cross-Chain Token
Last updated
Last updated
Each unique GMP solution operates through its distinctive token passing method, often employing variations of the lock/mint process. This involves locking the original token on the source chain and mint a GMP wrapped version of the token on the destination chain (e.g., axlUSDC and lzUSDC).
Yet, handling GMP wrapped iterations of the original token presents certain drawbacks:
Fragmented liquidity: Wrapped tokens lack fungibility between different bridges.
Sovereignty: Ownership of the wrapped token transitions to the GMP, causing the original token issuer on the source chain to relinquish control over the token on remote chains.
Vendor lock-in: The wrapped token contract becomes indefinitely tied to a particular GMP, leading to limited flexibility.
The XERC20 standard (EIP-7281) seeks to overcome these limitations by establishing a distinct token contract capable of achieving cross-chain fungibility.
This extension of the ERC20 standard introduces configurable permissions for specific addresses (bridges), enabling them to perform burns or mints within defined limits over designated time periods (For instance, bridge 0x12.. has a daily burn limit of 10^6 and a daily mint limit of 10^6).
This establishes a protocol for interaction between XERC20 and bridges, outlined as follows:
The issuer deploys the identical XERC20 token contract across desired chains.
The issuer grants burn/mint permissions to bridges on each XERC20 contract.
Bridges execute burn/mint functions on XERC20 contracts, enabling the transfer of value across chains.
This method offers several benefits:
The token issuer retains ownership of all token contracts.
Fungibility remains intact as all tokens are represented by identical contracts.
There's no lock-in to a specific GMP; if the token issuer wishes to support a new bridge, they can simply set rate limits for the new bridge within their XERC20 token. Similarly, if the token issuer opts to cease support for a bridge, they can set rate limits to 0 for that specific bridge.
While the XERC20 standard provides solutions to cross-chain token challenges such as fragmented liquidity, sovereignty, and vendor lock-in, it is not devoid of risks. These risks primarily stem from the following factors:
When transferring an XERC20 token, following the completion of the burning process on the local blockchain, the responsibility falls upon the bridge to ascertain the address of the remote token counterpart that will be minted.
If the bridge fails to manage the addresses effectively, there is a risk of inadvertently burning a token while attempting to mint a different one on the remote chain. Therefore, meticulous address management by the bridge is essential to ensure the accurate and secure transfer of tokens between blockchains.
This scenario occurs in the context of an XERC20 transfer. Following the burning of a token on the local blockchain, there exists a risk of failure to mint the token on the destination chain if the process is obstructed by the exhaustion of minting limits on XERC20 contract, potentially resulting in the loss of the token.
These risks are all mitigated by Glacis Cross-Chain Token (XERC20 extension)
While primarily functioning as a GMP aggregator, Glacis serves as a distinct bridge for XERC20 with the Glacis Cross-Chain Token (GXT).
When a token transfer is requested to Glacis, the GlacisTokenMediator contract takes charge of burning the required amount of tokens on the source chain, then the GXT source and destination addressess and the amount are passed as a regular message than can leverage all Glacis features for security/availability.
Finally, on the destination chain the GlacisTokenMediator is responsible for minting an equivalent amount of GXT tokens, this message flow can be set as redundant for more security.
To enable cross-chain token transfers via Glacis for a particular token contract, the issuer (owner) needs to establish burn/mint rate limits for the GlacisTokenMediator address on each XERC20 contract.
If an issuer wants at any time for Glacis to no longer perform bridging of his token, he simply needs to set the mint and burn rate to 0 for the GlacisTokenMediator address in XERC20 contract on each supported chain.
There are edge cases where it is impossible to generate a smart contract that has the same address due to the constraints of some EVMs' implementation. By design, XERC20 has no opinion on this, and it is up to Glacis to determine what the best solution is. To give the developer the most control, the XERC20 token describes which tokens from which chains are allowed to represent it.
This requires an extension to the XERC20 interface, which has been called IXERC20GlacisExtension. If you are using the XERC20 smart contract, this interface & functionality is automatically deployed with the smart contract. This is not provided by the default XERC20 implementation.
The additional functions have been included:
In a custom implementation, the only required function is getTokenVariant, which allows Glacis to query if an address from a specific Glacis chainId is designated as a variant of this XERC20. In the implementation provided for you, the setTokenVariant and removeTokenVariant functions allow the owner of the smart contract to configure these variants.
When transferring GXTs via Glacis, the inherent risks associated with XERC20 are reduced as follows:
On Glacis, the risk is mitigated by transferring the responsibility of managing counterpart addresses from the bridge to the GXT contract. GXT issuers can establish well-known token addresses counterparts in this contracts that Glacis will use to validate token transfers. This information is accessible for querying by any user.
Glacis conducts validation on both the source and destination GXTs to ensure counterpart alignment. If a malicious XERC20 token issuer attempts to alter its local counterpart to map to a different remote, potentially more valuable token, Glacis' counterpart validation will detect this manipulation and refuse to do the minting, the outcome will solely entail the burning of tokens of the malicious XERC20 issuer on the source chain.
The risk is alleviated by Glacis' retry feature, which is automatically enabled when issuing a GXT transfer. Once the revert is verified on the remote chain because of XERC20's minting limit, the routing can be retried once the limits are reset in the next time unit, typically one day, in this way the token can be recovered on remote chain after the error.
If the issuer has previously deployed a traditional ERC20 on the source chain, XERC20 offers a LockBox mechanism—a straightforward contract supporting 1:1 lock/mint and burn/unlock operations.
When a user locks (deposits) a specific amount of the legacy ERC20 token, an equivalent amount of the XERC20 token is minted. This allows users to convert their legacy ERC20s into XERC20s, enabling cross-chain transfers through Glacis.
When users transfer XERC20 tokens back to the source chain (token home), they can withdraw the initial amount of ERC20 tokens through this mechanism by burning the equivalent amount of XERC20 tokens.
