Trust assumptions

Every protocol is a layered combination of trust-minimized on-chain logic and trusted off-chain operations. MLKY 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 MLKY 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 MLKY 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 program-derived address (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 (hashes of the collateral-eligibility tree) 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 (fair market value times loan-to-value, with LTV in basis points). 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.
• Settlement waterfall correctness. Sale proceeds are always applied in the same order — commission, then the pool's principal, interest and fees, then the borrower's residual — and the three amounts sum to the proceeds exactly, for every input. The pool cannot receive more than the debt and the borrower cannot be skipped.
• Custody against the borrower. While a loan is active, the card is frozen under the loan's own authority. The borrower cannot transfer or sell it, and no buyer can take it from them. This holds even if every off-chain MLKY service is compromised. It is not a guarantee against the card's issuer, which is a trust assumption rather than an on-chain one — see NFT-issuer trust below.
• 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 MLKY-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 a single external provider, Alt.xyz. There is no second source to cross-check it. You trust:

• That Alt's prices are a reasonable representation of market value — with no independent opinion to contradict them.
• That the confidence and staleness gates in front of Alt are 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: the live LTV table (80% / 60% / 40% by confidence tier), per-card and per-type caps that limit blast radius, and a refusal to quote at all when Alt's confidence or population signal is below the floor.

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 MLKY 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. MLKY 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.
• Leave locked cards alone. Phygitals' cards are Metaplex Core assets, and that collection holds standing permissions to transfer, burn or freeze any card in it — including one currently locked as collateral. The lock the protocol places is refused by those permissions rather than the other way round, so the protocol can neither stop the issuer using one nor undo it afterwards. A transfer or a burn takes the collateral away; a freeze leaves it in place and takes away the ability to liquidate instead.

This last one is worth separating from the rest, because it is the only item on this page where the trusted party can act directly on collateral rather than on information the protocol consumes. A bad price or a bad Merkle leaf produces a loan that should not exist; this produces a loan that exists, was written correctly, and either has nothing behind it or cannot be closed. It is disclosed rather than fixed: the permissions belong to the collection, so the only technical answer would be to stop accepting Phygitals cards. The reasoning is recorded in ADR-007, and what a lender loses in that case is set out under lender-side risk.

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 — and in the issuer's case, the trust is not only in the inputs. A tokenization issuer holds permissions over the cards it minted that the protocol's lock does not override.

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.