Loaded NFT Pool
Pool lending against staked, reward-bearing .qom domains. Collateral is priced by reading the staking contract's deterministic emission schedule directly — no floor-price oracle, no peer auction, no off-chain valuation. Collateral PV is , computed in a single eth_call. The closest external precedent is Ajna's oracle-less bid-bucket model; the difference is that we don't need lender-set bids because the collateral prices itself via the QNS Staking emission state. Planned, builds after Forge is live and stable.
What problem this solves
Pool lending against NFTs is hard because NFTs lack reliable price oracles. Every prior pool design has had to build a floor-price feed that is slow, noisy, and manipulable — BendDAO's near-insolvency in August 2022 happened because ETH-priced floors fell faster than auctions could clear. Blur Blend in 2023 sidestepped this by going peer-to-peer with no oracle, but its perpetual + refi-auction model only clears under thick lender-side participation, which has not materialized for any NFT class outside top blue-chips.
.qom domains carrying an active QNS Staking position are a different shape of asset. The staking contract emits ZAP on a deterministic schedule — fixed reward rate , character-tier-weighted multiplier , fixed reward-end time . The future cash flow of a specific staked .qom is therefore a known on-chain quantity any contract can read without trusting an oracle.
We can run a pool against that. The collateral prices itself.
Collateral PV — the closed form
Let be the position's already-earned ZAP balance awaiting unlock, the per-position reward rate, the position's weight share (a function of character tier and lock multiplier), the reward-end timestamp, and current time. The position present value, in ZAP, is
Both terms are state on QNS Staking. The first is a plain mapping(uint256 => uint256) lookup; the second is a multiplication of three constants the contract exposes as view functions. There is no price feed for the NFT itself — its value is a function of the staking contract's own deterministic state.
Convert to QOM-equivalent borrow capacity using the same TWAP Forge uses (read off the LP-burned ZAP/QOM market on QomX), with a discount factor for safety margin:
The discount factor absorbs three risks: (i) ZAP/QOM TWAP drift over the loan term, (ii) any divergence between the contract's published emission schedule and realized emissions (governance pause, parameter change), and (iii) keeper / unstake-cost slippage if the contract has to recover via early-unstake. Launch target , intentionally conservative; tighter values follow once historical realized-vs-modeled emission ratios are observable.
Why pricing without an oracle works here
The collateral's value to the pool is bounded by two on-chain facts the contract can read with no off-chain dependency:
- The locked ZAP balance on the position (already-earned, awaiting unlock).
- The future emissions the position is entitled to until reward end ().
Both are state on QNS Staking. Both can be read in a single eth_call. Neither involves a price feed for the NFT itself. The pool then converts the ZAP-denominated value into a QOM borrow limit using the QomX TWAP — which reads a market whose LP is burned, so the rate cannot be rugged at the venue level.
No floor-price oracle. No off-chain valuation. The collateral is its own source of truth.
How it will work
- You arrive holding a staked
.qom. It is deposited in QNS Staking with rewards accruing on the standard schedule. - You deposit it into the Loaded NFT Pool. The pool sets a lien on the staking position via QNS Staking's lien hooks. The position keeps earning ZAP.
- You borrow QOM up to .
- The position keeps emitting ZAP to the pool's account. Lien-routed ZAP is sold to QOM at the TWAP and applied to your debt principal — the same self-deleveraging primitive Bootstrap Loans use, just initiated against an existing staked position rather than a fresh mint.
- Repay any time to clear the lien and reclaim full ownership of the
.qom. Or let the emissions finish the job — whichever comes first.
When liquidation makes sense (and when it doesn't)
Most "liquidation" events on this product won't be a fire sale of an NFT. They will be the contract triggering an early unstake via the lien — pulling out whatever ZAP is currently locked plus the remaining .qom, applying both to the debt.
A real auction-on-default of the underlying .qom only happens if:
- The borrower's at current TWAP proves insufficient to cover the debt, AND
- The borrower does not top up.
Because the position's worst-case ZAP value is mostly fixed at deposit time (the staking schedule is contract-immutable until reward-end), this scenario is bounded. Borrowers cannot accidentally take a position that becomes catastrophically underwater the way a floor-price-based NFT loan can — the residual NFT itself only enters the recovery path after the deterministic emissions have already been exhausted against the debt.
Why this only works on QOM
The product depends on three pieces of on-chain infrastructure that don't exist together anywhere else:
- QNS Staking — deterministic emission schedule and registry-level lien hooks (
setLien,clearLien,setApprovedLienContract). - A permanent ZAP/QOM market with burned LP, so the price reference is rug-proof at the venue level.
.qomdomains as the underlying NFT — limited supply, character-tier-weighted staking rewards, and active marketplace liquidity for the unstaked underlying.
Pawn-style P2P loans against NFTs work on every chain. Pool loans against staked, reward-bearing NFTs whose debt is auto-serviced from the collateral's own emission stream are unique to a chain that has all three primitives. As of mid-2026, no other chain exposes registry-level lien hooks at the controller layer for any NFT class — the closest live precedent is Alchemix SRENS for ENS auto-renewal, which uses Gelato keepers + a separate Alchemix CDP rather than a lien primitive at the registry itself.
Where this sits in the NFT-lending landscape
| Mechanism | Live example | What we do |
|---|---|---|
| Pool, floor-oracle-priced | BendDAO (2022) | Avoid — floor oracles fail under stress |
| P2P term, lender-priced | NFTfi, Arcade, our Pawn | Pawn handles the long tail |
| P2P perpetual, refi-auction | Blur Blend | Avoid — fragile under thin lender side |
| Bid-bucket pool, oracle-less | Ajna | Closest precedent — but we read state, not bids |
| Self-repaying via separate yield aggregator | Alchemix SRENS | Bootstrap Loan does this; here we use the collateral's own emissions |
| Pool, self-pricing via collateral's emission state | none at scale | The Loaded NFT Pool |
Status
| Status | Planned — design in progress, audit not yet scheduled |
| Target launch | After Forge is live and stable |
| Lender pool | TBD — may share Forge's QOM pool, may be standalone |
| Borrowable asset | QOM |
| Collateral | A staked, reward-bearing .qom on QNS Staking |
| Oracle | None for NFT pricing. ZAP/QOM TWAP only for converting ZAP value to QOM borrow limit. |
Why the discount factor matters. is the single calibration knob that trades borrower utility against pool risk. At , a position whose ZAP-equivalent value is 1,000 QOM (via the ZAP/QOM TWAP) borrows up to 400 QOM. Lower improves pool safety in scenarios (i)–(iii) above; higher improves capital efficiency for borrowers but compresses the cushion before the recovery path engages. The launch value is conservative on purpose — once realized-vs-modeled emission divergence has 6–12 months of empirical data, can ratchet upward in line with the historical worst-case observed deviation.
Comparison to PT-collateral lending on Aave/Morpho. Pendle PTs have a similar property: their value is a closed-form function of time-to-maturity and a discount rate. The Morpho PendleSparkLinearDiscountOracle reads PT prices off a linear-discount curve to avoid time-decay manipulation. The Loaded NFT Pool is structurally analogous — except instead of pricing a zero-coupon claim, we price a stream of deterministic future emissions, and instead of relying on an oracle adapter, we read the issuing contract directly.