Institutional on-chain execution is increasingly constrained by market structure. Liquidity may be visible on-chain, yet realized shortfall can accumulate quickly once order size, latency, information leakage, adverse selection, and settlement uncertainty are priced into the trade.
Revaz (Rezo) Shmertz, Managing Partner at BR Capital and Co-Founder of Super Protocol and T-Digital, approaches these questions through the quantitative trading disciplines. Drawing on research and execution engineering from T-Digital and BR Labs (developer of the BRRRolver solver), he considers critical market risks: implementation shortfall, inventory risk, adverse selection, latency, and execution leakage. The same variables that determine execution quality in markets remain relevant on-chain, but they appear inside a different market structure: decentralized exchanges, public state, solver auctions, programmable liquidity, and block inclusion.
The Institutional Execution Problem
A $10 million Ethereum (ETH) sale starts behaving differently from a retail swap well before settlement. Once the order consumes meaningful depth, the desk is managing implementation shortfall rather than simply comparing displayed quotes. The relevant reference point is the market when the trading decision was made; the outcome is the average price actually realized after the order interacts with available liquidity. For a partially unfilled order, implementation shortfall can also include the opportunity cost of the portion that was never executed.
A practical cost decomposition is:
Total Execution Cost ≈ Spread + Market Impact + Gas + Maximal Extractable Value (MEV) Leakage + Failure Cost + Latency and Settlement Cost
This is better understood as an attribution framework than as a strict accounting identity. Several of these effects can overlap: latency can increase market impact, adverse selection can appear in realized spread, and MEV can affect execution through more than one channel. The purpose of the decomposition is to identify where execution quality is being lost.
Spread and market impact are standard electronic-market problems. Public-mempool execution adds another problem: unusually high pre-trade transparency. For a conventional public swap, calldata can allow automated participants to observe or simulate the trade’s direction, size, route and expected state transition before inclusion. Searchers can simulate the pending state transition, identify profitable ordering opportunities, and compete for placement before the initiating transaction settles.
For an institutional desk, that information exposure becomes part of execution leakage. Private order flow can reduce it by keeping transactions away from the public mempool and therefore removing the order from public pre-trade visibility, particularly when a large directional order would otherwise advertise its footprint.
The liquidity available to the trade remains the same only if the submission path changes and the order ultimately reaches the same liquidity sources. If a pool cannot absorb $10 million without moving the market, private submission will not add depth; the order still consumes liquidity somewhere. Private execution may also be combined with Request for Quotes (RFQs) or private market-maker liquidity, in which case executable liquidity can improve – but the improvement then comes from the additional liquidity source rather than privacy itself.
Private execution also introduces dependencies around builders, inclusion probability, and information handling inside the private path, all of which can alter realized execution. For institutional use, “MEV protected” is therefore too coarse a description on its own. Realized shortfall, fill quality, reject and failure rates, and the distribution of execution risk between the trader, solver, liquidity provider and block-building infrastructure provide a more useful record of what the protection actually achieved.
Stop Choosing the Route. Define the Outcome.
Early on-chain execution was largely imperative. A wallet or router selected pools, sequence, and slippage tolerance before the transaction reached settlement. If the market moved between submission and inclusion, the trader either absorbed the deterioration within the specified tolerance or lost the fill.
Intent architecture changes the order of operations. An institutional desk can submit a constraint set such as:
Sell 2,000 ETH before time T. Receive at least X USDC. Stay inside the permitted chain and counterparty rules. If those conditions cannot be met, do not settle.
The route remains open to competition. A solver can evaluate an Automated Market Maker (AMM), an RFQ, private inventory, Coincidence of Wants, flash liquidity, or a combination of execution paths, then submit the best valid solution it can finance and settle.
CoW Protocol is one of the clearest implementations of this model. Signed orders enter auctions, where solvers compete to construct valid settlements using external pools, private or internal inventory, compatible opposing flow, and other liquidity sources rather than treating the visible AMM quote as the entire market.
Its current architecture goes further than simple order-by-order routing. CoW uses fair combinatorial batch auctions, allowing solvers to bid on individual orders or combinations of orders and letting compatible flow clear together where the economics permit it. External liquidity can then be used for the residual that cannot be matched internally.
This changes the optimization problem materially. A router primarily asks where a trade should go. A solver has to determine which combination of orders, liquidity sources, and available capital can produce the best valid settlement under the current state – and whether that settlement can still be financed and executed economically by the time it reaches inclusion.
The difference between routing and solving became operationally important for Revaz Shmertz and the BR Labs (formerly BRRR DAO) team when developing BRRRolver, its proprietary solver, to compete in the CoW solver environment. Basic route discovery represented only one part of the engineering problem. Auction timing, MEV exposure, gas, smart-contract integration, temporary liquidity, and fill-rate decay all influenced whether a solution that looked profitable during computation still made economic sense when settlement occurred.
BRRRolver had processed more than $100 million in cumulative volume by early 2026 after launching on Base, with development extending toward Ethereum. At that level of activity, the system behaves less like an aggregator and more like an execution engine, with inventory availability, gas repricing, competing flow, and pool-state changes all capable of turning a mathematically valid route into an uneconomic fill before inclusion. A router primarily determines where a trade should go; a solver also has to determine whether the proposed settlement can still be financed and executed economically as market state changes.
1inch Fusion addresses the same execution problem through a resolver model and Dutch-auction process. Its mechanism differs from CoW, while both architectures move route selection away from a fixed instruction submitted by the trader and toward competition between execution strategies. The comparison is useful because “intent-based execution” is not itself a single auction design. CoW organizes competition through solver auctions and batch settlement, while Fusion uses resolvers competing against an exchange rate that evolves through a Dutch-auction process; both nevertheless transfer more of the execution decision from the user to specialized execution infrastructure.
MEV Protection Is Not One Product
MEV leakage originates at several points in the execution chain, so a single protection layer cannot address every cost. Private order flow, batch matching, solver competition, and temporary liquidity act on different parts of the execution problem rather than providing interchangeable versions of the same protection.
Private Order Flow
Private submission primarily addresses information exposure by reducing the period during which public searchers can structure transactions around a pending order. More precisely, it can remove the order from the public mempool altogether, although information is still handled by participants inside the private execution path. For institutional blocks, even a modest reduction in adverse ordering can preserve a meaningful number of basis points, although the result still depends on the depth of the external market that ultimately absorbs the order.
Batch Auctions and Coincidence of Wants
Batch auctions change the amount of external liquidity that must be consumed.
Assume one desk is selling $10 million of ETH while buyers inside the same auction want $5 million. If those orders are compatible in price, assets, validity and settlement constraints, sending both sides independently through AMMs creates unnecessary impact if a solver can cross the compatible flow directly. Only the residual $5 million then needs to reach external liquidity.
A smaller residual order walks less of the liquidity curve, creates a smaller toxic footprint, and gives the solver more flexibility around inventory, hedging, and route selection, while also reducing the amount of fee-bearing external liquidity required to complete the trade. The reduction in market impact will not necessarily be proportional to the reduction in notional because AMM price impact is nonlinear, but the amount of directional flow that external liquidity has to absorb has clearly changed.
Solver Competition
Solver competition adds another layer of price discovery because participants can have very different economics. One solver may hold useful inventory, another may have access to private liquidity, a third may identify a superior multi-pool path, while another can use flash liquidity to finance settlement without maintaining the same balance-sheet exposure.
All of them compete against the same signed constraint. A solver contends with more than an algorithm. The economically feasible solution set depends not only on routing logic but also on capital and market access.
Within the CoW Protocol batch-auction environment, BRRRolver, developed by Revaz Shmertz and his team at BR Labs as an institutional execution resolver engine, demonstrates how atomic borrowing alters these economics. By integrating Aave flash liquidity directly into the settlement path, BRRRolver can finance intermediate token legs during the transaction bundle itself. This eliminates the requirement for static inventory between auction rounds, expanding the set of economically clearable routes without adding balance-sheet drag. However, atomic borrowing does not create unconstrained capital: gas costs, borrowing fees, and block-inclusion timing must still clear the trade’s profit threshold before inclusion.
The broader execution work across T-Digital, BR Capital and BR Labs treats these quantitative-trading frictions in this market structure. Adverse selection, inventory risk, route decay and latency remain active execution variables: a solution that clears economically at the beginning of an auction may no longer make sense later if gas reprices, available inventory is consumed, or another transaction alters the relevant pool state. On-chain settlement does not remove latency from the problem; it changes where the economic value of speed appears.
JIT Liquidity: Changing Executable Depth
Just-In-Time liquidity belongs in this discussion for a different reason. It is not simply another form of MEV protection; it changes the amount of liquidity available around a specific trade. A provider can deploy concentrated liquidity around an incoming trade, collect fees generated by that flow, and remove the position shortly afterward. The trader may receive better effective depth, passive Liquidity Providers (LPs) may experience fee decay, and the Just-in-Time liquidity (JIT) provider assumes timing and inventory risk.
The economics depend heavily on the quality of the incoming flow. A favorable block can compensate the provider for supplying temporary depth, while toxic flow can leave the same inventory exposed to adverse selection almost immediately. The provider may also hedge the inventory acquired through the trade elsewhere, so the relevant economics include not only pool fees but also hedging, gas and ordering costs.
JIT is therefore useful for understanding why static Total Value Locked (TVL) or a pre-trade liquidity snapshot can be misleading. The amount of liquidity sitting passively in a pool before an order appears is not necessarily identical to the depth that will compete for that order once the trade becomes visible and economically attractive to liquidity providers.
Taken together, these mechanisms show why “MEV protected” is too binary a label for an institutional desk. A transaction can avoid the public mempool and still face poor liquidity; a batch can contain opposing orders that cannot clear together; a solver can identify a superior route that becomes stale before inclusion; and a JIT provider can improve depth around one trade without making the venue structurally deeper outside that trade. The useful question is therefore not simply whether execution is MEV protected, but which part of the execution process is being improved and which risks remain.
Inside a $10 Million ETH Sale
Consider an institutional desk selling $10 million of ETH into USDC. One basis point on the ticket is worth $1,000.
The figures below remain deliberately hypothetical. They are not BR Solver, BR Capital, CoW Protocol, 1inch or Uniswap performance results, and the individual cost buckets should not be read as universal estimates. The table is intended to illustrate how different execution mechanisms can act on different components of the same order rather than to claim a fixed solver advantage.
| Illustrative Execution Structure | Fees / Spread | Market Impact | Information / MEV Cost | Gas / Failure | Total | Cost on $10M |
| Public AMM routing | 8 bps | 20 bps | 12 bps | 2 bps | 42 bps | $42,000 |
| Private routing, same liquidity | 8 bps | 20 bps | 3 bps | 2 bps | 33 bps | $33,000 |
| Competitive solver execution | 6 bps | 12 bps | 2 bps | 1 bp | 21 bps | $21,000 |
| Solver + compatible partial CoW match | 5 bps | 7 bps | 1 bp | 1 bp | 14 bps | $14,000 |
The comparison is more useful if read horizontally rather than as a claim that solvers always save 21 basis points. Each row illustrates a different change in execution structure and which cost component that change can affect.
The first comparison holds liquidity constant. The same order is routed privately rather than broadcast through the public mempool, so modeled market impact remains at 20 basis points because the available depth has not changed. Information and MEV cost falls from 12 basis points to 3, retaining nine basis points, or $9,000, on the $10 million ticket. That $9,000 is simply the arithmetic implied by the illustrative assumptions; it should not be interpreted as an estimate of the typical savings from private routing.
Competitive solver execution changes the liquidity path itself. One solver may hold inventory, another may source private liquidity, and a third may identify a more efficient multi-pool route. In the example, the winning execution structure cuts modeled market impact from 20 basis points to 12, with the improvement coming from different access to liquidity rather than concealment alone.
Opposing flow changes the economics again. If $5 million of the ETH sale can be crossed against compatible buyers inside the auction, external markets only need to absorb the remaining $5 million. Market impact falls with the residual size, inventory requirements shift, and less toxic flow needs to be hedged externally. The exact reduction in impact cannot be inferred from notional alone because the relevant liquidity curves are nonlinear.
JIT would represent another possible change to the execution structure. Instead of hiding the same order, finding another route or reducing the unmatched residual, temporary liquidity can alter the depth available on a particular route at execution time. However, assigning a fixed JIT benefit to the table would be misleading because the result depends heavily on pool structure, fee tier, hedging economics and competition among liquidity providers.
No institutional desk would hard-code a fixed solver advantage before seeing the auction. Depending on volatility, pool depth and competing flow, the difference could be 7 basis points, 15 basis points or 25, and under less favorable conditions it could be substantially smaller.
Scale makes these apparently modest improvements material. A repeatable 10 basis-point reduction in implementation shortfall across $500 million of monthly notional retains $500,000 that would otherwise disappear through execution costs. For a high-turnover strategy, execution engineering feeds directly into portfolio economics.
What Solver Markets Change for Institutional Desks
The broader lesson from operating inside solver markets is that execution is becoming an infrastructure layer of its own. Liquidity discovery, financing, order matching and settlement no longer need to be bundled into a single router or venue.
A fully on-chain institutional trading stack remains unlikely, and it does not need to be the end state for solver-based execution to matter. Portfolio construction, risk controls, and much of the decision logic can remain off-chain, while specialized execution systems compete over liquidity and blockchains provide programmable settlement where the economics justify it.
That model is closer to existing quantitative markets than the usual “TradFi moves on-chain” narrative suggests. Traditional trading desks already separate the investment decision from the machinery used to execute it; solver and resolver systems introduce a similar separation, but with public state, atomic settlement and programmable liquidity added to the execution problem.
Crypto reached 24/7 trading and API-native market access much earlier. The harder part is delivering consistent institutional execution when order size increases, volatility picks up, liquidity fragments across venues and timing becomes critical. This aligns with the market structure analysis led by Revaz Shmertz across BR Capital’s digital asset framework, backed by BR Labs’ direct operating data from BRRRolver inside competitive auction venues.
For an institutional desk, headline TVL or aggregate DEX volume only tells part of the story. Implementation shortfall, stressed fill rates, route stability under higher latency, inventory toxicity and pre-settlement information leakage say far more about whether a venue can actually handle size. A market can look liquid on paper and still deliver poor execution once volatility rises, inventory gets consumed, or routing conditions deteriorate.
JIT adds a useful qualification in the opposite direction: a static snapshot can also understate the liquidity that becomes available around a valuable order. Executable depth is therefore dynamic in both directions – displayed liquidity may disappear when conditions deteriorate, while new liquidity or solver inventory may appear when an order creates an economic incentive to provide it.
This is the larger lesson from solver-driven execution. CoW’s batch auctions, 1inch Fusion’s resolver model, private order flow, flash liquidity and JIT are not competing names for the same mechanism; they modify different parts of the path between an execution decision and final settlement. For an institutional desk, the real question is not which protocol has the largest headline liquidity number, but which execution architecture can reliably convert available liquidity into acceptable realized fills when size and market conditions become difficult.
This material is provided solely for research and informational purposes and evaluates theoretical execution mechanics and market structure variables. It does not constitute investment advice, financial analysis, a trading recommendation, an offer or solicitation to buy or sell securities or digital assets, or an execution guarantee by Revaz (Rezo) Shmertz, BR Capital, BR Labs, Super Protocol, T-Digital, or their associated entities.
Revaz Shmertz — an expert on on-chain payments and market infrastructure
