λ Lambda Markets working document · token mechanics · proposal

Reserve-Ratio Controller

How — and why — the split between burning and time-locking LMDA moves. One published rule instead of a monthly judgement call, so you never have to take our word for it: the two commitments — supply only shrinks and the protocol never market-sells — hold in every state the mechanism can reach. This is a proposal, open for feedback before it lands in the strategy doc.

The mechanism in one breath

A burn floor of 25% on every LMDA spend, forever. Beyond the floor, the split follows one of three published regimes — protect (25% burn), rebuild (50%), flush (75%) — selected by one internal number: the platform's USDC runway versus a 24-month target. Locked LMDA vests into a protocol-owned reserve over 12 months; a fixed slice of it supplies a fully visible liquidity book that strives to quote both sides — for every ask, a matching bid — post-only, on an on-chain order book. Filled asks are passive sales whose USDC sweeps to the reserves — the protocol only ever provides liquidity; it never takes it. This is not a stabiliser and not a rescue device; it exists to be fair, compliant, and durable.

01 / THE BIND

Three constraints that don't naturally coexist

Any split has to satisfy all three at once. A fixed number can satisfy the first two or the last two — never all three. That's why the split is dynamic, and why the thing that's fixed is the rule, not the number.

Credibility

"Supply only shrinks"

The doc stakes LMDA's story on usage burning supply. If burns quietly stop when convenient, the whole token note reads as weather-dependent. Whatever the rule is, some burn must be unconditional.

Durability

The platform must outlast cycles

Development, data and infrastructure are paid in USDC. Every token burned is value deliberately retired — right when reserves are healthy, wrong if it would ever cut into the platform's ability to keep building through a full bear market.

Compliance

Never market-sell

The public line is explicit: the protocol never takes liquidity, only offers it passively on terms available to any holder. So protocol-held LMDA converts to USDC only when someone chooses to lift a resting ask — never on demand.

02 / THE FLOW

Where every token goes

One rule for all LMDA inflow: usage spend and the LMDA-paid share of subscriptions route through the same splitter, so there's a single published mechanism instead of two. USDC-paid subscriptions bypass it entirely — they are the dependable USDC engine; passive ask fills in the liquidity book (section 05) add USDC on top when the market comes to meet them — welcome, never budgeted. Usage paid in USDC takes the simplest route of all: access is instant and the USDC joins reserves — payments are never swapped into LMDA.

Subscriptions paid in USDC or LMDA Usage spend priced in LMDA · payable either way Epoch splitter burn share B · set by regime USDC reserves runway · opex Time-lock → reserve vests 1/12 per month Burned permanent · supply shrinks USDC-paid share — straight to reserves LMDA-paid share same rule as usage 1−B B a fixed slice quotes the balanced liquidity book (05) passive ask fills USDC sweeps to reserves reserve ratio R — selects the regime paid in USDC straight to reserves — never swapped into LMDA
The one feedback loop that makes it dynamic: reserves feed the ratio, the ratio selects the regime, the regime decides how much LMDA is retired versus retained in the protocol-owned reserve. A fixed slice of that reserve supplies the liquidity book in section 05 — a bid for every ask as the target, ring-fenced from the runway. USDC-paid usage takes the bottom path — straight to reserves, never swapped into LMDA. Nothing anywhere in the loop ever takes liquidity.
03 / HOW YOU PAY

Pay in either currency — the sink stays real

Usage is priced in LMDA — that's what makes the supply sink real — but nothing forces you to hold it. Every payment settles instantly in whichever currency you choose; what differs is the route the money takes afterwards.

You payWhere it goesFeeds the sink?
Subscription · USDCStraight to reserves — funds development and the runway.no — by design
Subscription · LMDAThrough the splitter — burn / lock, identical to usage.always
Usage · LMDAThrough the splitter.always — ≥25% burns
Usage · USDCAccess is instant; the USDC joins reserves and funds the runway. It is never converted into LMDA.no — it funds the platform instead

No swapping, ever: what you pay is what the platform keeps. USDC arrives and stays USDC, strengthening the reserves; LMDA arrives and is burned or locked — and after vesting it can only ever sit in a balanced, fully visible liquidity book. Both currencies are quoted at the same live rate — no bonus, no penalty, no preferred option; LMDA's role comes from what it does inside the platform, not from steering at the checkout. And the protocol never takes liquidity: no market orders, in either direction.

04 / THE CONTROLLER

Three regimes, published as a mode — not a dial

Define R = current USDC runway ÷ a 24-month target (both internal numbers). R selects one of three regimes, each with a fixed split. A regime changes only when R crosses a boundary and stays there for two consecutive monthly checks — so changes are rare, deliberate, and never a drip-feed of the balance sheet.

25% 50% 75% PROTECT · 25% burn REBUILD · 50% FLUSH · 75% 0 0.75 1.25 1.6 R = USDC runway ÷ 24-month target · boundaries hold 2 months before a regime flips share of each LMDA spend lock share burn share 50 / 50 floor: never below 25%
The floor is the credibility guarantee: whatever the reserves look like, at least a quarter of every spend burns, so "a portion of every spend is retired from supply" stays unconditionally true. The steps are the privacy guarantee: a continuous dial would broadcast the reserves' month-to-month trajectory; three fixed regimes disclose only which mode the platform is in. Hysteresis at the boundaries keeps the regime from flickering.
Worked examples — a 100 LMDA spend under three reserve states
R = 0.4 · protectrunway under half of target
25 burned
75 locked → vest → passive asks
R = 0.85 · rebuildbetween the boundaries
50 burned
50 locked
R = 1.3 · flushabove target + buffer
75 burned
25 locked
05 / THE LIQUIDITY BOOK

Balanced liquidity — for every ask, a bid

A ring-fenced allocation — vested LMDA on one side, allocated USDC on the other — quotes both sides of an on-chain order book, and the system strives to keep the resting quotes 1 : 1: for every ask clip, a matching bid clip, small and equal, laddered outward at fully visible price levels. The job is to thicken liquidity so anyone can trade LMDA with less slippage — and when the market lifts a resting ask, that is a passive sale at a visible level anyone could also have posted: USDC beyond what the book needs sweeps to the reserves on a published rule. One thing the book never does is chase: bids rest where they were placed and are not repriced upward — bid liquidity at higher levels only appears as new subscription USDC is allocated. What fills is the market's choice. Never a market order, never taking liquidity — the market comes to us.

price mid · TWAP sanity check +5% +10% +15% asks · vested LMDA −5% −10% −15% bids · new subscription USDC target 1 : 1 for every ask, a matching bid Liquidity allocation ring-fenced · LMDA + USDC ✗ never a market order never takes liquidity · never leans a side bid side stays funded · excess USDC from ask fills sweeps to reserves
Balanced by aim, decided by the market: the system strives to keep resting quotes 1:1 — equal clips both sides, verifiable on-chain order by order. Which side fills is the market's choice: an ask fill is a passive sale whose excess USDC sweeps to reserves; a bid fill restocks the LMDA side. Bids never chase the market upward — higher bid levels appear only as new subscription USDC is allocated. Every clip sits at terms any holder could also post, resting post-only on an on-chain Solana order book — never a market order in either direction.
06 / THE KNOBS

Recommended parameters

Proposed starting values — the architecture holds if the numbers move. The runway target is the most consequential knob: it encodes how conservative the platform chooses to be. If you'd tune one of these, that's exactly the feedback we're asking for.

KnobRecommendedWhy
Burn floor25%Keeps "supply only shrinks with usage" unconditionally true — the credibility anchor.
Burn ceiling75%Even flush, retain a quarter — reserve optionality is cheap when you don't need it and priceless when you do.
Regimesprotect 25 · rebuild 50 · flush 75% burnThree fixed splits instead of a dial — the published number is a mode, not a reading of the balance sheet.
BoundariesR 0.75 / 1.25 · must hold 2 monthsHysteresis makes regime changes rare and deliberate — no flickering around a target, no monthly drip of information.
Runway target24 months of opexLong enough to survive a full bear market without touching anything token-related.
Cadencemonthly check · publish on changeThe regime is re-evaluated every month and republished only when it actually flips.
Vest12 months · linearLocked really means locked — long enough that retention can't be mistaken for a quick-sale queue.
Balance rule1 : 1 bid : ask · targetThe system strives to match every ask with a bid — liquidity provision, not disposal, not buyback. The resting balance is verifiable on-chain.
Book fundingring-fenced · vested LMDA + new subscription USDCAsks from vested LMDA; bids from newly allocated subscription USDC — old bids are never repriced upward to chase the market. Excess USDC from ask fills sweeps to reserves on the published rule.
Quote shapesmall equal clips · ±5% and out, both sidesDepth spreads across levels on both sides — the aim is no wall at best bid or best ask.
Book size≤5% of avg daily volume per sideThe book is thicker for everyone without protocol orders ever dominating it.
Order typepost-only · on-chain Solana order bookThe venue itself rejects any order that would take liquidity — the guarantee is structural, not procedural.
Payment ratemedian short-window TWAP · bounded driftLMDA- and USDC-quoted prices agree with the live market and can't be nudged by a brief spike in a thin book.
Burn timingat consumptionBurns fire when usage happens, never on top-up — refundable balances are never part-burned.
Input disciplinetrailing 12-mo opex · changes pre-announcedR's inputs can't be quietly steered: opex enters as a trailing average, and any change to the rule's definition applies one epoch after it's announced.
07 / THE HONEST CAVEAT

The split protects the reserves — subscriptions fund them

Worth being clear-eyed about, because it's where a mechanism like this could quietly over-promise: ask fills in the liquidity book only happen when the market chooses to lift a resting offer — real USDC when it comes, but never counted on. What dependably funds the platform is simpler:

Together: subscriptions fill the tank, the regime keeps the tank from being drained into the burn address during a drawdown, and the liquidity book keeps the market tradable — converting reserve LMDA to USDC only when the market lifts a resting offer. One metric, one forbidden move (taking liquidity) — and no promises where the market decides.

08 / TRANSPARENCY

What you'll see — and what stays private

The commitment, in plain words — headed for the strategy doc

"A portion of every LMDA spend is burned — never less than a quarter of it, permanently retired from supply. The remainder is time-locked and vests into a protocol-owned reserve over twelve months, where it can only ever rest as passive liquidity — visible bids and asks on a public order book, on the same terms available to any holder, never a market order. The balance between burn and lock follows a published rule with three fixed regimes tied to the health of the platform's reserves, and the current regime is always visible in-app."

09 / CAN IT BE GAMED?

A public rule on a public chain — so we went looking for the exploit

Everything here runs against a published rule, with the LMDA side verifiable on-chain. The right question is whether that openness hands anyone an edge. Short answer: the caps and the passivity do the protecting — knowing the rule tells you nothing the order book wasn't already showing. The honest answer also names the places where the engineering has to be deliberate; those carry their own rows in the knobs table above.

AttemptWhy it doesn't pay
Snipe the book's clipsEvery order is public the moment it rests — the published rule reveals nothing the book doesn't. Small equal clips on both sides leave nothing worth trading against.
Push the price to milk one sideThe book targets 1:1 and is capped per side — leaning on it fills a few small clips, bids never reprice upward to be milked on the way back, and the TWAP sanity check stops a manipulated print from re-anchoring the asks. The cost of moving the market exceeds anything the capped clips return.
Wash-usage to force burnsSpending LMDA on usage means paying full price for real product. The burn's benefit spreads across every holder pro-rata while the spender funds all of it. Self-defeating.
Time payments around the splitThe split changes where the protocol routes tokens, never what a user pays. There is nothing on the paying side to time.
Cycle credits back to cashCredits are non-transferable, non-refundable product value. There is no path from credits back to cash.
Pay-and-refund loopsBurns execute at consumption, not at top-up — a refundable balance is never part-burned.
Currency-choice arbitrageUsage is quoted at a median-filtered short-window rate with bounded daily drift, so the LMDA and USDC prices always agree with the live market and a brief spike in a thin book moves nothing. A stale or naive in-app rate would be exploitable — which is why the rate is a named knob, not an afterthought.
Trade the regime changeThree fixed splits, boundaries with two-month hysteresis, published on a fixed schedule. There is no continuous signal to trade — and R itself is private.

One guarantee is structural rather than procedural: every protocol order rests post-only on an on-chain Solana order book — an order type the venue itself refuses to execute against resting liquidity. "Never takes liquidity" is enforced by the exchange, not by trust. And everything else is verifiable the same way: the burn address, the lock program, and the 1:1 balance of the liquidity book are all public, order by order, any time.

10 / REJECTED

Designs considered and dropped

Fixed 50/50

Simple, but blind: it destroys value at the same rate whether the reserves are flush or thin — and durability through full cycles was the point.

100% burn

The loudest sink and the most fragile platform: the runway becomes hostage to subscriptions alone, with no compliant fallback at all.

Discretionary monthly call

"We decide each month" invites the suspicion it deserves. A published rule removes the discretion argument before it starts.

Selling at market when needed

Directly violates the public commitment and the compliance posture. Never on the table — listed so it's on record as considered and ruled out.

Auto-swapping USDC payments into LMDA

Converting incoming payments at the checkout — even passively — would make the protocol a counterparty to every payment and the sink compulsory. Dropped: what arrives as USDC stays USDC.

A one-sided ask ladder

An earlier draft of this very page. Asks without matching bids read as disposal rather than liquidity, however passive. Replaced by the balanced book — same passive sales when the market lifts an offer, but the system strives to quote both sides.