Health check
We have been quiet, on purpose.
For the past few months, we have been heads down building towards something bigger, and we are excited to reveal where we have landed.
Credit has always carried the same promise: the freedom to act before the money catches up, to do more than your current balance allows, to move on your own terms. It is the thing that gives people and businesses real agency in the financial system, and yet the infrastructure behind it has barely changed in 30 years. Terms are rigid because the technology is rigid, rates are expensive because the plumbing is expensive. The promise was real, but the engine behind it was not.
We have already seen what happens when you rebuild financial architecture from scratch. Stablecoins did it for payments, and overnight they became programmable, global, and structurally cheaper. That same transformation is now possible for credit, and almost nobody is building it.
Sprinter has been focussed on credit for a while, but we started by solving a different problem. We set out to make crosschain transactions seamless, built solver infrastructure, and it worked. The next step was to take it beyond the solver use-case, and the deeper we went into how people and applications actually move value, the more we kept running into the same gap. Every path eventually led back to credit: the missing layer, the primitive that nobody had built yet, and the one that would unlock the most value if someone did.
And so we got to work.
Today we are showing you the first piece of this makeover. A new Sprinter, enhanced from the ground up with new infrastructure, a new identity, and a new level of ambition. All driven by a single conviction.
Credit runs on Sprinter.
This is not just a cosmetic rebrand, it reflects a fundamental shift in what Sprinter is and where we are going.
We are a credit engine. Any application, whether they are building for consumers, businesses, or autonomous agents, can plug in via a single API and offer credit that actually works. That means flexible terms instead of one-size-fits-all, adaptive risk management instead of static rules, and economics that benefit the borrower because the collateral backing every credit line is productive, generating yield that makes credit cheaper by design.
The complexity stays under the hood, and the end user just gets better credit.
The new brand is just the beginning. Over the coming weeks, we will be sharing what we have been building behind the scenes, including a major upgrade to our core infrastructure and something entirely new for consumers.
We are not ready to say more just yet. But if you believe credit is the next great layer of finance to be rebuilt, and that the team that builds the engine will define how it works, then you will want to pay attention to what comes next.
Explore the new Sprinter, and stay tuned for what’s next.
Stay updated on all things Sprinter, and onchain credit, by following us on X, joining our Telegram, and reading more on our blog.
Part I asked what are we pricing when we quote a rate and answered with expected loss, capital, and margin. Part II focused on mechanism and guarantees. The final part of this series focuses on programmable, usage-constrained credit.
The moment you treat guarantees as code, you can underwrite routes and states rather than people. This part develops a concrete architecture for usage‑constrained credit in cross‑chain intent fulfillment, then generalizes it to other closed‑loop loans.
A solver receives a revolving credit line that can only be spent on executing a specific intent. Funds never touch the solver’s externally controlled wallet. At the destination chain, proceeds are swept into a repayment sink that pays the lender first. Only the surplus, if any, can leave the system. Misuse is structurally impossible; underwriting focuses on route risk.
Route risk in PD/LGD/EAD terms
An intent is posted and claimed (see Fig. 2). The solver locks a bond. The credit vault authorizes the source‑chain router to fund the route, tagging the bridge transfer so it can only land in the destination‑side sink. The destination router can call only whitelisted venues. When the trade completes, the sink retains principal, accrued interest, and protocol fees, and emits an attestation back to the source. Upon confirmation, accounting rolls forward and any surplus is released to the solver or shared with the user. If anything fails, timeouts and partial‑repayment rules determine how bonds are seized and how insurance funds step in.
No user pre‑funds the destination; the protocol fronts capital. The rate charged is the price of route risk: bridge failure, stale oracles, thin books, message delays. Loss given default is bounded by the repayment sink, by the solver’s bond, and by an insurance pool. Exposure at default is the funded notional during execution. Tightening allowlists, reducing timeouts, and sizing bonds cheapen the rate by cutting expected loss.
Once you have repayment sinks and allowlisted routers, many “closed‑loop” credits fall out: merchant payouts where settlement currency must be converted along the way; RWA vaults where incoming cash flows must amortize a facility before any dividends are paid; programmatic capex loans that can buy only specific on‑chain inventory. The technology is the same; only the whitelists and oracles change.
Code cannot erase risk; it only reshapes it. Priority becomes a matter of contract logic rather than contract law. Solvency depends on buffers that reflect finality lags and market depth at the destination. Reversibility is limited to what the mechanism allows; once a sink pays out, the system needs a credible path to recover mis‑routed funds. These constraints are not bugs—they are the design surface.
We started with rates as prices of risk, moved through mechanisms for moving value while we wait, and ended with guarantees that can be expressed as law or as code. The practical takeaway is simple: separate pricing from plumbing. Price the thing you actually risk (people, positions, routes); then pick the lightest mechanism that keeps obligations safe—ideally one that nets and batches until the boundary, backed by guarantees you can verify. As more cashflows originate on programmable rails, expect guarantees to migrate from paper to code and for non‑deliverables, repayment sinks, and risk engines to become standard parts of product design.
If you’re building cross-chain intents, routing, or solver infra and want route-first credit with real LP yield, reach out—we’re onboarding early partners.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
You tap for a coffee. Somewhere, a card network authorizes a payment, your bank promises to fund it later, and the café gets a message it can trust today. No coins move between you two in that moment; accounting does. That night, a batch closes and money finally travels. A few hours later, an on‑chain trader opens a perpetual futures position with 10× leverage. Again, no assets move between counterparties with every price tick; the system keeps score until a boundary is reached. Same story, different rails. The invisible thread is credit—sometimes explicit, sometimes implicit, sometimes just the promise that when needed, there is cash in the room. This series is about that thread: how we price it, how we secure it, and how code is changing what “settlement” even means.
TL;DR A loan’s rate is not a generic “fee for borrowing.” It is the cash price of uncertainty. Under the hood it combines the time value of money, the lender’s own cost of running the product, the expected loss from borrowers who won’t pay, a return on capital set aside for bad times, and a margin for competition and model error. Change the risk, change the price.
We can say this without jargon. In plain terms: the rate has five components. The first is the risk‑free baseline—what money earns with almost no risk over the same period. The second is funding and operations—the cost of deposits or wholesale funding, the salaries, the software, the compliance. The third is the expected loss from defaults in an average year. Risk teams compute this as EL = PD × LGD × EAD, where PD is the probability of default, LGD is the loss given default after recoveries/collateral, and EAD is the exposure at default. The fourth component is a capital charge—the return required on capital held for recessions and accidents. The fifth is margin.
A small example makes it concrete. Take a €10,000, one‑year loan. Suppose the risk‑free rate for the duration is 3% and running the product costs another 1%. If the risk team believes two out of a hundred similar borrowers will default (PD = 2%) and that, after selling collateral and collecting what can be collected, the average loss is forty cents on the euro (LGD = 40%), then across the whole book the expected loss is 0.02 × 0.40 × €10,000 = €80, or 0.8% of principal over the year. Add a modest 0.5% for capital and 0.7% for margin and you land near 6.0%. Now change only one fact: the borrower pledges a car you can seize and sell, so LGD falls to 10%. Expected loss drops to 0.2% and the fair rate glides toward 5.4%. Capital charge covers unexpected loss (tails), not the average loss already priced in EL.
In practice, each ingredient moves for different reasons. PD falls when underwriting improves—verifiable income, lower debt‑to‑income, cleaner payment history. In on‑chain systems, PD rhymes with the reliability of liquidation: good oracles, healthy order books, a live chain. LGD shrinks with real control over cash flows—first‑priority liens and guarantees in TradFi, over‑collateralization and repayment sinks that get paid before anyone else in DeFi. EAD is structural: amortizing loans dwindle over time; revolving lines can peak late; leveraged positions on‑chain have a special kind of exposure—the notional at risk during the seconds it takes to liquidate. A useful rule of thumb in volatile markets is latency VaR: expected price move × exposure × liquidation delay. Maintenance margins should be set so that, even across that delay, losses are still covered—or an insurance fund must catch what spills over.
Two loans with the same expected loss can still deserve different prices because of tails. Expected loss is the average. Lenders also hold capital for the unexpected: clustered defaults in a downturn, a frozen bridge, an oracle that goes out of tolerance. That capital expects a return. Futures markets make this explicit with initial and variation margin plus a default fund; consumer lenders do it implicitly by targeting a return on economic capital. If one pool has fat‑tailed outcomes and another doesn’t, the one with fatter tails will carry a higher capital coat of paint even if the expected‑loss coat is the same thickness.
This is where TradFi and DeFi feel different while solving the same equation. TradFi mostly prices people and paper: PD is about willingness and ability to pay; LGD is about legal priority and recoveries; EAD follows the contract schedule. DeFi mostly prices collateral and code: PD is about whether the liquidation machine keeps up; LGD is the shortfall after selling collateral (plus any insurance); EAD is the notional during liquidation or bridging. Both are trying to make expected loss small and capital affordable, just with different levers.
If you carry one idea forward from Part I, carry this: the rate is a story about risk that can be measured and moved. Lower PD by knowing your counterparty or by making misuse structurally impossible. Lower LGD by taking collateral you can truly control or by routing repayments to yourself first. Shape EAD by choosing structures that shrink exposure when it matters. The math is compact; the art is in the design.
Before we compare products, it helps to lock down the language. Settlement has two layers that sit at right angles. The first is the mechanism—how and when transfers are finalized. The second is the guarantee—the promises or safeguards that make that timing safe. “Guaranteed solvency” belongs to the second layer; it isn’t a timing rule, it’s the property that lets slower or more flexible timing work without creating unpayable obligations.
On mechanisms: at one end is instant or atomic settlement. Value and title change hands together, and if either leg fails, nothing happens. This is delivery‑versus‑payment and real‑time gross settlement: a clean swap with no exposure carried across time. A step away from that is escrow‑mediated settlement. Funds or assets lock immediately but do not release until a condition is proven—delivery confirmed, a dispute window expires, an oracle attests to a state. No one extends credit in the meantime; risk is parked in escrow rather than on a counterparty’s balance sheet.
Most day‑to‑day finance relies on deferred net settlement (DNS). Obligations are fixed now, but cash moves on a schedule—end‑of‑day batches, T+2 cycles, month‑end nets. Because many cash flows point both ways, the system nets them down to smaller transfers. Sometimes a third party layers credit on top—card issuers and BNPL firms pay the merchant today and collect from the buyer later—but the settlement layer itself is just batching and netting.
Then there is event‑driven or boundary settlement. Instead of moving cash at every interim event, the system keeps score internally and only moves real money at boundaries such as closing a position or withdrawing funds, or when risk limits are hit and liquidation is required. Timing becomes stochastic—the market decides when boundaries are reached—but the rules are deterministic: margins, oracles, liquidation incentives, and priority of payouts define what happens when a boundary is crossed. Finally, in markets that concentrate many bilateral trades, novated CCP settlement inserts a central counterparty between everyone else—becoming buyer to every seller and seller to every buyer—and runs multilateral netting with initial/variation margin, default funds, and auctions.
There is a cousin to these mechanisms that shows up everywhere: non‑deliverable agreements. Some contracts never require transfer of the underlying asset at all; they settle purely in cash off a reference price or index. A non‑deliverable forward on USD/KRW pays the difference in dollars at maturity; cash‑settled options and many index futures do the same. On‑chain, most perpetuals are by design non‑deliverable—the reference is a price index, and the settlement asset is a stablecoin. Non‑deliverables simplify custody but make pricing integrity the critical dependency: if the reference price is wrong, so is the payout. Oracles, dispute windows, and robust indices therefore sit squarely in the guarantee layer.
Now to guarantees—the layer that makes those mechanisms safe. Finality means that once a transfer is marked complete, it cannot be unwound except by a fresh transaction or a court order. Reversibility is the mirror image for conditional flows: when conditions are not met, value reliably returns to its origin (escrow release, chargebacks, dispute rules). Priority fixes who gets paid first; it is a legal assignment in paper systems or a programmed repayment sink on‑chain. And guaranteed solvency is the core invariant behind boundary models: at any boundary event, the system can meet its obligations from posted buffers, liquidation proceeds, and insurance, with any remaining shortfall pre‑allocated to a funded waterfall rather than pushed onto outsiders.
Sprinter Stash in this taxonomy: a non-deliverable, event-driven credit rail for cross-chain solvers, secured by guaranteed priority (repayment sink pays lender first) and guaranteed solvency (margin/limits/insurance). It converts LP stablecoin capital into on-demand credit that powers solver routes across chains, with LPs earning real yield from solver fees and safe passive sources.
With actors, the picture simplifies. We refer to the payer, who owes value, and the payee, who receives it. Depending on the mechanism, other roles attach: a lender/credit provider who advances funds so the payee needn’t wait; a risk engine that measures exposure and enforces margins and liquidations (a smart contract in DeFi, a CCP in TradFi); an escrow or oracle that locks value and proves conditions; a guarantor or insurance fund that absorbs tail events; and a venue, custodian, or settlement agent that executes or records transfers. Different combinations of these roles give each mechanism its distinctive risk shape.
A few practical questions help you choose. If a failed leg right now would cause irreparable harm and there is no credible recourse, you want instant exchange. If you can lock value and wait for proof, escrow buys safety without credit. If your flows are naturally batched and netted by the calendar, deferred settlement is efficient as long as priority is clear and the paying side can remain solvent until the window closes—either by its own strength or with a lender standing in. If exposures evolve with every price tick and moving cash that often is impractical, boundary settlement is appropriate, but only when solvency is guaranteed ahead of time and the order of payments at the boundary is indisputable. In markets where many parties face each other simultaneously, a CCP adds the discipline and efficiency of multilateral netting with a single, well‑capitalized risk manager.
In conclusion, the answer to the initial question, what we are pricing when we quote a rate, is expected loss, capital, and margin. Join us soon for Part II, which will ask a different question: while we wait for payment, how do we move value safely?
Make sure to stay tuned 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.