Part II - Instant vs. Guaranteed Settlement, Perps, Factoring, and Usage‑Constrained Credit
TL;DR
Some agreements truly need cash now (an instant/atomic mechanism). Many others only need guarantees layered on top of slower mechanisms: priority of payment, reversibility if conditions fail, and guaranteed solvency so boundary settlement is safe. Perpetuals are boundary settlement with guaranteed solvency; factoring is DNS with priority and bounded solvency via legal rights. Non‑deliverables show that sometimes there is no asset to deliver at all—only a cash difference to compute correctly.
How Part II differs from Part I
Part I asked what are we pricing when we quote a rate?—and answered with expected loss, capital, and margin. Part II asks a different question: while we wait for payment, how do we move value safely? The focus here is mechanism and guarantees, not rate math.
1) From pricing to plumbing: two settlement modes (through the mechanisms/guarantees lens)
The distinction becomes clearer once you separate when we move money from what makes that timing safe. Instant settlement is the clean room: nothing carries across time. Everything else requires some mix of reversibility, priority, or solvency so that waiting doesn’t become reckless. In the following pages we look at two emblematic cases—perpetual futures and invoice factoring—and a third that hides in plain sight: non‑deliverables.
2) Perpetuals: boundary settlement that requires guaranteed solvency
Perpetual futures DEXs are the cleanest on‑chain example of boundary settlement. Traders deposit margin before they do anything else. From that moment onward the system tracks profit and loss virtually. No one wires coins to winners on every price tick; the engine simply updates claims and keeps an eye on each account’s equity. When equity approaches zero, liquidation fires. Collateral is sold, the position is closed, and the proceeds repay losses. An insurance fund stands behind the residual risk if markets gap too quickly. Real money moves only at the boundary—when a trader deposits, withdraws, or closes.
Seen through our taxonomy, perps use the boundary mechanism, made safe by the guaranteed‑solvency invariant. In practice that means three things. First, collateral is sized so that the expected loss over liquidation latency is small. Second, liquidation rules are designed to realize collateral quickly, with incentives for keepers to act even in stress. Third, if prevention fails, a pre‑funded waterfall absorbs what remains. Priority is encoded too: on liquidation and withdrawal the order of payouts is unambiguous, so no one has to litigate after the fact.
A short example makes this less abstract. Imagine a trader opens a €100,000 notional long with 10× leverage on an asset whose price can move five percent in a minute during stress. If it takes thirty seconds to liquidate and the book is thin, the risk engine must assume that prices can move two to three percent before the position is flat. Maintenance margin is therefore set high enough that, after a three percent adverse move plus trading frictions, the collateral still covers the loss. If it does not, the insurance fund steps in, and the protocol later recoups the shortfall from fees. In that story the “probability of default” is the probability that liquidation fails to keep up; the “loss given default” is the share of loss that the margin and insurance do not cover; the “exposure at default” is the position’s size at the moment liquidation starts.
3) Factoring: DNS with priority and bounded solvency
Factoring is a good foil because it lives on paper and in courtrooms rather than in smart contracts, yet the logic is the same. A business sells an invoice to a factor at a discount. The obligation is fixed on day one, but cash moves later, usually on the invoice due date or in a batch. Between those two moments the factor’s safety comes from guarantees, not timing. Priority is established by legal assignment and, often, by notifying the buyer to pay the factor directly. Bounded solvency is created by with‑recourse terms, by trade credit insurance, and by concentration limits that prevent one obligor from dominating the pool.
Here too, numbers help. Suppose a €100,000 invoice payable in sixty days is sold without recourse. The risk‑free rate for two months is roughly 0.3% annualized. Verification, KYC, and servicing amount to another 0.2%. The buyer’s one‑year probability of default is estimated at 2%; scaled to sixty days that is about 0.33%. If recovery on default would be fifty cents on the euro after costs and delays, LGD is 50%. Expected loss over sixty days is therefore 0.33% × 50% × €100,000 ≈ €165 (0.165%). Add a small capital charge for tail risk—say 0.20% over the period—and a margin of 0.25%, and the total discount for sixty days lands around 0.915%, or €915. With a with‑recourse structure, effective LGD might fall to 10% because the seller must replace bad paper. The expected loss then drops to about €33, and the all‑in discount shrinks accordingly. (Side note: factors also model dilution risk—returns, credits, disputes—which reduces collectible cash even without default.) The math is simple; what matters is that the price is dominated by the buyer’s risk, not the seller’s identity.
4) Non‑deliverables: when settlement is only a number
Many markets never exchange the underlying thing. They compute a cash difference against a reference and pay it in a separate currency. In FX, an NDF on USD/KRW settles in dollars using a published KRW fixing. In commodities and equity indices, cash‑settled futures do the same. In crypto, most perpetuals are already non‑deliverable by design: the payoff depends on a price index, and settlement occurs in a stablecoin or common collateral.
Non‑deliverables sit comfortably inside both DNS and boundary mechanisms, but they elevate a different risk to the top: reference price integrity. If the fixing is manipulated or the oracle lags, a trade that looked fair on paper turns into a transfer of value. Guaranteeing non‑deliverables therefore means hardening indices (robust venues, time‑weighted windows, outlier filters), adding dispute or pause windows when feeds diverge, and making payout priority explicit so the right party is made whole first. The absence of custody risk is a gift; the price however is higher data quality requirements.
5) Usage‑constrained credit: programmable guarantees
Programmable rails let us bring the guarantees into code. Instead of wiring proceeds to a borrower’s free‑and‑clear wallet, funds land in contracts that can only do whitelisted things. Proceeds route to the lender’s sink first and only then do they flow outward. A borrower never has general‑purpose custody until the system is made whole. This is the same stack of guarantees—priority, solvency, sometimes reversibility—implemented as rules rather than paperwork.
One natural application, which we will develop in Part III, is cross‑chain solver credit (see Fig. 1). A lender fronts capital on one chain so a solver can fulfill an intent on another. The bridge tags the transfer to a repayment sink at the destination. The solver can interact only with approved venues, and the sink sweeps principal and interest before anyone else is paid. The mechanism across domains may be deferred or boundary; what makes it safe are the same guarantees adapted to a world with probabilistic finality and message latency.
Case study: Usage-constrained credit — Sprinter Stash
Sprinter Stash connects stablecoin LPs with cross-chain solvers who need instant, zero-collateral credit to execute intents. Credit never lands in a general-purpose wallet (see Fig. 1); it’s spent by allowlisted routers, and repayment is swept to the sink first, before any surplus flows out—so misuse isn’t possible by design. For LPs, returns come from solver service fees plus conservative passive yield sources; the protocol treats safety (MPC, audits) and ongoing risk monitoring as first-class concerns. Operationally, Stash hubs on Base with satellite pools and automated rebalancing across chains and venues, so solvers don’t pre-fund inventory or juggle bridges. In taxonomy terms: non-deliverable, boundary settlement for P&L; DNS-like scheduling for fees; guaranteed priority and guaranteed solvency enforced in code.
Putting it together
Once you split mechanisms from guarantees, design choices become easier to justify. Atomic settlement needs little more than finality. Escrow needs reversibility and, on release, priority. Deferred settlement needs priority and a lender or a solvent payer to span the window. Boundary settlement needs guaranteed solvency, because it trades frequent small transfers for occasional large ones at exits and triggers. CCPs are boundary systems with a professional risk manager in the middle. Non‑deliverables remove custody but demand pricing integrity. The rest is tuning: which risks dominate expected loss here—failure to liquidate, obligor default, oracle error, bridge latency, index manipulation—and which guarantee is cheapest to strengthen.
Stay tuned for Part III of the series "Beyond Loans - Credit as Price, Collateral and Code" and as always, stay updated on all things Sprinter, and onchain credit, by following us on X, joining our Telegram, and reading more on our blog.
Join us to shape the future of onchain credit.
