ricobank / gemfab Goto Github PK

• https://github.com/d-xo/weird-erc20
• https://github.com/sec-bit/awesome-buggy-erc20-tokens

• safe unchecked in some situations
• compare gas savings for deployment for precomputed hashes

DSS uses inline require(...) instead of auth modifier, let's see if this saves gas

Particularly to Dai, which treats approve(-1) as infinite and saves a store
See if we are still cheapest if we also track caller event: https://github.com/ricobank/gemfab/pull/67/files
If we aren't, decide if it's worth it

If possible it would be nice to make these bytes32 so that it dmap auto registration thing is less annoying

Because return values are not part of ABI, it should be accessible with the same call
But possibly interpreting the return value might give weird results, we should test it out and see what etherscan shows for bytes32 symbols

in constructor provide a bytes32 info, this is open to interpretation by creator, could be a file hash or dmap slot

E.G., PERMIT_TYPEHASH is exposed as a function since it is public, but this adds entrypoints. Since solidity gives us no control over the order of these functions in the initial jump table, this might be adding extra gas.

• Gem emits an extra event inside the transferFrom call which makes it possible to determine the caller (the cause of the transfer of funds) from the event logs:

  gemfab/sol/gem.sol

  Line 132 in 1bf11ae

  assembly{ log1(caller(), 0, 0) }

• To help make sense of Gem, we should provide a small utility that translates the combination of Transfer and anonymous events into sensible TransferFrom "events"
• To get a set of "TransferFrom" events for a particular caller:
  • Get all events where indexed event arg 1 (the second argument) is empty - these are the anonymous Caller events whose argument 0 is the caller
  • The immediately prior event (by absolute index) is the "Transfer" event with the rest of the information for the corresponding TransferFrom
• To get a set of all transfers and organize "TransferFrom" events based on cause
  • Get all Transfer events for the gem for the given block
  • For each Transfer event
    • if the event immediately following (by absolute index) is the anonymous Caller event, mark this "TransferFrom" as a transferFrom
    • if it is any other event, mark this "TransferFrom" as a transfer, and the caller is the src.

The world-famous ERC20 standard does not emit information about which address called the contract, even for transferFrom where that address is critical for making sense of token flows.

We can stay compatible with ERC20 by just adding a Caller(address caller) event right before xfer/mint/burn

e.g. mint/burn have no underflow/overflow tests

Gem is defined as haltable or not in constructor, cannot be modified after (mutable haltable can be emulated with controller).
Some tokens will need this for compliance (e.g. USD-backed IOUs), others will not, we can support both. Can define a non-haltable token with appropriate controller contract.

Most dapps expect Transfer() with address(0) as flag for mint or burn. This will help adoption of gem and reduce code.

fewer entrypoints and also can make the other functions external

Instead perhaps ward(address,bool) to toggle ward status

Hahahahahaha

Make functions cheaper by not rejecting ETH in function calls? Not like any other token gets rejected...

I think importing some of the OZ tests required adding a bunch of fat dependencies which npm complains about being old and insecure