📔Contract Architecture

MTVSwap is implemented in Solidity. A design priority for MTVSwap is to minimize the 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—is therefore handled in a “router” contract.

In fact, even part of the swap functionality can be pulled out into the router contract. As mentioned above, the last recorded balance of each asset is stored (in order to prevent a particular manipulative exploit of the oracle mechanism).

When using MTVSwap, the seller technically sends their 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 tokens.