What IUSD is in InfiniFi (and what it is not)

InfiniFi USD (ticker IUSD on CoinGecko, called iUSD across the codebase) is not a “stablecoin issuer” in the Circle/Tether sense. It is a receipt token minted when users deposit collateral (primarily USDC) into an on-chain system that then allocates that collateral across yield strategies. The entire token design is a risk-and-liquidity coordination game dressed up as a dollar token.

On Ethereum, IUSD is the ERC-20 at 0x48f9e38f3070ad8945dfeae3fa70987722e3d89c. CoinGecko lists its max supply as ∞, which matches the “mint on deposit” design rather than a fixed emission schedule.

The key mental model: IUSD sits at the base of a system that can (a) generate yield elsewhere and pay it to users who accept constraints and (b) absorb losses in a defined waterfall that can ultimately haircut IUSD itself by changing its internal accounting price. That last clause is the whole story.

The whitepaper frames this as a fractional-reserve banking analogue with a “duration gap” problem and a depositor-directed balance sheet; see the fractional-reserve framing. The tokenomics question is whether the incentives around liquidity choice and loss absorption create stability, or encourage users to farm yield until the first stress event forces a repricing.

Supply mechanics: mint, burn, and the hidden “rebase” via oracle price

IUSD supply is elastic. There is no fixed cap, no emissions curve, and no “allocation” bucket in the classic L1 sense. New IUSD is minted when someone deposits USDC through the gateway.

Two mechanics matter more than “circulating supply” charts.

1) Minting depends on an internal price, not a guaranteed 1:1. The minting logic computes how much receipt token (IUSD) to mint from an “asset token” (USDC) using prices pulled from the Accounting module. This is not just a unit conversion. If the protocol’s receipt-token price is moved, the mint rate changes.

2) Redemption depends on the same internal price, and can be queued. Redeeming burns IUSD and returns USDC, but the redemption controller can partially fulfill redemptions based on available liquidity and enqueue the remainder into a redemption queue for later claims.

The non-obvious part is how the system socializes tail losses. If losses exceed the buffers provided by “junior” participants (more on that below), InfiniFi can haircut all IUSD by updating the receipt-token oracle price downward. This is economically similar to a protocol-level devaluation.

This does not burn user balances. It reduces the protocol’s defined redemption value per IUSD. If you only think in ERC-20 balances, you will miss the actual loss mechanism.

Two smaller but still meaningful parameters exist at the edges. The protocol enforces minimum mint and redemption amounts (both are configurable by protocol roles), with defaults set in the minting and redemption controllers.

Yield and fee flows: who gets paid for taking which risk

InfiniFi’s incentive design is unusually explicit about “who earns yield” and “who eats losses.” That is good. It is also where most stablecoins fail when stress hits, because the incentives flip.

Yield accrual and distribution are centralized into the YieldSharing contract. It measures the system’s unaccrued profit or loss as the difference between total asset value (via Accounting and the farm registry) and the outstanding receipt token supply.

When yield is positive: the protocol mints new IUSD and distributes it to two groups: (1) holders of the staking vault token (siUSD) and (2) users in the locking module.

The distribution is not a simple pro-rata split. YieldSharing can weight returns using adjustable parameters:

This is the incentive engine. It can be used to keep enough capital locked to protect liquidity. It can also be used to overpay one constituency to bootstrap growth. The mechanism is neutral. The governance incentives are not.

When yield is negative: YieldSharing applies losses through a waterfall that is stated directly in the code comments: locking users → siUSD holders → iUSD holders, with the safety buffer absorbing small losses first.

That final step is the critical one. If losses exceed the safety buffer, and then exceed the total capital represented in the locking module, and then exceed the receipt tokens inside the siUSD vault, the remaining loss is applied by reducing the IUSD oracle price proportionally.

So the “yield-bearing stablecoin” label is incomplete. Holding plain IUSD is not yield-bearing in the protocol’s own distribution logic. Yield is routed to staking and locking users. Plain IUSD is the residual claimant that can be haircut if the buffers are insufficient.

For a direct comparison to another yield-linked design, see our Falcon Finance design.

Finally, the gateway can charge a zap fee on “zap-in” mints (swap other assets into USDC, then mint IUSD). The zap fee is capped at 1% (_zapFee <= 0.01e18) and fees are transferred as IUSD to YieldSharing.

Locking, siUSD, and governance power: incentive alignment or extraction surface

InfiniFi effectively sells two things: liquidity and loss absorption.

siUSD is implemented as an ERC-4626 vault over the receipt token. Users deposit IUSD and receive shares (siUSD). Profit is smoothed across epochs via “epochRewards,” and losses can be applied by slashing future rewards, current rewards, and principal in that order.

Two operational details matter for incentives:

That design is coherent. It prevents users from racing to exit before losses are accounted for. It also creates an obvious “panic focal point.” If users believe an accrual will realize a large negative yield, the rational move is to sell on secondary markets before the accounting catches up. This is the bank-run dynamic, on-chain.

Locking is a separate module where users lock IUSD into “buckets” defined by an unwindingEpochs duration. Buckets must be explicitly enabled by governance, and the code restricts bucket durations to 1-100 unwinding epochs.

Locking mints a distinct ERC-20 share token (a LockedPositionToken) per bucket. Those share tokens represent a pro-rata claim on the bucket’s receipt tokens.

From an incentive-alignment perspective, the locking module is trying to buy “committed capital” that can absorb losses before the senior token (IUSD) is repriced. In exchange, locked users get a larger share of profits via bucket multipliers and a global reward-weight system.

But this is also a place where incentive design can become extractive if governance is misused. Multipliers, maximum loss percentage, bucket availability, performance fee, target illiquid ratio, and liquid return multiplier are all levers. The “purist” stance is simple: every lever must be treated as an explicit redistribution policy. If it is not transparently governed, modelability collapses.

Governance and control plane (roles, timelocks, emergency action)

InfiniFi is not governed by a free-floating token. It is governed by roles in a Core access-control contract, with a very strong governor role at the top of the hierarchy.

The CoreControlled base contract also gives the governor an emergencyAction multicall that can execute arbitrary calls on arbitrary targets. That is operationally useful. It is also an explicit trust assumption.

Two more governance facts are structurally relevant:

Governance also reaches into the economic heart of IUSD through oracle control. The receipt-token oracle is set in Accounting by an ORACLE_MANAGER role, and the oracle itself can be updated by that role.

That means the “peg” is not purely market. It is a governed variable with a formal loss-absorption role. If you are evaluating IUSD as a stable asset, this is the first line you should underline.

Risk analysis: the bank-run game and a ranked risk register

Public market data captures the core risk in one glance: the IUSD price history shows an all-time low of $0.2431 on January 4, 2026 and an all-time high of $1.38 on January 11, 2026. For a token that markets itself as USD-adjacent, those dates matter more than any APY screenshot.

Dominant risk: liquidity mismatch plus discretionary repricing creates a reflexive depeg path.

The mechanism is structurally baked in:

Incentives under stress are harsh. Rational users do not wait around to discover whether they are above or below the loss-waterfall cutoff. They attempt to exit first. If exits are gated by “accrue then withdraw,” secondary market selling becomes the path of least resistance. That pushes market price below redemption value, which then changes beliefs about the system’s solvency, which accelerates the run. This is classic coordination failure.

InfiniFi’s countermeasure is to pay users to hold risk-bearing positions. That is what siUSD and the locking module do. When designed well, you get a stable base of sticky capital that absorbs normal volatility and small losses. When designed poorly, you get mercenary capital that shows up for yield and disappears at the first sign of accounting stress.

The hard part is parameter credibility. A system with many adjustable weights can remain stable, but only if governance has a track record of not extracting from one constituency to subsidize another. Otherwise, users price in political risk and the bank-run threshold moves closer.

If you want deeper frameworks for tracking these failure modes across protocols, browse our research reports.

Top 3 risks

  1. Bank-run dynamics and redemption gating, Trigger: a sudden rise in withdrawals or a fear event around strategy losses. Mechanism: redemption queue + exits blocked when unaccruedYield is negative, forcing users to seek liquidity in secondary markets and amplifying price dislocations. Who bears it: IUSD holders first via depeg, then everyone via haircut if losses exceed buffers. Measurable indicators: redemption queue length and pending claims, repeated PendingLossesUnapplied-style exit failures, and spot price trading persistently below internal redemption expectations.

  2. Governance and oracle control risk, Trigger: compromised multisig, governance error, or emergency intervention under pressure. Mechanism: governor-level emergencyAction authority plus ORACLE_MANAGER ability to set the receipt-token oracle that defines mint/redeem ratios and can be updated downward in loss scenarios. Who bears it: all users, but especially IUSD holders who rely on predictable redemption value. Measurable indicators: changes to oracle addresses, price updates in the receipt-token oracle, and unusual usage of emergencyAction patterns.

  3. Strategy and integration losses exceeding the buffer stack, Trigger: a major exploit or insolvency in underlying yield venues, or a sustained drawdown in the protocol’s deployed positions. Mechanism: losses flow from safety buffer to locked users to siUSD principal, and then spill into IUSD via oracle price reduction. Who bears it: first-loss capital providers (locked and staked), then senior IUSD holders if the shock is large enough. Measurable indicators: negative unaccruedYield, slashing events on siUSD (loss events), and receipt-token price reductions.

The bottom line from a tokenomics perspective: InfiniFi’s IUSD is a coherent mechanism design that pays for stability with explicit redistribution and an explicit haircut path. That can work. It is not “free yield.” It is a governance-heavy, parameterized balance sheet with a stablecoin UX wrapper.

If you are building something similar, treat the redistribution levers as first-class product surfaces. Users will. This is where tokenomics design services pay for themselves, because the failure mode is rarely “bad math.” It is incentives that look fine in calm markets and snap under coordination pressure.

If you need a quick baseline for stakeholder questions, start with our tokenomics FAQ.



This article is part of our Tokenomics Deep Dive series.