A September study found wider realized round-trip spreads for Solana trades routed outside aggregators at five of six major proprietary liquidity venues, suggesting that access to the same pool did not mean access to comparable trading terms.
The result puts the route into the center of the price comparison. A pool can settle trades on a public blockchain while a single operator controls its quotes. Comparing pool addresses alone therefore leaves out an important part of the transaction: how the order arrived.
The preprint by Ozan Solmaz, Lioba Heimbach and Jason Milionis, posted Sept. 29, examined proprietary automated market makers, or propAMMs, on Solana, Base and Monad. Its observations run from Sept. 1, 2025, through Aug. 31, 2026, with later starts for newer deployments. The Solana finding is a historical association between routing class and realized spreads, rather than a measurement of what every interface delivers today.
The same pool, different observed terms
An aggregator searches across liquidity venues and can split an order among them. Jupiter is one such routing provider on Solana. A propAMM is the venue supplying liquidity: one operator provides inventory and can update prices directly, without waiting for a trade to change the pool’s reserves.
The study compared aggregator and non-aggregator flow within the six largest measured Solana propAMMs for SOL/USDC. To estimate a realized round-trip spread, it paired consecutive fills on opposite sides of the same pool, within 25 slots and with trade sizes within a factor of two. There could be no intervening quote update from the operator, and both legs had to belong to the same routing class.
The researchers then compared the classes within cells defined by pool, day and trade-size bucket. That makes the test more informative than comparing unrelated venues or differently sized orders. It still pairs observed trades; the two fills need not be one customer’s actual buy-and-sell journey.
| Venue | Aggregator median spread, bps | Non-aggregator median spread, bps | Matched non-aggregator premium, bps | Cells with wider non-aggregator spread |
|---|---|---|---|---|
| HumidiFi | 0.09 | 0.86 | +0.4 | 77% |
| BisonFi | 0.71 | 1.01 | +0.1 | 76% |
| Tessera | 0.9 | 0.93 | +0.1 | 68% |
| SolFi V2 | 3.88 | 4.9 | +1.58 | 82% |
| GoonFi | 0.78 | 4.39 | +3.59 | 83% |
| ZeroFi | 1.52 | 1.5 | -0.05 | 41% |
Source: the study’s Table 1. All spread figures are realized round-trip measurements. The matched premium is the median within-cell difference; the final column counts matched cells, not trades or trading volume.
One basis point is 0.01 percentage point. The distinction between the columns matters. Tessera’s overall medians were 0.9 and 0.93 basis points, while its median matched premium was 0.1 basis points. The matched result comes from comparing the two classes inside each cell before summarizing those differences. Subtracting the displayed overall medians would answer a different question.
For the first five venues, non-aggregator spreads were wider in 68% to 83% of matched cells, with reported exact sign-test p-values below 0.001. ZeroFi went the other way on the matched median, with a small negative premium.
These are round-trip price gaps, not individual swap fees. Nor does the classification identify ordinary retail customers: non-aggregator flow can have different characteristics from aggregator flow. Matching pool, day and size reduces some differences between the groups, but it does not turn the comparison into a randomized test of what happens when the same person changes interfaces.
The economic rationale starts with stale prices. A passive pool can lose money when another trader acts on a market move before the pool’s price catches up. PropAMM operators can send price updates without executing a swap, reducing that exposure when their updates arrive before incoming trades.
That ability can benefit the operator through fewer stale-price losses. In the Solana sample, aggregator flow was also associated with tighter matched spreads at most of the measured venues.
The paper offers a more direct mechanism example on Base. In the Tessera implementation it decoded there, the researchers identified six fee components: base, age, priority, mode, default and address. The transaction sender and the contract calling Tessera’s interface can affect default and address treatment, including exemptions and penalties.
That demonstrates how a proprietary venue can make caller identity part of execution pricing. It is evidence about the inspected Base implementation, rather than proof that Tessera’s Solana deployment, or every other Solana propAMM, uses the same code or fee rules.
A separate issue is whether an attractive quote survives until settlement. The researchers documented Base Tessera fee decreases near block ends and increases near block starts, helping explain differences between the previous block’s quote and the eventual fill. They explicitly lacked historical Solana quote data to corroborate an analogous Solana quote-to-fill gap.
Aggregator 0x’s March investigation also reported Base quote-to-fill discrepancies involving Flashblock timing and spread changes. Its findings belong to that chain and to an interested routing provider’s investigation.
Wallet fees answer another question
A wallet charge can affect the amount a trader receives even when the underlying pool offers competitive terms. Phantom’s current swap disclosure, checked Nov. 2, lists a 0.85% fee for most swaps, with exceptions, alongside variable network fees. The exceptions include specified Cash-account flows and deposits to a perps balance.
That wallet fee is a different measurement from the paper’s round-trip spread. Price impact describes how an order’s own size affects its price. Slippage describes the movement between a quote and execution. A slippage tolerance sets how much deterioration a transaction permits; raising it does not create a fixed fee, but it allows a worse fill.
Jupiter’s current API documentation shows why the interface label also leaves questions unanswered. Its managed order path lets Metis, JupiterZ, Dflow and OKX compete, while its customizable build path uses Metis only. JupiterZ supplies request-for-quote liquidity, a separate mechanism from an on-chain propAMM pool.
Jupiter documents a 2-basis-point platform fee for SOL-to-stablecoin swaps on the managed order path, with other schedules for other categories. It lists no Jupiter swap fee on the build path, while integrator charges and network costs remain separate considerations.
Those disclosures describe available integrations and charges. They do not identify the route used by a particular Phantom swap or establish that a wallet avoids aggregators.
Adding a historical matched spread premium to a current wallet fee would therefore produce a misleading savings estimate. The comparison would mix a paired round-trip statistic with a charge on a particular swap, without establishing which costs were incremental or already reflected in the delivered amount.
Jupiter describes two approaches to reducing the quote-to-fill gap. Its execution-estimation account says routing incorporates observed execution data and simulation. Its JIT Swap description says candidate pools are carried into the transaction and re-quoted on-chain, allowing the selected pools or split to change when another candidate allocation offers a better output.
The useful test is therefore the completed trade: the route and venue used, the relevant charges, and the amount actually delivered under comparable conditions.