Token Integration Guidelines

Attribute	Compatibility	Explanation
Optionality of decimals	Not compatible	The existence of the decimals() function is not a hard requirement for ERC20 tokens, but SafetyModules and RewardsManagers require assets to have decimals.
Rebasing balances	Not compatible	SafetyModules and RewardsManagers make heavy use of internal accounting and thus cannot support rebase tokens.
Low to no decimals	Issues possible	The use of assets with a low number of decimals, or decimals of 0, might indicate that small numbers of the token (eg. 1 wei) are of substantial value. If that is the case, users of SafetyModules and RewardsManagers may experience loss due to rounding down in the protocol logic.
High decimals	Issues possible	The use of assets with a high number of decimals might indicate that a large integer is necessary to represent any significant value. If that is the case, note that SafetyModules and RewardsManagers internal accounting uses uint256, restricting the maximum possible number of tokens that can be stored to type(uint256).max.
Forced transfer	Issues possible	If the admins in control of the asset can be trusted, it should be reasonable to integrate tokens even if there exists the possibility of a forced transfer (ie. admins can forcefully move anyone's balance). When SafetyModule and RewardsManager assets are forcefully removed however, they will become insolvent.
Uncommon decimals type	Issues possible	SafetyModules and RewardsManagers assume that the number returned by decimals() fits into a uint8.
Fee on transfer	Issues possible	Tokens that take a fee on transfer (ie. the receiver will receive less than specified) do not appear to be causing any issues with SafetyModule and RewardsManager internal accounting. However they may impact user experience since eg. previewRedemption would return an amount that does include the token's fee. The user would need to manually subtract this fee to preview the amount of assets expected to receive from the redemption.
Token without success bools	Compatible	While the ERC20 standards requires a token's functions to return booleans to represent whether an action succeeded or not, many do not follow this standard. The protocol supports tokens that do not return such booleans (ie. usage of OpenZeppelin's SafeERC).
Blocklist	Compatible	The protocol's SafetyModule and RewardsManager smart contracts hold user's assets in custody. Assuming that a SafetyModule/RewardsManager contract itself is not added to a blocklist (ie. disabling transfers from the address), there's no issue. Even if any of the protocol's users are added to the asset's blocklist, they may simply specify a new address as receiver_ to bypass this.
Pausable	Compatible	While an asset is paused (ie. all transfers are disabled), all protocol interactions requiring the movement of funds are unavailable, except for redemptions. Everything else will continue to work as intended within a SafetyModule/RewardsManager internal accounting.
Multiple token addresses	Compatible	Tokens that have multiple addresses (also called Double-Entry-Tokens) do not appear to be able to cause any issues with the protocol. The SafetyModule/RewardsManager exclusively uses the address that was specified as the asset (ie. there's no sweeping or rescuing function interacting with other token addresses).
Tokens with callbacks	Compatible	Some token standards extend ERC20 and add callbacks/hooks that will dispatch a call to the receiver and/or sender of a transaction if they are a contract (eg. ERC777). This can allow for "reentrancy", ie. the receiver may re-enter the contract and exploit the fact that state has not been fully updated yet. The SafetyModule/RewardsManager contract's interactions are happening at the very end of its external functions, making sure that the state is fully updated at the point of transfer.
Limited amount size	Compatible	Some ERC20 tokens appear to allow transferring full integers (ie. uint256) but will in practice revert when a large transfer amount is specified. Thanks to the fact that all interactions involving token transfers with SafetyModule/RewardsManager can be split into multiple calls (resulting in the same effect as a single call with a larger amount) this should not be an issue.