# 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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.multipli.fi/technical-architecture/collateral-and-oracle-profile.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.