# ITIP003 - Index Coop Vaults

Aggregating research for Vaults/ Vault Issuance on top of SetTokens.

# Table of Contents

[TOC]

## Design Considerations

### Gasless Issuance via EIP-2612

[EIP-2612](https://eips.ethereum.org/EIPS/eip-2612) allows extension of EIP-20 standard with a new function ```permit``` allows users to modify the ```allowance``` using a signed message, instead of through ```msg.sender```.

This can enable users to permit Index Coop contract to use their funds sometime after they sign the message, and Index Coop and can build infrastructure to bulk mint setTokens for them, and save them gas costs.

**To be researched further by Product team**.

### Notes

##### Downsides:
* Adds some complexity
* Also adds time to delivery
##### Positives:
* We can use a standard ERC4626 design at launch and get most of the benefits
* We can we upgrade to EIP 2612 later
##### Upgrading to Add ERC 2612 later
* The majority of the extra work to enable this functionality (90%) would be to create the service for a keeper network to manage and queue up transactions for users
* So it makes sense to set up the Smart Contracts to be EIP2616 ready from day 1 but not enable that functionality until later on.
* Only 10% more work
##### Safety Considerations
* What are potential exploits we need to mitigate?
* What exactly is the transaction flow etc?
* User has to sign an approval, but also has to deposit funds
* Research EIP721 - gasless permit to spend tokens
##### Strategy Execution
* When should the vault’s funds be used to perform a Flash Mint?
* Should there be a minimum $$ threshold?
* Should we factor in the current gas price?
* Can we make issuance and redemption instant?
* Can we use a third party like Biconomy?

Some some more discussion around gas incentives and thresholds can be found in **Decentralised Mint section**.

## Vault Share Accounting

Vault Share calculations is a crucial piece of the puzzle, and need to be thought through before implementation. This logic is a key attack vector on the vault and its funds.

### How many shares should a deposit() call mint?

Shares to mint should be proportional to the increase in the *balance* of the vault ie the share *supply* should increase in proportion to the increase in the total net worth of the vault (Reserve Balance+ setToken *Redeemable* Balance)

An equation that expresses the above logic for vault share calculation -

a = Amount to deposit
B = Balance of vault before deposit
s = Shares to mint 
T = Total shares before mint 

$$
{a + B \over B } = {s + T \over T }
$$

When a user deposits amount a , we will check for balance and share supply before the deposit, and solve for s using the above equation.

Simplifying the above the equation

$$
s = {aT \over B}
$$

As an example,
Lets consider a scenario with Vault build on top of MMI setToken.

Assuming some values :

MMI Balance in Vault : 50 units
MMI NAV : 1.2 USDC 
MMI *Redeemable* Balance = 50 * 1.2 = 60 USDC 
Current Reserve Size : 40 USDC
Current Share Supply : 100 units 

Allice deposits 20 USDC into the vault, to calculate shares to mint

$$
s = {20 * 100} \over 100
$$

The vault is supposed to mint 20 shares for Alice.

### How much amount should a withdraw() call return?

Shares to burn should be proportional to the descrease in the *balance* of the vault ie the share *supply* should descrease in proportion to the decrease in the total net worth of the vault (Reserve Balance + setToken *Redeemable* Balance)

$$
{B - a \over B } = {T - s \over T }
$$

When a user burn shares s , we solve for a ie the amount that is returned to the user

Simplifying the above equation

$$
aT = sB
$$

### Edge cases

##### Edge case (A) - What if the value of underlying assets change between deposits *before* the reserve is invested into the strategy?

A sequence of events we want to test the our share calcuation logic for -

Vault has 40 USDC as reserve, 50 MMI Tokens with NAV 1.2 USDC
Alice Deposits 20 USDC 
MMI NAV falls to 1.1 USDC
Bob deposits 20 USDC
Alice withdraws all their funds
Bob withdraws all their funds

Let's run the shares calculation again with the above edge case -

State before User Alice's Deposit 
Share Supply : 100 units 
MMI Balance in Vault : 50 units
MMI NAV : 1.2 USDC 
Vault Reserve Size : 40 USDC

Alice deposits 20 USDC in the vault

Alice's Deposit size : 20 USDC 
Share Supply : 100 units 
Reserve size = 40
MMI Balance in Vault : 50 units 
MMI NAV : 1.2
MMI *Redeemable* Balance = 50 * 1.2 = 60 USDC
Total Balance before deposit = Reserve + MMI Redeemable Bal = 100 USDC 

Shares to mint for Alice would be -
$$
s = 20 * 100 \over 100
$$

$$
s = 20
$$

Bob also deposits 20 USDC in the vault, however the value of MMI setToken is now 1.1 USDC

Alice's Deposit size : 20 USDC 
Share Supply : 100 units + 20 units for Alice = 120 units
Reserve size = 60 (initial 40 USDC + Alice's deposit)
MMI Balance in Vault : 50 units 
MMI NAV : 1.1 (changed before Bob's deposit)
MMI *Redeemable* Balance = 50 * 1.1 = 55 USDC
Total Balance before deposit =
Reserve + MMI Redeemable Bal = 115 USDC 

Shares to mint for Bob would be -

$$
s = {20 * 120} \over 115
$$

$$
s = 20.86
$$

Thus, Bob gets more shares than Alice for the same amount deposited as the NAV of the setTokens in the Vault *decreased* between their deposits.

Alice withdraws from the vault

Alice shares = 20
Reserve sizes = 80 USDC (Inital Reserve + Alice's Deposit + Bob's Deposit)
MMI Balance = 50 
MMI NAV = 1.1 USDC
Total Vault  Balance before withdrawal = 135 USDC
Total Shares supply = 140.86

$$
a = {20 * 135} \over 140.86
$$

$$
a = 19.16
$$

Alice gets 19.16 USDC back from the vault, mainly due to the NAV change after her deposit.

Bob withdraws from the vault,

Bob's shares = 20.86
Reserve size = 60.84 USDC (Inital Reserve + 
Alice's Deposit + Bob's Deposit - Alice's Withdrawal) = 
MMI Balance = 50 
MMI NAV = 1.1 USDC
Total Vault  Balance before withdrawal = 115.84 USDC
Total Shares supply = 140.86

$$
a = {20.86 * 115.84} \over 120.86
$$

$$
a = 19.9935
$$

Bob gets their full ~$20 back on withdrawal as they had deposited *after* the fall in MMI NAV.

#### Note on Balance

The *balance* of the vault should be denominated and expressed in ETH or USDC. Vault built on products like icETH, dsETH can be denominated in ETH, while MMI can be denominated in USDC. Composite indices can be in ETH or USDC, this is TBD and evaluated.

## Mint Management and Costs

As capital accumulates in the Pool Reserve, an external actor needs to invoke the rebalance from USDC/ETH to underlying setToken. Let's call this function as `invest()`. Below, we discuss the who, when, and how of the `invest` function.

### (A) IC Managed Mints - Instant
An IC bots listen for deposit() events and flashmints the underlying token for each deposit.

#### Pros :
- Vault shares provide maximum value ie no cash drag as capital is always under use.
- Users mint for 20-30% of the earlier gas cost.
#### Cons
- High capital cost for IC. This likely would be more expensive than POL losses in some cases.
- Centralized minting mechanism, dependent on IC’s keeper infra upkeep.

### (B) IC Managed Mints - Periodic
IC bots listens for deposit() event periodically and flashmints the underlying token to the vault. Periodic flashmint frequency can be decided based on popularity of the product. For ex icETH would be need to be Flashminted 2-3 times a week, while something like dsETH could be minted once a week.

#### Pros :
- Much more capital efficient for IC.
#### Cons
- Slightly lower value accrued for capital due to cash drag ie capital sitting idle between flash mint calls
- Centralised

### (C ) Decentralised Minting - Threshold Discovery Based

Anybody can call invest() at any time, and is incentivised by 100% of a mint fee (ex 0.1% of the user funds in the reserves). This helps us let the market decide the right threshold based on the current state of gas markets.

Ex if gas cost to call invest is $100, at 0.1% mint fee, it would be profitable to call invest when reserves hit $100,000.

### (D) Decentralised Minting - Fixed Threshold & Incentive Based

Anybody can call flashmint(incentivised by the vault share capital OR IC capital) after capital reserve in the vault has hit a certain threshold. Vault share capital can be deducted in the form of a mint fee, and capital threshold set to a level where mint fee can cover the gas exp on most instances. For ex - if mint fee is 10 bps , a $10,000 capital threshold can incentivise upto $10 gas incentive. Keeping mint fee fixed, capital threshold can be changed periodically based on product popularity and gas markets.

#### Pros :
- Capital expenditure can be socialised amongst depositors.
- If IC incentivises a public() flashmint, it can still guarantee a hypothetical amount of revenue against capital expenditure.
- Decentralised
#### Cons :
- Incentives might not always be enough for users to call the flashmint.

## Architecture Considerations

### Initial Idea

### Modular #1

Vault, VaultStrategyExtension, NAV Helpers, Flashmint Contracts, SetTokens

#### Vault
The Vault contract takes in user deposits, maintains share acccounting, carries reserve funds until they are used to mint setTokens.

#### Vault Strategy Extension
Vault strategy extension carries all the instructions for minting setTokens when `invest()` is called. It will check for reserve size, underlying setToken prices etc before passsing parameters/instructions for minting.

#### Flashmint Contracts
Existing Index Coop Flashmint contracts which can take in vault funds and mint the setTokens to the vault.

#### SetTokens
SetToken contracts are basket of Governance, Yield, or Debt tokens.

#### NAV Helpers
NAV helpers act like oracles for underlying setTokens, which help vault share accounting and other calculations.

# Future Improvements

## Multi Asset Vaults

##### ERC4626 limitation:
A single ERC20 in a vault will have the same high cost to mint, Someone still has to pay this cost
Puts a limit on the number of strategies / complexity of the underlying vault token.
###### Proposed Solution:
* Multi-Asset Vaults with flexibility weightings
* Mint individual strategies at a time within a diversified product, Instead of minting a full basket every time
* Which strategy to mint be can defined by some logic
* Long term - can these house our portfolio tokens and help to solve liquidity challenges for minting


###### Resources
* [Miro Board](https://miro.com/app/board/uXjVMemPGPs=/)
* [Discord Discussion](https://discord.com/channels/942575405607559178/1078355239587033179/1083739574615937074)
* [Inital Vault Research Dump](https://docs.google.com/document/d/1u8s4dyEFjLI6BbeRsGsNkym1MylcNtmKUcXfzurO5rY/edit#)

## Open Questions
* Assets depeg between deposits? https://discord.com/channels/942575405607559178/1078355239587033179/1085567598923620392

### Problems for Asset Managers

#### Priority 1 for an Asset Manager is Outperforming ETH.
* Rebalancing, not being able to do Auctions
* Productivity of Idle Assets within the Set
* Ex : xSushi.
* Once Assets have been added to the Set, they cannot be staked/invested for any other purpose.
* Composite + Yield Sets
* For Ex : APE has 30% inflation
* To be able to quickly add productivity capabilities within constraint timelines().
* Risk is still top consideration
* For ex : Lending based on rates on Aave.
* Can we add a simple invoke module to invoke ANY action using call data?
* Security Risks
* Whitelist of Contracts the Module can enable interactions with
*