Risks

This page is an honest, comprehensive inventory of the things that can go wrong when using Milky. It is intentionally direct: protocols that hide their risks tend to surprise their users when those risks materialize, and Milky's design contains both engineered mitigations and trust assumptions that you should understand before depositing or borrowing.

The risks are grouped by surface area: smart contracts, oracle and pricing, borrower-side, lender-side, issuer trust, governance, and regulatory.

Smart-contract risk

Milky is implemented in Anchor on Solana. The on-chain program controls the movement of all USDC and NFTs in the protocol; a bug in the program could allow funds to be stolen or locked.

Specific concerns:

Logic bugs. Despite extensive test coverage and review, a protocol of this complexity may contain unknown bugs. The most consequential surfaces are the loan create/draw/repay/close path, the auction settle path, and the oracle quote verification.
Account-model edge cases. Solana's account model has subtleties around rent, account closing, and PDA derivation that can produce surprising behavior under unusual conditions.
Dependency risk. The program depends on Anchor, the SPL Token program, and Metaplex's Token Metadata program. Bugs or upgrades in those dependencies could affect Milky.
Solana network risk. Periodic Solana network congestion or outages can prevent transactions from landing, delay default resolution, and cause user-experience issues. They do not affect the on-chain state once a transaction lands, but they can affect timing.

Mitigations: the protocol uses checked arithmetic everywhere, follows Anchor's recommended patterns for account validation, and has an extensive test suite covering happy paths, edge cases, and adversarial scenarios. An external audit is part of the production launch path.

Oracle and pricing risk

The oracle is the biggest off-chain trust surface (see trust assumptions for the full inventory).

Specific concerns:

Bad pricing data. If Alt.xyz (or whichever data source is active) returns wrong prices for a card, the oracle will sign quotes based on those prices and the protocol will lend against them. The on-chain caps limit blast radius but don't eliminate it.
Oracle-key compromise. If the Ed25519 oracle keypair is stolen, an attacker can sign arbitrary quotes against any allowlisted asset type, up to the protocol's caps. The AllowedOracle allowlist can be updated to revoke a compromised key, but there is a window between compromise and revocation.
Single-source posture. In single-source mode, there is no cross-check against a second pricing source. A subtle data-source error has no automatic detection.
Headline-FMV anchoring. Today the oracle signs the headline FMV rather than the lower bound of the confidence interval. The conservative LTV partially compensates for this, but it is a less defensive posture than anchoring on the lower bound would be.
Stale price between quote and draw. The protocol re-checks the quote expiry at draw, but within the 5-minute window the price the lender effectively underwrites can move. This is a small risk for most card markets.

Mitigations: short quote TTL (5 minutes), draw-time re-check, optional two-source aggregation that takes the minimum, conservative default LTV (70%), per-card and per-type exposure caps, and the ability to deactivate a compromised oracle key on-chain.

Borrower-side risk

If you are a borrower:

Total loss of card on default. If you don't repay before maturity plus the grace period, the card is auctioned and you receive nothing — not even the surplus above the debt. Repaying late by even one day costs you the card.
Card immobility during loan. From the moment you draw, the NFT is locked under the protocol's authority. You cannot transfer or sell it, and because the issuer redeems the physical card only against that NFT, you cannot pull the physical card from the issuer's vault either.
Fixed interest is fixed. If you repay early, you still owe the full term interest. There's no early-repayment discount.
Pool can be paused. If the pool you borrowed from is paused, you can still repay (repayments are not pause-blocked), but a paused pool cannot accept new loans.
Operational risk on repayment. A wallet error, lost private key, or transaction failure near the deadline can convert a healthy loan into a default. Build in a buffer.

Mitigations: clear deadline visible in the app, predictable time-based default (no surprise health-factor liquidations), grace period before default eligibility, and the option to repay at any time after draw.

Lender-side risk

If you are an LP (today, that means a pool admin — see the single-LP note):

Auction shortfalls. A defaulted card may sell at auction for less than the debt, and the pool absorbs the difference. NAV drops, PPS drops, and your USDC value is reduced.
No-bid auctions. A defaulted card may expire without any bids, ending up in the pool's custody. The card's eventual disposition determines your recovery, with timing uncertainty.
Concentration in pricing source. All pool yields ultimately depend on the oracle's pricing being correct. Systematic mispricing could affect every loan in the pool.
Liquidity timing. Withdrawing means burning shares for the pool's idle USDC. If utilization is at the cap, large withdrawals may need to wait for repayments.
Variable yield. There is no fixed APR for LPs. Realized returns depend on borrow demand, default rates, and auction recoveries.
Pool admin is immutable. You cannot transfer pool admin authority once initialized, and you cannot eject a misbehaving admin (today the admin is also the only LP, so this is internal, but in a future multi-LP world it would matter more).

Mitigations: per-card and per-type caps that bound any single bad outcome, conservative default LTVs, utilization caps that preserve withdrawal headroom, and pause functionality for emergency response.

Bidder-side risk

If you bid in an auction:

You're buying a card you may not have inspected. Auction bidders do not have access to the physical card before bidding. You rely on the grading certificate, the oracle's identity binding, and the underlying issuer's physical custody.
No buyer's remorse. Once a Dutch bid is accepted (or an English auction settles), the card is yours. There's no on-chain cancellation.
Settlement is winner-signed. The protocol expects the winning bidder to settle (Milky's app bundles this in the same Dutch bid transaction). If you bid via a custom flow that decouples bid and settle, you must settle within a reasonable window.

Mitigations: the auction is fully on-chain and transparent, the collateral-binding rules ensure the NFT corresponds to the certified card you're bidding on, and most bidders use the Milky app's bundled flow.

Issuer / NFT-backing risk

This is the largest non-protocol trust assumption in Milky and worth highlighting explicitly: Milky never custodies the physical card. The on-chain NFT was minted by a third-party tokenization issuer (today, CollectorCrypt and Phygitals), and that issuer is fully responsible for holding the underlying graded card and honoring redemptions. Milky's role is strictly to operate a lending market against the existing NFT representation.

Specific concerns:

Issuer solvency or operational failure. If the issuer goes out of business, loses inventory, or stops honoring redemptions, the on-chain NFT may no longer correspond to a retrievable physical asset. Lenders funding the loan, borrowers locking the NFT, and bidders winning the auction all carry this exposure.
Mint integrity. Lending fairness requires that the issuer minted exactly one NFT against each grading certificate, against the right certificate, and never re-minted the same physical card under a different mint without burning the original. Milky cannot cryptographically verify this against the physical world; it relies on the issuer's mint discipline and the protocol's CertLock to catch same-cert duplicates inside its allowlist.
Redemption logistics. When a card is finally claimed (e.g. after a successful auction), the new owner coordinates directly with the issuer for shipping, insurance, and any import duties. Milky has no role in this step. Issuer redemption policies (KYC, shipping fees, geographic restrictions) apply.
Issuer onboarding / removal. As Milky adds or removes issuers from the allowlist over time, the binding root rotates. Borrowers and lenders should pay attention to which issuers a pool currently recognizes — not all pools accept all issuers.

Mitigations Milky can offer: collection-level allowlists let pools restrict themselves to issuers whose track record they're comfortable with; per-asset-type and per-card caps bound any single bad outcome. What Milky cannot offer: insurance against issuer-side failure or any guarantee of physical-card delivery.

Governance and operational risk

Milky's protocol governance is centralized today — multisig and distributed-operator roadmaps exist but are not yet in production.

Specific concerns:

Admin-key compromise. A compromised admin key could rotate the Merkle root to include malicious leaves, deactivate honest oracles, or update pool parameters in damaging ways.
Pool-admin immutability. A compromised pool admin (today, also the LP) cannot be rotated; the only recourse is to drain the pool via withdrawals.
Single-operator availability. If Milky's backend is offline, new loans, new defaults, and quote refreshes don't happen. Existing on-chain state is unaffected.
Single-LP launch posture. Today's pools are funded by a single LP per pool — typically the operator. This concentrates LP risk in the operator's risk-management practices.

Mitigations: the on-chain caps limit blast radius even of a fully compromised admin, the AllowedOracle allowlist is fast to update, withdrawals are pause-resistant, and the multi-party governance roadmap is in active development.

Regulatory and jurisdictional risk

The legal status of tokenized graded trading cards as collateral, and of platforms that extend credit against them, varies by jurisdiction and is evolving.

Specific concerns:

Securities classification. A regulator could in principle take the position that LP shares are securities; even if Milky pushes back, a regulatory action could disrupt operations.
Lending licensing. Consumer lending regulations vary widely. A jurisdiction may require licensing to extend credit to its residents.
Pawn / lending laws. Some jurisdictions have specific pawn regulations that could apply to card-collateralized loans.
Tax. Borrowing against a card may have different tax consequences in different jurisdictions than selling it. Consult a qualified tax professional.
Sanctions and AML. The protocol does not sanction-screen on chain, but operators may be required to in their off-chain workflows.

Milky's operating entity addresses these constraints in its terms of service and through jurisdictional restrictions. None of this eliminates the underlying regulatory uncertainty.

What you can do

Start small. Whether borrowing or lending, begin with an amount whose worst-case loss you can absorb.
Read the section relevant to your role end to end. The Borrowing and Lending sections cover the operational rules in depth.
Watch protocol updates. Major changes (new pools, oracle rotations, parameter updates) are announced through the project's public channels.
Treat the documented behavior as authoritative over informal conversations. If something differs from this site, the documentation here is the contractual reference for the deployed protocol.