good morning!!!!

Skip to content
Snippets Groups Projects
Commit 4e6e2155 authored by Jake Johnston's avatar Jake Johnston
Browse files

Merge branch 'docsUpdate' into 'master'

Docs update

See merge request ip/app!337
parents a3e0ab65 9bbbd1ae
Branches
No related tags found
No related merge requests found
# IPT Sale
GFX Labs will start the sale of Interest Protocol Tokens (IPT) on August 15th. The sale will last until the allocated IPT for public distribution has been distributed. This post introduces both IPT and Governor Charlie, along with how the sale of IPT will take place.
The IPT sale period has concluded, and the sale is no longer active at this time.
## IPT and Governor Charlie
......@@ -17,23 +17,4 @@ The GFX team will only retain a minority interest in the protocol. After the sal
Below is the initial distribution of IPT total supply:
![IPTdistribution](./IPTdistribution.png)
GFX has allocated 35,000,000 IPT (35% of the total token supply) to the token sale. Each IPT will sell for between 0.25 and 0.50 USDC, depending on demand. The exact price calculations are described below.
The new mechanism offers one million (1%) tokens per period at a starting price of $0.25 and a maximum price of $0.50. The sale has a minimum duration of 35 periods, a total of 32 days, to sell 35 million tokens (35% of the total supply) but will continue until the allocated supply is exhausted.
Each period, the sale parameters will reset to the base price ($0.25) and tokens offered (1m). The purchaser gets the same price regardless of the number of tokens purchased, but the price updates after each sale based on the number of total tokens purchased.
For example, at the beginning of a new day, a bidder could pay $250k (USDC) and receive 1m IPT; however, if the bidder instead paid $50k and received 200k IPT, then the next price would be $0.30. The next price is calculated by (tokens purchased / maximum offered)*(ceiling price - floor price) + floor price. Adjusting the price after a purchase encourages bidders to purchase while the remaining daily supply is high.
While the minimum duration of the sale is 35 days, which assumes maximum constant participation, we’re targeting closer to 2-3 months to complete the sale. By stretching out the sale over an extended period of time, the platform has more time to mature. From the distribution, during the sale, and thereafter the protocol is controlled by IPT holders.
GFX Labs will retain the right to change the maximum number of tokens offered, the duration of each period, the floor price, and the ceiling price. Since the IPT token will be in circulation outside our sale contract, the secondary market may independently develop. To reduce the arbitrage opportunity for MEV bots, we may increase the minimum price to align closer with the secondary market and favor people over bots.
Rather than doing a traditional 24 hours per period, we've chosen 22 hours. By selecting 22 hours, the start time will progressively change by two hours to make the sale more accessible across all time zones.
## Participate
To participate, visit the [sale page](https://interestprotocol.io/#/sale). Review the User Agreement and [Token Sale Contract](https://etherscan.io/address/0xFbD3060Fe1Ed10c34E236Cee837d82F019cF1D1d#code). Purchasers need to set an allowance for their USDC to the sale contract. All purchases are immediately deliverable.
This page is for general information purposes only. It should not be relied upon for accounting, legal, or tax advice.
*This page is for general information purposes only. It should not be relied upon for accounting, legal, or tax advice.*
\ No newline at end of file
# BPT Vault
## Overview
The BPT Vault is a sub-vault of users' main vault. The BPT Vault manages Capped Collateral tokens by holding the capped token in the BPT vault. Deposits to the BPT vault are made via the CappedBptToken contract, and withdrawals occur at the main vault. The sub-vault provides additional functionality and acts as a conduit without requiring users to interact with it directly.
Each BPT Vault has the same owner and sub-vault ID as its parent vault. New vaults are made by the Voting Vault Controller, similar to the Vault Controller. Unlike the primary vault, users **cannot** send assets directly to the vault. Users should not interact with the vault contract directly, other than to stake their underlying tokens or to collect rewards.
### NOTE
Any partial withdrawal or liquidation will unstake *all* of that token back to the underlying BPT. So if these tokens are to be staked again, it must be done manually via `stakeAuraLP()`
## Constructor
* uint256 id
* The number of the vault. The same as the Parent.
* address vault_address
* The address of the primary vault.
* address controller_address
* where the vault references for access to the protocol.
* address voting_controller_address
* where the vault references for access to the protocol.
## Modifier
* onlyVotingVaultController
* checks if _msgSender is the controller of the voting vault
* onlyVaultController
* checks if _msgSender is the controller of the vault
* onlyMinter
* check if _msgSender is the minter of the vault
## Functions
* function parentVault() external view returns (address)
* return address(_parentVault)
* function id() external view returns (uint96)
* return _vaultInfo.id;
* function stakeAuraLP(IERC20 lp) external returns (bool)
* Stakes all `lp` into Aura rewards tokens via the Aura booster contract
* If `lp` is AuraBal, stake occurs directly through rewards pool
* function claimAuraLpRewards(IERC20 lp, bool claimExtra) external
* Claim any rewards generated by the BPT
* `claimExtra` should only be true if the LP offers extra rewards, as it uses more gas
* Any unclaimed rewards are not included in the value of the BPT, and so do not contribute to borrowing power
* function unstakeAuraLP(address lp) external onlyMinter
* Allows the minter to unstake manually if desired
* function controllerTransfer(address _token, address _to, uint256 _amount) external onlyVaultController
* Allows the primary vault controller to transfer tokens (used for the liquidation)
* function votingVaultControllerTransfer(address _token, address _to, uint256 _amount) external onlyVotingVaultController
* Allows the voting vault controller to transfer tokens (used for the withdraw)
# Nft Vault
## Overview
The NFT Vault is a sub-vault of users' main vault. The NFT Vault manages Capped Collateral tokens by holding the capped token in the NFT vault. Deposits to the NFT vault are made via the UniV3CollateralToken contract, and withdrawals occur at the main vault. The sub-vault provides additional functionality and acts as a conduit without requiring users to interact with it directly.
Each NFT Vault has the same owner and sub-vault ID as its parent vault. New vaults are made by the NFT Vault Controller, similar to the Vault Controller. Unlike the primary vault, users **cannot** send assets directly to the vault. Users should not interact with the vault contract directly, other than to collect rewards.
## Constructor
* uint256 id
* The number of the vault. The same as the Parent.
* address vault_address
* The address of the primary vault.
* address controller_address
* where the vault references for access to the protocol.
* address voting_controller_address
* where the vault references for access to the protocol.
## Modifier
* onlyVotingVaultController
* checks if _msgSender is the controller of the voting vault
* onlyVaultController
* checks if _msgSender is the controller of the vault
* onlyMinter
* check if _msgSender is the minter of the vault
## Functions
* function parentVault() external view returns (address)
* return address(_parentVault)
* function id() external view returns (uint96)
* return _vaultInfo.id;
* function collect(uint256 tokenId, address recipient) external onlyMinter
* Allows the vault minter to collect any revenue generated by the Uni V3 Position
* Uncollected revenue is *not* included in the value of the position and so does not contrubute to borrow power
* function controllerTransfer(address _token, address _to, uint256 _amount) external onlyVaultController
* Allows the primary vault controller to transfer tokens (used for the liquidation)
* function votingVaultControllerTransfer(address _token, address _to, uint256 _amount) external onlyVotingVaultController
* Allows the voting vault controller to transfer tokens (used for the withdraw)
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment