System Coin: TAI
ERC20 representation of the coins backed by system collateral
1. Summary
The Coin
contract is the user-facing ERC20 token maintaining the accounting for external system coin balances. Most functions are standard for a token with changing supply, but it also has notable features such as the ability to approve transfers based on signed messages.
2. Contract Details & Functions
Variables
name
symbol
version
decimals
changeData
- if1
governance can change thename
and/orsymbol
and no one can usepermit()
; if different than1
governance cannot changename
orsymbol
anymore andpermit()
can be usedtotalSupply
- total coin supplybalanceOf(usr: address)
- user balanceallowance(src: address, dst: address)
- approvalsnonces(usr: address)
- permit noncewad
- fixed point decimal with 18 decimals (for basic quantities, e.g. balances).
Functions
mint(usr: address
,amount: uint256)
- mint coins to an addressburn(usr: address
,amount: uint256)
- burn at an addresspush(usr: address
,amount: uint256)
- transferpull(usr: address
,amount: uint256)
- transfer frommove(src: address
,dst: address
,amount: uint256)
- transfer fromapprove(usr: address
,amount: uint256)
- allow pulls and movesmodifyParameters(parameter: bytes32
,data: uint256)
- modify the value ofchangeData
setName(name_: string)
- change the token'sname
ifchangeData
is1
setSymbol(symbol_: string)
- change the token'ssymbol
ifchangeData
is1
permit(holder: address
,spender: address
,nonce: uint256
,expiry: uint256
,allowed: bool, v: uint8
,r: bytes32
,s: bytes32)
- approve by signature; only callable ifchangeData != 1
transfer(dst: address
,amount: uint256)
- transfers coins frommsg.sender
todst
3. Walkthrough
For the most part, coin.sol
functions as a typical ERC20 token although it has a couple of core differences:
push
,pull
&move
are aliases fortransferFrom
in the form oftransferFrom(msg.sender, usr, amount)
,transferFrom(usr, msg.sender, amount)
&transferFrom(src, dst, amount)
.permit
is a signature-based approval function. This allows 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 to pay for gas.
4. Gotchas (Potential Source of User Error)
Unlimited allowance is a relatively common practice. This could be something used to trick a user by a malicious contract into giving access to all their Coin. This is concerning in upgradeable contracts where the contract may appear innocent until upgraded to a malicious contract.
Coin 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
.
Built-in meta-transaction functionality of Coin
The Coin 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.
5. Failure Modes (Bounds on Operating Conditions & External Risk Factors)
N/a
Last updated