Trust assumptions

Every protocol is a layered combination of trust-minimized on-chain logic and trusted off-chain operations. Milky is no exception: the parts of the system that handle money and collateral are verified by the Solana program, while the parts that decide what to price and at what price are off-chain services operated by the Milky team today.

This page is an honest inventory of which is which.

What the on-chain program verifies

These properties are enforced by the Solana program itself. Even if every off-chain Milky service were compromised tomorrow, these guarantees would still hold:

• Signature validity. Every signed quote must have a valid Ed25519 signature from a pubkey present in the on-chain AllowedOracle list, over the exact bytes that match the on-chain reconstruction.
• Replay protection. A UsedQuote PDA is created per (oracle pubkey, quote id) pair on first use. The same quote can never be used twice.
• Merkle inclusion. A binding leaf must be provably included in one of the K=3 currently-active Merkle roots in Config. A fake binding rejected by the Merkle proof can never produce a loan.
• Field consistency. The oracle's signed quote, the Merkle proof receipt, and the on-chain accounts (pool, NFT mint, collection) must all agree on the (NFT, cert, asset type, pool) tuple. Inconsistencies cause the loan-create transaction to revert.
• Caps. Principal must be within the pool's [min, max] range, within the per-card cap, and within FMV × LTV / 10,000. The LTV must respect both the global ceiling (90%) and the pool ceiling.
• Concentration. Per-asset-type exposure caps and pool utilization caps are checked on every draw.
• Auction waterfall correctness. Settlement always pays the pool before the protocol fee, and never pays the borrower.
• Custody. While a loan is active, the NFT cannot be transferred out of the collateral vault by anyone other than the loan authority PDA (which only the program can sign for).
• Lock semantics. A given NFT cannot back two simultaneous loans (ActiveLock). A given physical cert cannot back two simultaneous loans (CertLock).

What you trust off-chain

These properties are operationally enforced by Milky-operated services. A failure or compromise of these surfaces could harm users in specific ways, even if the on-chain program continues to function correctly.

Pricing accuracy

The oracle signs FMVs based on data from external providers (Alt.xyz, optionally CardHedger). You trust:

• That the data providers' prices are reasonable representations of market value.
• That the aggregation logic (single-source headline, two-source conservative-min) is implemented correctly.
• That nobody intervenes between the data fetch and the signing step to substitute a different price.

The on-chain program will accept any price the oracle signs. If the oracle signs $10,000 for a card actually worth $100, the protocol will lend against the inflated value up to its caps.

Mitigations: conservative LTVs (default 70%), per-card and per-type caps that limit blast radius, plus the optional second source that refuses to sign if it disagrees.

Merkle allowlist correctness

The off-chain indexer decides which (NFT, cert, asset type) leaves appear in each Merkle root. You trust:

• That the indexer correctly attributes each NFT to the grading certificate the issuer minted it against.
• That removed certs (e.g. cards that were redeemed out of the issuer's vault and the corresponding NFT was burned) are evicted from future roots within a reasonable timeframe.

A malicious or buggy indexer that signs off on a wrong NFT-to-cert binding would let a borrower open a loan against a card they don't actually own. The signed quote would still need to bind to the same (wrong) cert and asset type, so this requires both the indexer and the oracle to be inconsistent in the same direction — but the protocol trusts both off-chain services, in concert, to be correct.

Oracle key custody

The oracle's signing key is a regular Ed25519 keypair held by the Milky backend. You trust that:

• The key is stored securely (hardware-backed where possible).
• The key is not leaked or stolen.
• A key rotation procedure exists if compromise is suspected (AllowedOracle can be deactivated on-chain in seconds).

Multi-party signing (multisig or threshold-MPC) for the oracle key is on the roadmap but not in production today.

Admin key custody

A separate admin key controls Merkle root rotation, oracle allowlist updates, and pool-parameter updates. You trust the same set of properties about the admin key as the oracle key. Multisig governance of the admin key is the production target.

NFT-issuer trust (physical-card backing)

The on-chain NFT only matters because there's a real graded card sitting in the issuer's vault. Milky does not custody, vault, or insure any physical card; it lends purely against the on-chain NFT minted by a third party. You therefore trust the issuer (today, CollectorCrypt and Phygitals) to:

• Hold the physical card that backs each NFT in their vault, faithfully and continuously.
• Have minted the NFT against the specific grading certificate it claims to represent (no swap, no duplicate, no orphaned mint).
• Honor redemptions when an NFT holder requests the underlying card, and follow their published custody and insurance policies.

The lending protocol cannot enforce issuer-side correctness; it can only ensure that on-chain ownership of the NFT is well-defined and that the loan/auction state machine is faithfully executed. If an issuer fails — operationally, financially, or through fraud — the NFT can become detached from any redeemable physical card. This is the most significant trust assumption in the system.

Off-chain availability

Even when the on-chain program is healthy, the user-facing experience depends on:

• The oracle backend being online to issue quotes.
• The keeper bot triggering defaults and no-bid cancels promptly.
• The indexer reflecting accurate loan and pool state in the app.

Outages here do not lose user funds, but they degrade the user experience and can delay default resolution.

Summary

The honest summary: on-chain logic prevents money or collateral from being moved incorrectly given honest off-chain inputs, but the off-chain inputs themselves are trusted. The protocol's design deliberately limits the blast radius of any single off-chain failure (via caps, conservative LTVs, multi-source aggregation) but does not eliminate it.

For a more applied view of these risks, see the Risks page.