# Smart Contract Architechture

To enable user investments and withdrawals in a maximum of 2 clicks, we propose the following approach to facilitate the entire process:

- Create the user's operation params to get the user’s signature for a meat transaction.

The user’s signature consists of a valid `nonce`, `domainSeparator`, `requestTypeHash`, and `suffixData`. See [EIP-712](https://eips.ethereum.org/EIPS/eip-712).

- Verify the user’s signature, nonce, minimum deposit/withdrawal value, and the asset for making the user's meta transaction.

During the verification process which would be done off-chain, asides the signature which should have been formulated using the EIP-712 standard, there is also need to verify that the user is investing or withdrawing above a minimum value set by the platform. This is based on the fact that the platform charges a constant fee for transactions (say 1%). We want to make sure that after carrying out the user’s transaction, there is enough value charged from the user to cover the cost.

We also need to ensure that a whitelisted asset is being used by the user for investment because we only accept tokens that have implemented permit approvals. This is necessary for the user to not make an additional approval call thus elongating the transaction process. See [EIP-2612](https://eips.ethereum.org/EIPS/eip-2612) and [EIP-3009](https://eips.ethereum.org/EIPS/eip-3009).

- If every condition is passes, the transaction is executed by a gas relayer on the user’s behalf.

During execution, the logic smart contract with a registered domain in the platform, with implementations to perform trades in different liquidity pools, is called by a trusted **Forwarder** smart contract. It appends the signer’s address as the sender of the transaction. This call deducts the necessary fees from the payment asset, and sends the rest to the pool. The LP tokens are held by the platform for the user. This is to avoid having the user to sign another approval when withdrawing liquidity.

Here we have the option of building a native backend or adopting existing services from [OpenZeppelin Defender](https://defender.openzeppelin.com/), [Chainlink Keeper](https://docs.chain.link/chainlink-nodes/oracle-jobs/job-types/keeper), [Gelato Netork](https://www.gelato.network/), or any other for gas relay.

### Integrations

2 layers will come into play to achieve our goals, assuming we adopt a thirdparty relayer. They include:

:small_blue_diamond: **Forwarder**: A contract to handle transactions on users' behalf using signature verification.

:small_blue_diamond: **Logic SC**: A contract to handle staking, swaps, liquidity providing, etc, on DeFi protocols like Curve, Uniswap, etc.

### Forwarder

We want to develop an architechture that executes transactions for users even if they do not have the gas fees to pay in ether.

To achieve this, we would need to construct a request type for users to make the necessary transactions. Let us consider a request of the following structure:

struct ForwardRequest {
    address from;  // the user making the request
    address to;    // the address recieving the value (eth)
    uint256 value; // the amount of ether being sent
    uint256 gas;   // the gas price of the tx
    uint256 nonce; // the nonce for the transaction
    bytes data;    // encoded data for the tx
    uint256 validFrom; // when the transaction validity period begins
    uint256 validUntil;    // when the transaction validity period ends
}

To avoid creating arbitrary data with the risk of execution in a different DApp with the same `nonce` because different DApps could have similar structures, we need to include a variable `domainSeperator` which would add the extra spice for perculiarity in the signature.

To complete the framework needed to create arbitrary transaction requests, verify, execute, and manage domains/request types, we will adopt the interface [IForwarder](https://bitbucket.org/tbd-zabn8uv/tbd-sc/src/master/protocol/contracts/interfaces/IForwarder.sol).

### Logic SC

Since we intend to launch the MVP without launching a utility token, we will only need to focus on providing smart contract(s) that would allow investments in Curve and UniswapV2, and Uniswap V3.

This architecture needs to hold the LPs issued when providing liquidity on the various pools. The smart contract should manage the users’ balances based on participated pools and earnings. It should also be an upgradable contract as it will be holding LPs

This SC should whitelist accepted tokens which have permit approvals, and it should deduct transaction fees.