Skip to main content
This page focuses on the conceptual role of the Super Vault.
For function‑level details and contract interfaces, see the Core Components and Integrate EarnUSDT pages.

Summary

Super Vault is the single pooled portfolio that sits behind EarnUSDT and quietly handles all the complexity for you. It collects user capital from the Cooldown Vault, allocates it across Kaia‑native and multichain strategies, and exposes a single portfolio value that determines the EarnUSDT share price.
  1. Liquidity‑managed & RWA‑ready: A cooldown window lets the system plan redemptions in advance, so it can safely use less liquid DeFi and RWA strategies while still meeting user withdrawals.
  2. Multichain aggregation via Runespear: Super Vault can bridge capital to other chains (like Ethereum) and pull it back, using Runespear to keep cross‑chain accounting conservative and in sync.
  3. Strategy engine, not a single farm: Your deposit is spread across multiple on‑chain strategies (Kaia DeFi + multichain), with allocations adjusted over time rather than chasing a single yield source.
  4. Governance, fees & risk controls: Strict role‑based permissions, health checks, loss limits, pause switches, and automated fee logic (management / performance fees, currently set to 0%) are all enforced on‑chain to keep operations controlled and user yield transparent.

1. Role in the vault stack

At a high level, the Kaia-side stack looks like this:
User ↔ Cooldown Vault ↔ Super Vault ↔ { Kaia strategies, OriginVault ↔ RemoteVault ↔ remote strategies }
Cooldown Vault (Kaia)
  • Entry/exit pool for users.
  • User flows reach this vault only via SuperEarnRouter; it does not expose direct user deposit or withdrawal entrypoints.
  • Enforces cooldowns, loss limits, and other user‑facing safety policies.
  • Mints/burns EarnUSDT based on the price‑per‑share that ultimately comes from the Super Vault and its connected vaults.
Super Vault (Kaia)
  • Aggregation layer that:
    • Collects capital from the Cooldown Vault.
    • Decides how much to keep on Kaia vs. how much to send to multichain strategies.
    • Keeps the Kaia‑side portfolio aligned with target allocations and risk limits.
  • Conceptually, it is the “single portfolio” whose value backs EarnUSDT.
OriginVault (Kaia, ERC‑7540‑like)
  • Cross‑chain hub for capital that leaves Kaia.
  • Holds USDT earmarked for strategies on other chains.
  • Manages queued deposits and withdrawals through an ERC‑7540‑like async redemption model (not formally ERC‑7540) that must be processed via bridge and messaging layers.
  • Works with the bridge/accounting components to track all assets “in transit”.
RemoteVaults (e.g. Ethereum)
  • Vaults on remote chains that receive bridged assets.
  • Deploy funds into whitelisted DeFi and RWA strategies (e.g. Morpho, RWA protocols, other vaults).
  • Their value flows back through OriginVault and the Super Vault, and ultimately appears as a higher share price for EarnUSDT on Kaia.
All of these pieces together define the total assets that back EarnUSDT. The Super Vault is the place where this portfolio is logically aggregated.

2. What counts as “Super Vault assets”

When we talk about “total assets backing EarnUSDT”, we are really talking about the Super Vault’s consolidated view of:
  • Idle USDT on Kaia (liquidity buffers).
  • Positions in Kaia‑native strategies.
  • Cross‑chain assets, including:
    • Shares in OriginVault on Kaia.
    • Assets and strategy positions in RemoteVaults on other chains.
    • Assets currently in flight across the bridge.
Because cross‑chain transfers and messages are asynchronous, the system uses a conservative accounting model:
  • Transfers in progress are tracked in a bridge queue and via the accounting layer.
  • Assets are not treated as “arrived” until they are visible and confirmed on the target chain.
  • State snapshots piggybacked on cross‑chain messages keep Origin/Remote views consistent over time.
This means:
  • In short periods of heavy cross‑chain activity, numbers may be slightly conservative.
  • As messages and transfers settle, accounting converges to the exact true value without double‑counting.
For more on the cross‑chain accounting model, see the Runespear & Messaging page.

3. Capital routing & portfolio engine

The Super Vault does not hard‑code a single yield source. Instead, it acts as a portfolio engine that: Concretely, this looks like:
  • Maintaining a liquidity buffer on Kaia to serve redemptions and operational needs.
  • Deploying part of the capital into Kaia DeFi / RWA strategies via dedicated strategy contracts (e.g. StrategyMorphoGauntletUSDTVault).
  • Sending another part into multichain strategies, by:
    • Depositing into OriginVault on Kaia.
    • OriginVault coordinating bridging to RemoteVaults on other chains.
    • RemoteVaults investing into curated DeFi/RWA strategies (e.g. Morpho vaults).
From the Super Vault’s perspective, all of these positions roll up into a single notion of “portfolio value”, which is what ultimately backs EarnUSDT.

3.1 Vault + Strategy structure

Under the hood, the Super Vault follows a vault + strategies model:
  • The Super Vault itself is a tokenized vault that issues shares (EarnUSDT on Kaia).
  • It delegates capital to a set of strategy contracts, each of which knows how to interact with a particular yield source (e.g. Morpho, RWA vaults, or OriginVault for cross‑chain deployments).
  • Each strategy has parameters such as:
    • Debt ratio – max share of the Super Vault’s assets it is allowed to manage.
    • Min / max debt per harvest – how fast the position can scale up or down.
    • Strategy‑level performance fee (strategist fee) – optional share of profits for the strategy implementer.
The architecture supports multiple strategies per vault, allowing the portfolio engine to:
  • spread risk across different protocols and sectors,
  • cap exposure to any single strategy, and
  • adapt allocations as markets change.
In practice, EarnUSDT uses a curated subset of strategies chosen through the opportunity‑set and risk‑framework process, rather than trying to chase every possible yield source.

3.2 Supporting automation & safety rails

Several supporting components work around the Super Vault + strategy layer:
  • LightKeeper (Kaia / remote) Off‑chain helpers call the LightKeeper contracts to harvest and tend strategies:
    • harvests(strategies[]) realizes profit/loss and reports it back to the vault.
    • tends(strategies[]) rebalances positions without realizing profit/loss.
    • Helpers use harvestTrigger() / tendTrigger() on each strategy to decide when it’s worth calling, taking into account gas costs and expected gains.
  • CrosschainKeeper (Kaia / remote) Coordinates bridging and remote vault operations, including:
    • bridging idle USDT between OriginVault and RemoteVaults,
    • depositing into / withdrawing from remote vaults,
    • processing redemption queues and fulfilling withdrawals in batches.
    From the Super Vault’s point of view, CrosschainKeeper is what keeps the cross‑chain part of the portfolio in sync with target allocations.
  • HealthCheck Each strategy can be wired to a HealthCheck contract that enforces profit / loss bounds per harvest. If a harvest would realize an unexpectedly large loss or gain (e.g. due to oracle issues or abnormal behavior), the transaction can revert and alert operators.
  • BaseFeeOracle / FeeOracle To avoid harvesting when gas is too expensive relative to expected yield, strategies can consult a base‑fee oracle, which decides whether current gas prices are acceptable for running harvests.
  • Roles around the Super Vault The vault stack follows a layered role model:
    • Governance – ultimate authority, can change system‑level parameters (fees, deposit limits, emergency shutdown, role assignments).
    • Management – day‑to‑day portfolio management (strategy onboarding/removal, health‑check tuning, liquidity thresholds).
    • Guardian – emergency responder that can pause vaults in critical situations.
    • Keeper – hot‑wallet or bot roles that drive automation via LightKeeper / CrosschainKeeper, with limited authority.
This separation lets the Super Vault operate largely automatically, while still having clear safety rails and escalation paths for operators.

3.3 Fee model (management & performance fees)

The underlying vault contracts that implement the Super Vault support the two fee types:
  • Management fee
    • A flat annualized rate on total assets under management (AUM).
    • Accrued over time and taken when strategies harvest, by minting vault shares to the rewards/fee recipient.
    • Economically, this slightly slows the growth of price‑per‑share compared to gross strategy performance.
  • Performance fee
    • A percentage of realized profit on harvests.
    • Also charged in shares at harvest time, taken out of the gain before it is reflected in the share price.
    • Can exist both at the vault level (protocol/treasury fee) and at the strategy level (strategist fee via StrategyParams.performanceFee).
For the EarnUSDT Super Vault on Kaia, these fees are currently configured to 0%, so all realized yield flows through to users (modulo external protocol fees). If fees are ever turned on:
  • The UI and docs will display APY on a net‑of‑fee basis.
  • Fees will continue to be taken only from yield, not by charging explicit withdrawal spreads or hidden mark‑ups.

4. Withdrawals and liquidity management

When a user initiates a redemption of EarnUSDT:
  1. The request is created on Kaia via SuperEarnRouter and flows through the Cooldown Vault, starting a short cooldown period (CooldownVault is not directly callable by users).
  2. During this window, the system:
    • Draws on Kaia‑side liquidity buffers.
    • Brings capital back from remote chains via the same path in reverse (RemoteVault → OriginVault → Super Vault → Cooldown Vault).
    • Unwinds or rebalances strategy positions as needed, subject to:
      • Max loss thresholds,
      • Slippage limits,
      • Bridge safety checks and timeouts.
  3. After the cooldown and internal settlement complete, the user receives Kaia USDT at the price‑per‑share locked in when the request was made (see $EarnUSDT for token‑level details).
From the Super Vault’s point of view, this is a controlled shift from invested positions back into idle USDT while withdrawals are being met, rather than a forced fire‑sale of underlying assets.