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.
Fee on transfer	Not Compatible	SafetyModules and RewardsManagers support multiple tokens and make heavy use of internal accounting and thus cannot support fee on transfer tokens.
Tokens with callbacks	Not Compatible	SafetyModules and RewardsManagers support multiple tokens and make heavy use of internal accounting and thus cannot support tokens with callbacks.
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.
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).
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.