You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For a long time, ERC20 was an ABI definition masquerading as a semantic spec. This means some "ERC20" tokens are now technically non-compliant even though the developers were following what the standard said at the time.
When the semantics were finally standardized, it revealed all the warts in the design. ERC20 tokens are surprisingly hard to build and use correctly.
Experience building token system shows that nearly all custom dapp logic lies when to mint/burn, and almost no dapp has a concept of "logic on transfer". In practice, every single dapp has its token re-audited to ensure it doesn't violate the same basic rules in every project.
Meta-proposal: Design by github thread is a bad idea
Proposal: A universal token factory that constructs a common "Token" type.
The token:
has a "controller" which is just a regular simple "owner" address. I propose "controller" because people tend to anthropomorphize "owner" and forget that single-signature control is a special case. The controller can update via setController. It really is just an "owner".
controller can call mint/burn/move ("move" is a backdoored "transfer")
The factory:
DOES fire an event recording new tokens,
does NOT assign a numeric ID
does NOT have a registry.
Do not dare try to launch the "first" "official" one of these without bytecode-level formal verification. You know who you are.
Consider this OP an evolving document, I will revise it with a concrete spec and rationale for each decision above.
Maybe if all the right people tweet about it we could even call these "ETokens" or "eTokens".
The text was updated successfully, but these errors were encountered:
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
For a long time, ERC20 was an ABI definition masquerading as a semantic spec. This means some "ERC20" tokens are now technically non-compliant even though the developers were following what the standard said at the time.
When the semantics were finally standardized, it revealed all the warts in the design. ERC20 tokens are surprisingly hard to build and use correctly.
Experience building token system shows that nearly all custom dapp logic lies when to mint/burn, and almost no dapp has a concept of "logic on transfer". In practice, every single dapp has its token re-audited to ensure it doesn't violate the same basic rules in every project.
Meta-proposal: Design by github thread is a bad idea
Proposal: A universal token factory that constructs a common "Token" type.
The token:
setController
. It really is just an "owner".mint
/burn
/move
("move" is a backdoored "transfer")The factory:
Do not dare try to launch the "first" "official" one of these without bytecode-level formal verification. You know who you are.
Consider this OP an evolving document, I will revise it with a concrete spec and rationale for each decision above.
Maybe if all the right people tweet about it we could even call these "ETokens" or "eTokens".
The text was updated successfully, but these errors were encountered: