scifi
Search…
Token addition checklist
This list tries to list what checks we should perform on a token before adding it to an Index (either at creation time or via a rebalance)
Upgradeability
Upgradeability via a Proxy pattern is a hard no, unless it's already properly disabled (eg: the contract is updated by its Owner, and the Owner was already set to address 0)
Other upgradeability options (eg: delegating the minting cap or other parameter to a secondary, changeable contract) are okay as long as they don't interfere with the
transferFrom, transfer or approve methodsBalance changes outside of transfers
The token MUST NOT decrease holders' balances unless in an action initiated by the holder or an approved spender. This could lead to the Index being undercollateralized.
Transfer or TransferFrom modifications
Basically the transferFrom or transfer methods must:
- Increase the receiver's balance by exactly the amount that is subtracted from the sender
- Always transfer tokens if the balance and allowance (if applicable) is sufficient, without checking anything else that isn't set by the token holder. (Although baked-in blacklists, which are set at contract deploy time and are not modifiable by anyone could be okay)
- IF they DO return a value, the value MUST be
truewhen the transfer suceeds.
Common offenders are:
- Address blacklisting: They're a hard no. It'd give the component's admin the ability to lock the Set contract.
- Transfer fees: They're a hard no as well. This could eventually be walked around if forking Set protocol
- Timelocks (although they could be non-problematic. Every case should be reviewed separately)
- Pausing that inhibits transfering
Approve modifications
It's important it doesn't have caps (either soft, silent ones or ones that revert) or blacklisting, otherwise rebalances might not be possible.
In the case a token has max allowance value of
uint96, for example, special care should be taken to be sure that we remain able to rebalance the token away given its decimals (if, say, 100x the max allowance value could be locked in the Index, we'd have to execute 100 trades to rebalance it away, and that could be problematic)If the token implements approval race protections (not allowing approve of an amount M > 0 when an existing amount N > 0 is already approved), we should check that the rebalancing module always transfers as many tokens as it approves, otherwise it might not be possible to rebalance it away.
Weird decimals
If the token has less than 18 decimals, it shouldn't be an issue, however, tokens with more than 18 decimals will limit the amount of the Index that can be minted, and we should check that it remains at acceptable levels
ERC20 deviations we don't care about
- IF
transferFromortransfermethods DO NOT return a value, we don't care if the transfer doesn't revert if it fails, since the balance is checked independently (transferFrominExplicitERC20.sol) - We don't care if the token fails on a zero-value transfer, since mints/redeems of that amount don't make any sense and rebalance will fail before attempting to transfer a value of zero. (
_validatePreTradeData)payProtocolFeeFromSetTokendoesn't do transfers of zero
- We don't care if the token fails on a transfer to the null address, since the system never burns tokens that way.
- it doesn't make sense to call
payProtocolFeeFromSetTokenif the fee recipient is the null address. (other than to have the total supply of the token more closely match the circulating supply, but it doesn't make a difference)
- Anything related to events.
- redeem and mint have reentracy guards, so malicious tokens couldn't exploit reentrancy attacks in this operations. Reentrancy attacks on exchange trades have not been researched, though.
Last modified 1yr ago