Risks

This page is an honest, comprehensive inventory of the things that can go wrong when using MLKY. It is intentionally direct: protocols that hide their risks tend to surprise their users when those risks materialize, and MLKY'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

MLKY 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 program-derived address (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 MLKY.
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 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 public/private 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. Alt.xyz is the only pricing source, so there is no cross-check against a second provider and no automatic detection of a subtle data-source error. This is the reason the launch-tightened loan-to-value (LTV) table is in force.
Headline fair-market-value anchoring. Today the oracle signs the headline fair market value (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 lifetime (5 minutes), draw-time re-check, the live LTV table (80% / 60% / 40% by confidence tier), per-card and per-type exposure caps, refusal to quote when Alt's confidence signal is below the floor, and the ability to deactivate a compromised oracle key on-chain.

Borrower-side risk

If you are a borrower:

Loss of the card on default. If you don't repay before maturity plus the grace period, the card is sold. You keep whatever the sale returns above your debt, net of a 5% commission, but you lose the card and you lose the difference between a forced 24-hour sale and one you would have run yourself.
A sale with no buyer returns you nothing, and there is no date by which that changes. This is the genuine worst case: the price falls to your principal, nobody takes it, the card goes into protocol custody and there are no proceeds to distribute. MLKY may sell it off-platform later and credit you anything above the debt, but nothing obliges a sale and no deadline sets when one must happen, so your equity in the card is unrealised rather than pending. It is also most likely on exactly the cards where you would most want a residual — ones that have fallen a long way since the loan was written. Plan on nothing.
The residual is a claim, not a payment. It is written to the chain in your name and you have to submit a transaction to collect it, and no interest accrues on it while it sits. It does not lapse on its own: your claim path never checks the clock, so the credit stays collectable by you indefinitely. What happens at 12 months is that the protocol admin gains a competing right to sweep it, and from then on whichever transaction lands first wins — so treat 12 months as the point after which the money stops being reliably yours rather than as an expiry.
Redemption during a sale is a race. The right to repay lasts until the card sells, but a descending sale can be taken by a buyer at any moment, with no notice period. Intending to redeem is not the same as redeeming.
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):

Shortfalls. A defaulted card may sell for less than the debt, and the pool absorbs the difference. Net asset value (NAV) drops, price per share (PPS) drops, and your USDC value is reduced. Note that the 5% sale commission comes off the gross before you are paid, so a sale clearing at exactly the debt still leaves you short.
No-bid sales are a total write-off, with an unscheduled chance of a recovery. A defaulted card may expire without any bid. The card goes into protocol custody, not yours, and the loan is written off against the pool in full at that moment. MLKY can later sell the card off-platform and the proceeds do reach the pool, as a recovery rather than a repayment — so the lift, if it comes, goes to whoever holds shares on the day of the sale rather than to whoever held them on the day of the default. Do not model a held card as a receivable: nothing obliges a sale, no deadline sets when one must happen, and a card can sit in custody indefinitely. The write-off is immediate and certain; the recovery is possible and unscheduled. Both paths by which a lender used to end up holding the collateral — pool_admin_claim_defaulted_collateral and pool_admin_withdraw_nft — were removed in August 2026.
Defaults cannot pay you more than the loan. Your recovery is capped at principal plus interest; proceeds above that are the borrower's residual. Before August 2026 the pool kept half of any surplus above the debt, so the upside case was better than it is now and the shortfall case was worse.
The collateral — or the exit — can be taken away without your involvement. On a loan against a Phygitals card, both the card's presence and your ability to liquidate depend on the issuer not using permissions it holds over its own collection. Transferred or burned, your recovery is the same as a no-bid sale: nothing. Frozen, the card stays exactly where it is and the default becomes unsellable instead — no write-off, no shortfall, and no way to close the loan until the issuer reverses it. This is a trust assumption rather than a protocol guarantee, and it is set out in full under issuer / NFT-backing risk.
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 annual percentage rate (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 (MLKY'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 MLKY app's bundled flow.

Issuer / NFT-backing risk

This is the largest non-protocol trust assumption in MLKY and worth highlighting explicitly: MLKY 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. MLKY'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. MLKY 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. MLKY has no role in this step. Issuer redemption policies (KYC, shipping fees, geographic restrictions) apply.
Issuer onboarding / removal. As MLKY 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.
Standing permissions over cards that are locked. Phygitals issues its cards as Metaplex Core assets, and its collection holds permissions to transfer, burn or freeze any card in it. Those permissions do not pause while a card is collateral. MLKY's lock stops the borrower and stops a buyer; it does not stop the issuer, because Metaplex resolves the issuer's permission ahead of the lock rather than behind it. A transfer or a burn leaves the loan outstanding with nothing behind it and no protocol action that recovers it — the transfer case is tested against Metaplex's own program, and the burn case follows from that permission being built the same way rather than from a test. A freeze is a different shape: the card stays where it is and the default becomes unsellable instead, because settling a sale means handing the card to its buyer. It is also set on the collection rather than on one card, so it would reach every Phygitals loan at once, and nothing tests it. All three are disclosed rather than mitigated — the permissions belong to the collection, so declining them would mean declining Phygitals cards altogether. Nothing suggests any of them has ever been used; the decision to accept them and say so is recorded in ADR-007.

Mitigations MLKY 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 MLKY cannot offer: insurance against issuer-side failure, any guarantee of physical-card delivery, or any technical block on an issuer's own permissions over the cards it minted.

Governance and operational risk

MLKY'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 — the hash of the collateral-eligibility tree — 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 MLKY'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 MLKY 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.

MLKY'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.