This article details how ID-based Transfer leverages utilizes identities managed on the Mycel Chain and Intent-Centric Design to enhance the money transfer experience across various blockchains.
How Intent-Centric Design improves the Web3 world and what kind of experience ID-based Transfer provides was discussed in the previous article, so we recommend you read that one first.
[Introducing Intent-Centric Interface]
ID-based Transfer makes use of the Permit2 standard, which helps realize Intent, and the ID services provided by Mycel Chain. In this article, I will explain in detail what exactly these elements are and discuss how they can be combined to implement ID-based Transfer.
About Permit2
Permit2 is a new authentication standard proposed by Uniswap last year. This standard allows users to transfer ERC20 tokens they own from any contract. They solve the traditional challenges associated with transferring ERC20 tokens.
Off-chain, the user creates and signs an 「Order」 specifying the parameters of the transfer authorization, including the amount and duration for the contract to which he/she delegates the transfer of the tokens. Based on this signature, a third party 「Filler」 executes the transaction to the contract, and the contract transfers the tokens on behalf of the user.
The gas fees associated with executing the transaction are paid by the person executing the transaction, and the user does not pay for the gas himself. In other words, the user delegates the execution of the transaction to a third party, called the “filler”.
The Permit2 contract verifies the user’s signature on the Order and transfers the tokens as instructed. Since the user’s signature cannot be tampered with, The gas fees associated with executing the transaction. This means that the user can safely trust the Filler to execute the transaction.
History of Authentication for Token Transfer
To see what Permit2 enables us to do, let’s review the history of how Permit2 came to be. There have always been mechanisms to request a third party to transfer ERC20 tokens.
Approve
The ERC20 token has a feature called 「Approve」. This allows users to allow third parties to transfer their tokens. However, this ‘Approve’ feature leads to UX issues as it necessitates users to execute a transaction every time they grant transfer permissions, which can be cumbersome and gas-intensive. Additionally, the need for frequent transactions introduces the issue of recurrent gas fees, further detracting from the user experience.
Typically, to avoid these UX issues, the Dapp may request the maximum amount of money transfer permissions from the user at the time of first use. Once granted, this permission allows for potentially unlimited transfers of the user’s tokens via the contract, introducing significant security risks. In particular, if the contract provided by the Dapp side is hacked or if the Dapp side provides a malicious function for the contract, the user’s assets are at great risk.
Permit
Permit is a mechanism developed to solve the problem of the existing Approve functionality, i.e., the need to execute each transaction.
With this mechanism, the user only needs to generate a signature off-chain, which can be verified by a Permit-enabled contract to enable the transfer of tokens. However, in order to enable delegated transfers via signatures, it is necessary to first execute an Approve function to authorize the Permit contract to transfer up to a certain amount of money.
However, this Permit mechanism is not applicable to standard ERC20 tokens and is limited to certain extended ERC20 token standards, making it less versatile. This inflexibility has been a challenge for Permit.
Permit2
Permit2 extends Permit’s capabilities, introducing an upgrade that enables signature-based transfers for traditional ERC20 tokens, broadening its applicability.
With this new standard, users can now delegate the transfer of their tokens to a third party simply by generating a signature. The third party also enables gas-free money transfers for the user by covering the gas costs incurred in executing the transaction.
Dapp, which utilizes Intent, incorporates the functionality of Permit2 and takes on the role of signing the transaction on behalf of the user. This system significantly improves the user experience in the token transfer process by simplifying the authorization mechanism and reducing gas costs.
Role of Mycel Chain
Mycel has built its own blockchain, Mycel Chain, to provide a domain system.
On the Mycel Chain, users can purchase domains and bind a wide variety of resources to those domains. For example, just like a typical NFT, a user can acquire a domain through Mycel Chain and link multiple blockchain addresses to it, and then use the domain to transfer money on each testnet. This provides a new form of blockchain name service.
[Mycel Dashboard](https://dashboard.mycel.domains/)
The ID-based Transfer mechanism introduced here, which merges the concepts of Mycel Chain and Intent, enables domain holders to receive assets such as ERC20 tokens directly by their domain name, bypassing the need for explicitly linking addresses on the Mycel Chain. This means assets transferred to their domain can be received directly without additional setup.
The user receiving the assets will generate an off-chain signature on the account associated with the domain they hold. This signature facilitates the direct receipt of assets through Dapps, streamlining transactions and enhancing efficiency.
At the heart of this system is the convenience offered by utilizing memorable domain names for transactions, replacing the need for complex blockchain addresses. This approach allows users to conduct transactions using domain names that are easy to remember, thereby avoiding the traditional, complex, and error-prone process of entering addresses.
This technological advancement represents a significant step towards fostering a more user-friendly and accessible environment within the blockchain and Web3 ecosystems.
Design of ID-based Transfer
This component diagram assumes that Alice wants to transfer tokens via the Ethereum network to the owner of the domain bob.cel. It is sufficient for Alice to know the domain name bob.cel and to identify its owner as Bob (Of course, it does not matter if she knows that).
If Alice wishes to transfer a specific token via ID-based Transfer, she is required to perform an Approve transaction with the Permit2 contract initially.
Next, Alice specifies the amount she wants to send to bob.cel via the Mycel web app. The app queries the Mycel Chain to obtain the public key of the user who owns the bob.cel domain. Information about the amount of money sent, the public key, and Alice’s signature on that information are stored as a 「SenderOrder」 in Mycel’s back-end Order pool.
Once the SenderOrder from Alice is stored in the pool, Mycel notifies Bob that he has a money transfer request addressed to bob.cel. Bob, who wishes to receive the money, specifies the recipient address and generates a signature from the account that owns the bob.cel domain via the Mycel app. A 「RecipientOrder」 containing this signature and the recipient address is sent to the backend.
Upon receiving the RecipientOrder, the web app searches for the corresponding SenderOrder and verifies Bob’s signature in the RecipientOrder using the public key associated with the bob.cel domain linked to the SenderOrder. Once this verification is complete and it is confirmed that Bob is in fact the owner of bob.cel, a transaction is created matching the SenderOrder and RecipientOrder.
When Mycel sends this transaction to Ethereum, Alice’s tokens are transferred to Bob’s specified address via the Permit2 contract.
Through this system, Bob is able to receive tokens at any address not directly linked to bob.cel on the Mycel Chain.
As a result, Alice can simply use the domain name to send money without knowing Bob’s actual address.
Looking Ahead: Future Prospects
This description covers the most fundamental functionalities.
We envision these mechanisms enabling not only cross-chain transfers via domains but also the payment of gas fees with ERC20 tokens.
A common challenge in cross-chain transfers is the potential variation in tokens required for gas payments across different chains.
Consider the scenario of transferring a specific token held on Ethereum to a Layer2 account for the first time using a bridge.
If you want to transfer tokens to another account after receiving tokens in your L2 account, you will need to prepare new gas tokens for use in that L2 account. Having to specifically prepare gas tokens and send them to the desired account imposes a significantly cumbersome user experience.
However, by applying the concepts of Intent and Account Abstraction to Layer2 solutions, it is conceivable to enable transfers with only the owned tokens, without the need for separate gas tokens. This has the potential to overcome the challenges of cross-chain remittance.
Mycel aims to harness the concepts of Intent and Domains to bring innovative changes to the remittance experience across various blockchains.
