The gateways for collateral and system coins to join or exit the system
There are three main token adapter types:
CollateralJoin- allows standard ERC20 tokens to be deposited for use with the system.
ETHJoin- allows native Ether to be used with the system.
CoinJoin- allows users to withdraw their system coins from the protocol into a standard ERC20 token (and vice-versa).
safeEngine- storage of the
collateralType- id of the
CollateralTypefor which a
CollateralJoinis created for.
collateral- the address of the
systemCoin- the address of the
contractEnabled- an access flag for the adapter.
decimals- decimals for the collateral type.
join- join tokens into the system
exit- exit tokens from the system
disableContract- disable the adapter and only allow
token adaptercontract has 4 public functions: a constructor,
disableContract. The constructor is used on contract initialization and sets the core variables of that
exitare both true to their names.
Joinprovides a mechanism for users to add the given token type to the
SafeEngine. It has slightly different logic in each variation, but generally resolves down to a
transferand a function call in the
Exitis very similar, but instead allows the the user to remove their desired token from the
disableContractallows the adapter to be drained (allows tokens to move out but not in).
CollateralJoincontract serves a very specified and singular purpose which is relatively abstracted away from the rest of the core smart contract system. When a user desires to enter the system and interact with the
gebcontracts, they must use one of the
CollateralJoincontracts. After they have finished with the
gebcontracts, they must call
exitto leave the system and take out their tokens. When the
disableContractd by an
authed address, it can
exitcollateral from the SafeEngine but it can no longer
User balances for collateral tokens added to the system via
disableContractare accounted for in the
tokenCollateralaccording to collateral type
CollateralTypeuntil they are converted into locked collateral tokens (
Safe.lockedCollateral) so the user can draw system coin.
CoinJoincontract serves a similar purpose. It manages the exchange of Coin that is tracked in the
SafeEngineand ERC-20 Coin that is tracked by
Coin.sol. After a user draws Coin against their collateral, they will have a balance in
CoinJoin.coinBalance. This Coin balance can be
exit' ed from the SafeEngine using the
CoinJoincontract which holds the balance of
SafeEngine.coinBalanceand mint's ERC-20 Coin. When a user wants to move their Coin back into the
SafeEngineaccounting system (to pay back debt, participate in auctions, pack
coinBag's in the
GlobalSettlement, or utilize the CoinSavingsAccount, etc), they must call
CoinJoin.join. By calling
burn's the ERC-20 Coin and transfers
CoinJoin's balance to the User's account in the
SafeEngine. Under normal operation of the system, the
Coin.totalSupplyshould equal the
SafEngine.coinBalance(CoinJoin)balance. When the
disableContract'd by an
auth'ed address, it can move Coin back into the SafeEngine but it can no longer
exitCoin from the SafeEngine.
The main source of user error with the
TokenAdaptercontract is that Users should never
transfertokens directly to the contracts, they must use the
joinfunctions or they will not be able to retrieve their tokens.
There are limited sources of user error in the
TokenAdaptercontract system due to the limited functionality of the system. Barring a contract bug, should a user call
joinby accident they could always get their tokens back through the corresponding
exitcall on the given
The main issue to be aware of here would be a well-executed phishing attack. As the system evolves and potentially more
TokenAdaptercontracts are created, or more user interfaces are made, there is the potential for a user to have their funds stolen by a malicious
TokenAdaptercontract which does not actually send tokens to the
SafeEngine, but instead to some other contract or wallet.
There could potentially be a
SafeEngineupgrade that would require new
TokenAdaptercontracts to be created.
collateralcontract 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 scenario likely presents little risk though because the token going through this upgrade would more than likely want to work alongside the community to be sure this was not an issue.