Dapp-a-day 18: ERC20 token vault
Today's dapp is a simple but very useful utility called a "vault".
The purpose of a vault is also very simple: to store ERC20 tokens.
A vault is useful for example any time you need to segregate token
holdings into several distinct buckets, or when you want to set up a
shared account, maybe owned by a
DSEasyMultisig (see Dapp-a-day 5).
Vaults are protected using
DSAuth (see Dapp-a-day 4), so they can
either just be owned or can have more sophisticated access control.
Whoever owns or controls a
DSVault can tell it to perform token
operations, such as transferring X amount of token Y to account Z,
or even (as long as the vault has the necessary ERC20 approval)
transferring X amont of token Y from account W to account Z.
A single vault is able to hold any number of different ERC20 tokens.
Anyone is free to make deposits to a vault by simply transferring
tokens directly into it using the regular ERC20
The owner of a vault can also ask the vault to perform the transfer.
Vaults are very staightforward to understand and think about, and can
be a useful building block in many different kinds of applications.
Take a look at the source code: https://github.com/nexusdev/ds-vault
If you’ve been paying attention, you’ll notice that there is something
strange about the source repository: there’s no
Why? Well, Dapple allows you to keep your source code wherever you
want (by configuring the
sol_sources property in your
and so far the convention has always been to put it in
Nexus has decided to move away from this convention as part of a more
general policy to try to whenever possible avoid the term "contract".
Because "smart contracts" are neither smart nor contracts, and because
the term "contract" in particular already means something different,
we are taking this opportunity to move to the tried-and-true
If you think of a directory as a "vault" for source code, then you see
why it made sense to bring this up in the context of today's dapp. :-)