# MetaRate Design Specifications

MetaRate in a nutshell(Workflow):
Users can collateralize their assets in the form of NFTs, to mint new vaults. Based on those vaults users can borrow funds from the lenders of the system. The borrowers have a fixed duration of one year and have the ability to gain leverage by taking out loans out from th ecosystem.

# Modules in MetaRate

1. SmartCell Minting
2. Vault Creation, Managment and workflow
3. Protocol Insurance
4. System BuyBack Module

## Smart Cell Design Concept

Smartcell is based on the universalvault standerd implemented by alchemix, but has some difference,i.e. it comes with inbuilt strategies, and after a certain time period, owner authed addresses.

interface IUniversalVault {
    /* user events */

    event Locked(address delegate, address token, uint256 amount);
    event Unlocked(address delegate, address token, uint256 amount);
    event RageQuit(address delegate, address token, bool notified, string reason);

    /* data types */

    struct LockData {
        address delegate;
        address token;
        uint256 balance;
    }

    /* initialize function */

    function initialize() external;

    /* user functions */

    function lock(
        address token,
        uint256 amount,
        bytes calldata permission
    ) external;

    function unlock(
        address token,
        uint256 amount,
        bytes calldata permission
    ) external;

    function rageQuit(address delegate, address token)
        external
        returns (bool notified, string memory error);

    function transferERC20(
        address token,
        address to,
        uint256 amount
    ) external;

    function transferETH(address to, uint256 amount) external payable;

    /* pure functions */

    function calculateLockID(address delegate, address token)
        external
        pure
        returns (bytes32 lockID);

    /* getter functions */

    function getPermissionHash(
        bytes32 eip712TypeHash,
        address delegate,
        address token,
        uint256 amount,
        uint256 nonce
    ) external view returns (bytes32 permissionHash);

    function getNonce() external view returns (uint256 nonce);

    function owner() external view returns (address ownerAddress);

    function getLockSetCount() external view returns (uint256 count);

    function getLockAt(uint256 index) external view returns (LockData memory lockData);

    function getBalanceDelegated(address token, address delegate)
        external
        view
        returns (uint256 balance);

    function getBalanceLocked(address token) external view returns (uint256 balance);

    function checkBalances() external view returns (bool validity);
}

A few changes to be made to that above template,
1. when an user lock erc20, it goes and stakes it in some custom coded yearn strategy,( we can also build upgradable contracts in possible throughe 'delegate' call so that we can change and direct user staked funds to the new strategy, or use a thrid party like an aggregator(low maintenance)).
2. When an user unstakes, the user pays (current balance-original balance/2 -> protocol buybackadddress; this flow reverts if the C.B-O.B=-ive).
3. Add the ability for each vaults for transferring the funds to the Protocol Insurance module after liquidatecell() has been called.The function is called after fixed term of one year, or as per the vaults settings. The liquidatecell function grabs the entire stake amount, unwraps the funds deployed in any strategy, withdraws it and swaps it for DAI, if not DAI itself and then send it to the ProtocolInsurance module. (the swap to dai is done in the unstake() function call too.)
4. In summary the vaults along with having it own owner also has any public function call for its liquidatecell() on its behalf after the term has passed.

So by doing this, we can have series of vaults that could be added to the system through the comptroller. Where the smartcell gets minted when an nft is sent, the smartcell is designed to accpet list of nft by its issuer/orchestrated address which now is the protocol comptroller. The list could be updated at any time. New vaults could be added and keepers can manage the existance of the vaults. Vaults can have purpose specific stretegies for deploying the funds or could be designed to be upgradable(completely optional, can ve scratched off or left for v2)

## Vault Creation Management and workflow

The vaults in the system refer to the core module which accepts the SmartCell collateralize it and mints virtual in-system unit, representing $, called vUSD and mints mxrate token (as per the oracle price, using band's oracle ) to refelct the vUSD minted, swap it for DAI/USDC/ETH using a periphery contract mxrateproxy.

> We can design the system to have, three contracts- Comptrollermaj, Liquidation, Liquidation_Auction, Protocol Insurance.


*Comtrollermaj* is the where the core logic of the system is stored, this is where new vault types are initiated, through _addvaults() system function, ran by the authed users. Users create new vaults through by sending protocol accepted smartcells. When the user post their collateral through the post_coll() the contract reads the amount of vaule staked in the smartcell by the user, which then gets added to the total_collateral for the user in the system for that particular collateral(vault). When the user would like to withdraw_coll() the protocol runs a check that whether the system is maintaining the minimum collateralization ratio, which is represented by the $\frac{collateral}{debt}$, debt in the system for a particular vault is created when the user calls borrow(), the protocol reverts the borrow call, if the new debt requested would exceed the borrow(). A user can have different vaults of different collateral type (smartcells).

When the MCR has defaulted, any user can call in Liquidate function on any vaults, which would rewards them with 'x' mxrate tokens. Users while calling in the liquidate function, mentions the collateral type and user address. The Liquidation contract grabs() the collaterals of the user and send it to the auction contract. The debt defaulted by the to-be-liquidated-vault is dedcuted from the comtrollermaj and is added to the Liquidation contract. The liquidation contract receives the highest bid from the auctioncontract.Teh debt stpred int he liquidation contact is an *unsigned integer*.

When an Liquidate function has been successfully called the collaterals stored in a vault are liquidated and are added in successve auctions`(if there are more than 1 smartcell in the vault for the same collateral type)` in which users can take part in, the auctions run for `_ttl`,48 hours, when the auction starts the highest bidder receives the smartcell which contains the NFT along with the value staked system in the smartcell.

When a bidder bids in the system it becomes a permanent commitment in the contract, for that auction of lets say collateral_id[1] the contract keeps 'x' amount of mxrate token, the commitment has been finalized onchain. Now when a new user wants to bid even higher lets say 'x1' for that collateral_id[1], the auction contract sends the 'x' mxrate tokens to the first bidder and finalizes the highest_bid to be 'x1'; this process goes on successively until the auction time ends and the smartcell for a particular auction is sent to he highest biddder.The auction is restarted after **`ttl`** if it hasnt received any bid in that time period. The mxrate tokens receievd are burned and the $ amount represented by the mxrate balances the vusd stored in the `debt_lq` param of the Liquidation contract and the `debt` param of the auction contract

However when the `debt` param stored in the auction function gets over a certain amount (as decided by the governance) the activeinsurance() can be called upon.

## Protocol Insurance design concept-

This module is responsible for restoring balance in the ecosystem, when 'too much' of bad debt has been accumulated. This soaks out the open market mxrate tokens with the help of PI_core and backstop_core and burns the tokens to balance the system.


With activeinsurace() call, the system passes the baddebt accumulated in the auction contract to the protocol Insurance contract. The job of the Protocol Insurnace module is to cease the baddebt, by making use of its DAI and mxrate reserve. Users can deposit DAI and mxrate and in return they receive LM rewards.

There will be cool down period of 21 days noticed in both the liquidity mining rewards and when users want to withdraw there share from the pools.

During the auction taking place in the PI_Core, the module uses a maximum of 70% of the deposited fucnds stored in the protocol and offers to buy that much of the debt worth of mxrate tokens, in accordance to the value receievd from thr oracle to take care of the baddebt. The inital price offered by the protocol in the auction is a fucntion of time, where iniatally it offers the exact amount of price as noted by the oracle and during the final hour it offers and additional 10% price on top of the oracle reporte price to buy mxrate tokens off from the market.

### The distribution logic of the rewards for the protocol insurance is as follows


Reference- https://github.com/aave/safety-module

Whenever the LiquidateCell() and Liquidate() is successfully called the protocol mints 'x units' of tokens to reward the liquidator for maintaining the prootcol successfully.

## System Buy-Back Module(SBM)-

This module accepts the revenue generated from the smartcells in the form of DAI along with the collateral when liquidatecell() is called. After enough reserve has been accumulated (lets say x amount of DAI) anyone can call in the activeSBM(). This function allows the contract to lets users deposit mxrate tokens which then gets clubbed with similar amount of DAI from the reserve and the LP token gets staked in the module. The depositors receive tokenized postion of their share and can claim their LP token from the SBM. If the holders claim their share before 24 months, they recieve half their share after 6 months from the time when they first staked. The module has different tranches. Whenever a tranche has been filled up, a new tranche is initated which starts to accumualte the revenue and the collaterals driven from liquidatecells() fucntion call. The contract addreess where the collaetrals and revenue are stored are kept in a deletege address, which can be upgraded once a new tranche is initiated.

# Governance

We fork compounds governonr bravo adn work on it.