Skip to content

Dai

The origin of DAI was designed to represent any token that the core system considers equal in value to its internal debt unit. Thus, the DAI Module contains the DAI token contract and all of the adapters DaiJoin adapters.

The Dai contract is the user-facing ERC20 token contract maintaining the accounting for external Dai balances. Most functions are standard for a token with changing supply, but it also notably features the ability to issue approvals for transfers based on signed messages.

Why are these components important to the Multi-Collateral Dai (MCD) System?

Section titled “Why are these components important to the Multi-Collateral Dai (MCD) System?”

The Dai contract is the user facing ERC20 contract maintaining the accounting for external Dai balances. Most functions are standard for a token with changing supply, but it also notably features the ability to issue approvals for transfers based on signed messages.

Join consists of three smart contracts, one of which is the DaiJoin contract. Each join contract is created specifically to allow the given token type to be joined to the vat. Because of this, each join contract has slightly different logic to account for the different types of tokens within the system. The DaiJoin contract allows users to withdraw their Dai from the system into a standard ERC20 token.

  1. transferFrom in the DAI contract works in a slightly different form than the generic transferFrom function. The DAI contract allows for “unlimited approval”. Should the user approve an address for the maximum uint256 value, then that address will have unlimited approval until told otherwise.
  2. push, pull & move are aliases for transferFrom calls in the form of transferFrom(msg.sender, usr, amount) , transferFrom(usr, msg.sender, amount) & transferFrom(src, dst, amount) .
  3. permit is a signature-based approval function. This allows for an end-user to sign a message which can then be relayed by another party to submit their approval. This can be useful for applications in which the end-user does not need to hold ETH.
    • In order to use this functionality, a user’s address must sign a message with the holder, spender, nonce, expiry and the allowed amount. This can then be submitted to Permit() to update the user’s approval.

Built-in meta-transaction functionality of Dai

Section titled “Built-in meta-transaction functionality of Dai”

The Dai token provides offchain approval, which means that as an owner of an ETH address, you can sign a permission (using the permit() function) which basically grants allowance to another ETH address. The ETH address that you provide permission to can then take care of the execution of the transfer but has an allowance.

Unlimited allowance is a relatively uncommon practice (though becoming more common). This could be something used to trick a user by a malicious contract into giving access to all their DAI. This is concerning in upgradeable contracts where the contract may appear innocent until upgraded to a malicious contract.

DAI is also susceptible to the known ERC20 race condition, but should not normally be an issue with unlimited approval. We recommend any users using the approval for a specific amount be aware of this particular issue and use caution when authorizing other contracts to perform transfers on their behalf.

There is a slight deviation in transferFrom functionality: If the src == msg.sender the function does not require approval first and treats it as a normal transfer from the msg.sender to the dst.

Failure Modes (Bounds on Operating Conditions & External Risk Factors)

Section titled “Failure Modes (Bounds on Operating Conditions & External Risk Factors)”

There could potentially be a vat upgrade that would require new join contracts to be created.

If a gem contract were to go through a token upgrade or have the tokens frozen while a user’s collateral was in the system, there could potentially be a scenario in which the users were unable to redeem their collateral after the freeze or upgrade was finished. This seems to be a small risk though because it would seem likely that the token going through this upgrade would want to work alongside the Sky community to be sure this was not an issue.

Key Functionalities (as defined in the smart contract)

  • Mint - Mint to an address
  • Burn - Burn at an address
  • Push - Transfer
  • Pull - Transfer From
  • Move - Transfer From
  • Approve - Allow pulls and moves
  • Permit - Approve by signature

Other

  • name - Dai Stablecoin
  • symbol - DAI
  • version - 1
  • decimals - 18
  • totalSupply - Total DAI Supply
  • balanceOf(usr: address) - User balance
  • allowance(src: address, dst: address) - Approvals
  • nonces(usr: address) - Permit nonce
  • vat - storage of the Vat’s address
  • ilk - id of the Ilk for which a GemJoin is created for
  • gem - the address of the ilk for transferring
  • dai - the address of the dai token
  • one - a 10^27 uint used for math in DaiJoin
  • wad - fixed point decimal with 18 decimals (for basic quantities, e.g. balances).

Released into the public domain (CC0 1.0 Universal) – trademarks remain with their owners; no warranty. See full license.