ICHI Docs v3
Search…
ICHI Overview
Branded Dollars
Multichain
Subcomponent Guide
ICHI Branded Dollars are built in a modular fashion. This page describes the modular subcomponents and how they are built to enable the system to behave as expected.
Oracles
Oracles are price feed modules that report the value of assets in the oneToken Vault through a normalized interface. In the ICHI and oneToken system, Oracles are used for providing price feeds for project tokens, Collateral Tokens, and oneTokens. Price Oracles are vital to the correct operation of the system and are chosen based on preference for price feed source, interpretation (e.g. smoothing), and volatility-detection logic.
oneToken Oracles are structured in a reusable fashion. As Replaceable Modules, we expect Oracles to evolve and be customized towards the oneTokens they will be used for so the system assumes nothing about the operation of the Oracle itself. Instead, we define a normalized interface so that new implementations can be wrapped and used to report back the results of inspecting external sources. The figure below shows how the Oracle inheritance is structured. This enables flexibility and customization yet keeps to certain boundaries to ensure security.
Oracle Inheritance Map
The contracts in RED are each examples of different oracle implementations that can be used/implemented for certain oneTokens. Each implements separate logic and can be used as a price feed for certain assets.
- 1.UniswapOracleSimple.sol: Averages observations over configurable (but unchangeable) time periods. Returns a price in a configurable (but unchangeable) token. Multiple instances can support multiple time-periods or different index tokens. A single instance can be shared and has the ability to observe multiple quotes for multiple tokens using the same (unchangeable) time-period and index currency. Only Oracles that return quotes in registered Collateral tokens can be registered in the OneTokenFactory where it is assumed that all registered Oracles return a USD quote.
- 2.ICHIPeggedOracle.sol: Returns 1:1 without consulting external sources. Useful for gas optimization if the peg is assumed to be very strong.
- 3.ICHICompositeOracle.sol: Composes quotes from 2 or more other Oracles. For example, token:ETH feeding into ETH:USD would return a token:USD by executing both steps in series.
oneToken Governance determines which Oracle to use for each token in the oneToken Vault and sets the values of parameters the Oracle needs. Multiple different oneToken Vaults can share the same Oracle.
Mint Masters
The Mint Master is singularly concerned with one action: computing a Minting Ratio for a given oneToken. It computes the Minting Ratio using internally-defined logic based on observable on-chain data within or without the ICHI system.
Minting Ratio
The ratio of Collateral to project tokens required to mint a oneToken. For example, oneBTC at a 91% minting ratio would be minted with 91% USDC and 9% wBTC. The computation of the Minting Ratio is handled by external modules that are admitted by ICHI Governance and adopted into oneToken Vaults by their respective oneToken Governance.
Every oneToken has a Minimum Minting Ratio which is the minimum percentage of stablecoin that needs to be used to mint new oneTokens. oneToken holders can vote to adjust the Minimum Minting Ratio using the voting power calculated by the oneToken Governance contract.
Incremental Mint Master Implementation
Similar to other components of the oneToken system, Mint Masters are modular and enable minting logic to be customized for each oneToken community's needs. the Incremental Mint Master is an example of a simple Mint Master that can be implemented for a oneToken instance.
The Incremental Mint Master implements a Minting Step Change which controls the amount a minting ratio can change. A change to the minting ratio happens everytime: (1) Someone mints a oneToken, (2) someone redeems a oneToken. Whether the price moves up or down depends on whether the oneToken price is slightly below/above $1. In this instance of a Mint Master:
- Lowering the Minting Ratio decreases the portion of value to mint that must be supplied by the user in the form of Collateral tokens, and increases the acceptable amount of the value to mint that can be supplied in the form of the Project Token - risk on.
- Increasing the Minting Ratio increases the portion of value to mint that must be supplied by the user in the form of Collateral tokens, and decreases the acceptable amount of the value to mint that can be supplied in the form of the Project Token - risk off.
E.g. When the market value of the Project Token is in decline this has the effect of lowering the Community Treasury value which, if unchecked, could lead to a Reserve Ratio of less than 100%. By extension, the contract could become illiquid. In this case, the Minting Ratio increases automatically when the price of the oneToken is beneath $1. The now higher Minimum Minting Ratio can accelerate a price adjustment as well as place a floor under the automatic adjustments. In both cases, increasing the ratio of Collateral to Project Tokens in the Community Treasury gradually (through minting transactions) adjusts the Collateral Ratio. As this is adjusted in favour of more Collateral versus Project Tokens, exposure to possible value decline in the Project Token is reduced (risk off scenario).
Risk on/Risk off opportunity with the Incremental Mint Master
Reminder: This is one possible instance of a Mint Master. The modularity of oneToken Architecture accommodates flexible design. Every oneToken has a Mint Master which can be shared with other oneToken instances.
Collateral Tokens
Collateral Tokens are specific external ERC20 contracts with strong pegs to 1 USD. They serve three primary functions - minting oneTokens, redeeming oneTokens, and Collateral Ratio calculation.
Collateral in Minting and Redeeming oneTokens
Collateral Tokens are accepted and emitted in the Minting and Redemption processes. 0-n stablecoins are accepted in tandem with Project Token at a specific ratio, the Minting ratio, by the oneToken Vaults. Upon redemption of oneTokens, oneToken Vaults burn the oneTokens in return for stablecoins of equal value (Collateral Tokens) minus the redemption fee. Since more than one kind of stablecoin can exist in the oneToken Vault at any given time, multiple stablecoin options are always offered on a “while supplies last” basis.
E.g. If the contract accepts USDC and USDT as Collateral then the user may be forced to accept multiple stablecoins when redeeming their oneToken. This would be the case if their oneToken holdings exceed the USD value of a certain stablecoin in the Collateral Reserve. Thus redeeming 100 oneSUSHI when the Collateral Reserve includes 75 USDC and 75 USDT, the redeemer could elect to get 75 USDC for 75 oneSUSHI in one transaction and 25 USDT for the other 25 oneSUSHI through a second redeem transaction.
Collateral Tokens are owned by the oneToken Vault. Admission of Collateral Tokens is up to ICHI Governance which administers the oneToken Vault and enforces boundaries over oneToken deployments.
Note: Rebalancing Collateral Tokens could be accomplished manually if the oneToken Governance finds it beneficial, or automated as an ongoing process through a combination of Strategies and Controller logic.
Strategies
A Strategy is a modular contract that is purpose-built for deploying Collateral and Community Treasury funds, receiving multiple types of tokens, and reporting balances of each type of token it holds. These are one-time transactions, not ongoing processes, that can perform atomic actions on the Community Treasury and Collateral, usually involving one or more interactions with external staking and farming contracts. Strategies could entail like-kind trades that may be desirable in connection with a change of Collateral, staking assets, hedging, and many other asset allocation schemes. Strategy can be purpose-built to work with any external contracts and interact with multiple token types at any given time.
Characteristics and Limitations
- 1.Strategies must have functions to move funds around.
- 2.Strategies don’t rely on whitelisted tokens.
- 3.Strategies can interact with multiple token types, but can only be assigned to one known token*.
- 4.Strategies automatically execute allocations of the assets allocated to them (by the Controller or oneToken Governance) from the oneToken Vault.
*A known token is one that has been registered to the oneToken Vault. This process includes configuration of the Oracles.
E.g. The oneETH community has decided to put a Strategy in place that can provide ETH-ICHI to that respective pool on SushiSwap. They allocate 10% of their ETH and ICHI from their Treasury to the Strategy which will automatically deposit those tokens into the pool and get back LP tokens. At this stage the said Strategy may not be able to further deploy these LP tokens because it does not have that capability, depending on the developer’s preference for modularity or completeness. The Controller could instruct the Strategy to send those LP tokens back to the oneETH Vault and for the Vault to send those to another Strategy focused on using those LP tokens to farm and receive yield for the oneETH treasury. Strategy allowances (ERC20) facilitate the transfers and also give Controllers an indication of governance objectives. For example, Strategy A with LP tokens and an LP token allowance of zero, plus Strategy B with an infinite LP token allowance could be interpreted by a Controller as an indication that governance wants to move the LP tokens from Strategy A to Strategy B when feasible and affordable (gas). Controllers can use any specialized logic to determine actions.
Similar to the other modular components in the ICHI and oneToken system, Strategies will be admitted via the ICHI Governance and selected by oneToken Governance. oneTokens assign 0-1 strategies per known token which can help a UI value tokens in the Vault. While a Strategy can interact with multiple tokens, the logic is specified to a single known token within the Vault.
Controller
The Controller’s main function is to supervise and automate the transfer of funds between oneToken Vaults and Strategies. It can examine balances, other factors in the system, and any internal parameters (based on the Controller implementation) in order to rebalance funds. These configurable parameters do not need to be normalized across multiple Controller implementations.
Controllers can be reused across multiple oneToken instances and oneTokens can change Controllers. Each Controller is customized based on the features oneToken Governance wants to use.
Last modified 28d ago