Collateral and Oracle Profile

A Collateral Profile is the unit of risk configuration. It ties together:

• token address + adapter

• oracle method

• liquidity assumptions

• parameter set in RiskRegistry

Profile IDs

Use bytes32 profileId = keccak256(abi.encode(symbol, token, version)) or explicit constants.

Liquid collateral eligibility (hard gate)

A token may enter the liquid pool only if all are true:

1. Priceability

   • at least two independent pricing sources or a primary + robust sanity check

   • staleness behavior defined

2. Liquidation feasibility

   • auction can clear meaningful size without relying on multi-day off-chain processes

   • DEX depth, market-maker commitments, or reliable redemption within short settlement

3. Transferability

   • adapter and auction house can legally/technically hold and transfer the token

4. Operational transparency

   • supply, NAV (if applicable), and key events observable

   • clear issuer/custodian posture

---

Oracle and valuation architecture

Pricing is the sharp edge of an RWA-collateral protocol. The design must be conservative by default and fail closed.

1. Components

• Price Router (PriceRouter)

  • single read interface for the Ledger: getPrice(profileId) -> (price, status)

  • returns USD price and a status code

• Feed Verifier (SignedFeedVerifier)

  • accepts signed price messages from authorized signers

  • verifies quorum and freshness

  • stores latest accepted value

• Guard Layer (PriceGuards)

  • sanity checks: max delta, staleness, cross-source divergence, market premium/discount bounds

  • can place a profile into restricted mode

2. Price statuses

The Ledger must act differently depending on price status:

• OK: price fresh and within guardrails

• STALE: too old; issuance disabled; repayments allowed

• DISPUTED: sources disagree; issuance disabled; may tighten safety checks

• HALTED: manual stop; only risk-reducing operations allowed

3. Pricing methods per asset category

A) Tokenized T‑bills (NAV-based)

Target behavior: price increases gradually with accrued yield.

Primary source

• signed NAV/share price from an authorized signer set (issuer admin, fund admin, or designated oracle operators)

Sanity sources

• on-chain market price TWAP (if token trades)

• bounded daily drift: NAV should not jump beyond plausible yield + market move bounds

Guardrails

• staleness threshold (tight): if NAV not updated within SLA, set STALE

• max-change: if NAV changes beyond X bps/day, require multi-signer consensus or halt

B) Tokenized stablecoins

Target behavior: price near $1 with depeg detection.

Sources

• external oracle feed (primary)

• on-chain DEX TWAP (sanity)

• optional: CEX index via signed feed (sanity)

Guardrails

• if price < 0.995 (configurable), issuance disabled automatically

• if price < 0.985, peg rail outflow disabled and safety factor tightened (optional)

• staleness triggers restricted mode

C) Tokenized gold

Target behavior: price tracks spot gold with token-specific conversion.

Sources

• XAU/USD spot feed (primary)

• token market TWAP (sanity)

• token-specific ratio (e.g., token represents 1 gram or 1 ounce)

Guardrails

• divergence clamp between spot-implied and market price

• staleness and max delta checks

4. Oracle message format (signed feed)

Use EIP‑712 structured data:

• profileId

• price (USD per token unit, AMT precision)

• validAfter, validUntil

• nonce (optional)

• sourceId

Quorum rules:

• N-of-M signers, configurable per profile

• reject if less than quorum, stale, or outside bounds