Architecture

Native offers a liquidity providing system for RFQ providers built on top of the Compound v2 model and Native RFQ system. It consists of the following contracts:

  1. Vault contract holds user assets and serves as the treasury for a NativePool instance. It inherits the Comptroller contract from Compound v2.

  2. A list of LP token contracts LpToken that allows liquidity providers to deposit assets to the vault, mint interest earning LP tokens derived from borrowers and RFQ provider open position fees. It inherits CErc20 (which inherits CToken contract) from Compound v2.

Workflow

liquidity provider: mint, redeem, borrow, repay, liquidate

  1. It has the exact functionalities as Compound

  2. Liquidity providers interact with LP token contracts to mint, redeem, borrow and repay with the difference being the underlying asset is held by Vault instead of the LP token contracts.

  3. The interest accrual mechanism for liquidity provider operations are exactly the same as Compound.

  4. When there are unhealthy borrowing positions, the liquidate function in Vault is open to anyone to claim the collateral by repaying the debt.

  5. Special Note: Besides major tokens, Native Lend powers altcoin trading. For major tokens with reliable oracle prices, the LP token operates exactly like Compound with full functionality. For altcoins, liquidity providers can deposit assets and mint the LP tokens. The asset can then be used by RFQ providers to fill the swap and LPs can earn fees. However, a liquidity provider cannot borrow altcoins and LP tokens of altcoins cannot serve as collateral.

RFQ providers: trade

  1. The RFQ provider's address would be added to the NativePool as a valid signer for RFQ.

  2. When a swapper sends a swap request to Native off-chain API, Native checks with the RFQ providers for their quote and if they want the order to be filled with Native Lend liquidity. The RFQ providers then return the respective quote and signature that will be verified on-chain by NativePool.

  3. Native’s off-chain system verifies the quote and generates the signature to approve borrowing from Native Lend. The signature would be verified on-chain in Vault.

  4. Native’s API returns the quote containing the 2 signatures (1 from RFQ provider & 1 from Native) to the swapper allowing the swapper to call the NativeRouter to execute their trade.

  5. NativeRouter processes the call-data and calls NativePool for swapping. NativePool will verify the signature of the RFQ provider, and transfer the tokens from Vault to the swapper. A callback is also sent to NativeRouter to transfer tokens from swapper to Vault.

  6. At the end of the transaction lifecycle, NativePool sends a callback to Vault to account for the position change for the RFQ provider. Tokens transferred from Vault to swapper would be a short position and tokens transferred into Vault would be a long position. All live positions for the RFQ provider are recorded on-chain.

  7. Vault calls the 2 LP tokens involved to update the variable netSwapBorrow. For long positions, the borrow amount decreases (could be negative) and the inverse for short positions. The update of the borrow amounts would cancel out the change in the actual asset resulting in no change in the exchange rate before and after the trade.

admin: epoch update

  1. Native admin has the right to update the RFQ providers' open positions by the fees calculated off-chain.

  2. After the update, the netSwapBorrow of each LP token contract should increase, and the exchange rate for LP token increases.

RFQ providers: settle

  1. RFQ providers can permissionlessly call the repay function of Vault to close short positions. The contract transfers assets from the RFQ provider to the vault and updates the positions.

  2. For a settlement request that requires claiming long positions, the RFQ provider needs to call Native’s API with the settlement proposal (amount of short positions to repay & amount of long positions to claim). Native’s off-chain system would validate the settlement proposal and return a signature.

  3. The RFQ provider then calls the settle function of Vault to execute the settlement.

RFQ providers: collateral and liquidate

  1. RFQ providers can put in collateral to obtain borrowing credit. They can mint LP tokens and call addCollateral in Vault to stake the LP tokens for collateral.

  2. When RFQ providers want to remove collateral, they call Native’s off-chain API. Native’s systems validate the withdrawal amount to ensure that the removal would bring the RFQ provider’s position into default before returning a signature to allow collateral withdrawal.

  3. A whitelist of liquidators can liquidate the RFQ provider's unhealthy positions. However a signature from Native’s off-chain API is required to do so.

Last updated