Contract re-architecture

3.2 Contract re-architecture

One design priority for DEX Raiden v1.1 is to minimize the surface area and complexity of the core pair contract—the contract that stores liquidity providers’ assets.

Any bugs in this contract could be disastrous, since millions of dollars of liquidity might be stolen or frozen. When evaluating the security of this core contract, the most important question is whether it protects liquidity providers from having their assets stolen or locked. Any feature that is meant to support or protect traders—other than the basic functionality of allowing one asset in the pool to be swapped for another—can be handled in a “router” contract. In fact, even part of the swap functionality can be pulled out into the router contract. As mentioned above, DEX Raiden v1.1 stores the last recorded balance of each asset (in order to prevent a particular manipulative exploit of the oracle mechanism).

The new architecture takes advantage of this to further simplify the DEX Raiden v1 contract.

In DEX Raiden v1.1, the seller sends the asset to the core contract before calling the swap function. Then, the contract measures how much of the asset it has received, by comparing the last recorded balance to its current balance. This means the core contract is agnostic to the way in which the trader transfers the asset. Instead of transferFrom, it could be a meta transaction, or any other future mechanism for authorizing the transfer of ERC-20s or BEP-20s.