# Agent Gateway (MCP) Source: https://docs.ix.finance/developers/agent-gateway A hosted, read-only Model Context Protocol endpoint that lets AI agents query IX RWA assets, stats, and portfolios. IX RWA exposes a hosted, **read-only** [Model Context Protocol](https://modelcontextprotocol.io) (MCP) endpoint — the **Agent Gateway**. It lets AI agents and MCP-compatible clients read the protocol's live data directly: the IX-CORE index and its constituents, protocol statistics, and wallet portfolios. It is served by the app itself, so agents connect by URL — no install, no build, no repo. The Agent Gateway is **read-only**. Agent-initiated transactions (payments, allocation) are a roadmap item, gated behind the verified money-path and mainnet — see [Roadmap](/why-ix-rwa#roadmap). ## Endpoint ```text Endpoint theme={null} https://testnet.ix.finance/api/mcp ``` Transport is **Streamable HTTP** with stateless **JSON-RPC 2.0** (protocol version `2025-06-18`; server `ix-rwa` `0.1.0`). CORS is open, and JSON-RPC **batch** requests are supported. A plain `GET` on the endpoint returns server info and the tool names for a quick liveness check. ## Tools | Tool | Arguments | Purpose | | ---------------- | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | `list_assets` | `gpu?` (string), `availableOnly?` (boolean) | List index constituents with value, APY, daily revenue, and funding. Optional GPU-model filter / available-only. | | `get_asset` | `id` (string, required) | Full detail for one asset, including its on-chain ownership token address. | | `protocol_stats` | *(none)* | Protocol-level stats: AUM/NAV, NAV-per-share, total invested, protocol earnings, asset & holder counts. | | `get_portfolio` | `wallet` (string, required) | A wallet's positions, ownership, and yield. | ## Quickstart Send an MCP `tools/list` request to discover the tools above and their input schemas. `initialize` and `ping` are also supported. Invoke a tool with `tools/call`. For example, list only available H200 assets: ```json theme={null} { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "list_assets", "arguments": { "gpu": "H200", "availableOnly": true } } } ``` Note the argument is `wallet` (not `walletAddress`): ```json theme={null} { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "get_portfolio", "arguments": { "wallet": "0x…" } } } ``` ## Response shapes Tool results are returned as MCP text content containing JSON. Representative fields: ```json list_assets theme={null} { "count": 3, "assets": [ { "id": "…", "name": "…", "gpu": "H200", "numGpus": 8, "region": "…", "valueUsd": 250000, "apyPct": 18.4, "dailyRevenueUsd": 126.30, "investorPoolUsd": 150000, "fundedPct": 42.5, "fullySold": false } ] } ``` ```json protocol_stats theme={null} { "aumUsd": 0, "navPerShareUsd": 1.0, "totalInvestedUsd": 0, "totalProtocolEarningsUsd": 0, "assetCount": 0, "holders": 0, "network": "Base Sepolia (chain 84532)" } ``` `get_asset` additionally returns `description`, `reliabilityPct`, `hourlyRateUsd`, `tokenAddress`, and the `ownership` split (**40% IX / 60% investors**). AUM and NAV-per-share come from the **live on-chain vault** (6-decimals), matching the app — not a database sum. ## Use it from an MCP client Add the endpoint to any MCP-compatible client (for example, Claude Code): ```json theme={null} { "mcpServers": { "ix-rwa": { "type": "http", "url": "https://testnet.ix.finance/api/mcp" } } } ``` Or via the CLI: ```bash theme={null} claude mcp add --transport http ix-rwa https://testnet.ix.finance/api/mcp ``` ## Data, honestly The Gateway serves the same data the app uses. On testnet, NAV and yield are **simulated in settlement but driven by live market data** (the `LiveDataNAVOracle`, fed from live Vast.ai rates) as described in [Revenue & distributions](/protocol/revenue-and-distributions); realized on-chain figures are distinguished from simulated ones. # For institutions Source: https://docs.ix.finance/for-institutions An allocator's one-page overview of IX RWA — the instrument, thesis, key terms, and where to verify every claim. IX RWA gives allocators fractional, on-chain exposure to **income-producing AI compute** through a single index token, with reporting and reserves that are recomputable from public chain data rather than taken on trust. This page is the one-screen summary; every claim links to where you can verify it. ## The instrument | | | | ------------------ | ------------------------------------------------------------------ | | **Instrument** | IX-CORE — an ERC-4626 index vault share (ERC-20, 6-dec) | | **Underlying** | A book of GPU / AI-infrastructure assets, rented at market rates | | **Return source** | Real net rental revenue, accrued into NAV (not token emissions) | | **Pricing** | NAV-per-share = `totalAssets ÷ totalSupply`, recomputable on-chain | | **Subscription** | Deposit USDC, mint IX-CORE at NAV | | **Redemption** | Redeem at NAV — instant up to available cash, else FIFO queue | | **Fees (testnet)** | Entry 0% · exit 0.10% · management 1%/yr streamed | | **Network** | Base (Sepolia testnet today; mainnet after audit) | | **Custody** | Non-custodial — the wallet is the account | ## Thesis AI runs on compute, and compute is a **real, cash-flowing asset** whose ownership is concentrated in a handful of hyperscalers. IX RWA turns that asset base into an ownable, verifiable index — real yield from real utilization, priced and reported on-chain. ## How value flows ```mermaid theme={null} flowchart LR LP[Allocator] -->|USDC| V[IX-CORE vault] V -->|mint at NAV| LP HW[GPU compute] -->|rented| REV[Net revenue] REV -->|accrues| V V -->|NAV/share rises| LP V -->|redeem at NAV| LP ``` ## Trust & assurance posture Positions and NAV are derived from verified on-chain events, never client input. Every NAV move is a recorded attestation with an evidence hash you can recompute. Least-privilege roles; upgrades move to multisig + timelock at Phase-2. Third-party audit is a prerequisite for mainnet; report published on launch. ## Diligence trail * **Risk** — [Risk framework](/security/risk-framework) (register + mitigations) and [Risk disclosures](/security/risk-disclosures) * **Economics** — [Fees & terms](/protocol/fees-and-terms), [Revenue & distributions](/protocol/revenue-and-distributions) * **Valuation** — [Transparency & NAV](/protocol/transparency-and-nav), [Proof of Reserve](/protocol/proof-of-reserve) * **Contracts** — [Smart contracts](/protocol/smart-contracts) (verified addresses on BaseScan) * **Reporting** — [Reporting & assurance](/security/reporting-and-assurance) IX RWA is live on **Base Sepolia testnet** with clearly-labeled, simulated settlement. Nothing here is an offer, solicitation, or investment advice. Mainnet follows a third-party security audit — see the [roadmap](/why-ix-rwa#roadmap). # How it works Source: https://docs.ix.finance/how-it-works From a real compute asset to on-chain fractional ownership, revenue, and exit — the full lifecycle. IX RWA connects three worlds: **real infrastructure** that produces revenue, an **on-chain ownership layer** that makes it fractional and transparent, and **investors and agents** who allocate capital to it. This page is the mental model that ties them together. ## At a glance ```mermaid theme={null} flowchart LR A[Real compute asset] -->|onboarded as a cohort| B[On-chain registry + index weight] B -->|deposit stablecoin| C[Investor mints IX-CORE at NAV] C -->|compute is rented| D[Net revenue] D -->|accrues into NAV/share| C B -.->|verify| E[NAV and reserve coverage] ``` ## The lifecycle A compute asset (say, a GPU cluster with a known value and operator) is registered with an on-chain identity and wrapped in a **cohort vault**. It enters the IX-CORE index by a published, rules-based weight. An investor connects a wallet and deposits a stablecoin (USDC). The **IX-CORE vault** mints ERC-4626 shares at the current NAV-per-share — a slice of the whole index, not a single asset. The underlying compute is rented to operators and end-users. That gross revenue, net of operator and protocol fees, is the yield the index produces. The investor share of net revenue accrues into the vault, raising NAV-per-share for every holder at once — no claim step. Holdings, NAV, reserve coverage, and asset identity are all visible on-chain and surfaced in the app, so ownership and performance can be independently checked. ## Identity: your wallet is your account There is **no signup, email, or password.** Connecting a wallet *is* your identity — public browsing is open to everyone, and connecting is only needed to invest or manage a position. The wallet layer is powered by [Privy](https://privy.io), pinned to Base Sepolia testnet. Reads and writes are pinned to the protocol's active chain, so the app behaves correctly even if your wallet drifts to another network. ## The invest flow, precisely You approve the IX-CORE vault to spend your USDC. You call `deposit(amount)`. The vault takes your USDC and mints IX-CORE shares to you at the current NAV-per-share. The position is confirmed from the on-chain transaction — shares and value are read from the blockchain, not from the browser. ```mermaid theme={null} sequenceDiagram actor U as Investor participant V as IX-CORE vault (ERC-4626) participant N as NAV Oracle U->>V: approve + deposit(amount) N->>V: NAV-per-share V->>U: mint IX-CORE shares at NAV V-->>U: emit Deposit(owner, assets, shares) Note over U,V: Position is recorded from the verified on-chain event ``` **Design principle — the chain is the source of truth.** Ownership and value are derived from verified on-chain events, not from client-submitted figures. This is a hard requirement before any real value moves on mainnet. ## What's in the index At launch, IX-CORE is \~100% the **compute sleeve** (shown as a live weight). The index is designed to admit more sectors over time, each entering by a rules-based weight: | Sector | Examples | | ------------------------------- | ----------------------------------------------------- | | **AI Infrastructure**\*(live)\* | GPU clusters, accelerator fleets, data-center compute | | **Energy**\*(planned)\* | Solar, wind, and battery storage that power compute | | **Real Estate**\*(planned)\* | Data-center campuses and industrial facilities | ## Exit You exit by **redeeming IX-CORE at NAV** — the vault burns your shares and returns value, drained from the smoothing/redemption buffer. A secondary AMM market is deferred to pre-mainnet. ## Where to go next The contracts and how they fit together. What IX-CORE is, how it's priced, and what it entitles you to. # IX RWA Source: https://docs.ix.finance/index Tokenized ownership of real-world compute — fractional, on-chain, and transparent. IX RWA is a real-world asset (RWA) protocol for **compute**. It turns income-producing infrastructure — GPU clusters, accelerator fleets, and the data centers that house them — into a single on-chain index anyone can own a fraction of, track transparently, and earn from. IX RWA is currently **live on Base Sepolia testnet** (chain id `84532`) at [testnet.ix.finance](https://testnet.ix.finance). All figures shown in the app are **simulated and clearly labeled** testnet values. Mainnet launch follows a third-party security audit — see the [Roadmap](/why-ix-rwa#roadmap). ## What you can do today See the IX-CORE index and its constituents — the compute assets that back it, their operators, and their live weight. Deposit stablecoins and mint **IX-CORE**, one ERC-4626 token that represents your fractional ownership of the whole book. Live NAV, reserve coverage, and an on-chain asset registry — ownership you can recompute, not take on faith. A hosted, read-only **MCP** endpoint lets AI agents query the index, stats, and portfolios. ## The thesis in one line > Compute is the raw material of AI, it produces real cash flow, and it is almost entirely owned by a handful of hyperscalers. IX RWA makes it an **ownable, tradable asset class**. ## How the pieces fit Each compute asset (e.g. a GPU cluster) is registered on-chain with its identity, operator, and value, and enters the index by a rules-based weight. See [How it works](/how-it-works). You deposit stablecoins and mint **IX-CORE** at net asset value — a single token that owns the whole compute book, not one asset at a time. See [Ownership & IX-CORE](/protocol/ownership-and-ixd). Compute is rented out; net revenue raises the index's NAV-per-share, so your yield accrues automatically. See [Revenue & distributions](/protocol/revenue-and-distributions). NAV, reserves, holdings, and asset identity are all checkable on-chain. See [Transparency & NAV](/protocol/transparency-and-nav). ## New here? The end-to-end mental model. The market, the design principles, and where we're headed. The Agent Gateway (MCP) and data access. # Architecture Source: https://docs.ix.finance/protocol/architecture The smart contracts behind IX RWA and how they fit together. IX RWA is a set of upgradeable smart contracts on **Base**. A single ERC-4626 index vault (**IX-CORE**) sits on top of per-asset **cohort vaults**; a NAV oracle prices the index, an asset registry keeps identity verifiable on-chain, an attestor registry gates every NAV move behind recorded proof-of-reserve, and a smoothing reserve buffers yield and redemptions. ## Contract topology ```mermaid theme={null} flowchart TD U[Investor wallets] -->|deposit USDC / redeem at NAV| V[IX-CORE vault · ERC-4626] V -->|mint/redeem shares| U subgraph Pricing[NAV pricing seam] ORA[LiveDataNAVOracle · INAVOracle] -->|hardwareValueUSD| V ATT[AttestorRegistry · PoR gate] -->|setCohortValue| ORA end REG[AssetRegistry] -.->|cohortHasActiveAsset| ORA FEED[Off-chain EconomicsFeeder] -->|attest value + evidenceHash| ATT FEED -->|notifyRevenue| V RES[SmoothingReserve] -->|coverShortfall| V MC[MerkleClaim] -->|one-time BNB migration at NAV| U V --> TRE[Treasury · fees] ``` ## Valuation, exactly IX-CORE's price is fully mechanical — two terms, both readable on-chain: ```text theme={null} totalAssets() = USDC.balanceOf(vault) ← cash + accrued revenue (trustless) + navOracle.hardwareValueUSD() ← off-chain hardware value (INAVOracle seam) NAV-per-share = totalAssets() / totalSupply() ``` Depositing revenue raises the **cash term** (yield up); depreciation lowers the **oracle term** (NAV/share down). Units are USDC 6-decimals throughout. This is the mechanism that replaced BNB-era Merkle distributions — see [Revenue & distributions](/protocol/revenue-and-distributions). ## Components | Contract | Responsibility | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **IX-CORE vault** (`IXCoreVault`) | ERC-4626 accumulating index token. Mints/redeems shares at NAV; revenue accrues into NAV-per-share; holds the redemption queue. See [Ownership & IX-CORE](/protocol/ownership-and-ixd). | | **Cohort vaults** | One per SPV/batch; the construction unit. New assets become a cohort and enter IX-CORE by a rules-based weight. On testnet a cohort is a registry grouping, promotable to a standalone sub-vault later without changing the read surface. | | **NAV Oracle** (`LiveDataNAVOracle`) | Publishes per-cohort hardware value behind an `INAVOracle` seam. On testnet it is fed by the off-chain **EconomicsFeeder** from **live Vast.ai market rates + real hardware cost/depreciation/resale** — settled in test tokens, never hand-typed. Byte-identical to the mainnet oracle; only the feed source and settlement token change. | | **Attestor Registry** (`AttestorRegistry`) | The **proof-of-reserve gate**. Assigned the oracle's updater role so that, once the direct-EOA write is revoked (a pre-mainnet lockdown step), NAV can move only via a recorded attestation (attestor + `evidenceHash` + time). See [Security model](/security/security-model). | | **Asset Registry** (`AssetRegistry`) | The construction ledger: assets grouped into cohorts, each with cost basis, operator, lifecycle status, and a hashed hardware identity (machine + GPU serials). Drives which cohorts count toward NAV. | | **Smoothing Reserve** (`SmoothingReserve`) | A USDC buffer that smooths yield and funds the redemption queue. Custody only; its balance is public. | | **Merkle Claim** (`MerkleClaim`) | One-time migration airdrop converting former BNB holders into IX-CORE at NAV. See [Revenue & distributions](/protocol/revenue-and-distributions#why-accrual-instead-of-merkle-claims). | | **Treasury** | Receives protocol fees and reserve flows. | ## Roles & permissions Every privileged action is a named role, not an ambient owner. Roles are granted at deploy and move to a multisig / governance setup at the audited Phase-2 redeploy. See [Governance](/security/governance). | Role | Held by (testnet) | Can | | ------------------------ | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | `DEFAULT_ADMIN_ROLE` | Protocol admin | Set fee params, fee recipient, reserve/oracle pointers, register/retire assets, pause | | `ORACLE_UPDATER_ROLE` | AttestorRegistry (intended sole updater; EOA path revoked pre-mainnet) | Push cohort values into the NAV oracle | | `ATTESTOR_ROLE` | EconomicsFeeder (testnet) → real attestors (mainnet) | Submit an attested reserve value + evidence hash | | `REVENUE_DEPOSITOR_ROLE` | EconomicsFeeder | Call `notifyRevenue` to accrue revenue into NAV | | `KEEPER_ROLE` | Keeper / feeder | Process the redemption queue; quarantine assets on a bad/stale feed | | `SPENDER_ROLE` | Vault + keeper | Pull from the smoothing reserve to cover a shortfall | | `UPGRADER_ROLE` | Protocol admin | Authorize UUPS implementation upgrades | ## Redemption path A liquid share token sits on top of illiquid hardware, so exits are designed so they can't bank-run the reserve: ```mermaid theme={null} flowchart TD R[redeem / withdraw] --> C{owed ≤ availableCash?} C -->|yes| PAY[Pay instantly · exit fee skimmed] C -->|no| Q[Burn now, queue request · FIFO] Q --> PROC[KEEPER processQueue n] Q --> CLM[User claim reqId] PROC --> FUND{balance + reserve ≥ owed?} CLM --> FUND FUND -->|yes| OUT[USDC to receiver] FUND -->|no| WAIT[Stays queued · FIFO fairness] ``` `availableCash = balance − reserveFloor` keeps a buffer reachable only by the queue processor, never an instant sell. On the queued path the exit fee stays in the vault as extra buffer for remaining holders. ## Observability The protocol emits an event for every state change, so the indexer and transparency surfaces reconstruct state from the chain rather than from client input: | Event | Emitted when | | -------------------------------------------------------------- | --------------------------------------------- | | `Deposit` / `Withdraw` | Shares minted / redeemed (ERC-4626) | | `RevenueAccrued(cohortId, amount)` | Revenue deposited into the vault | | `RedemptionQueued` / `RedemptionFulfilled` | A redemption is queued / paid | | `FeesTaken(mgmtFeeShares)` | Streaming management fee minted | | `CohortValueSet(cohortId, old, new, at)` | Oracle hardware value updated | | `ReserveAttested(cohortId, value, evidenceHash, attestor, at)` | Proof-of-reserve attestation recorded | | `AssetIdentitySet` / `AssetStatusChanged` | Hardware identity anchored / lifecycle change | ## Upgradeability Core contracts are deployed behind **UUPS proxies**, so implementations can be upgraded without changing addresses or migrating balances. Upgrade authority (`UPGRADER_ROLE`) is held by the protocol admin today and moves to a multi-signature / governance setup at the audited Phase-2 redeploy. Each contract reserves a storage `__gap` so state can be extended across upgrades without collisions. Config is **chain-agnostic** — chain id, RPC, and token addresses are parameters, so a second chain later is a deploy, not a rewrite. ## The source-of-truth principle Ownership and positions are reconstructed from **verified on-chain events** by an event indexer, not from client input: ```mermaid theme={null} flowchart LR TX[On-chain deposit/redeem tx] --> EV[Transfer / Deposit event] EV -->|indexed and verified| BE[Chain-as-truth holder state] BE --> RPT[NAV, holdings, and reporting] ``` This is the invariant the protocol holds before real value moves on mainnet — see the [roadmap](/why-ix-rwa#roadmap). # Fees & terms Source: https://docs.ix.finance/protocol/fees-and-terms The IX-CORE fee schedule and redemption terms in one place — entry/exit/management fees, the reserve floor, and how exits are paid. Everything that affects what you pay and how you exit, in one place. IX-CORE follows OpenZeppelin's **ERC-4626 fees** pattern, so a `preview*` call always equals the actual result — there is no hidden slippage. ## Fee schedule | Fee | Parameter | Testnet default | Basis | How it's taken | | ----------------- | ----------------- | ---------------- | ----------------- | ---------------------------------------------------------------------------------------------- | | **Entry** | `entryBps` | `0` (0.00%) | On deposit amount | Skimmed on deposit, routed to the fee recipient | | **Exit** | `exitBps` | `10` (0.10%) | On redeemed value | Deducted on redeem; on the *queued* path it stays in the vault as buffer for remaining holders | | **Management** | `mgmtBpsPerYear` | `100` (1.00%/yr) | On NAV, streamed | Dust shares minted to the fee recipient pro-rata to elapsed time | | **Reserve floor** | `reserveFloorBps` | `0` (0.00%) | On total assets | Not a fee — a share of assets held back from *instant* redemption (queue-only buffer) | These are the **testnet** defaults. All four parameters are admin-settable, capped at 100%, and change through [governance](/security/governance); the current on-chain values are always readable on the [vault contract](/protocol/smart-contracts). ## How the management fee works The management fee is **streamed**, not charged in lumps: on every deposit, redeem, and parameter change (and on an explicit `pokeFees()`), the vault mints a tiny number of shares to the fee recipient pro-rata to the time elapsed since the last accrual. The effect is a smooth, predictable dilution rather than a periodic deduction — and because it is settled before any parameter change, a rate change never applies retroactively. ## Redemption terms IX-CORE redeems **at NAV**. Because a liquid token sits on top of illiquid hardware, payout is tiered: If the amount owed is within `availableCash` (vault balance minus the reserve floor), you're paid immediately. Larger exits **burn your shares now** and join a first-in-first-out queue. Your NAV is locked at redemption time; only the cash timing is deferred. A keeper processes the queue (`processQueue`), or you pull your own request (`claim`) once the vault balance plus the [smoothing reserve](/protocol/revenue-and-distributions#the-smoothing-reserve) can cover the head of the queue. * **No lock-up.** There is no minimum holding period; redemption is constrained only by available liquidity. * **No secondary market yet.** An AMM listing for instant secondary exit is a pre-mainnet roadmap item; until then, redeem-at-NAV is the exit. * **FIFO fairness.** A later, smaller request cannot jump an earlier, not-yet-fundable one. ## Migration terms (former BNB holders) Holders of the retired BNB-era token convert into IX-CORE **once**, via a one-time Merkle claim on Base, **value-for-value at NAV**. Claims are open until a published deadline; unclaimed shares are swept to the treasury after the window closes. Ongoing distributions are **not** Merkle-based — see [Ownership & IX-CORE](/protocol/ownership-and-ixd#migrating-from-the-old-bnb-token). All figures are **simulated testnet** values today. Fee parameters, redemption mechanics, and terms are finalized for mainnet at the audited Phase-2 redeploy. # Ownership & IX-CORE Source: https://docs.ix.finance/protocol/ownership-and-ixd IX-CORE is the single ERC-4626 index token that represents your fractional ownership of IX RWA's compute book. When you invest, you deposit stablecoins and mint **IX-CORE** — one ERC-4626 index token that represents your fractional ownership of IX RWA's entire compute book. You do not buy assets one at a time: IX-CORE owns the whole index, and its value tracks the net asset value (NAV) of everything inside it. ## IX-CORE at a glance | Property | Value | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Standard | ERC-4626 vault share (ERC-20), 6 decimals | | Symbol | `IX-CORE` | | Behaviour | **Accumulating** — revenue raises NAV-per-share, no separate payout | | Deposit asset | USDC (test), 6 decimals | | Network | Base Sepolia testnet (chain id `84532`) | | Share price | `totalAssets ÷ totalSupply` | | Entry / exit fee | `0%` / `0.10%` (testnet defaults) | | Management fee | `1%/yr`, streamed (testnet default) | | Contract | [`0x0dE437Ab692B0BD7baF158815ac08412A1680D73`](https://sepolia.basescan.org/address/0x0dE437Ab692B0BD7baF158815ac08412A1680D73) | IX-CORE is currently backed \~100% by the compute sleeve, shown as a live weight — not described as "diversified." New sectors enter the index by a published, rules-based weight as cohort vaults are onboarded. ## Share price, exactly Price is not set by anyone — it is computed from two on-chain terms: ```text theme={null} totalAssets = USDC held by the vault (cash + accrued revenue) + navOracle.hardwareValueUSD() (off-chain hardware value) NAV-per-share = totalAssets ÷ totalSupply ``` Both terms are readable on-chain at any time, so **NAV-per-share is recomputable**, never asserted. Revenue raises the cash term; hardware depreciation lowers the oracle term. ## How ownership is issued You mint IX-CORE by depositing into the vault; shares are issued at the current NAV-per-share. Redeeming burns your shares and returns value at NAV. ```mermaid theme={null} flowchart LR U[Investor] -->|deposit USDC| V[IX-CORE vault ERC-4626] V -->|mint shares at NAV| U N[NAV Oracle] -->|hardwareValueUSD| V R[Revenue accrual] -->|raises NAV/share| V V -->|redeem at NAV| U ``` Approve, then `deposit(assets, receiver)` USDC into the IX-CORE vault. The vault mints IX-CORE to you at the current NAV-per-share — your slice of the whole book. `balanceOf` is the record of what you own; its value is `shares × NAV-per-share`. ## Fees IX-CORE follows OpenZeppelin's **ERC-4626 fees** pattern, so a `preview*` call always equals the actual result — no hidden slippage. Full schedule and redemption terms: [Fees & terms](/protocol/fees-and-terms). | Fee | Parameter | Testnet default | How it's taken | | ------------- | ----------------- | --------------- | ------------------------------------------------------------------------------- | | Entry | `entryBps` | `0` (0%) | Skimmed on deposit, sent to the fee recipient | | Exit | `exitBps` | `10` (0.10%) | Deducted on redeem; on the queued path it stays in the vault as buffer | | Management | `mgmtBpsPerYear` | `100` (1%/yr) | **Streamed** — dust shares minted to the fee recipient pro-rata to elapsed time | | Reserve floor | `reserveFloorBps` | `0` | Share of assets held back from instant redemption (queue-only buffer) | The streaming management fee accrues on every deposit, redeem, and param change (and can be poked with `pokeFees()`), so it dilutes at a smooth, predictable rate rather than in lumps. All four parameters are admin-settable and capped at 100%. Suppose NAV-per-share is `1.05` and the entry fee is `0%`. 1. You deposit `1,000` USDC. 2. Entry fee `0%` → the full `1,000` is priced in. 3. Shares minted `= 1,000 ÷ 1.05 ≈ 952.38` IX-CORE. 4. As revenue accrues, NAV-per-share rises; your `952.38` shares are worth more USDC on redeem — you never claim a separate payout. With the testnet `0.10%` exit fee, redeeming those shares later returns NAV minus `0.10%`. ## What IX-CORE entitles you to * **A pro-rata claim on the index's NAV** — the underlying compute assets plus revenue accrued into the vault. See [Revenue & distributions](/protocol/revenue-and-distributions). * **A verifiable position** reflected in live NAV, reserve coverage, and the on-chain asset registry. See [Transparency & NAV](/protocol/transparency-and-nav). * **Redemption at NAV** — burn shares to withdraw, paid instantly when cash allows or via a FIFO queue drained from the smoothing reserve. ## Redeeming: instant or queued Because a liquid token sits on top of illiquid hardware, redemptions are paid instantly only up to `availableCash` (vault balance minus the reserve floor). Larger exits **burn now and queue** — the request is paid FIFO by a keeper (`processQueue`) or pulled by you (`claim`) once the vault balance plus smoothing reserve can cover it. This is what stops a liquid share token from bank-running the hardware behind it. ## Supply & bootstrap IX-CORE supply is **dynamic**: shares are minted on deposit and burned on redemption, ERC-4626 style. There is no fixed cap and no pre-mine. The initial supply that represents existing hardware is minted once — either by the admin `seedShares` bootstrap or by the migration [Merkle claim](/protocol/smart-contracts) — which also prevents a "zero-share trap" where hardware value exists but no shares do. ## Migrating from the old BNB token Former holders of the retired BNB-era ownership token convert into IX-CORE **once**, via a [one-time Merkle claim](/protocol/smart-contracts) on Base, valued at NAV, value-for-value. Ongoing distributions are **not** Merkle-based — that mechanism now exists only for the migration airdrop, and unclaimed shares are swept to the treasury after the window closes. All testnet figures are **simulated and clearly labeled**. Treat IX-CORE as an ownership instrument within IX RWA, not as a general-purpose traded currency, until mainnet launch after audit. # Proof of Reserve Source: https://docs.ix.finance/protocol/proof-of-reserve How IX RWA gates every NAV move behind a recorded attestation — and how to verify reserves and hardware identity yourself. A tokenized asset is only as trustworthy as your ability to check it. IX RWA is built so the value backing IX-CORE is **not** something you take on faith: every change to NAV passes through a recorded, on-chain attestation, and the hardware behind each asset is anchored to a hash you can recompute. ## The gate: no NAV move without an attestation The NAV oracle's `ORACLE_UPDATER_ROLE` is assigned to the [**Attestor Registry**](/protocol/smart-contracts). Once the direct-EOA write is revoked — a pre-mainnet lockdown step — there is exactly one path to move NAV: ```mermaid theme={null} sequenceDiagram participant AT as Attestor (ATTESTOR_ROLE) participant AR as AttestorRegistry participant O as NAV Oracle participant V as IX-CORE vault AT->>AR: attestReserve(cohortId, valueUSD, evidenceHash) AR->>AR: record (attestor, value, evidenceHash, timestamp) AR->>O: setCohortValue(cohortId, valueUSD) O->>O: enforce bounds (maxBps) + staleness (maxAge) V->>O: hardwareValueUSD() when pricing Note over AR,O: A bad value still reverts at the oracle ``` Because the registry is the writer, every reserve value on record carries **who** attested it, **what** evidence backs it (`evidenceHash`), and **when**. On testnet the direct-EOA oracle write has not yet been revoked, so treat the gate as the target end-state; on mainnet real attestors are added and every EOA path is revoked. See [Security model](/security/security-model#proof-of-reserve). ## What an attestation contains | Field | Meaning | | -------------- | --------------------------------------------------------------------------------- | | `cohortId` | The sleeve (SPV/batch) being attested | | `valueUSD` | Attested reserve value, USDC 6-dec | | `evidenceHash` | `keccak256` of the off-chain evidence bundle — invoices, serials, site, telemetry | | `attestor` | The address that signed the attestation | | `at` | Block timestamp of the attestation | Read the latest attestation for any cohort with `latest(cohortId)`, and check recency with `isFresh(cohortId, maxAge)`. ## Verify reserves yourself Call `latest(cohortId)` on the Attestor Registry to get `valueUSD`, `evidenceHash`, `attestor`, and `at`. Confirm `isFresh(cohortId, maxAge)` is true — a stale feed also trips the vault's own staleness guard and blocks pricing. Retrieve the off-chain evidence bundle and recompute its `keccak256`; it must equal the on-chain `evidenceHash`. Cross-check the attested cohort values against `hardwareValueUSD()` and rebuild NAV-per-share as `totalAssets ÷ totalSupply`. See [Transparency & NAV](/protocol/transparency-and-nav). ## Verify hardware identity Each asset can anchor a **hardware identity**: `identityHash = keccak256` of the canonical bundle (machine id, host id, motherboard, geolocation, and per-GPU serials), plus GPU model and serial count. Call `identityOf(assetId)` on the Asset Registry, re-hash the off-chain bundle, and confirm the two match — proof that the anchored machine is the one backing the asset. ## Honest boundary The Attestor Registry enforces the **process**, not the **truth** of the evidence. On-chain, it guarantees that NAV only moved through a recorded attestation with an evidence hash and bounded, staleness-checked values. Genuinely independent proof-of-reserve additionally requires a real third-party attestor holding `ATTESTOR_ROLE` and a real evidence pack behind each hash. On testnet the attestor is the EconomicsFeeder key; at mainnet, real attestors are added and the direct-EOA write is revoked — the **same code**, a different signer. See the [roadmap](/why-ix-rwa#roadmap). # Revenue & distributions Source: https://docs.ix.finance/protocol/revenue-and-distributions How compute revenue is generated, split between investors and the protocol, and accrued into IX-CORE's NAV on-chain. IX RWA assets earn by renting out compute. That revenue, net of costs, is split between investors and the protocol — and the investor share **accrues into IX-CORE's net asset value (NAV)** rather than being paid out as a separate claim. Your yield shows up as a rising NAV-per-share, realized when you redeem. ## From gross rental to investor yield ```mermaid theme={null} flowchart TD G[Gross rental revenue] -->|minus operator fee| N1[After operator fee] N1 -->|minus IX management/performance fee| N[Net revenue] N -->|investor share · notifyRevenue| A[Cash term of NAV rises → NAV/share up] N -->|protocol share| X[IX treasury] ``` The asset's compute is rented at market rates over a period. Operator and protocol fees (management / performance / creation-redemption) are deducted. The investor share is deposited into the vault via `notifyRevenue(cohortId, amount)`, raising the cash term of `totalAssets` — so IX-CORE's NAV-per-share rises for every holder at once, no claim transaction required. You realize accrued yield by redeeming shares at the higher NAV. ## How accrual moves the price NAV has two terms — cash and hardware value — and revenue moves the **cash** term: ```text theme={null} totalAssets = USDC.balanceOf(vault) ← notifyRevenue adds here (yield ↑) + hardwareValueUSD() ← depreciation lowers here (NAV ↓) ``` Because `notifyRevenue` simply transfers USDC into the vault (tagged with a cohort id for the indexer), the price change is trustless: anyone can watch the balance rise on-chain. The `REVENUE_DEPOSITOR_ROLE` (the off-chain EconomicsFeeder) is the only caller. ## Fee model Investor-facing vault fees follow OpenZeppelin's ERC-4626 fees pattern, so previews equal actuals: | Fee | Testnet default | Notes | | ---------- | ----------------- | --------------------------------------------------- | | Entry | `0%` | Charged on deposit | | Exit | `0.10%` | Charged on redeem; kept in-vault on the queued path | | Management | `1%/yr`, streamed | Dust shares minted pro-rata to elapsed time | These sit on top of the operator and protocol economics that determine net revenue before it ever reaches the vault. See [Fees & terms](/protocol/fees-and-terms) for the full schedule. ## Yield Yield is **dynamic** — `total revenue ÷ total NAV`, shown as a trailing-window realized figure, with NAV-per-share displayed alongside so depreciation stays visible. A **smoothing reserve** buffers period-to-period swings and also serves as the redemption buffer. If an asset's feed goes stale or diverges, it is **auto-quarantined** in the asset registry — dropped from NAV and yield until healthy (the oracle sums only cohorts with ≥1 Active asset). Yield and NAV shown in the app are **simulated in settlement but driven by live market data** on testnet: a `LiveDataNAVOracle` behind a swappable `INAVOracle` seam is fed from live Vast.ai rates and real hardware cost/depreciation, settled in test tokens. They are not a promise of realized return; the mainnet oracle is the same code with an operator-attested feed. See the [roadmap](/why-ix-rwa#roadmap). ## The smoothing reserve A dedicated `SmoothingReserve` contract holds USDC that: * **Smooths distributions** — topped up from a skim of revenue so good periods cushion weaker ones. * **Funds redemptions** — the vault pulls from it (`coverShortfall`, `SPENDER_ROLE`) when a queued exit exceeds the vault's own balance. Its balance is public on-chain, so reserve coverage is verifiable rather than asserted. ## Why accrual instead of Merkle claims The BNB-era design paid distributions via Merkle claims. IX-CORE **retires that for ongoing payouts**: revenue compounds into NAV automatically, which is gas-free for holders, keeps every share equal, and removes the per-distribution claim step. The Merkle mechanism now exists **only** for the one-time [migration airdrop](/protocol/ownership-and-ixd#migrating-from-the-old-bnb-token). ## Auto-compounding by design Because IX-CORE is an **accumulating** vault, distributions are effectively auto-reinvested — you don't opt in. Your position grows as NAV-per-share rises; withdrawing means redeeming at the higher NAV. **Status:** the vault, accrual, and redemption paths are live on testnet with simulated settlement. The first **real** revenue accrual runs as part of the verified money-path milestone on the [roadmap](/why-ix-rwa#roadmap). Until then, figures illustrate the model, not realized payouts. # Smart contracts Source: https://docs.ix.finance/protocol/smart-contracts On-chain addresses for the IX RWA protocol on Base Sepolia, with explorer links for independent verification. All IX RWA contracts are public and verifiable on-chain. This page lists the canonical addresses for the IX-CORE vault system; per-asset (cohort) data is additionally discoverable through the on-chain registry surfaced on the [Transparency](/protocol/transparency-and-nav) page. **Network:** Base **Sepolia testnet** (chain id `84532`). These are testnet addresses and all figures are **simulated and clearly labeled** in-app. Mainnet addresses are published here at launch, after the third-party audit — see the [roadmap](/why-ix-rwa#roadmap). ## Core (IX-CORE vault system) | Contract | Role | Address | | --------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **IX-CORE vault** | ERC-4626 index token — mint/redeem at NAV | [`0x0dE437Ab692B0BD7baF158815ac08412A1680D73`](https://sepolia.basescan.org/address/0x0dE437Ab692B0BD7baF158815ac08412A1680D73) | | **NAV Oracle** | `LiveDataNAVOracle` — per-cohort hardware value behind the `INAVOracle` seam | [`0xF0b8D1e333380C7725b4B10a83e323412C92d010`](https://sepolia.basescan.org/address/0xF0b8D1e333380C7725b4B10a83e323412C92d010) | | **Attestor Registry** | Proof-of-reserve gate — the intended sole writer of the NAV oracle (direct-EOA write revoked pre-mainnet) | [`0xC06700f7089ba6939c38c541510663a24b3a51a1`](https://sepolia.basescan.org/address/0xC06700f7089ba6939c38c541510663a24b3a51a1) | | **Asset Registry** | On-chain identity for each compute asset (machine + GPU serials, hashed) | [`0x75913165dd8Aa68c1B055806da4DAddA00ea5857`](https://sepolia.basescan.org/address/0x75913165dd8Aa68c1B055806da4DAddA00ea5857) | | **Smoothing Reserve** | Yield-smoothing buffer + redemption buffer | [`0x2fF5993004A94e7A4A25EA3a07FB7b05A65EC1C6`](https://sepolia.basescan.org/address/0x2fF5993004A94e7A4A25EA3a07FB7b05A65EC1C6) | | **Merkle Claim** | One-time migration airdrop for former BNB holders | [`0xEc560D305dF3Fd89A6295bBA47B1CfD7A4d5110a`](https://sepolia.basescan.org/address/0xEc560D305dF3Fd89A6295bBA47B1CfD7A4d5110a) | | **USDC (test)** | Deposit / settlement asset (6-dec) | [`0x58AB17fDf2b0FCc784f580FC9eEeE6cf87477889`](https://sepolia.basescan.org/address/0x58AB17fDf2b0FCc784f580FC9eEeE6cf87477889) | | **IX Treasury** | Protocol fee + reserve recipient | [`0x9D36850a03e4eC6D0ED3332E285A12603CF5dab2`](https://sepolia.basescan.org/address/0x9D36850a03e4eC6D0ED3332E285A12603CF5dab2) | All core contracts are **UUPS proxies** — use **Read as Proxy** on BaseScan to see live state. ## Key events Every state change emits an event, so the indexer and transparency surfaces reconstruct state from the chain: | Contract | Events | | ----------------- | ----------------------------------------------------------------------------------------------- | | IX-CORE vault | `Deposit`, `Withdraw`, `RevenueAccrued`, `RedemptionQueued`, `RedemptionFulfilled`, `FeesTaken` | | NAV Oracle | `CohortValueSet`, `MaxAgeSet`, `MaxBpsSet` | | Attestor Registry | `ReserveAttested`, `NavOracleSet` | | Asset Registry | `AssetRegistered`, `AssetStatusChanged`, `AssetIdentitySet`, `AssetAttested` | | Smoothing Reserve | `ToppedUp`, `ShortfallCovered` | ## Cohort vaults New assets are onboarded as **cohort vaults** (one per SPV/batch) and enter IX-CORE by a rules-based weight. Each cohort is recorded in the Asset Registry and linked from the [Transparency](/protocol/transparency-and-nav) registry, so you can confirm exactly which assets back the index — and at what weight — before you invest. Go to [testnet.ix.finance/transparency](https://testnet.ix.finance/transparency). The page shows the live (simulated, labeled) NAV inputs — asset values, revenue, and reserve — so anyone can recompute NAV-per-share. Open any address on [BaseScan](https://sepolia.basescan.org) and use its read functions (and **Read as Proxy** for upgradeable contracts) to confirm parameters directly. Always verify addresses against this page and the in-app registry. IX RWA will never ask you to send funds to an address shared over DM, email, or social media. See [Official domains](/resources/official-domains). # Transparency & NAV Source: https://docs.ix.finance/protocol/transparency-and-nav How IX RWA reports net asset value, reserve coverage, and an on-chain asset registry you can verify. Transparency is a core design principle: ownership and value should be **recomputable**, not taken on faith. IX RWA publishes an on-chain asset registry alongside live NAV and reserve coverage — so you can rebuild the numbers yourself instead of trusting a dashboard. ## Net Asset Value (NAV) **NAV** is the total value backing the index. IX-CORE's share price is simply `NAV ÷ supply`, and every input is on-chain: ```text theme={null} NAV (totalAssets) = USDC.balanceOf(vault) ← cash + accrued revenue + navOracle.hardwareValueUSD() ← Σ active-cohort hardware value NAV-per-share = NAV ÷ totalSupply ``` `hardwareValueUSD()` sums **only cohorts with ≥1 Active asset** in the registry, so a quarantined or retired cohort drops out of NAV automatically. Each asset's identity and value are recorded on-chain (machine + GPU serials, hashed), with explorer links for independent verification. Computed from cash, oracle hardware value, and supply — rebuildable from on-chain inputs, not asserted. ## Per-cohort values & freshness The NAV oracle exposes each cohort's value and the timestamp of its last update (`cohortValueUSD(cohortId) → value, updatedAt`), plus a global `lastUpdate()` and `isStale()`. That lets the transparency surface show not just what each sleeve is worth but how fresh the number is — and the vault refuses to price against a stale feed. ## Reserve coverage The **smoothing reserve** backs redemptions and buffers yield. Its balance is public on-chain, so reserve coverage — how the deployed capital maps to asset value plus buffer — is a verifiable ratio rather than a claim. ## Verify the hardware identity yourself Each asset can carry an on-chain **identity anchor**: `identityHash = keccak256` of the canonical off-chain identity bundle (machine id, host id, motherboard, geolocation, and the per-GPU serial list), plus the GPU model and serial count. Call `identityOf(assetId)` on the Asset Registry to get the `identityHash`, `machineId`, model, and `serialCount`. Retrieve the full off-chain identity bundle served by the transparency surface. Recompute `keccak256` of the bundle and check it equals the on-chain `identityHash`. A match proves the anchored machine is the one backing the asset. On testnet, NAV and revenue are **simulated in settlement but driven by live market data**, published by a `LiveDataNAVOracle` behind a swappable `INAVOracle` seam. Independent, oracle-attested **Proof of Reserve** — where a whitelisted attestor records a value plus an evidence hash — is gated on-chain by the [Attestor Registry](/protocol/proof-of-reserve); real third-party attestors are a pre-mainnet trust item. See [Roadmap](/why-ix-rwa#roadmap). ## Verify NAV on-chain Visit [testnet.ix.finance/transparency](https://testnet.ix.finance/transparency). Each asset, the NAV oracle, the reserve, and the IX-CORE vault link to [BaseScan](https://sepolia.basescan.org). Use the explorer's read functions (including **Read as Proxy** for upgradeable contracts) to pull `totalAssets`, `totalSupply`, and `hardwareValueUSD`, and rebuild NAV-per-share directly on-chain. ## Testnet disclosure All figures are **simulated testnet** values today — NAV, reserve coverage, AUM, and yield reflect the Base Sepolia deployment settled in test tokens, and are re-established with a fully attested feed at mainnet launch after audit. # FAQ Source: https://docs.ix.finance/resources/faq Common questions about IX RWA, IX-CORE, yield, and getting started. A real-world asset protocol for compute. It tokenizes income-producing infrastructure — GPU clusters and the data centers around them — as a single on-chain index anyone can own a fraction of and earn from. See [How it works](/how-it-works). IX-CORE is one ERC-4626 index token representing your fractional ownership of the whole compute book. You mint it when you deposit, and its value tracks the index's NAV. See [Ownership & IX-CORE](/protocol/ownership-and-ixd). Connect a wallet and deposit a stablecoin (USDC). The IX-CORE vault mints shares to you at the current NAV-per-share. See [How it works](/how-it-works#the-invest-flow-precisely). From real compute rental revenue, net of operator and protocol fees. The investor share **accrues into IX-CORE's NAV-per-share** — no claim step. On testnet these figures are simulated and clearly labeled. See [Revenue & distributions](/protocol/revenue-and-distributions). On testnet: entry `0%`, exit `0.10%`, and a streaming management fee of `1%/yr` (taken by minting dust shares over time). Previews equal actuals — no hidden slippage. See [Fees & terms](/protocol/fees-and-terms). Every NAV move passes through the on-chain Attestor Registry, which records who attested it and a hash of the supporting evidence. You can also re-hash an asset's off-chain identity bundle and compare it to the on-chain anchor. See [Proof of Reserve](/protocol/proof-of-reserve). Yes — you **redeem IX-CORE at NAV**. Redemptions are paid instantly up to available cash; larger exits queue FIFO and are paid as the vault and smoothing reserve refill. A secondary AMM market is deferred to pre-mainnet. See [Fees & terms](/protocol/fees-and-terms#redemption-terms). It burns your shares now and joins a FIFO queue. A keeper processes the queue (`processQueue`), or you can pull your own request (`claim`) once the vault balance plus smoothing reserve can cover it. FIFO fairness means the queue never skips ahead. It's constrained: only the Attestor Registry can write it, a single update can't move a cohort by more than a set bound, and a stale feed pauses deposits/redeems. See [Security model](/security/security-model#oracle-guards). **Base Sepolia testnet** (chain id `84532`) today, migrated off BNB Chain. The canonical mainnet chain is confirmed at the audited Phase-2 redeploy. See [Why IX RWA](/why-ix-rwa#where-it-runs). Former BNB holders convert into IX-CORE **once**, via a one-time Merkle claim on Base valued at NAV. See [Ownership & IX-CORE](/protocol/ownership-and-ixd#migrating-from-the-old-bnb-token). Not yet. A third-party audit is a prerequisite for mainnet; results are published in [Trust & Security](/security/security-model). Testnet is for evaluation only. No KYC on testnet — connecting a wallet is the only identity. Eligibility requirements may apply at mainnet depending on jurisdiction. Yes — a read-only [Agent Gateway (MCP)](/developers/agent-gateway) lets agents query the index, stats, and portfolios. Agent transactions are a roadmap item. # Glossary Source: https://docs.ix.finance/resources/glossary Key terms used across the IX RWA protocol and documentation. | Term | Meaning | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **RWA** | Real-world asset — an off-chain asset represented on-chain. Here, income-producing compute. | | **IX-CORE** | The ERC-4626 index token representing fractional ownership of the whole IX RWA compute book. | | **ERC-4626** | The tokenized-vault standard IX-CORE uses; shares are minted/redeemed against underlying assets at NAV. | | **NAV** | Net Asset Value — `USDC in the vault (cash + revenue) + oracle hardware value`. | | **NAV-per-share** | `NAV ÷ supply` — the price at which IX-CORE mints and redeems, recomputable from on-chain inputs. | | **Accumulating** | IX-CORE reinvests revenue by design — it raises NAV-per-share rather than paying a separate distribution. | | **Cohort vault** | The construction unit: one grouping per SPV/batch of assets, added to IX-CORE by a rules-based weight. | | **NAV Oracle** | `LiveDataNAVOracle` — publishes per-cohort hardware value behind an `INAVOracle` seam, fed from live market data (test settlement), bounded and staleness-guarded. | | **INAVOracle** | The swap seam: the only NAV dependency the vault has, so the feed source can change without touching the vault. | | **EconomicsFeeder** | The off-chain service that pushes live-market values and revenue on-chain (holds attestor / revenue / keeper roles on testnet). | | **Attestor Registry** | The proof-of-reserve gate: the intended sole writer of the NAV oracle, so every NAV move is a recorded attestation. | | **Proof of Reserve (PoR)** | Evidence that reserves back the index; enforced on-chain by requiring an attestor + evidence hash for every NAV move. See [Proof of Reserve](/protocol/proof-of-reserve). | | **evidenceHash** | `keccak256` of the off-chain evidence bundle (invoices, serials, site, telemetry) recorded with each attestation. | | **identityHash** | `keccak256` of an asset's canonical hardware bundle (machine id, serials, geolocation) — re-hash off-chain data to verify the anchored machine. | | **Asset Registry** | On-chain identity and lifecycle for each asset (machine + GPU serials, hashed), powering transparency. | | **Smoothing reserve** | A USDC buffer that smooths yield and funds the redemption queue; its balance is public on-chain. | | **Entry / exit fee** | Deposit/redeem fees (testnet `0%` / `0.10%`), following OpenZeppelin's ERC-4626 fees pattern (previews equal actuals). | | **Management fee** | A streaming fee (testnet `1%/yr`) taken by minting dust shares pro-rata to elapsed time. | | **Reserve floor** | The share of assets held back from instant redemption — reachable only by the queue processor. | | **availableCash** | `vault balance − reserve floor` — the cash a redemption can be paid from instantly. | | **Redemption queue** | If instant cash is short, redemptions burn now and queue FIFO, paid as the vault + reserve refill. | | **Bootstrap / seedShares** | The one-time mint of initial supply representing existing hardware (or the migration claim), preventing a "zero-share trap." | | **Auto-quarantine** | An asset drops out of NAV/yield automatically if its feed goes stale or divergent (oracle counts only active cohorts). | | **Reserve coverage** | A transparency ratio comparing on-chain reserve + asset value to capital in the vault. | | **Merkle claim** | Now used **only** for the one-time BNB→IX-CORE migration airdrop; retired for ongoing payouts. | | **Money-path** | The end-to-end flow of value; IX RWA requires it to be derived from verified on-chain events. | | **Chain-as-truth** | Positions are reconstructed from on-chain events by an indexer, not from client-submitted figures. | | **UUPS proxy** | The upgradeable-proxy pattern behind each core contract; upgrades need `UPGRADER_ROLE`, addresses never change. | | **Phase-2 redeploy** | The audited mainnet redeployment where canonical chain, pricing, and the real oracle feed are finalized. | | **Agent Gateway** | The hosted, read-only MCP endpoint for AI agents to query protocol data. | # Official domains Source: https://docs.ix.finance/resources/official-domains The only domains and addresses operated by IX RWA. Anything else is not us. Scammers clone RWA platforms. Bookmark this page and check any link against it before connecting a wallet or sending funds. ## Official properties | Property | URL | | ------------------- | ------------------------------------------------ | | App (testnet) | [testnet.ix.finance](https://testnet.ix.finance) | | Documentation | [docs.ix.finance](https://docs.ix.finance) | | Website | [ix.finance](https://ix.finance) | | X / Twitter | [x.com/ixrwacapital](https://x.com/ixrwacapital) | | Agent Gateway (MCP) | `https://testnet.ix.finance/api/mcp` | IX RWA moved to **ix.finance**. The former `ixrwa.capital` domains (including `testnet.ixrwa.capital`) now permanently redirect here — but always confirm you land on **ix.finance**. ## How to stay safe Confirm the URL exactly matches the table above — watch for look-alike characters and extra words in the domain. Cross-check any address against [Smart contracts](/protocol/smart-contracts) and the in-app registry before interacting. IX RWA will never DM you first, ask for your seed phrase or private key, or request funds to a "support" address. If a site, message, or address is not listed here, treat it as fraudulent. When in doubt, stop and verify through the official channels above. # Governance Source: https://docs.ix.finance/security/governance Who controls what in IX RWA — roles, upgrade authority, emergency controls, and the path to multisig / timelock governance. IX RWA has **no ambient owner**. Every privileged action is a named, least-privilege role, and the authority to change code or parameters is explicit and on-chain. This page is the single reference for who can do what, and how that control decentralizes on the way to mainnet. ## Roles & permissions | Role | Held by (testnet) | Can | | ------------------------ | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | `DEFAULT_ADMIN_ROLE` | Protocol admin | Set fee params, fee recipient, reserve/oracle pointers, register/retire assets, pause | | `ORACLE_UPDATER_ROLE` | AttestorRegistry (intended sole updater; EOA path revoked pre-mainnet) | Write cohort values into the NAV oracle | | `ATTESTOR_ROLE` | EconomicsFeeder (testnet) → real attestors (mainnet) | Submit an attested reserve value + evidence hash | | `REVENUE_DEPOSITOR_ROLE` | EconomicsFeeder | Accrue revenue into NAV (`notifyRevenue`) | | `KEEPER_ROLE` | Keeper / feeder | Process the redemption queue; quarantine assets on a bad/stale feed | | `SPENDER_ROLE` | Vault + keeper | Pull from the smoothing reserve to cover a shortfall | | `UPGRADER_ROLE` | Protocol admin → multisig/timelock | Authorize UUPS implementation upgrades | Roles are separated by design: the key that feeds revenue cannot upgrade contracts, the keeper that processes redemptions cannot move NAV, and no single key holds everything. ## Upgrade authority Core contracts are **UUPS proxies**: implementations can be upgraded without changing addresses or migrating balances, and every `_authorizeUpgrade` is gated by `UPGRADER_ROLE`. ```mermaid theme={null} flowchart LR P[Propose upgrade] --> TL[Timelock delay] TL --> MS[Multisig / governance approval] MS --> EX[Execute upgrade via UPGRADER_ROLE] EX --> PX[Proxy points at new implementation] ``` On testnet, upgrade authority is held by the protocol admin for iteration speed. At the audited **Phase-2 redeploy**, `UPGRADER_ROLE` and `DEFAULT_ADMIN_ROLE` move to a **multi-signature wallet behind a timelock**, so upgrades require multiple signers and a public delay before they can execute. The governance-hardening test suite exercises exactly this: an upgrade **reverts without the timelock** and **succeeds only via the timelock after its delay**, the deployer **renounces** its standalone control, and the multisig can pause and set parameters. ## Emergency controls | Control | Effect | Who | | -------------------- | ------------------------------------------------------------- | --------- | | **Pause** | `Pausable` halts deposits, mints, and redemptions | Admin | | **Oracle staleness** | A stale feed auto-blocks pricing (`NavStale`) until refreshed | Automatic | | **Quarantine** | A bad/diverging asset is dropped from NAV until healthy | Keeper | | **Oracle bounds** | A single NAV update can't move a cohort beyond `maxBps` | Automatic | These are containment tools, not backdoors: none of them can move user funds to an arbitrary address, and all are visible on-chain. ## Parameter changes Fee parameters (entry, exit, management, reserve floor) and pointers (oracle, reserve, fee recipient) are admin-settable, bounded (bps capped at 100%), and emit events (`ParamsSet`, `FeeRecipientSet`, `ReserveSet`). The streaming management fee is settled at the old rate **before** any change, so parameter updates never apply retroactively. See [Fees & terms](/protocol/fees-and-terms). ## Decentralization path Single protocol-admin key for fast iteration; all actions on-chain and event-logged. Admin and upgrader roles move to a multisig behind a timelock; the deployer renounces standalone control; the AttestorRegistry becomes the sole NAV writer. Progressive decentralization of attestation and parameter governance as the asset base and operator set grow. Governance arrangements described for mainnet (multisig, timelock, role renouncement) are the **target end-state**. On testnet the protocol admin retains direct control for iteration. See the [roadmap](/why-ix-rwa#roadmap). # Reporting & assurance Source: https://docs.ix.finance/security/reporting-and-assurance How IX RWA reports NAV and revenue, and the assurance program — on-chain recomputability, evidence-hashed attestations, and third-party audit. IX RWA's reporting model is **verify, don't trust**: every headline figure is either read directly from the chain or backed by a hash you can recompute against public evidence. This page describes what is reported, how often, and how you check it. ## What is reported | Metric | Source | Cadence | Verify | | -------------------------------- | ---------------------------------------------- | --------------------- | ---------------------------------------------------- | | **NAV / NAV-per-share** | Live vault read (`totalAssets`, `totalSupply`) | Real-time (per block) | [Transparency & NAV](/protocol/transparency-and-nav) | | **Per-cohort value + freshness** | NAV oracle (`cohortValueUSD`, `lastUpdate`) | Per attestation | [Proof of Reserve](/protocol/proof-of-reserve) | | **Reserve coverage** | Smoothing reserve balance | Real-time | On-chain `balance()` | | **Revenue settled** | `RevenueAccrued` events + revenue snapshots | Per settlement | Revenue proof (below) | | **Holdings / positions** | Event-indexer read model (chain-as-truth) | Real-time | Re-derive from `Transfer` events | All of these are recomputable from public on-chain inputs — no figure originates from a private dashboard. ## Revenue proof (hash-chained snapshots) Each revenue settlement is committed to a signed, hash-chained record so a reading can't be silently revised after the fact: ```mermaid theme={null} flowchart LR LIVE[Live market inputs] --> BUNDLE[Canonical inputs bundle] BUNDLE -->|keccak256| IH[inputs_hash] IH --> CH[chain_hash = keccak · prev_chain_hash + inputs_hash] IH -->|evidenceHash| ATT[On-chain attestReserve] CH --> NEXT[Next snapshot links here] ``` * Each snapshot stores the **canonical inputs bundle** (formula version, live rates, per-cohort NAV & revenue) plus `inputs_hash = keccak256(bundle)`. * Snapshots form a **tamper-evident hash chain**: `chain_hash = keccak256(prev_chain_hash || inputs_hash)`. * The same `inputs_hash` is submitted on-chain as the attestation's `evidenceHash`, so the reported figure and the on-chain record are one and the same. **To verify a reading:** pull the snapshot, recompute `keccak256` of the canonical bundle, confirm it equals both the stored `inputs_hash` and the on-chain `ReserveAttested` `evidenceHash`, then walk the `chain_hash` back to confirm the record was never rewritten. ## Proof-of-reserve program Reserve values reach the oracle only through the [Attestor Registry](/protocol/proof-of-reserve), which records `(attestor, valueUSD, evidenceHash, timestamp)` for every move. On testnet the attestor is the EconomicsFeeder key; at mainnet the program adds **independent third-party attestors** holding `ATTESTOR_ROLE`, each move backed by a real evidence pack (invoices, serials, site, telemetry) behind its `evidenceHash`. ## Audit & security assurance A **third-party smart-contract audit** is a prerequisite for mainnet launch. The audit report and remediation status will be published in [Trust & Security](/security/security-model). Until then, testnet is for evaluation only and is not production-secure. ## Observability Every state change emits an on-chain event (deposits, redemptions, revenue accrual, fee mints, cohort value sets, attestations, asset lifecycle). An event indexer reconstructs holder state and reporting **from those events**, so the reporting layer can always be rebuilt from the chain rather than trusted. See [Architecture → Observability](/protocol/architecture#observability). # Risk disclosures Source: https://docs.ix.finance/security/risk-disclosures The material risks of participating in IX RWA. Read before investing. Participating in IX RWA carries risk. This page summarizes the material risks in plain terms. It is informational and is **not** investment, legal, or tax advice. For the structured treatment (likelihood, impact, mitigations), see the [Risk framework](/security/risk-framework). IX RWA is currently on **Base Sepolia testnet**. Testnet tokens and figures have **no monetary value**, are **simulated in settlement**, and are for evaluation only. ## Key risks Smart contracts can contain bugs. Contracts are UUPS-upgradeable, which introduces admin-key considerations until `UPGRADER_ROLE` and other privileged roles move to multisig / governance at the Phase-2 redeploy. A third-party audit is a prerequisite for mainnet. Returns depend on real compute being rented and operators performing. Utilization, hardware depreciation, downtime, and operator default can reduce or eliminate revenue. Hardware depreciation lowers the oracle term of NAV, so **NAV-per-share can fall**. NAV can rise and fall, and shares are priced at NAV. You can redeem at NAV, but only up to `availableCash` (vault balance minus the reserve floor) is paid instantly; larger exits **queue FIFO** and are paid as the vault and smoothing reserve refill. A secondary AMM market is not yet live, so instant exit is not guaranteed. NAV depends on the `LiveDataNAVOracle` behind an `INAVOracle` seam. On testnet it is fed from live market data and settled in test tokens. Guards limit the damage a bad feed can do: a single update can't move a cohort by more than `maxBps`, and a stale feed (`now − lastUpdate > maxAge`) **pauses deposits/redeems** until refreshed. Every NAV move must pass through the [Attestor Registry](/protocol/proof-of-reserve) with an evidence hash. Residual risk remains: an attested value can be wrong within bounds, and a divergent asset is only removed once quarantined. Entry, exit, and a streaming management fee apply (testnet `0%` / `0.10%` / `1%/yr`). The management fee dilutes holders continuously by minting dust shares; parameters are admin-settable (capped at 100%) and can change. Yield, APY, and NAV shown in the app are **simulated in settlement on testnet** and, at mainnet, model-based estimates. They are not promises of return; realized results may differ materially. The regulatory treatment of tokenized real-world assets is evolving and varies by jurisdiction. Eligibility rules may apply at mainnet. IX RWA is non-custodial. If you lose access to your wallet, IX RWA cannot recover your funds or ownership. ## No advice Nothing in this documentation is an offer, solicitation, or recommendation. Do your own research and consult qualified professionals before making financial decisions. # Risk framework Source: https://docs.ix.finance/security/risk-framework A structured view of IX RWA's material risks — category, description, on-chain mitigation, and residual exposure. This is the structured, allocator-facing companion to the plain-language [Risk disclosures](/security/risk-disclosures). It maps each material risk to the specific on-chain mechanism that mitigates it and the exposure that remains. It is informational, not investment advice. IX RWA is on **Base Sepolia testnet** with simulated settlement. The mitigations below are implemented in code today; their **effectiveness with real capital** is established at the audited mainnet redeploy. ## Risk register | # | Risk | Description | Mitigation (on-chain) | Residual exposure | | -- | --------------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | 1 | **Market** | Compute rental rates and demand fall, lowering revenue and hardware value | NAV marks hardware to live market rates; depreciation is reflected, not hidden | Directional market risk is not hedged — NAV-per-share can fall | | 2 | **Liquidity** | A liquid share token sits on illiquid hardware; mass redemptions exceed cash | Reserve floor + FIFO redemption queue + smoothing reserve; NAV locked at redeem time | Queued exits wait for the buffer to refill; no instant secondary market yet | | 3 | **Counterparty / operator** | Operators underperform, default, or a hosting venue (e.g. Vast.ai) fails | Per-asset cost basis + operator recorded on-chain; quarantine drops a bad asset from NAV | Off-chain operator performance is not on-chain-enforceable | | 4 | **Valuation / oracle** | A wrong or stale NAV misprices deposits and redemptions | `INAVOracle` seam + per-cohort bounds (`maxBps`) + staleness auto-pause + attestor gate | An attested value can be wrong *within* bounds until corrected | | 5 | **Operational** | Feeder / keeper / indexer failure stalls NAV updates or the queue | Staleness pause fails safe; chain-as-truth indexer rebuilds from events; roles are separated | Off-chain infra availability affects freshness, not custody | | 6 | **Smart-contract** | A bug in the vault or peripherals | UUPS upgradeability, `ReentrancyGuard`, `Pausable`, storage `__gap`s, test suite | Unaudited on testnet — a third-party audit is a mainnet prerequisite | | 7 | **Governance / key** | Privileged-key misuse or compromise | Least-privilege named roles; upgrades → multisig + timelock at Phase-2; no ambient owner | Testnet admin retains direct control until the Phase-2 lockdown | | 8 | **Fee / dilution** | Streaming management fee dilutes holders; params can change | Fees follow ERC-4626 (preview == actual); bps capped at 100%; changes are event-logged | Management fee is a continuous drag; parameters are admin-settable | | 9 | **Regulatory** | Tokenized-RWA treatment varies and evolves by jurisdiction | Non-custodial, transparent, verifiable design | Eligibility / access rules may apply at mainnet | | 10 | **Custody / key** | Loss of your wallet keys | Non-custodial — IX RWA never holds your keys | IX RWA cannot recover lost keys or funds | ## How the mitigations compose ```mermaid theme={null} flowchart TD F[Bad or stale input] --> B{Oracle bounds maxBps} B -->|move too large| REV[Reverts] B -->|within bounds| S{Staleness maxAge} S -->|stale| PAUSE[Vault pauses pricing] S -->|fresh| A{Attested?} A -->|no attestation| REV A -->|attestor + evidenceHash| NAV[NAV updates on record] Q[Diverging asset] --> QUAR[Keeper quarantine → drops from NAV] ``` No single control is load-bearing on its own: bounds cap the size of an error, staleness stops pricing against a dead feed, the attestor gate puts every move on record, and quarantine removes a bad asset entirely. ## Where to verify each claim * **Valuation & oracle** — [Transparency & NAV](/protocol/transparency-and-nav), [Proof of Reserve](/protocol/proof-of-reserve) * **Liquidity & redemptions** — [Fees & terms](/protocol/fees-and-terms), [Ownership & IX-CORE](/protocol/ownership-and-ixd#redeeming-instant-or-queued) * **Smart-contract & governance** — [Security model](/security/security-model), [Governance](/security/governance) * **Reporting & assurance** — [Reporting & assurance](/security/reporting-and-assurance) # Security model Source: https://docs.ix.finance/security/security-model How IX RWA protects funds and data — the trust boundaries, the money-path invariant, and audit status. Security is a precondition for real capital, not a feature added later. IX RWA's security model rests on one principle: **the blockchain is the source of truth, and every position and NAV figure is derived from verified on-chain events.** ## The money-path invariant Ownership and value are never taken from what a client claims — they are read from the chain and verified before anything is recorded. ```mermaid theme={null} flowchart LR U[User action] --> TX[On-chain deposit / redeem] TX --> EV[Vault event] EV --> CHK{Verified?
sender, amount, event} CHK -->|yes| REC[Indexed into holder state] CHK -->|no| REJ[Rejected] ``` An event indexer reconstructs holder positions from on-chain `Deposit`/`Transfer` events (chain-as-truth), and NAV-per-share is recomputable from published on-chain inputs. This invariant gates the transition to real money. ## Proof of Reserve NAV can only move through a recorded attestation. The NAV oracle's `ORACLE_UPDATER_ROLE` is assigned to the **AttestorRegistry** so that, once the direct-EOA write is revoked — a pre-mainnet lockdown step — no key can write NAV directly. ```mermaid theme={null} flowchart LR A[Attestor · ATTESTOR_ROLE] -->|attestReserve · value + evidenceHash| AR[AttestorRegistry] AR -->|setCohortValue| O[NAV Oracle] O -->|bounds + staleness checks| O O --> V[IX-CORE vault prices off NAV] ``` Every move is on record as `(attestor, valueUSD, evidenceHash, timestamp)`. The oracle then applies its **own** guards to the pushed value, so a bad attestation still reverts on-chain. **Honest boundary:** the registry enforces the process, not the truth of the evidence. Independent proof-of-reserve still requires a real third-party attestor holding `ATTESTOR_ROLE` and a real evidence pack (invoices, serials, site, telemetry) behind each `evidenceHash`. On testnet the attestor is the EconomicsFeeder key and the direct-EOA oracle write has not yet been revoked; on mainnet real attestors are added and every EOA path is revoked — same code. See [Proof of Reserve](/protocol/proof-of-reserve). ## Oracle guards The NAV oracle runs two guards, unchanged from testnet to mainnet: | Guard | Parameter | Effect | | ------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Bounds** | `maxBps` | A single update can't move a cohort value by more than `maxBps` of its previous value. Zeroing a live cohort is blocked — removal is done via registry **quarantine**, never a value of 0. | | **Staleness** | `maxAge` | If `now − lastUpdate > maxAge`, `isStale()` is true and the vault **reverts deposits/redeems** (`NavStale`) until a fresh push arrives. A never-updated oracle reads stale (fail-safe). | ## Redemption safety A liquid share token can't be allowed to bank-run illiquid hardware: * **Reserve floor** — instant redemptions are capped at `availableCash = balance − reserveFloor`; the floor is reachable only by the queue processor. * **FIFO queue** — larger exits burn now and queue, paid in order once the vault balance plus smoothing reserve can cover the head (`processQueue` by a keeper, or user `claim`). FIFO fairness means the queue never skips ahead. ## Trust boundaries | Layer | Control | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Wallet / identity** | Non-custodial. Connecting a wallet is the only identity; IX RWA never holds your keys. | | **Contracts** | UUPS-upgradeable behind proxies; `UPGRADER_ROLE` moves to multisig / governance at Phase-2. `ReentrancyGuard` on all value-moving paths; `Pausable` admin stop. See [Governance](/security/governance). | | **NAV / oracle** | Priced only through the `INAVOracle` seam, written only by the AttestorRegistry, bounded and staleness-guarded. | | **Roles** | Least-privilege, separated: admin, attestor, oracle-updater, revenue-depositor, keeper, spender, upgrader — no single ambient owner. | | **Off-chain records** | Derived from verified on-chain events; reconciled against the chain. | ## Audit status IX RWA is on **Base Sepolia testnet** with simulated settlement. A **third-party security audit** is a prerequisite for mainnet launch; results and the audit report will be published here. Until then, do not treat testnet as production-secure. See the [roadmap](/why-ix-rwa#roadmap) and the [Risk framework](/security/risk-framework). ## Responsible disclosure If you believe you have found a vulnerability, please report it privately to the team rather than disclosing publicly. A formal disclosure policy and contact are published with the audit at launch. # Why IX RWA Source: https://docs.ix.finance/why-ix-rwa The market, the design principles, and the roadmap to mainnet. ## The opportunity Artificial intelligence runs on compute, and compute is a **real, cash-flowing asset** — GPUs and the facilities around them are rented continuously at market rates. Yet ownership of that asset base is concentrated in a small number of hyperscalers, and it is effectively closed to ordinary investors and to the AI agents that increasingly consume it. IX RWA opens it up: fractional, on-chain ownership of income-producing compute — as a single liquid index — with the transparency and settlement guarantees of public blockchains. Returns come from actual compute rental revenue, not token emissions. Own a slice of infrastructure that is otherwise capital-prohibitive. Designed so AI agents can read the market directly and, in time, allocate to it. ## Design principles Ownership and value are derived from verified on-chain events, never from figures a client claims. Verifiable state is a precondition for real capital. NAV, reserve coverage, holdings, and asset identity are published and recomputable. We favor "verify" over "trust." Live features are documented as fact; anything not yet shipped is labeled roadmap. On testnet, every NAV and yield figure is **simulated and clearly labeled** — we never present simulated data as realized results. Security, auditability, and correct accounting come before growth. One chain, proven with real money, before any expansion. ## Where it runs IX RWA is **live on Base Sepolia testnet** (chain id `84532`) today, having migrated off BNB Chain. The protocol is EVM-based and **chain-agnostic** by design, but Base is the primary chain: it offers native USDC rails, a direct Coinbase fiat on-ramp (a fast-follow), and low-cost settlement suited to agent payments. The canonical mainnet chain is confirmed at the audited Phase-2 redeploy. ## Roadmap The following describes planned work. Items are not live until stated otherwise in the relevant section of these docs. The IX-CORE index vault: deposit, mint/redeem at NAV, revenue accrual into NAV-per-share, live (simulated) NAV and reserve coverage, an on-chain asset registry, the one-time BNB→IX-CORE migration claim, and a read-only Agent Gateway (MCP). Chain-as-truth ownership accounting and the first **real** revenue accrual — swapping the testnet feed for real settlement through the `INAVOracle` seam — end to end. SPV / legal wrapper and attestation, third-party security audit, canonical-chain redeploy, and mainnet launch. Secondary exit (redeem-at-NAV, then an AMM listing) and agent-initiated allocation.