Core Technical Concepts

Technical overview of a Decentralized Monetary Authority

This section will discuss the technical building blocks of Decentralized Monetary Authorities including their modular design, architectural components (which can be customized for each oneToken community) that enable the system to function, and the inheritance map of the oneToken interface. The code for ICHI and oneTokens is open-source and can be found by going to ICHI's GitHub page.

Modularity

A key principle of ICHI’s architectural design is Modularity. The ICHI platform allows for components to be modular (similar to a microservices architecture) in order to allow for simplified and safe updates/upgrades when certain logic within contracts need to be changed. Additionally, the platform has certain components that are meant to be permanent, yet can be upgraded through a Proxy process. This allows ICHI to be simple and safe to upgrade as well as customizable (as it pertains to oneToken implementations). It increases separation of concerns, enables code reuse, and gives clarity into which jurisdiction applies to each guarded function.

Architectural Components

Component	Function
ICHI Governance	Global governance controls the oneTokenFactory and manages global parameters. Governance itself is external to the oneToken system.
oneToken Factory	A contract that acts as a oneToken deployment mechanism. Global (ICHI) state information is stored and managed in this system-wide hub.
oneToken Governance	Governance of specific oneToken instances with user votes weighted by their holdings of the corresponding oneTokens in specific liquidity pools. oneTokenGovernance can replace oneToken modules or upgrade the core contract using the Proxy pattern.
Proxy Upgrade System	A system for upgrading smart contracts. It includes an Owner, Proxy Admin, and Proxy.
oneToken Vault	The core upgradeable (through a Proxy upgrade) contract owned by oneToken Governance that holds assets, mints and burns ERC20 tokens, and controls the process flow during the minting and redemption process, including coordinating modularized components.
Versions	oneToken Vault implementations that are published by deployers and admitted to the network by ICHI Governance. oneToken Governance can optionally adopt (upgrade, downgrade) an approved version of the oneTokenVault.
Oracles	Price feed modules that report the value of assets in the oneToken Vault through a normalized interface. The oneToken Vault passes Oracle price conclusions and volatility signals to Mint Master modules.
MintMaster	A Mint Master uses any available information to compute the current minting ratio. The Minting Ratio adjusts over time to maintain the exchange rate peg of a oneToken to 1 USD. The interface includes a maximum transaction volume figure (can be infinite) to accommodate anticipated future logic requirements. Since the rate can be up to 100% and the maximum volume can be as low as zero, the Mint Master can be a circuit-breaker if so desired. Oracles report volatility. MintMasters decide what to do.
Collateral Tokens	0-n stablecoins that are accepted in tandem with Member Tokens at 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). Since more than one kind of stablecoin can exist in the oneToken Vault at any given time, multiple stablecoin options can be given upon redemption. While there will likely be sufficient Collateral to back all outstanding oneTokens, each specific stablecoin is redeemable on a “while supplies last” basis.
Strategies	Trading contracts that invest funds in yield-farming contracts, receive other types of tokens and report balances of each type of token they hold. A Strategy interfaces with a oneToken contract through the Controller. The interface to the Controller defines the minimum viable requirements to be a compatible contract. Strategies will be admitted via the ICHI Governance and selected by oneToken Governance.
Controller	A global contract that executes the appointed strategies for a given oneToken Vault at the specified period of time. The Controller also implements system-wide invariants such as enforcing conservation of value or allowable fees/slippage rules.

The figure below provides a view of how each of the components in the oneToken system are deployed and what contract owns/admits each component.

oneToken Component Interaction

Inheritance Map

ICHI and the oneToken Factory were designed with Replaceable Modules to allow for flexibility and customization. With this in mind, we created the system to abide by a structured inheritance tree that contains specific interfaces. These interfaces provide guidelines and structure for each upgradable component in the system and ensure that once approved, these components are standardized for simple plug and play capabilities. The figure below shows the overall inheritance map of the ICHI and oneToken systems with each shape representing a Solidity contract that is either an Interface or an implementation contract.

Inheritance Map of original implementation of the oneToken Factory

Color Key:

Blue Squares: Interface

Green Oval: Abstract

Red Oval: Contract