Motivation
The current interfaces or implementations of ERC tokens (ERC-20/721/1155) don’t include “issuer” as a part of its standard, the underlying value of tokens relies on implicit community consensus. Think of the fact you can copy & paste source code to deploy your own “USDC” or “BAYC” contract, but they will not bear any value.
However, this convention has two major limitations:
- It limits adoption of new tokens. Each token will need to “gather consensus” before it is getting widely accepted.
- It makes cryptocurrencies prone to phishing attacks. There is no way to verify whether a token is “authentic” due to lack of definition.
These limitations will become more notable under the context of soulbound tokens(SBT). Imagine there will be miscellaneous SBTs issued by governments, organizations, and persons. How can we determine which SBTs are trustful and which are not, given the fact they are not tradable and do not bear money value?
That’s why we want to propose a standard interface to allow tokens to be verifiable with regard to its issuer, this standard can be applied to all kinds of tokens but is believed to be most useful in SBTs.
Solutions
We humbly describe two options briefly for early discussion, the complete spec will be on the way.
Option #1. Create an on-chain registry to host and maintain token-issuer mapping.
Inspired by the SSL certificate which binds the identity of a website to a cryptographic key pair, we can bind the token contract to its issuer account. While publicly trusted certificate authority(CA) is required by SSL protocol, blockchain can provide such a registry using smart contracts by its decentralization nature. Necessary verification will be performed on the bind-relation registration process. Users can directly query the registry to check the issuer of some token contract.
Option 2. Directly store issuer information along with verification material inside token contracts.
Another way is to store issuer information inside the token contract. While each token contract is able to claim its issuer, tokens with verifiable issuer will be required to further provide its verification material in specific format (e.g. issuer signing message) and keep it on-chain. Users will need to verify whether issuer information matches verification material if they want to check the issuer of some token contract.
Next Step
We are working on complete specification of this proposal, and will propose a formal EIP after that. In the meantime, we are also building a SBT product which incorporates this idea as part of the design.
Any suggestions and feedback are sincerely welcomed!