Dapp-a-day 6: Upgradeable Tokens

Each weekday leading up to devcon2, Nexus will highlight a dapp, library, or package (something with a dappfile) as a promotion of our toolchain and as case studies for other developers. Yesterday's Post

ds-token is a framework for writing upgradeable tokens. It depends on ds-auth and implements erc20.

https://github.com/nexusdev/ds-token

It achieves two seemingly opposing goals:

• Keep the "interface" address fixed - don't burden consumers with your update logic (e.g. registry lookups or following an update chain).
• Allow the behavior to be changed (with the ability to lock down, of course), and make it painless.

This is done by splitting the token contract into 3: A "Frontend", a "Controller", and a "Datastore". These are all DSAuth (DSAuthorized), they look up to a DSAuthority for access control.

The frontend has erc20 function definitions as well as emit* event callback functions.

The controller has implementations of the erc20 functions extended to also accept the frontend's msg.sender as an argument (ERC20 semantics depend on msg.sender).

The datastore holds all app state and has only dumb getters and setters and makes logic updates significantly easier.

This design is partially an artifact of the days before DELEGATECALL and usable libraries, which could arguably reduce this to a 2-contract system. But still, separating the entrypoint and logic controller makes me less nervous about accidentally butchering state.

There is a DSToken "installer" (a "smart factory") which instantiates a token that is functionally equivalent to ERC20Base. It installs a token "into" an existing DSBasicAuthority.

With ds-token under our belt, we can explore applications that use tokens as well as applications that are tokens. Wow, coins!