# Vault Reporting ### **Overview** Ditto offers your vault infrastructure an upgrade through the **Ditto Custom Oracle Service** — a decentralized, restaked oracle that publishes the portfolio NAV on a fixed schedule (e.g., hourly/4h/daily) with a defined SLA and max‑staleness guard. This value becomes the **source of truth** for calculating the current vault share price, defined as: $$ NAV\_{\text{usd}} = \sum (\text{assets marked to FMV}) - \text{liabilities} $$ These values use 18 decimals with rounding mode “round‑down” and the base currency (USD) explicitly stated.\ This ensures a single, unambiguous formula — eliminating pricing disputes and providing a reliable reference for ERC-4626/7540 hooks that consume this value — allowing all depositors to see the near-real-time, verifiable performance; typical lag = block finality + update interval. *** ### Pricing Policy > **Source order:** on‑chain oracle/TWAP → vendor FMV → VWAP fallback.\ > **TWAP window:** 30 minutes (default).\ > **SLA:** 5 minutes.\ > **Max staleness:** 45 minutes.\ > **FX oracle & cache TTL:** configured by governance Prices are aggregated in order of priority: first from on‑chain oracles or TWAPs, then from vendor full‑market‑value feeds, with a volume‑weighted average price (VWAP) as a fallback. *** ### **Motivation** Today, vault performance and total asset value are derived from multiple off-chain dashboards manually. These are valuable tools but come with limitations: * Updates are delayed and infrequent. * Off-chain dashboards require human reconciliation of wallet lists and signer changes; our feed removes that manual step by attesting source lists on-chain. By integrating Ditto’s **Custom Oracle**, your vault gains a **continuous, decentralized, and transparent pricing mechanism** — making the vault share value **cryptographically verifiable** at all times. *** ### **How It Works** #### **1. Data Aggregation** Ditto restaked operators fetch data from all relevant asset sources: | Source | Description | | ----------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | |

Indexers/RPC scans
example

| Fetched via Debank / RPC scans. | | **Perp DEX positions** | Collateral ± unrealized PnL at the oracle price; apply a haircut if the price feed is stale. | | **CEX balances (read‑only keys)** | Use exchange APIs with read‑only keys; mark balances to FMV via the pricing policy. | > 🔒 Read-only API keys are shared among Ditto operators and never exposed publicly.\ > Keys are managed through KMS/HSM with at-rest encryption, restricted by IP allow-listing and least-privilege scopes.\ > Only fetcher pods have ephemeral access; operators never view raw credentials.\ > Key rotation cadence(e.g. 30 days) and a compromise response playbook are enforced to ensure ongoing security integrity.\ > Operators never see raw secrets; only short-lived fetcher tokens are used *** #### **2. Operator Consensus** Each Ditto restaked operator independently computes the **portfolio’s total USD value** based on the aggregated data. * **Operator set size (n)** and **threshold (t)** define how many signatures are required to publish NAV. * **Aggregation**: median of submitted NAV values with a median absolute deviation (MAD) outlier filter to remove outliers. * **Signature scheme**: BLS aggregated signatures, with slashing or eviction for misbehaving operators. Values are then submitted to the Othentic Consensus Aggregator, which: * Validates multiple operator submissions and their signatures. * Publishes this value on-chain. *** #### **3. On-Chain Publication** The **on-chain value** represents the **Net Asset Value (NAV)** of the vault, updated periodically (e.g., hourly or daily). This value directly determines the **current vault share price** used for: * **New deposits:** calculates how many shares the user receives per token deposited. * **Withdrawals:** determines how much underlying value each share redeems. * **Transparency:** gives depositors a verifiable real-time metric of vault performance. To prevent stale-price exploitation during periods of high inflows or outflows, the protocol applies several safeguards: * **Deposit/withdrawal queue windows**: aligned to NAV update intervals. * **Deviation guard**: compares the published **NAV** against a **TWAP NAV**. * **Preview functions** (`previewDeposit`, `previewWithdraw`): revert when **staleness exceeds the SLA**, ensuring users interact only with fresh prices. * An optional **anti‑arbitrage spread** may be applied near the SLA edge. These controls ensure that pricing integrity and fairness are maintained, even under volatile market conditions. *** ### **Benefits** * Provides a **near‑real‑time** (latest verified) on‑chain NAV and price per share feed with a defined SLA and staleness guard. * Supports both DeFi positions and CEX balances via read‑only keys. * Enables ERC‑4626/7540 vault hooks to access the **latest verified** NAV for depositor fairness. * Gas infrastructure via ERC‑4337/7579 is used only for transaction submitters, reducing overhead for vault operators. *** ### **Deployment Flow** 1. **Setup** * Curator provides read-only API keys and wallet addresses. * Ditto registers these sources in the oracle config. 2. **Operator Fetch & Compute** * Restaked operators independently fetch and calculate total USD value. 3. **Consensus & Publication** * Aggregated operator value is posted on-chain via Ditto Oracle Automation. * The vault smart contract uses this value to fetch share price. 4. **Verification** * Any user can verify vault NAV and share price directly on-chain. * Frontend dashboards display “verified by Ditto” tag with latest update timestamp. To start integration please contact *** ### **Service Summary** * Provides a **near‑real‑time** (latest verified) on‑chain NAV and price per share feed with a defined SLA and staleness guard. * Supports both DeFi positions and CEX balances via read‑only keys. * Enables ERC‑4626/7540 vault hooks to access the **latest verified** NAV for depositor fairness. * Gas infrastructure via ERC‑4337/7579 is used only for transaction submitters, reducing overhead for vault operators. *** ### **Outcome** By integrating Ditto’s Custom Oracle, your vault transitions from **opaque manual valuation** to **fully transparent, on-chain verified NAV and share pricing**. This improves: * **Depositor trust** * **Operational transparency** * **Auditability** * **Market confidence** * **Reduced pricing delay** and positions your strategy as a leader in **institutional-grade DeFi asset management**. #### We put NAV on-chain without migrating your stack; competitors either keep NAV off-chain (Cryptio/Lukka) or require moving assets into their vault (Enzyme). | Platform | On-Chain Pricing Feed | DeFi + CEX support | Notes | | --------------------------- | -------------------------------------------- | ------------------------------- | -------------------------------------------------------------------------------------- | | **Ditto Custom NAV Oracle** | ✅ Yes — Othentic BLS-aggregated attestations | Yes (DeFi + CEX read‑only keys) | On‑chain quorum publishes NAV and pps; can ingest FMV from vendors like Lukka/Cryptio. | | **Cryptio** | ❌ None | Partial (off‑chain accounting) | Off‑chain accounting; no on‑chain oracle. | | **Lukka** | ❌ None | Partial (enterprise FMV) | Produces FMV but no on‑chain output; can be ingested by Ditto. | | **Enzyme** | ✅ Internal (vault-level) | No external CEX | Native vault accounting internal to Enzyme; cannot aggregate external CEX balances. | *** ### **Update SLA and Failure Handling** To maintain reliable on-chain pricing, the NAV Oracle enforces a strict **Service Level Agreement (SLA)** for update frequency.\ If updates are missed or delayed, the system automatically applies fallback and signaling mechanisms. **Mechanisms:** * **Skip-block policy:** minor missed updates within tolerance are skipped without slashing to prevent redundant transactions. * **Operator set churn:** persistent underperformance triggers automatic replacement of inactive operators from the active set. * **Staleness guard:** when the update delay exceeds the SLA threshold, reads fall back to the **last valid NAV** value, and a `Stale()` event is emitted on-chain. These controls ensure continuity of data availability while preserving transparency around operational reliability. *** ### **Proof Bundle Publication** Each NAV update includes a **proof bundle**, containing: * Source data snapshots (DeFi + CEX positions) * Pricing ticks and oracles used * Individual operator signatures The **hash of the proof bundle** is published on-chain with every update, while the full bundle is stored off-chain for audit and verification purposes. **Events:** * `ProofBundlePublished(proofHash, proofURI)` — emitted per update. * The `proofURI` provides access to the full verification bundle hosted on IPFS, Arweave, or a similar decentralized store. This ensures reproducibility, auditability, and verifiable linkage between on-chain NAVs and off-chain data sources. *** ### **Incident Communication** In the event of data feed issues, missed updates, or operator coordination failures, Ditto maintains a dedicated **incident communication channel** and **status page**. **Key components:** * Real-time status updates on NAV Oracle health and SLA adherence. * Public incident reports summarizing root cause, resolution timeline, and corrective measures. * Operator coordination and transparency log for historical events. This guarantees operational transparency and trust for all vault integrators and depositors.