Gem is an ERC20 token implementation. GemFab is a token factory that builds Gems.
The idea is to stop deploying tokens directly, and use a factory for all tokens.
Gem is not safe for extension via inheritance. Instead of customizing your gem via inheritance, you should use the built-in mint and burn, with multi-owner ward for authentication.
Minting and burning from a controller contract which defines the rules for when those can occur is the most 'hygenic' way to implement all forms of tokenomics.
If you check gemfab.built(gem), you know that gem is a Gem -- no further audit needed.
An independently deployed Gem will not appear in the factory's record of valid gems, which will complicate verification for no reason.
More importantly, having a record that the gem was built from the factory allows other contracts to infer that certain invariants are maintained,
which a codehash check cannot satisfy because contracts can write to their state during construction time.
Here are some other implementation choices made for Gem.
- An anonymous event with a single indexed argument we call the Caller event is inserted next to
Transferevents generated bytransferFrom - Infinite allowance via
approve(code, type(uint256).max);. This avoids a useless store and is a major gas savings. permit-- There are several minor variations in the wild; this one uses EIP-2612 (notably, has a small difference from earlier permit in Dai).- Custom error types for all possible error conditions, with a consistent error API.
- Invariants preserved with controlled mint/burn means
uncheckedblocks can be used to save gas in every function. - Functions are
payable, saving a little bit of gas. The contract as a whole will still reject ether sent to invalid ABIs, including regular ether "send" (call with no calldata), which covers the most common mistake.
Working with gemfab
(Note: No packs are published yet -- watch for 'release' branch). See pack/gemfab_<network>.dpack.json to get the gemfab object plus Gem and GemFab types. See dpack for docs on how to use these packs.
Discussion
"ERC20" is an ABI definition masquerading as a semantic spec. There is no "standard ERC20". As a result, the token ecosystem is a disaster. In an ideal world, this would have been the lesson that taught EIP enthusiasts to stop doing design by committee.