# 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