DEVNETYou are on Solana devnet. Funds are not real. Behavior matches mainnet.

How MLKY works

MLKY lets you turn a graded trading card into a productive asset. This page walks through the entire round-trip of a loan, from the moment a borrower requests a quote to the moment a card is either reclaimed or auctioned.

The four roles in the protocol

Every loan involves four distinct parties:

  • Borrower — the wallet that owns the card-backed NFT and wants USDC liquidity without selling.
  • Liquidity provider (LP) — the wallet that has deposited USDC into a pool and earns interest from the loans that pool funds.
  • Oracle — an off-chain service operated by MLKY that prices each card and signs that price for use on-chain. The oracle is the only entity that can attest to a card's fair market value at a given moment.
  • Auction participants — anyone who places a bid when a defaulted card goes up for sale. Bidders compete to acquire the card; what they pay is applied to the debt, and anything above it goes back to the borrower.

There's also a fifth, semi-passive role: the pool admin, who configures each lending pool's parameters (which collections it accepts, what terms it offers, how concentrated it can become).

End-to-end flow

Quoteoff-chain
Verifymerkle proof
Createloan opens
DrawUSDC paid out
repay
CloseNFT returned
Six on-chain steps; the oracle's quote is the only off-chain interaction the borrower has to initiate.

1. Pick a card and request a quote

The borrower selects a graded card from their wallet. MLKY resolves the card's grading certificate (e.g. a PSA cert number plus its grade) to a canonical asset identity, then asks the oracle for a fresh quote. The quote is short-lived (about five minutes) and contains:

  • The card's fair market value (FMV) in USDC.
  • The maximum loan-to-value (LTV) ratio the protocol will allow on it.
  • The term length and interest rate for the loan the borrower picked.
  • A unique quote id that prevents the same signature from being reused.

2. Verify a Merkle proof on-chain

MLKY maintains a rotating allowlist of every card eligible to be used as collateral. Before opening a loan, the borrower submits a small Merkle proof — a compact proof that their card is in that allowlist — for the current root version. This produces a proof receipt account that the next instruction will consume.

3. Open the loan

The borrower submits the signed oracle quote together with the proof receipt. The protocol verifies the oracle's Ed25519 signature, checks that all the on-chain caps are respected (LTV ceilings, principal limits, per-card and per-asset-type concentration limits), and creates the loan in a Created state. At this point no money or NFT has moved yet — there is a short "pending draw" window during which the borrower can complete the next step.

4. Draw the funds and lock the card

Drawing transfers the borrower's NFT into the protocol's collateral vault and sends them USDC equal to the principal minus the origination fee (the fee is withheld from disbursement). The loan becomes Active, and the maturity clock starts ticking.

5a. Repay before maturity (the happy path)

To close the loan, the borrower pays back the principal plus the full fixed interest. The card is unlocked and returned, and the loan account is closed, refunding rent. There is no early-repayment penalty and no prepayment discount: the interest is fixed at draw time.

Closing does not immediately free the card. One record keyed to the card's grading certificate is retained for 48 hours so that a repayment cannot be turned straight back into a new loan against the same card; after that anyone — in practice the borrower, who gets the rent back for doing it — closes it with card_cooldown_release and the card is borrowable again.

5b. Extend instead of repaying

A borrower who reaches maturity without the cash has a middle option. An extension settles the outstanding interest in full, pays down at least 10% of the principal, and charges a fresh origination fee on a new term — one transfer, no rollover or penalty charge. The loan stays Active and the card never moves; it is the same loan repriced smaller.

Two limits make it a renewal rather than a treadmill. A loan may be extended three times at most, and every extension re-underwrites the card against a fresh oracle quote — so a card that has fallen far enough that even the reduced principal breaches the loan-to-value ceiling is refused. Extending is open for the whole of Active, including inside grace, and closed once the loan has defaulted.

See extending a loan.

5c. Default after maturity (the unhappy path)

If the borrower neither repays nor extends by maturity plus the grace period — the term or 7 days, whichever is shorter — the protocol admin can mark the loan as defaulted. loan_mark_default_and_start_auction takes the Config program-derived address (PDA) with has_one = admin, so one global key starts every sale on every pool, and no other wallet can. The collateral stays locked and the card is put up for sale.

The lender has no move of their own here. MLKY runs the sale and the lender is repaid in cash; there is no instruction by which a pool admin obtains the card.

The borrower does keep a move: they can repay at any point until the card sells, which closes the sale, refunds any standing bidder as a credit, and returns the card.

6. Sale and settlement (only if defaulted)

A descending-price sale opens at the card's appraised value — the fair market value the oracle signed at origination, carried on the loan — and falls linearly to the loan's principal over 24 hours, passing the full payoff on the way down. The first bidder to accept the current price wins the card.

The proceeds are applied in a fixed order: a 5% sale commission, then the pool's principal, then its interest and fees, and everything left over goes to the borrower. The pool cannot receive more than the debt, and the borrower's residual is written as a credit they claim rather than pushed to their wallet.

If no bidder appears before the sale expires, the card moves into protocol custody. The lender takes the loan as a full write-off; they do not receive the card.

Where the protocol lives

MLKY is deployed on Solana. The on-chain program is written in Anchor, and all loan, pool, auction, and oracle accounts are publicly inspectable. The off-chain components (oracle, keeper bots, indexers) are operated by MLKY today, with a roadmap toward multi-party operation as the protocol matures.

Continue reading