oneToken Governance, technical overview

Within the ICHI system we divide governance into two sections based on scope of authority. Both sections rely on the same voting code (in separate instances) that enables voting rights based on tokens staked. The sections are divided into:

  1. Global (ICHI) Governance

  2. Local/Instance (oneToken) Governance

ICHI Governance

ICHI Governance is the system’s overall governance which we refer to as “global”. It is the highest level of authority and thus has the largest scope. It provides boundaries inside of which the oneToken Governance instances can function to govern their oneToken community-backed Collateral and Treasury. ICHI Governance is responsible for admission control as it pertains to:

  1. Accepting the creation of a new oneToken species, its initial configuration and its corresponding Community Governance contract.

  2. Adding a new Collateral Token to the list of “like kind” Collateral Tokens available in the Collateral Reserve for oneToken holders.

  3. Adding and removing implementation versions.

  4. Adding Oracle, MintMaster, Controller, and Strategy implementations.

Key components include

  1. Versions: oneToken implementations.

  2. Oracles: Price aggregators for each token in the Community Treasury and Collateral.

  3. MintMaster: sets the Minting Ratio.

  4. Collateral Tokens: USD hard pegged stablecoins accepted and emitted in the Minting and Redemption processes.

  5. Strategies: Modular contracts purpose-built for deploying Collateral and Community Treasury funds.


ICHI Governance also deploys oneToken implementations. It does so by specifying an initial configuration from the available predetermined options. This is done through the following steps:

  1. ICHI Governance includes the initial oneToken configuration and instructs the oneToken Factory to deploy a new oneToken contract.

  2. The oneToken Factory (owned by the ICHI Governance contract) validates the input including confirmation that only a pre-approved implementation Version, Oracles and Collateral are specified.

  3. The oneToken factory deploys the oneToken instance and the system of contracts is ready for service.

Components used in deploying oneTokens

oneToken Governance

oneToken Governance is akin to local or community governance. Each oneToken instance has its own community-led governance with the ability to decide on customized implementations of system components that are whitelisted by ICHI Governance. oneToken Governance is implemented as an address which can be an EOA (Externally Owner Account), multisig, or on-chain governance contract capable of emitting bytecode. Important issues that oneToken governance deals with include:

  1. Adjusting the Minting Minimum/Maximum or absolute Ratio for new minted oneTokens when using the Incremental implementation of the MintMaster, or working with other parameters chosen modules require.

  2. Adjusting the type of Collateral used, e.g. change USDC to DAI or a combination of both.

Each oneToken is a vote on treasury allocations, specific stablecoins parameters (like minting and redeeming fees), and on adoption programs.