![Nexus Logo](https://i.imgur.com/JoJ8cXZ.png)

**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](https://steemit.com/ethereum/@nikolai/dapp-a-day-5-easy-multisig)**

`ds-token` is a framework for writing upgradeable tokens. It depends on [`ds-auth`](https://github.com/nexusdev/ds-auth) and implements [`erc20`](https://github.com/nexusdev/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!