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.

The problem we kept finding

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.

How we got here

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.

Introducing the new Sprinter

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.

What’s next

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.

sprinter.tech.

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.

1) The promise

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.

2) The flow in words

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.

3) Why this is credit

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.

4) From solvers to other uses

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.

5) Risks and their honest names

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.

Conclusion — Why this matters (and what to build next)

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.

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.

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.

Part I — Pricing Credit: From Rates to Risk

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.

Interlude — Settlement Taxonomy, Non‑deliverables, and Actor Map

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.

Sprinter Stash’s app will officially go live tomorrow at 12pm CET, unlocking a new way for DeFi participants to earn rewards by contributing USDC liquidity to Sprinter Stash.

But this isn’t just about staking and waiting. It’s a chance to be part of the next wave of crosschain liquidity infrastructure — and earn real rewards for doing so. For those who jump in early, the benefits get even better.

How it works

Sprinter Stash is a dynamic liquidity layer designed to power crosschain execution within the Sprinter protocol. Liquidity providers deposit USDC into the protocol through an intuitive interface, selecting the chain they want to deposit from and locking their funds for a chosen duration.

Once deposited, Stash takes over, algorithmically distributing and rebalancing liquidity across supported chains based on live solver demand. This allows solvers to borrow credit on destination chains without collateral, enabling instant, capital-efficient execution across the ecosystem.

When a transaction is filled, the borrowed funds are repaid on the source chain. From there, profits flow back to LPs, who earn from a combination of solver fees, passive yield, and Stash points.

It’s liquidity that works harder — and smarter.

Introducing Stash Points & The Sprinter Olympics 🏅

When Stash goes live tomorrow, the race to rewards begins! We will be kicking off a series of events as part of the Sprinter Olympics, where you can earn Stash Points, a new rewards system that tracks your contributions across the Sprinter ecosystem.

The first event will be The 100M Stash, where you can earn Stash Points by depositing USDC into Sprinter Stash and locking your liquidity for a chosen duration. Stash points will be distributed 1:1, for every $1 staked, you receive 1 Stash point.

More ways to earn will be revealed in the coming weeks, in addition to the leaderboard going live soon - so keep stacking points and we’ll see who’s leading the race.

Early LPs get a head start 🏃‍♂️

Sprinter Stash rewards liquidity providers with points, and yield that scales based on how long you lock your funds. The longer you commit, the higher your multiplier, starting at 0.4x for a 3-month lock, up to a generous 2.2x for a 12-month commitment.

And for early adopters, there’s an additional reason to act fast: deposits made within the first 48 hours of each milestone unlock a 100% SPRNT bonus on your USDC deposit, on top of your regular rewards. No extra steps required — just show up early, and your bonus will be automatically applied.

To kick things off, we’re rewarding our earliest Stashers with both base multipliers and bonus points.

Base Multipliers

Lock your liquidity and earn more Stash points based on your commitment:

• 3-Month Lock → 0.4x Stash points
• 6-Month Lock → 1.0x Stash points
• 12-Month Lock → 2.2x Stash points

Bonus rewards (First 48 Hours)

Deposit USDC in the first 48 hours of each milestone and you’ll receive a 100% bonus on your USDC deposit, in Stash points — no extra steps needed.

How to Stash

Sprinter Stash gives LPs access to dynamic, multichain rewards - powered by solver activity and protocol incentives.

Here’s how it flows:

1. Visit https://app.sprinter.tech/stash
2. Connect your wallet & select a chain. Deposit USDC directly into Sprinter Stash.
3. Choose your Stash lockup. You can lock your Stash for 3 months, 6 or 12. (Or you can chose not to lock and just earn the APY).
4. Stash allocates liquidity across chains. Liquidity is algorithmically rebalanced to meet solver demand in real time.
5. Solvers use credit instantly. Solvers borrow on destination chains without collateral to execute trades and arbitrage opportunities cross-chain.
6. Settlement & rewards. Once filled, funds are repaid on the source chain. Profits flow back to LPs as APY, solver and strategy fees.

You earn from:

• Solver fees
• Strategy fees
• Multi-dimentional Passive yield
• Sprinter incentives & Stash Points

The Final Countdown

Sprinter Stash goes live at 12pm CET, tomorrow Thursday 13th November. The early bird count down starts then. Staking early means maximizing your rewards, both with boosted multipliers and exclusive bonus rewards for early birds.

Connect your wallet. Multiply your rewards. Power the future of crosschain DeFi.

The Sprint has officially begun 🏁

Join the Sprint and follow us on X, joining our Telegram, and reading more on our website.

Going live later this week, Sprinter Stash welcomes a new era of credit and sustainable yield for decentralized finance.

The next frontier in crypto is credit. While stablecoins, tokenization and DeFi brought trillions of USD in assets on chain, market efficiency and UX still lack behind.

Sprinter Stash is a new onchain credit protocol that powers the next-generation of use cases, from solver credit lines to trading, whilst rewarding LPs with sustainable, risk-managed stablecoin yield. Stash provides zero-collateral credit, so solvers don’t need capital, users don’t need to touch bridges, and dApps get instant fills.

Our first supported venues: Intent protocols and wallets. But this is just the beginning.

The Challenges: Centralization and Barriers to Entry

As DeFi has evolved toward intent-based architecture and crosschain composability, a new class of infrastructure actors, solvers, has emerged. Solvers translate user intent into action, often across multiple chains and assets. But their growth is being stifled by one persistent bottleneck: capital.

While protocols may be decentralized in architecture, the execution layer remains heavily centralized, controlled by a small number of entities that have the liquidity, operational scale, and risk infrastructure to operate effectively.

The Result?

• Limited competition and centralization risk in solver-based ecosystems
• High barriers to entry for new builders and crosschain DeFi applications
• Liquidity fragmentation across chains and protocols, reducing overall efficiency.

At the core of the problem lies the cost, access, and management of the required capital crosschain. Solvers must not only source capital across multiple chains, but also manage inventory risk, price volatility, and bridge friction—all before earning any return.

More specifically:

• Access & Cost of Capital: Participants need cost-efficient access to liquidity across chains in order to compete on execution. For most, this capital must be pre-funded, siloed, or actively bridged—making operations complex and expensive.
• Inventory Risk & Fragmentation: Managing funds across chains introduces exposure to volatile assets, impermanent loss, and idle capital. Without sophisticated infrastructure, this risk often outweighs potential returns.

While leading market makers have already built the required crosschain infrastructure, the majority of the market still lacks access to these capabilities.

Unlocking shared, risk-managed liquidity will not only broaden participation but also increase resilience, decentralization, and innovation across the DeFi stack.

What is Sprinter Stash?

Sprinter Stash is a credit-based liquidity protocol that connects stablecoin LPs with crosschain actors like solvers and strategists and bridges the gap between passive capital and high-frequency, crosschain demand.

• For Liquidity Providers: Sprinter Stash offers risk-managed stablecoin yield from real protocol usage and solver borrowing
• For DeFi (Solvers and soon others): Stash provides cheap and managed crosschain liquidity via zero-collateral credit, abstracting away the need for pre-funded, siloed liquidity

By bridging the gap between capital and execution, Sprinter Stash enhances liquidity efficiency, reduces fragmentation, and accelerates DeFi adoption. Stash’s native chain will be BASE, with satellite pools on every other chain.

Why Sprinter Stash?

For Liquidity Providers

Sprinter Stash is for liquidity providers looking for an attractive yield opportunity based on a new DeFi primitive:

• High Yield & Low Risk: Sprinter Stash utilizes multiple yield sources to maximize capital efficiency and returns: LPs earn from service fees paid by solvers to access credit as well as proven passive yield sources (such as lending protocols) ensuring low risk. Stashing (staking) earns additional rewards.
• Secure & Credible: MPC-secured multi-party threshold signing, risk mitigation mechanisms, and smart contract audits by Veridise and Spearbit/Cantina make Sprinter Stash a secure platform. Built in partnership with ChainSafe, a team with 7+ years of industry expertise across core protocol development, standardization/ EIPs and security audits /council work.

For Crosschain DeFi

Sprinter Stash enables capital-efficient crosschain execution by removing the need for pre-funded liquidity pools or collateralized loans. Liquidity is automatically managed across chains via a variety of rebalancing and netting protocols. At launch, Stash initially supports solvers filling orders in:

• Across
• LiFi Intents
• Mayan Finance
• Rhinestone

Solvers can use Stash credit lines to borrow and fill — creating faster, more competitive intent execution. Sprinter Stash credit is designed to scale beyond solving itself. Over the next weeks and months, we’ll expand credit and collateral types to further increase efficiency in DeFi for traders, Portfolio Managers and Strategists.

How Sprinter Stash Works

1. Liquidity Providers deposit USDC on Base from any chain into the protocol’s liquidity hub - Receiving spUSDC-LP tokens in return. Liquidity is then managed across the pools on supported chains.
2. Solvers access liquidity instantly, without collateral – Solvers are executing their fills through Stash. After a fill is completed via credit, Stash receives the deposited funds on the source chain repaying the credit and keeping profits for LPs and solvers. Stash works as a closed credit system where the MPC validates all intents to be filled and ensure credit will be repayed.
3. LPs earn dynamic rewards – Yield is optimized through a combination of base yield from supply in lending protocols, such as Aave, and yield from solver borrow fees. LPs are also eligible to earn staking rewards in the form of SPRNT emissions, with higher multipliers for longer locks in addition to bonus incentives for earlybirds.

By bringing together liquidity providers and solvers Sprinter Stash creates a more efficient and scalable solver environment for the entire DeFi ecosystem. Stash launches with supported:

• Destination Networks - Base, Arbitrum, Optimism
• Tokens - DAI, ETH/WETH, USDT, WBTC
• Protocols - Any EVM crosschain bridge/ swap protocol such as 1inch Fusion+, Across, Debridge Liquidity Network, Everclear, Mayan.Finance with many more upcoming
• Rebalancing/ Inventory Management - CCTP, native Bridges, Everclear.

The Future of Onchain Credit is Here

Crypto’s next evolution depends on seamless liquidity movement across chains. Sprinter Stash isn’t just another liquidity protocol, it’s a credit layer that makes crosschain transactions faster, more capital-efficient, and scalable.

With low-risk, high-reward liquidity pools for LPs and zero-collateral liquidity access for solvers, Sprinter Stash is reshaping the way liquidity moves in DeFi and beyond.

Stash goes live later this week, stay updated on how you can participate, and how you can earn rewards by following us on X, joining our Telegram, and reading more on our website.

Join us to shape the future of onchain credit.

📬 Are you building a solver, PM system, or DeFi infra that needs crosschain liquidity? Reach out to us on X or Telegram. We’re onboarding early partners now.

This article is based on the talk ‘Rethinking Competition in Solver-Based Networks’ given at Protocol Berg in Berlin June 13th 2025. (Watch it here)

In Part 2,  we looked under the hood of real-world solver networks like CoW Protocol and Across. What we found was clear:

• A handful of solvers dominate execution and rewards
• Most solvers operate at a loss or barely break even
• Centralization is driven not by better algorithms — but by access to private liquidity, infra scale, and privileged flows

The current landscape is one where the appearance of competition masks the erosion of trust. And the longer these patterns persist, the harder it becomes for new solvers — or new ideas — to emerge. So what do we do now?

Groundhog Day - Haven’t we seen this before?

Before proposing solutions, it makes sense to take a look into areas that that have dealt/ are dealing with similar challenges:

1. Traditional Finance (TradFi), which has spent decades regulating against market dominance and conflict of interest.
2. Ethereum block building, where similar centralizing forces are playing out — but where responses like PBS (Proposer-Builder Separation) - in the form of Buildernnet or ePBS -  are emerging.

Regulation as a Curator of Free Markets — and a Blueprint for Built-In Accountability

When we hear “regulation,” it’s easy to associate it with bureaucracy or red tape. But in healthy market systems, regulation plays a subtler, more foundational role: it curates freedom by keeping markets open, contestable, and fair. In TradFi, regulatory frameworks evolved to prevent dominant players from entrenching themselves, to reduce information asymmetries, and to ensure that coordination doesn’t become control. These functions are just as relevant in the architecture of intent-based DeFi protocols.

In traditional finance, antitrust law limits monopolistic behavior and enforces market contestability. It ensures that even the most powerful market makers or brokers can’t lock out newcomers by cornering access to liquidity or exploiting exclusive relationships. In DeFi, dominant solvers — equipped with deep capital, private liquidity, and privileged venue access — can create very similar exclusionary dynamics. If left unchecked, a few actors could dominate the intent landscape — not because they offer the best service, but because they’ve captured key infrastructure.

Structural separation is another legacy from TradFi that DeFi should take seriously. Regulations like MiFID II or the Glass-Steagall Act were introduced to prevent financial institutions from bundling roles in ways that created conflicts of interest. Yet today’s solvers often handle quoting, routing, simulation, and settlement — consolidating everything into a single opaque stack. Without protocol-level design nudges toward modularity, this consolidation becomes a bottleneck for competition and innovation.

Information asymmetry is another fundamental challenge. In traditional markets, mechanisms like the SIP feed (which ensures everyone sees the same market data) or IEX’s latency equalization are there to curb unfair advantages. In DeFi, fast access to off-chain liquidity or exclusive CEX integrations often determine who wins. Techniques like commit-reveal quoting or shared liquidity indexes can act as DeFi-native forms of latency equalization — not to slow anyone down, but to ensure fair visibility and access.

Regulatory structures also aim to prevent hidden subsidies and backdoor privileges. A trading firm with zero-fee access or CEX credit lines can offer better quotes than competitors — but not necessarily in a sustainable or transparent way. Without clear disclosures or leveling mechanisms, such advantages distort what should be an open market for intents.

Regulation in TradFi doesn’t just police bad actors — it provides the public infrastructure that makes trust possible. Whether it’s licensing regimes, capital requirements, or transparency standards, these mechanisms shift trust from actors to systems. That’s the same direction intent-based protocols should be heading. Verifiable execution, shared mempools, and neutral auction mechanisms are the scaffolding for economic trust.

Traditionally, this has operated through ex post oversight: regulation governs outcomes and enforces fairness through audits, reporting, and supervisory enforcement — typically applied after the fact. To enable this, regulators rely on institutionalized self-regulation: firms are expected not only to follow rules, but to build validation systems that demonstrate adherence.

In crypto, we often talk about “transparency” or “public data” — but that alone doesn’t constitute regulation. What makes crypto special is the ability to replace institutional self-regulation with cryptographic and protocol-level guarantees. In other words: programmed validation and contestability, applied in near real timeIn intent-based systems, some regulatory functions may be taken up by protocol governance — curating incentives, enforcing fairness standards, and protecting market structure. But it's not obvious that this is the right or only place for such functions. Depending on how the ecosystem evolves, these roles might live at other layers: in L1 intent standards, shared execution infrastructure, or inter-protocol coordination bodies.

Right now, what’s more important than the location of these responsibilities is that they exist — and that they are designed to manage the same systemic risks TradFi regulators once addressed: monopolistic behavior, structural opacity, and exclusionary access.

Yet implementing these checks is hard when protocols face conflicting incentives. Rules that promote sustainability — like quote visibility, fair access to liquidity, or solver diversity — may reduce competitiveness in the short term. And since each protocol competes for orderflow, few are willing to make the first move. That’s how we end up in a kind of regulatory coordination failure — what might be called crypto’s Three-Body Problem.

“Crypto’s Three-Body Problem” is about balancing decentralization, efficiency, and user protection — in systems with no central coordinator and no agreed-upon arbiter.

— Other Internet

Ethereum Block Production: Solvers Have Been Here Before

Block builders operate in a competitive environment that closely mirrors the dynamics of solver-based networks. Over the past two years builder competition has become increasingly concentrated. A small handful of builders now consistently win the majority of blocks — not necessarily due to better algorithms, but because of privileged access to private order flow, tight vertical integration with wallets and searchers, and advanced infrastructure for simulation and bid submission.

This centralization trend accelerated following Ethereum’s transition to Proof-of-Stake and the introduction of MEV-Boost in late 2022. While MEV-Boost formally separated block proposers from builders, it also allowed builders to aggregate transaction flow and extract maximum value from it. By mid-2024, just a few builders — including rsync-builder, Titan, and beaverbuild — were responsible for over 80% of blocks on MEV-Boost relays.

At the same time, wallet integrations such as Flashbots Protect and MEV Blocker began funnelling user transactions directly to preferred builders, reinforcing a feedback loop of exclusive flow and execution dominance.

Protocol extensions like PBS (Proposer-Builder Separation) and initiatives like Buildernet aim to address this by modularizing the builder role and enforcing more neutral execution, but implementation is still evolving. Solver networks may face the same questions — and may require similar architectural interventions.

Pillars of Decentralized Solving: Shared Infrastructure as a Competitive Equalizer

Today, solving intent-based protocols is expensive — not just in capital, but in engineering. Each solver team builds and maintains its own infrastructure for liquidity discovery, route computation, quote evaluation, and execution. This duplication is wasteful, but more importantly, it creates steep barriers to entry. Only well-capitalized teams can afford to compete.

One way forward is to rethink what infrastructure needs to be private — and what could be public.

Protocols could establish shared primitives like a public liquidity index, a common routing and quoting library, and neutral relay layers. These wouldn’t remove competition, but they’d refocus it. Rather than everyone solving the same baseline engineering problem, competition would center on strategy, specialization, and responsiveness.

Baseline execution could be governed via SLA-style mechanisms, where any party can execute a route under a quality-guaranteed model. Solvers who contribute better or faster routes on top of the shared baseline could earn discovery premiums, rather than having to maintain end-to-end infra to capture value.

This isn’t just a novel design idea — it echoes lessons from TradFi but also systemically important infrastructure.

In traditional finance, public infrastructure plays a central role in keeping markets fair and contestable. From consolidated price feeds (like SIP in the US) to clearing networks and neutral auction venues, the goal is always the same: to prevent dominant players from winning by controlling the rails.

DeFi protocols can follow suit. Shared solving infrastructure, if developed as a public good, levels the playing field and ensures that solver success is based on skill rather than privileged access, exclusive deals, or opaque vertical integration.

It also enables functional role separation, another staple of well-regulated markets. In TradFi, exchanges, market makers, and clearing agents are structurally distinct because bundling them leads to conflicts of interest. In DeFi, solvers are increasingly full-stack: they route, quote, simulate, settle — and increasingly even control the frontend. That consolidation poses systemic risks.

The solution isn’t to ban vertical integration, but to offer credible public alternatives. Shared fee estimators, liquidity indexes, and quoting interfaces make it possible for small or specialized teams to participate, and make it harder for any one actor to dominate.

Just as TradFi uses antitrust tools to protect market structure, DeFi protocols should treat shared infrastructure as a strategic defence: not just for efficiency, but to preserve contestability and innovation in the long run.

Role Separation: Unbundling Routing, Quoting, and Execution

Vertical integration — where solvers handle quoting, routing, and execution end-to-end — creates a larger surface for centralization and limits ecosystem diversity. By decoupling these roles, protocols can encourage a more modular architecture where each component evolves independently, can be benchmarked transparently, and reused across implementations.

Rather than allowing solvers to perform all functions in a single opaque stack, protocols can define distinct competitive models tailored to each role:

This role-based separation helps shift the competitive dynamic away from resource-driven dominance and toward open, strategy-based participation — strengthening decentralization and long-term protocol resilience.

Shared Liquidity Index: Removing duplicated discovery efforts

Today, solvers compete largely on the basis of their internal infrastructure — the speed and accuracy with which they can discover and model fragmented liquidity across venues. This is very inefficient as it creates a lot of duplicated work, without tangible market improvements. A shared Liquidity Index levels the playing field by making real-time market data a network/chain-level public good.

Instead of requiring each solver to maintain its own integrations, liquidity sources themselves — such as AMMs, PMMs and other RFQ venues — publish updates (price curves, token pairs, sizes) into a shared registry. These updates can be signed messages or on-chain events and are consumed by all solvers equally.

This reduces infrastructure overhead, improves transparency, and aligns with the ethos of DeFi: composability and openness.

Public Liquidity Only: Redirecting Private Liquidity to Public Interfaces

Access to private liquidity — whether through private market makers, prime brokers, or exclusive RFQ endpoints — remains one of the most significant advantages for solvers today. To mitigate this, protocols can build on the concept of a shared liquidity index by requiring that all liquidity sources be accessible to all participating solvers and published through the shared index. This would incentivize private liquidity providers to route their flow through the same public interfaces used by AMMs and open RFQ venues, leveling the playing field and reinforcing transparency.

Reclaiming Efficient Markets: From Infrastructure to Trust

Intent-based protocols promised to unlock more expressive, user-centric coordination — but that promise is increasingly at risk. As in block production and TradFi before it, consolidation in solver networks is driven less by superior performance and more by control over infrastructure, liquidity, and privileged access. The appearance of competition masks a deeper structural imbalance.

What history teaches us — from antitrust enforcement to Ethereum’s own builder ecosystem — is that markets do not remain open by default. Contestability must be engineered. Protocols must choose to embed fairness into their architecture: through shared infrastructure, unbundled roles, and neutral access layers that prevent vertical dominance.

Just as TradFi regulation evolved to preserve competitive integrity, intent-based DeFi must develop its own mechanisms — not to impose bureaucracy, but to encode openness. This is about moving from trust in actors to trust in systems: systems that are auditable, modular, and resistant to capture.

The path forward is not about eliminating competition — it’s about re-aligning it. When baseline infrastructure is shared, differentiation moves to strategy, responsiveness, and innovation — not relationship-driven advantages. That’s how new solvers enter, new ideas thrive, and trust in the ecosystem grows stronger over time.

Thank You

A huge thanks to the teams at Flashbots, Barter, Li.Fi & Propeller Heads for the discussions and inspiration!

If you’re a solver, protocol designer, or researcher, we’d love to hear your thoughts and keep the dialogue going!

Join us on our mission to shape the future of crosschain!

🏃‍♂️ Follow us on X

🏃Visit us at sprinter.tech

This article is based on the talk ‘Rethinking Competition in Solver-Based Networks’ given at Protocol Berg in Berlin, June 13th 2025.

In Part 1, we introduced the concept of economic trust as a necessary complement to cryptographic trust in solver-based networks. We argued that economic trust is not just about verifying code or signatures, it’s about trusting systems of incentives, access, and enforcement to produce outcomes that are fair, resilient, and decentralized.

But trust doesn’t emerge in a vacuum. It is shaped, in large part, by the market structures in which solvers operate. In Part 2, we explore how today's competition models in solver-based protocols are evolving — and in some cases, replicating the same centralization dynamics we hoped to escape. 

The Rising Costs of Being a Solver

Solving typically unfolds in five key steps. While the general structure holds across intent types, the specifics, especially around execution and risk, can vary significantly. First, let’s walk through the common process. Then we’ll compare how it applies across different solving contexts:

Each of these tasks requires building out and maintaining infrastructure: real-time data ingestion, fast simulation engines, and tightly coupled onchain/offchain orchestration. Therefore running a production-grade solver is no longer a weekend project - assuming you want to capture at least 1% of relevant order flow. 

Based on our own experience and discussions with numerous solver teams across different protocols, we estimate that costs for operating a production-grade solver typically range from $13,000 to $26,000/month. And that’s before accounting for penalties, slashing, or capital lock-ups.

The State of Solver-Competition: Case Studies from the Field

Let’s look at two prominent protocols: CoW Protocol and Across. 

We analyzed profits and solver participation for both for the first four months of 2025 based on the available on-chain data (mostly Dune) and anonymized the solver names. 

CoW Swap – Trading Volume & Rewards

The data shows that out of 28 total solvers active on CoW Protocol, only 12 handled more than 1% of trading volume in the first four months of 2025. Remarkably, just three solvers account for over 50% of all volume, underscoring a steep concentration of execution power. 

The rewards picture is even more top-heavy. Among the top three solvers, one stands out as an outlier—capturing nearly 50% of all rewards.

It’s important to note, that the reported rewards here are pure protocol rewards as reported by CoW and solvers might have other sources of revenue from arbitrage and/ or positive slippage for example that we are going to analyze at a future time. 

The chart plots the share of ideal rewards captured by each solver over the analysis period. The x-axis shows individual solver identities (anonymized), while the y-axis reflects the percentage of ideal rewards successfully captured. Ideal rewards refer to the maximum reward available to a solver upon winning an auction, assuming optimal execution and successful settlement. The green band reflects, based on the cost estimations above - the survival zone of solvers where we assume solvers to be able to cover their costs. 

In response to community feedback, we refined our analysis by including quote rewards, which account for a non-trivial share of income for some solvers. We highlight in yellow those solvers whose position shifts into the estimated survival zone due to these rewards. While this adjustment does improve the outlook for a few actors the broader distribution remains consistent: a handful of solvers extract most of the rewards, and the rest remain under persistent pressure. The underlying asymmetry tied to access to liquidity, inventory, and infrastructure continues to dominate.

Based on observed auction behaviour, we identify four strategic solver archetypes: 

• Noisy Solvers (Grey): Characterized by sporadic participation and inconsistent performance. These solvers likely operate with limited alpha, generic heuristics, or outdated strategies. Their wins are infrequent and appear more random than targeted. This group likely includes altruistic solvers motivated by non-monetary goals—such as providing backstop liquidity or supporting specific protocols—as well as lean independent teams operating with minimal costs. From a systemic perspective they are unlikely to reliably challenge the pricing of top solvers, particularly those with scale, capital, and privileged liquidity access.
• Optimizers (Orange): Solvers who focus on onchain liquidity and routing, attempting to win a high number of auctions by offering attractive prices. This comes at the cost of higher settlement risk — particularly in cases of volatile public liquidity.
• Multi-Strategy Solvers (Olive): These solvers balance selectivity and infrastructure sophistication. Likely using private liquidity in certain paths or fallback strategies, they maintain lower failure rates while staying close to break-even. Their approach appears to be about survival through efficiency, not dominance.
• Vertically Integrated Solvers (Green): A class of full-stack operators combining deep capital, internal inventory, CEX connectivity, and minimal reliance on public liquidity. These solvers win selectively, capturing high-value intents where they can extract the full spread with low failure risk. Their edge often stems from privileged relationships — including low or zero trading fees, direct CEX access, or even preferential credit lines — and may extend to alignment with builders or validators, further consolidating control.

The chart clearly shows a two class solver landscape — where access to privileged liquidity separates the top performers from the rest of the competition.

After presenting this analysis, we received valuable feedback from the CoW Protocol community, specifically pointing to nuances in solver profitability and strategy that are not fully captured in our current data lens. A few key points:

• Cost models vary widely: Some solvers operate lean, even part-time, while others resemble prop trading firms with significant infrastructure budgets. This means our baseline cost estimates likely represent an upper-middle range.
• Profit beyond protocol rewards: Solvers with alpha on certain routes or privileged liquidity access may extract profit outside of the reward mechanism. For example, quoting strategies, retained slippage, profits from arbitrage or optimized flow execution could yield additional margins not visible in reward capture metrics.
• Survivorship bias & persistence: While charts show stark reward concentration, the long-term presence of many solvers suggests some are sustainably profitable in ways not directly observable from public reward data alone.

Our response to this: 

We fully agree that solver strategies and infrastructure vary widely, and that profitability can be augmented through alpha extraction, preferential liquidity access, and cross-protocol optimization that are not fully captured by our analysis.

Furthermore it’s a bit simplistic to infer profitability from rewards alone, especially in a landscape where short-term losses may be accepted to build positioning/ reputation or gain market share. That said, comparisons to ultra-lean solver or one person setups — while valid, should be made with caution. These operations may indeed exist and succeed today, but they are often idiosyncratic, difficult to replicate, and may not scale sustainably in a competitive or professionalizing ecosystem. Designing protocol dynamics with these edge cases as the baseline risks underestimating the infrastructure investment required for a resilient and diverse solver set.However, we believe reward capture data reveals behavioral clusters that hint at distinct operational solver archetypes as we have described above. We see this clustering as useful for interpreting solver strategies—beyond binary profitability metrics. We’re continuing to refine our methodology and welcome more collaborative insight from teams active in the space.

Across Protocol– Trading Volume & Rewards

The chart provides a view of solvers and their respective share of volume and rewards (revenue) in the first four months of 2025. What we observe:

• $4.6 billion USD in total volume, 10 out of 78 solvers process at least 1% of this volume.
• 'Nessus', the solver operated by the team behind Across, covers the largest share of the bridge volume. This solver does not really take part in competition: it waits for other solvers to fill and only steps in as a last resort. That this solver is capturing roughly half of the volume might indicate that there are not enough incentives for other solvers to capture this volume and/ or hold the required inventory needed.
• The rewards distribution broadly mirrors the volume curve: a few solvers dominate, while most only contribute minimally to the overall economic activity.

This chart examines for participating solvers the bridge volume in Millions handled as well as the achieved revenue rate (in basis points - bps) for that volume. The green band reflects, based on the cost estimations above - the survival zone of solvers where we assume solvers to be able to cover their costs. Furthermore the solver dot size indicated the amount of available inventory in US Dollars.

What we observe:

• Out of 78 total solvers, 5 to 10  solvers are profitable under the cost assumptions  made — one of which is external (Lichas).
• The top-performing external solver ‘Lichas’ benefits from significantly more liquidity—holding over $3.7 million USD in inventory, compared to less than $600k for most peers.This liquidity advantage enables economies of scale as it substantially reduces rebalancing costs and enables to fill more tokens and larger orders.

After publishing our analysis, we received valuable feedback from the Across team, particularly around solver costs, data assumptions, and the broader ecosystem structure. Below we respond to some of the key points raised:

Cost Assumptions

We agree that the cost to run an Across solver is likely on the lower end or even below the mentioned range of  $13,000–$26,000/month, particularly compared to more complex solving environments like CoW Protocol. A number of lean, one-person solver setups exist and in some cases are quite profitable. However, our goal was to show the spectrum of operational complexity across different solver networks, with CoW and Across representing two useful endpoints.

From a systemic perspective, relying on one-person solvers is risky, kind of like in the Uber model: great at first when market expansion is incentivized, but not necessarily sustainable once incentives and costs normalize. And realistically, most indie teams won’t be able to beat professional top solvers long-term

Clarifications on Methodology used

• Reward BPS: Our revenue rates account for gas costs, but not failed transactions. Including failure-related costs (especially for fills without reimbursements) would likely worsen the outlook for some solvers. We also tracked priority fees, and noticed that some solvers pay up to 25% of potential revenue in tips—an often-overlooked factor.
• Inventory Sizing: To estimate solver liquidity, we sampled wallet balances over time. For each solver, we used the maximum sustained balance (held for at least x consecutive days) to approximate minimum accessible capital. This method is imperfect—it misses private rebalancing strategies, shared capital pools, and non-transparent funding sources—but gives a directional sense of who holds inventory advantage.
• Rebalancing Costs: These are a critical missing component. Due to a lack of standardized reporting or public visibility, we didn’t include them. If better heuristics or tools emerge, we’d love to incorporate them into future versions.
• Solver Landscape: Across's high number of solvers relative to CoW is likely a direct function of low entry barriers and permissionless participation. This is a strength, but also means a long tail of solvers may remain economically unviable over time. In contrast, CoW’s permissioned structure and high bond requirements create natural gatekeeping and lead to a more concentrated solver set.

Potential Future Research

• Inferred cost, i.e. asking what cost level would make X% of solvers profitable based on observed rewards. We’re exploring this approach, but it depends heavily on improving our underlying cost and revenue models.

Summary: What We’ve Learned from CoW and Across

Analyzing CoW Protocol and Across side by side highlights several structural realities of today’s solver markets:

• Winner-takes-all dynamics: A small number of top solvers dominate volume and rewards.
• Most professional solvers aren’t profitable: While user welfare improves, margins remain thin for the majority of participants. Solving is largely a reputation game and solvers are looking for other areas of revenue such as Arbitrage/MEV, Solver Infrastructure or privatizing orderflow via dedicated Swap APIs.
• Liquidity access is key: The biggest centralizing forces are capital requirements and access to non-public liquidity—far more than logic or latency.
• Protocol-level improvements are underway, but current adjustments are unlikely to shift the underlying incentives in a meaningful way.

These findings underscore the need to design not just for user welfare, but for contestability, sustainability, and long-term resilience. 

Looking ahead, Part 3 will explore potential solutions to these challenges by drawing insights from traditional finance and the ethereum builder landscape, to help build more resilient, fair, and sustainable solver-based networks.

Thank You

We’re incredibly grateful to the teams at Across and CoW Protocol for their thoughtful, constructive feedback. Their openness, technical insight, and willingness to engage critically helped surface important nuances we couldn’t have captured alone.

The goal here isn’t to discredit the involved protocols or present a final or definitive model, but to kickstart a deeper conversation around solver economics, sustainability, and protocol design. We hope it encourages more open data, better tooling, and ultimately, healthier competition across the ecosystem.

If you’re a solver, protocol designer, or researcher, we’d love to hear your thoughts and keep the dialogue going!

Join us on our mission to shape the future of crosschain!

🏃‍♂️ Follow us on X

🏃Visit us at Sprinter.tech

As intent-based DeFi architectures evolve, the role of solvers—the agents responsible for fulfilling user intents—has become increasingly central. Solvers compete to route trades, bridge assets, or bundle transactions across chains. They are the execution layer behind the abstraction.

Yet, despite the innovation, a fundamental question emerges: Can we trust these systems—not just cryptographically, but economically?

In this article, we’ll define what economic trust means in solver-based networks, why it's essential, and how we can build it. We’ll start by introducing a six-part framework for understanding trust in DeFi execution systems, then explore how systems in traditional finance approach economic trust. 

What is Economic Trust?

In cryptographic systems, we trust code: smart contracts do exactly what they’re programmed to do. But when it comes to solvers, we’re relying on off-chain actors to behave in economically fair and competitive ways—choosing optimal paths, pricing honestly, and not abusing their privileged execution role.

So, what is economic trust?

Economic trust is the confidence that a system of incentives, rules, and access will consistently produce fair, competitive, and efficient outcomes—even when participants act in their own self-interest.

This is particularly important in solver-based systems, where:

• Users can't directly verify how execution decisions were made
• Solvers may selectively fulfill only profitable trades
• Protocols may design auction systems or selection mechanisms that advantage certain players

If trust breaks down, so does participation. Users leave. Solvers centralize. Protocols become brittle.

The Six Dimensions of Economic Trust

To build solver networks that scale and remain fair, we need more than just open APIs or auction systems—we need to design around six interlocking dimensions that together create a foundation of economic trust.

These dimensions give us a systematic lens through which we can analyze how protocols enable—or inhibit—economic trust. In the rest of this article and the series ahead, we’ll explore each one in more depth—starting with access

How Traditional Finance Handles Economic Trust

Traditional finance has spent decades developing frameworks to enforce trust and fairness—both through law and structure. While this is by no means perfect, we believe that there is a lot to learn from existing systems in terms of things that have worked/ did not work.

In TradFi:

• Market access is regulated: You must be licensed to participate. Capital requirements, compliance procedures, and approvals ensure that all participants meet a minimum bar.
• Roles are functionally separated: Custodians, brokers, exchanges, and clearinghouses are distinct entities. This reduces conflicts of interest and prevents single actors from dominating the flow of assets or information.
• Behavior is governed by rules and norms: From circuit breakers to disclosure requirements to best execution laws, a combination of explicit regulation and industry-wide standards help ensure participants act fairly—even when incentives differ.

These mechanisms form the foundation of economic trust in traditional markets. But they come at a cost: gated access, high compliance burdens, and limited transparency.

What’s Next?

DeFi gives us an opportunity to reimagine these safeguards using programmable, transparent, and permissionless infrastructure. 

This new infrastructure allows us to transition from a system where market access is gated and rules are defined ex ante by legal and regulatory institutions, to one that is open and inclusive—where access no longer needs to be restricted upfront, because behavior and rules can be enforced in situ through programmable constraints applied at every transaction.

In the next part of the series we start with the first and most foundational dimension: Access.

Join us on our mission to shape the future of crosschain!

🏃‍♂️ Follow us on X/Twitter

🏃Visit us at Sprinter.tech

This post is not meant to be an introduction to these concepts, rather a deeper look at the current state of affairs with the needs of developers in mind. If you want a primer, check out this MPC Intro and this Account Abstraction resource.

The Evolution of Embedded Wallets

The rapidly evolving embedded wallet space has significantly improved user experience for both users and developers, completely improving the onboarding process for newcomers. Today, embedded wallets provide seamless onboarding, allowing users to access crypto apps without needing to manage private keys directly.

As embedded wallets scale, distinguishing between authentication and authorization becomes essential. Technologies like MPC and Shamir Secret Sharing have come into the focus as the primary technology embedded wallets use to make their underlying wallet infrastructure more secure and resistant to hacks.

Many apps have adopted embedded wallets, increasing the prevalence of MPC wallets and their onchain complement, account abstraction (AA) wallets.

Despite significant advancements, new UX tools can create security gaps and confusion about how to use these tools effectively together. A recent wallet-as-a-service exploit underscored the importance of secure practices for generating, storing, and signing with embedded wallet signers

The Core Issues: Association and Fragmentation

The core issues fall into 2 main themes: association and fragmentation. Let's get into it.

1. Signer Association

The absence of a standardized association mechanism between AA wallets and MPC signers has resulted in several challenges. Currently, there's no reliable way to determine whether an AA wallet is already paired with an MPC signer—or vice versa—before integration.

From the start, this uncertainty forces developers to decide upfront whether the AA wallet or the MPC signer should serve as the user's primary wallet, leading to inconsistent implementation across platforms.

A lack of clear direction means developers often resort to workarounds such as obscuring wallet addresses or choosing which ‘account’ address to display to the user as their wallet and associated public key. When developers must resort to these user experience trade-offs, the security and usability of the application suffers.

Fragmented Signers

Account abstraction aims to improve wallet user experience, but its adoption has been hampered by embedded wallet walled gardens.

One key challenge is the variation in how embedded wallets are implemented. For example, some providers issue one new embedded key for each application a user interacts with, creating silo’d embedded wallets. Others (like Para), enable universal embedded wallets where the same wallet can be reused everywhere. App-specific embedded wallets per app vs. a universal embedded wallet for every app strongly influences UX.

Security is another major implementation concern, as developers can struggle with multi-signer management. Some developers simply add multiple owners to an account, which necessitates complex permission systems or forces an all-or-nothing approach to access management.

2.The (re)Discovery Problem

When users are confronted with a cluttered interface filled with multiple wallet choices (especially multiple wallets from multiple apps), the process of identifying and selecting the right wallet becomes overwhelming. With smart accounts and silo’d embedded wallets, this problem is exacerbated.

Many users end up with separate smart accounts for each application due to inadequate rediscovery mechanisms. Smart accounts created with one provider may not be compatible with those generated using another.

3. On and Offchain Permissions

Permissions are tough, and interfaces are challenging to get right for every type of use case. Thankfully, we can blend both onchain, and offchain permissions seamlessly into a unified experience.

ERC-7715 offers a unique to have wallets sign overtop of permissions, granting other keys (not just ECDSA 👀) to have the ability to sign on-behalf of an account. Effectively, 7715 resembles a JWT token. Users sign off on what an application can do with their account, all offchain, then the app co-signs every action against the JWT which is enforced onchain. This pattern is beautiful because it resembles what developers are used to (JWTs!) with the security that you expect from self-custody. Applications specific permissions, that are verifiable onchain.

However, not all permissions make sense to encode onchain – driving demand for offchain policy and permissioning systems.

Offchain permissions bring the convenience of multi-chain scalability, privacy, and easy upgradeability – however, they are very difficult to enforce in most traditional models. Put simply, any EOA wallet that has a permission layer requires intensive trust, as gaining possession of the private key (if held in a browser or enclave) is sufficient to bypass any permission controls that may be implemented.

This is where Distributed MPC comes in. Because keyshares are never recombined, there is a clear layer at which to enforce permissions. Further, proactive refreshing enables differentiated key shards per-app - reducing the risk of least-common-denominator app compromise.

These two innovations give rise to cross-chain and cross-app signers, all while keeping transparent guarantees signing access and minimizing key access.

4. Cross-Chain Compatibility

The challenges of fragmentation are further amplified when considering cross-chain compatibility. Users often forget to deploy their wallets across multiple chains, leading to discrepancies in smart contract wallet addresses.

Additionally, there is no guarantee that the same signers will be available on every chain because CREATE2 is not fully future-proof, making it difficult to maintain a consistent cross-chain experience. If an application does not exist on both chains and the signer is scoped to a specific domain, users may find themselves at an impasse with no clear solution for accessing their funds across chains.

While AA may offer a seamless wallet experience on one blockchain, the requirements and constraints of another chain’s VM can require significant modifications or even result in incompatibility.

To mitigate this, most teams need to adopt an MPC cross-chain signer + AA per-chain structure which can be difficult to manage (see Section 1). The story isn’t over at signing. To make the experience go the extra mile when building cross-chain, or even intent based applications, you need a solver. With all the components we’ve described above, providing clean delegation to a solver on your behalf (safely), enables beautiful UX for everyone.

The End Game

Making a decision today is still incredibly difficult. We’ve found that developers can get around these nuances by using:

• A universal (cross-app, cross-chain, and fully portable) embedded wallet as an MPC signer that can be associated with account abstracted wallets on different chains/L2s
• The MPC signer as the canonical cross-chain public address for the user to limit funds loss

The ideal end game will need to look like:

• A universal way to associate AA wallets with MPC signers. This should solve the signer problem, x-chain problem, and discovery
• Better standardization across AA specs per chain per VMs

We’re excited to work together towards a unified approach to UX. If you’re committed to reducing fragmentation, and want to talk solvers we’d love to chat!

About our Authors: Greg is the Founder of Chainsafe and Sprinter. Nitya is the Founder of Para.

Blockchain technology promised a decentralized and transparent future, yet for many, it still feels out of reach—complicated, costly, and inaccessible. Obstacles like Maximal Extractable Value (MEV) and fragmented ecosystems have transformed what should be seamless interactions into frustrating, time-consuming, and expensive processes.

But this is just the beginning—we're still writing the narrative. And in this chapter, Solvers are one of the main characters.

By interpreting user intents—simple statements of desired outcomes—and executing them with precision, the solver ecosystem is bridging the gap between blockchain technology's potential and its practical use.

What are solvers?

Solvers are sophisticated optimization entities that handle the intricate details of onchain interactions, freeing the user to focus on their goals. Acting as intermediaries, solvers evaluate execution pathways, reduce inefficiencies, and enhance user outcomes.

For example, if you want to swap ETH for USDC at the best price, a solver will analyze all available decentralized exchanges, calculate fees, and execute the trade efficiently. Similarly, if you need to transfer assets between Ethereum and Polygon, a solver will identify the optimal bridge and handle the complexities of execution, saving time and reducing errors.

By abstracting the complexities of blockchain transactions, solvers translate users' complex intents—such as swapping tokens or transferring assets—into actionable steps that prioritize optimal outcomes.

Intent-based systems

At the core of a solver network lies the concept of intents. The web3 community is discovering the potential of intent-based systems to shift the burden of complexity away from the user, allowing them to focus on their goals without navigating technical intricacies.

Intents are signed messages that only define an acceptable end state and potential constraints. They don't define "how" this end state is achieved. Finding the best "how" is outsourced to a specialized actor, called a solver. — Redefining Blockchain Interactions

While intent solutions simplify blockchain interactions, challenges like fragmentation and a lack of composability across protocols remain significant barriers to realizing their full potential.

Solvers vs searchers

Maximal Extractable Value (MEV) has been a persistent challenge in blockchain networks. Searchers—entities that reorder, include, or exclude transactions for profit—often operate at users’ expense, exploiting vulnerabilities and increasing costs through practices like front-running and sandwich attacks.

Solvers, in contrast, focus on optimizing user outcomes. They compete in intent-solving auctions to provide better prices, mitigate MEV risks, and deliver value-added services. Interestingly, the skills and expertise required for searching and solving are quite similar, making teams with a background in MEV searching particularly effective as solvers. Many top solvers started as searchers, leveraging their deep understanding of MEV dynamics and optimization to deliver user-focused solutions. However, solvers are not immune to financial incentives, and their behaviour is influenced by the competitive market of the wider solver ecosystem. Addressing risks like centralization and the principal-agent problem is crucial for maintaining user trust.

What do solvers do?

The role of solvers is expanding rapidly, driven by the growing adoption of intent-centric models. Acting as market participants, solvers match potentially complex intents with counterparties and chart the most efficient paths to fulfill them. In return, solvers earn fees for their services, creating a symbiotic relationship between users and the ecosystem.

Execution quality

Solvers improve execution quality by finding optimal routes for complex intents. In some cases, intents are matched directly through mechanisms like coincidence of wants or ring trades, which eliminate fees and slippage. However, these scenarios are rare. Batch auctions, like those implemented by CoW Swap, aggregate intents over time, enabling solvers to compete for the best execution paths.

Despite these advancements, a significant challenge persists—the lack of composability between systems. Intents on UniswapX currently can't interact with those on CoW Swap, limiting a solver's ability to fully optimize transactions across platforms. The push toward generalized intent networks aims to overcome this hurdle, unlocking cross-protocol composability for solvers.

Simplifying user experiences

Interacting with blockchain platforms often feels like navigating a maze. Achieving optimal results requires users to juggle token markets, compare exchange rates, avoid MEV attacks, and manage transaction fees. For many, this complexity creates friction that limits participation. Solvers offer a solution by removing these barriers, focusing on the user's desired outcomes, and handling the complexity behind the scenes.

Take Bob, a casual investor looking to convert 2 ETH into a portfolio of smaller tokens: 50% into LINK, 30% into UNI, and 20% into AAVE. Without solvers, Bob would need to:

1. Check prices for each token manually on exchanges like Uniswap or SushiSwap.
2. Split his ETH into exact portions, factoring in slippage and gas costs for each trade.
3. Execute three separate transactions, each incurring fees.
4. Monitor market conditions to ensure fair prices for every swap.

This process is time-intensive, costly, and prone to errors—making it an uphill battle for users like Bob.

With solvers, Bob expresses his intent—"Convert 2 ETH into a portfolio of LINK (50%), UNI (30%), and AAVE (20%)." While Bob's goal is technically a complex intent, for a human, it's the simplest way to express his needs. The solver then analyzes multiple DEXs, optimizes execution, and batches the transactions for minimal transaction fees, creating the portfolio seamlessly.

By focusing on intent execution and interpretation, solvers make blockchain interactions accessible for everyday users—no advanced technical knowledge or financial expertise required.

How do they operate?

The solver's role goes beyond simple execution—they combine technical expertise, advanced algorithms, and robust infrastructure to deliver seamless, efficient and optimized execution.

Onchain routing

Solvers shine when it comes to creating efficient pathways for onchain transactions, focusing on reducing gas costs, minimizing slippage, and avoiding network congestion. By interacting with decentralized exchanges (DEXs), liquidity pools, and other protocols, solvers identify the most advantageous execution routes.

However, current systems, like UniswapX or CoW Swap, often lack composability, preventing intents from interacting across platforms. This limits a solver's ability to optimize transactions through rare mechanisms like coincidence of wants or ring trades. Generalized intent networks aim to address these limitations, unlocking full composability for solvers and enhancing execution quality.

Offchain liquidity management

Some Solvers extend their capabilities beyond onchain activity by tapping into off-chain liquidity sources, adding flexibility and improving transaction pricing.

Through access to private order flows and external liquidity providers, Solvers can deliver competitive pricing that often surpasses what is achievable onchain.

Private order flows help minimize market price impact, especially for large trades. Solvers working with institutional-grade liquidity providers can execute substantial transactions discreetly, preventing adverse effects on market prices. However, accessing these flows is rare and often strategically cumbersome.

Crosschain execution

A user who wants to swap tokens on Ethereum and receive assets on Polygon can use a solver to identify the optimal bridge, handle the transfer, and ensure they get their desired asset with minimal delays.

Solvers orchestrate transactions across multiple blockchains, ensuring seamless interoperability for users. This involves bridging assets, dynamically managing crosschain liquidity, and delivering fast, reliable settlements across networks. In a fragmented rollup-centric future, solvers act as an abstraction layer, mitigating UX challenges and improving transaction reliability.

By dynamically managing liquidity across chains, solvers effectively mitigate risks from fragmented markets, creating a smooth, efficient user experience.

Latency optimization

In blockchain transactions, timing is everything. To stay competitive, solvers optimize for low-latency processing, especially in MEV-sensitive scenarios. This involves minimizing delays in pathfinding, securing liquidity, and submitting transactions faster than competitors.

Latency optimization is particularly crucial in high-frequency scenarios like MEV mitigation. In these contexts, even a fraction of a second can determine whether a solver successfully fulfills an intent. By prioritizing speed and precision, solvers deliver timely and efficient execution.

Competitions among solvers

Auctions are key to ensuring users receive the best possible execution quality.

Batch auctions—like those implemented by CoW Swap—aggregate user intents over time, allowing solvers to compete to fulfill them. Solvers place bids based on their anticipated returns, factoring in potential profits from MEV mitigation or gas savings. This process encourages the solver ecosystem to optimize their strategies to deliver superior outcomes.

Another auction format, the Dutch auction, dynamically adjusts pricing based on demand, fostering efficient competition while aligning incentives with user outcomes. Unlike traditional order flow auctions, these mechanisms prioritize delivering optimized execution directly to users rather than offering refunds based on auction bids.

These mechanisms align incentives with user outcomes, but centralization risks persist. Reduced competition in the solver ecosystem could lead to extractive behaviour and diminished benefits for users. Encouraging diversity among solvers and adopting accountability frameworks is extremely important in mitigating these risks.

Addressing risks and challenges

As generalized intent systems become a reality, solvers will unlock new levels of efficiency and interoperability. However, challenges such as centralization risks, reduced competition, and censorship resistance must be addressed.

While solvers promise significant improvements in onchain interactions, their growing dominance raises concerns. Centralization among solvers could amplify risks like reduced competition and extractive behaviour. Accountability frameworks and decentralized governance structures will play a vital role in mitigating these risks.

Moreover, encouraging ecosystem-wide standards for intents will enhance solver participation, competition, and execution quality. This approach aligns incentives across stakeholders and ensures that solvers empower users without compromising the decentralized ethos of web3.

By focusing on execution efficiency, mitigating MEV risks, and simplifying user interactions, solvers are making blockchain more accessible and user-friendly. However, achieving this vision requires ongoing innovation and collaboration across the ecosystem.

The next chapter for solvers

Solvers are more than just a technical upgrade—they’re a shift in how we engage with blockchains. By abstracting complexity and delivering seamless user experiences, solvers are rewriting what’s possible onchain. However, their potential is only as strong as the ecosystem supporting them.

The path forward isn’t just about fixing risks—it’s about setting the stage for a more collaborative and open onchain future. Centralization concerns, governance gaps, and interoperability challenges are hurdles, but they’re also opportunities to build better systems.

With the adoption of standardized intent-based systems and diverse solver participation, the ecosystem will push past these obstacles and unlock a more inclusive, decentralized web3.

This isn’t just a tech story—it’s a community-driven evolution. As solvers reshape blockchain interactions, their success depends on collective effort. Developers, researchers, and users alike must come together to ensure solvers aren’t just functional but transformational.

The real win? A blockchain experience that’s intuitive, fair, and powerful enough to empower anyone, anywhere. With solvers, we’re not just building systems—we’re building a future where blockchain feels effortless and accessible to all.

Join Sprinter’s run club

Set your application apart and embrace the multichain ecosystem. 

🏃‍♂️ Follow us on X/Twitter

🏃Visit us at Sprinter.tech

Sprinter

Sprinter is a suite of tools for developers building multi-chain consumer applications that want to give the best experience for their end user. An end-to-end toolkit that provides chain abstraction, bridging, and cross chain contract call, all out of the box.”

Sprinter

Sprinter is a suite of tools for developers building multi-chain consumer applications that want to give the best experience for their end user. An end-to-end toolkit that provides chain abstraction, bridging, and cross chain contract call, all out of the box.”

The need for the abstract

Once introduced, personal computers required users to be a bit tech-savvy. It was nothing too major, just knowledge of how to use the terminal and eventually some HTML skills if you wanted to build a website, but mostly, it was straightforward. 

As technology evolved and the Internet established itself as a global infrastructure, the user experience (UX) evolved along with it. Computers became easier, and those clunky UXs became cleaner. When we use our computers today, whether a smartphone, laptop, desktop, or even smart fridge, we encounter a UX that has become familiar. The goal was, and still is, to make it easy and intuitive. You want a user to enter your app or website and immediately know what they’re doing. 

When we look at the differences between web1 and web2, one of the most obvious is the UX. It took decades of protocols, innovations, failures, and eventually, standards to reach the user-friendly Internet we know today. However, the user experience takes a step back when we look at the differences between web2 and web3.

It wasn’t improved simplicity that led the web3 revolution—it was the paradigm-shifting cypherpunk dream we were all holding onto. We didn’t care that it looked ugly and was complicated to use. We wanted freedom and protection from centralized and malicious actors. But in all honesty, we are entering a new stage of web3—one that's gearing up for mainstream adoption.

So, what should be the goal here? In my mind, it's simple. If we want users to use web3, we need to make it easy. For everyone to benefit from the freedom, transparency, and security that web3 provides, we need to mirror some level of web2 UX.

"We're building applications that use blockchain."
- Greg Markou, CPO/Co-Founder of ChainSafe & Sprinter

Chain abstraction

Chain abstraction is all about simplifying the user's web3 experience. Users shouldn't have to worry about which network they're on, which currency they’re using, or how to transfer tokens between them. It provides users with a familiar experience. Imagine a unified interface connecting you to web3 with zero interruptions and no distractions.

Like the leap from web1 to web2, chain abstraction means turning complex web3 navigation into something as intuitive as the simplest website.

How are we making this happen?

Layer 2 enhancements and Infrastructure solutions
Layer 2 solutions like rollups and state channels are increasingly being adopted to overcome the limitations of primary blockchain layers, expedite transactions, and reduce costs.

Solutions like ZK-rollups consolidate multiple transactions off the primary chain and validate them through cryptographic proofs, ensuring their accuracy and security. Infra solutions like decentralized oracles and cross-chain messaging protocols are crucial in facilitating fluid communication and interactions across diverse blockchain networks​.

Intent-based design
Intent-based protocols are crucial in simplifying user interactions within the blockchain space. By focusing on the user's goals (intentions) rather than the underlying blockchain mechanics, these designs allow for more intuitive and accessible applications.

By automating the decision-making process behind transactions, intent-based systems can dynamically choose the most efficient execution paths, improving the speed and cost of operations across multiple chains.

Universal accounts and liquidity
A universal account (a unified interface) simplifies blockchain interactions by allowing a single account to operate across multiple chains. This simplification aids in managing wallets across networks and utilizes universal liquidity to facilitate transactions without the cumbersome process of manual bridging.

This setup not only boosts user convenience but also enhances the efficiency of asset management and transfer across the blockchain landscape​.

Key EIPs changing the landscape

• EIP-4337: Account Abstraction
• EIP-7555: SSO Login 
• EIP-7715: Delegating permissions to embedded wallets

These EIPs focus on how wallets interact with the application layer and tie back into chain-agnostic protocols.

The big game-changer for web3 applications is EIP-7715: 

• Allows tagging embedded wallets with permissions
• Enables off-chain-based signatures for delegating actions
• Users can potentially sign up to 20 transactions on L2s without realizing
• Removes the need for one button click per transaction
• Allows applications to control the signing experience

Standardization is key to the success of future web3 development. Without it, we risk creating siloed solutions rather than fostering interoperability.

EIP-4337, for example, left a lot of gaps, which is why we’re seeing a real need for standardization in the space now. We care deeply about it because, without a solid framework, we risk creating more fragmentation among chain abstraction providers.

That’s why we’re not just sitting on the sidelines. We’ve had a direct hand in shaping these standards—we even co-authored EIP-7555—and are working closely with the key groups involved to ensure that everything comes together consistently and collaboratively.

Benefits of chain abstraction

Promoting seamless multi-chain operations
A decentralized application (dapp) could facilitate effortless interactions across diverse networks with some level of abstraction, allowing transactions and data transfers to flow smoothly between networks without the typical barriers. 

Whether you're managing assets, deploying smart contracts, or integrating services, chain abstraction ensures that these activities are straightforward.

Empowering developers with simplified tooling
One major hurdle in web3 development is the steep learning curve associated with different blockchain protocols.

Chain abstraction could remove this complexity by offering a unified development environment. Developers should be able to create dapps using a single, consistent set of tools, APIs, and smart contracts across multiple networks.

Enhancing the user experience
Users should be able to engage with dapps with the same ease and familiarity as web2 interfaces without needing to understand the technicalities of blockchain technology. 

Simplifying web3 UX is critical to broadening adoption and fostering a more inclusive, less fragmented digital economy.

Increasing flexibility and scalability
In a chain abstracted system, enterprises and developers wouldn't be tied to a single blockchain, allowing them to leverage the strengths of various networks for different aspects of their operations.

Added flexibility supports scalability, enabling a business to expand its web3 strategy without being constrained by the limitations of any particular protocol.

Bolstering security and reliability
By distributing operations across multiple networks, cross-chain applications would enjoy enhanced security and reliability. 

Imagine a robust framework where, even if one network faces downtime or security issues, the system can seamlessly switch to another, ensuring uninterrupted service.

What is the CAKE framework?

The CAKE framework provides a modular, composable approach to blockchain systems, focusing on improving interoperability and enhancing user experience in a multi-chain environment.

The framework addresses the complexities of interacting with multiple blockchain networks, such as managing different wallets, navigating cross-chain communication, and optimizing transaction workflows. It's divided into four distinct layers, all of which are necessary elements for seamless multi-chain interactions.

Laying the groundwork for a standardized approach to cross-chain interactions. A clear, modular structure empowers developers to build on a consistent foundation, promoting uniformity and interoperability among diverse blockchain systems.

This initiative marks a significant step towards creating a unified experience, setting the stage for broader adoption and more seamless interactions across networks.

CAKE Working Group

The Cake Working Group is a industry collaboration to accelerate the development and adoption of Chain Abstraction through the CAKE framework. The cake is real.

CAKE Working Group

By abstracting the technical complexities and optimizing multi-chain operations, we're stepping closer to a more connected and seamless blockchain ecosystem. This shift towards user-friendly blockchain solutions holds the promise of broadening adoption and fostering a digital environment where innovation and inclusivity can thrive.

Together, we are paving the way for a future where blockchain's potential is fully realized, making it as straightforward and intuitive as using any conventional online service.

Join Sprinter’s run club

Set your application apart and embrace the multichain ecosystem. 

🏃‍♀️Keep up with Sprinter! Follow us on X/Twitter.

🏃‍♂️Want Sprinter in your tech stack? Join the waitlist here.

Together with Electron Labs, Sygma is integrating Spectre into Electron’s Universal Proof Aggregation layer, Quantum, enhancing the accessibility of verifiable cross-chain states, while reducing gas costs on Ethereum.

Spectre is Sygma’s blockchain coprocessor, enhancing on-chain computations with off-chain zero-knowledge proofs for speed and security. As part of Sygma's tailored security approach, Spectre integrates seamlessly to enhance scalability and privacy while maintaining trustlessness. It is currently on testnet, with the mainnet launch coming soon. 

By incorporating Spectre into its aggregation process, Electron Labs will significantly lower the gas costs associated with proof verifications on Ethereum for Spectre users. The cost of verifying a single proof, traditionally around 300,000 gas, would be reduced to about 8,000 gas.

“Super excited to partner with the Electron Team! The integration of our uniquely secure consensus and storage proofs into Quantum ZK agglayer will enable Sygma and other users of Spectre to drastically reduce costs for secure interoperability”
– Alex M, VP Product of ChainSafe, Sygma Core Contributor 

How this will look:

This integration optimizes cost efficiency and streamlines the Ethereum verification process, making it more accessible and sustainable for widespread use.

Electron Labs:

Electron is building a one-of-a-kind Superprover that is a Universal ZK-Proof Aggregator, enabling value creation of $10bn / year. Aiming to become the de facto engine for ZK-proof aggregation on Ethereum, their flagship product, Quantum, is live and currently aggregating protocols such as Scroll, Worldcoin, Loopring, and DeGate on testnet, cutting costs by 85% per proof.

“This partnership will enhance the suite of companies planning to use the Quantum ZK agglayer, reducing the costs for all by 1/n”
– Garvit Goel, CEO of Electron Labs

Website | Quantum Testnet | Twitter | Telegram

Build with Sygma

Visit us at buildwithsygma.com 🛠️

Next-generation composability and interoperability will provide applications with the features they need. Whatever solution projects have in mind, Sygma gives you the power to deploy multi-chain infrastructure quickly, lowering the entry barrier for developers and users.

Check out our documentation or GitHub to get started.

Have a question? Hop into our Discord 👋

Twitter | YouTube

Sygma is thrilled to announce that we are integrating the Sygma Protocol directly into the Tangle Network. This venture marks another step forward in Sygma’s mission of expanding network interoperability.

Following the integration, Tangle will have full interoperability with all EVM-based chains and the Polkadot ecosystem. Future connections will also be easily implemented through the Sygma framework, allowing Tangle to tap into new networks as they emerge.

What is Tangle? 

The Tangle Network is a blockchain platform that provides secure, decentralized services to and from its community of code-contributing developers. Tangle uses advanced cryptographic techniques and a unique re-staking mechanism, offering a modular infrastructure to benefit developers, restakers and off chain service operators.

Tangle's modular design lets developers build and combine service components called Blueprints, such as oracles, bridges, and zero-knowledge applications.

Developers can earn rewards by contributing Blueprints, while operators earn by staking assets and providing validator services. Tangle ensures that staked assets from any ecosystem are used efficiently, offering rewards based on secured value.

How will Sygma enhance Tangle?

With a focus on seamless cross-chain communication and asset transfers, Integrating Sygma into Tangle will unlock:

• Secure External Interactions: Sygma uses advanced cryptographic techniques to ensure integrity and confidentiality in cross-chain communications. Furthermore, Sygma will facilitate seamless interactions between Tangle and other blockchain networks. 
• Cross-Chain Asset Transfers: Sygma enables the cross-chain transfer of assets between Tangle, Polkadot, and EVM chains, expanding Tangle’s user base and the effectiveness of apps developed with its infrastructure. 
• Enhanced Developer Functionality: This feature will expand the functionality and use cases available to developers building on Tangle.

As part of this partnership, the Sygma team will actively participate in the development, integration, testing, security auditing, and ongoing maintenance/support needed for the project.

We are committed to working closely with the Tangle team to address challenges and optimize the system’s performance and security.

We aim to ensure a smooth, secure, and successful integration process.

Looking Ahead

We are excited to play a pivotal role in enhancing Tangle’s cross-chain capabilities. This integration marks a significant step towards making Tangle an interoperable and future-proof ecosystem. We look forward to an engaging and fruitful collaboration with the Tangle community!

Build with Sygma

Visit us at buildwithsygma.com 🛠️

Next-generation composability and interoperability will provide applications with the features they need. Whatever solution projects have in mind, Sygma gives you the power to deploy multi-chain infrastructure quickly, lowering the entry barrier for developers and users.

Check out our documentation or GitHub to get started.

Have a question? Hop into our Discord 👋

Twitter | YouTube

Sygma is teaming up with LayerEdge to create the first hybrid trust minimized multi-party computation (MPC) based bridge for Bitcoin. The bridge will allow users to transfer their BTC and inscriptions directly between Bitcoin and LayerEdge.

The first trust-minimized Bitcoin bridge

To prevent a single entity from controlling the critical signing key, the bridge uses a federated MPC approach for validating bridging requests. The key is created collectively through a secure ceremony by multiple relayer agents, so it never gets fully assembled in one place, avoiding vulnerabilities and single points of failure.

Instead of relying on traditional methods, like multi-sigs, relayers participate in the MPC ceremony for each bridging event. This method allows distributed computation on secret inputs without revealing outputs, providing a secure foundation for cross-chain transactions and data transfers. 

The current relayers include ChainSafe, Bware, Phala, Blockops, Sygma, & LayerEdge Foundation.

LayerEdge

LayerEdge uses Bitcoin's built-in security to support BTCFi for native assets and inscriptions, creating a utility-driven ecosystem. As an Optimistic Rollup on Bitcoin, LayerEdge improves functionality with its unique Hybrid Modular Data Availability (DA) layer, ensuring data is verified and validated directly on Bitcoin. This Hybrid Modular DA also allows other Bitcoin Layer 2 solutions to use Bitcoin for data verification and validation while storing data on any existing DA layer. This method strengthens data integrity and offers flexibility for different data storage needs.

Sygma

Sygma is a cross-consensus interoperability protocol, enabling general message passing, asset transfers, non-fungible tokens, and decentralized finance. Sygma’s initial framework, Chainbridge, was also the chosen bridge behind the launch of Avalanche’s official Avalanche-Ethereum bridge. With a focus on increasing interoperability, Sygma aims to enable users to leverage the unique benefits of multiple networks.

Our collaboration with LayerEdge marks a significant step forward in Sygma’s mission of enhancing interoperability by improving the security and efficiency of cross-chain transactions within the Bitcoin ecosystem.

Build with Sygma

Visit us at buildwithsygma.com 🛠️

Next-generation composability and interoperability will provide applications with the features they need. Whatever solution projects have in mind, Sygma gives you the power to deploy multi-chain infrastructure quickly, lowering the entry barrier for developers and users.

Check out our documentation or GitHub to get started.

Have a question? Hop into our Discord 👋

Twitter | YouTube