New Paradigm Wallets and Tokens
New Token Design
ERC20 tokens are Ethereum-based standard tokens that can be traded and transferred on the Ethereum network. But the essence of ERC20 is based on the EOA wallet design. EOA wallet has no state and code storage, and the smart contract wallet is different.
Almost all ERCs related to tokens are adding functions, our opinion is the opposite, we think the token contract should be simpler, more functions are taken care of by the smart contract wallet.
Our proposal is to design a simpler token asset based on the smart contract wallet,
It aims to achieve the following goals:
Keep the asset contract simple, only need to be responsible for the transaction function
approve and allowance functions are not managed by the token contract , approve and allowance should be configured at the user level instead of controlled by the asset contract, increasing the user’s more playability , while avoiding part of the ERC20 contract risk.
Remove the transferForm function, and a better way to call the other party’s token assets is to access the other party’s own contract instead of directly accessing the token asset contract.
Forward compatibility with ERC20 means that all fungible tokens can be compatible with this proposal.
Examples
The third party calls the user’s token transaction(transferForm),
Judges whether the receiving address is safe (safeTransferForm),
Permit extension for signed approvals (ERC-2612,``permit)
Authorizes the distribution of the user’s own assets(approve, allowance),
Add the transfer hook function. (ERC-777, hook)
The above work should be handled by the user’s smart contract wallet, rather than the token contract itself.
New Wallet Design
The smart contract wallet allows the user’s own account to have state and code, bringing programmability to the wallet. We think there are more directions to expand. For example, token asset management, functional expansion of token transactions, etc.
It aims to achieve the following goals:
Assets are allocated and managed by the wallet itself, such as approve and allowance, which are configured by the user’s contract wallet, rather than controlled by the token asset contract, to avoid some existing ERC-20 contract risks.
Add the transferFungibleToken function, the transaction initiated by the non-smart wallet itself or will verify the allowance amount
Users can choose batch approve and batch transfer. Batch approve can greatly reduce gas. The contract wallet itself manages the authorization status of all assets, and batch approve can be performed without calling multiple asset contracts.
Users can choose to add hook function before and after their transferFungibleToken to increase the user’s more playability
The user can choose to implement the receive hook
Use the sequence diagram to compare the difference between using this interface to transfer tokens.
Alice calls the transfer herself
The user call the transaction sequence diagram now(transfer).
The user use new paradigm to call the transaction sequence diagram, dotted lines are optional.
Alice doesn’t call the transfer herself
Sequence diagram of third party calling user transaction now(transferForm).
Sequence diagram of third party calling user transaction use new paradigm.(transferFungibleToken).
The third party uses new paradigm and is compatible with the old dapp protocol and EOA to call the user transaction sequence diagram(transferForm).
Last updated
