Anderson
If you look at Solana over the past few months, almost every major liquidity pair shares one common pattern: most of the volume is flowing into Proprietary AMMs (Prop AMMs). Over roughly the last 60 days, total daily trading volume across Prop AMMs has held above $1 billion ,for SOL/USDC specifically. Prop AMMs frequently capture more than 60% market share and have peaked around 86% on some days. This is a clear signal that Solana’s liquidity structure is being rebuilt around a new model.
For a CTO or Web3 founder building products in DePIN, RWA, or AI Agents – especially systems that depend heavily on on-chain liquidity – the key question is no longer “Are Prop AMMs worth paying attention to?” but rather: if high‑quality liquidity on Solana is increasingly consolidating around Prop AMMs, what architectural adjustments does my product need in order not to fall behind? To answer that, we need to stop thinking of Prop AMMs as a “better Uniswap” and start treating them as an entirely different architectural primitive, born at the right time, on the right infrastructure, within the right market structure.
When DeFi first emerged, traditional AMMs – like Uniswap v2 and v3 being the canonical examples are solving the problem of permissionless liquidity very well. Conceptually, they behave like vending machines: prices are defined by a fixed formula, most commonly (x * y = k), liquidity is provided passively by a crowd of LPs, and the pricing curve only moves when trades pass through. No one “sits and watches” to decide how prices should be adjusted in real time; everything is encoded in the formula.
This model is good enough for the early stage, but from the perspective of a professional market maker, its limitations are obvious. You cannot encode complex inventory‑management strategies, you cannot adjust spreads flexibly according to market conditions, and you cannot react quickly to sharp market moves when all you have is a static equation and a large amount of liquidity “sleeping” on a curve. Whenever the market moves, you are essentially standing still, waiting to be picked off by smarter order flow.
Prop AMMs follow a very different philosophy. Instead of letting a passive crowd of LPs dump capital into a shared pool, each **Prop AMM **is operated by a single professional market maker, using their own proprietary capital. The entire trading logic – previously running on private servers in finely tuned engines – which mean it is pushed directly on‑chain as a Solana program plus a pricing curve that can be updated continuously. If you think of traditional AMMs as vending machines with fixed price boards, a Prop AMM is like a high‑frequency trader sitting in front of multiple monitors, constantly updating quotes – except the engine is plugged directly into Solana’s runtime instead of a private rack of servers.
From a computational‑complexity standpoint, this is a step change. On a traditional order book, updating quotes means canceling and replacing many orders; the cost scales with the number of orders, i.e. O(N). A Proprietary AMM, by contrast, represents its entire quoting state as a mathematical pricing curve; to change strategy, the market maker only needs to tweak a handful of parameters, turning the problem from O(N) into O(1). That enables them to quote tighter spreads, concentrate liquidity closer to the oracle price, and achieve much higher capital efficiency than passive AMMs with the same amount of capital. This is the first reason Prop AMMs have a natural edge in capturing market share – but for them to truly dominate, they also need the right infrastructure. That’s where Solana comes in.
Prop AMMs are not a neutral DeFi pattern that you can trivially port to every chain. They are a Solana‑specific primitive because only on Solana do three critical factors line up: cheap updates, favorable execution prioritization, and an architecture that is close to real‑time systems.
First, Solana doesn’t just make swaps cheap; more importantly, it makes price updates extremely cheap. Lightweight oracle‑update transactions in systems like HumidiFi consume on the order of 143 Compute Units, more than 1,000 times less than a typical aggregator swap. In practice, that means market makers can update their pricing curves at very high frequencies without being crushed by costs. If you are used to designing real‑time systems, you will recognize this as the condition where you can treat price updates as a continuous control plane rather than rare, expensive events.
Second, Solana prioritizes transactions based on the Fee / CU ratio. When an oracle‑update transaction uses very few CUs, adding a small tip is enough to give it an extremely high Fee/CU ratio and push it to the front of the Jito auction queue. The result is a cheap form of on‑chain “cancel priority”: Prop AMMs can refresh their quotes before taker buy/sell transactions are executed. This directly reduces the risk of adverse selection – being hit on stale quotes after the market has already moved – and allows market makers to run extremely tight spreads while keeping risk within acceptable bounds.
Third, Solana’s architecture allows multiple updates within a single slot, unlike the more discrete block‑based model of many EVM L1s/L2s. A Prop AMM such as HumidiFi can update its state dozens of times per second. At that point, a smart contract is no longer a piece of code that is “occasionally called”; it is effectively a real‑time market‑making engine living inside the chain’s runtime. These three elements – cheap updates, effective cancel priority, and a continuous architecture – combine to make active liquidity not just “nice to have” but the naturally optimal configuration. In that environment, Prop AMMs outcompeting passive AMMs is not a surprise; it is the logical outcome.
Even a perfectly designed Prop AMM engine is useless without sufficient, suitable order flow. This is where Solana’s market structure – dominated by aggregators, especially Jupiter – becomes strategically important for Prop AMMs.
On Solana, more than 40% of total DEX swap volume flows through aggregators, and Jupiter is by far the dominant player in that layer. For many Prop AMMs, the share of volume coming from aggregators is almost total: around 99.2% of volume on GoonFi, 97.3% on ZeroFi, 92.5% on Orbic, and 88.4% on SolFi is routed by aggregators. This creates a very clear reality: instead of having to source flow piecemeal from many wallets, dApps, and front‑ends, a Prop AMM can integrate once with Jupiter and instantly tap into a large stream of non‑toxic retail order flow across the entire network.
The flow Jupiter provides has two crucial characteristics. First, it is predominantly retail flow, not razor‑sharp HFT or pure arbitrage strategies that specialize in hunting mispricing. Second, Jupiter’s goal is to optimize best execution for end users, not to shield or favor any particular AMM. Together, these two factors create an ideal environment:
Prop AMMs can quote extremely tight spreads – in the 0–0.5 bps range for major pairs like SOL/USDC – while Jupiter, as a super‑aggregator, continually prefers whichever route offers the best price. The better a Prop AMM quotes, the more volume it receives; the more volume and fees it earns, the more room it has to refine its strategies and tighten spreads further. A classic positive flywheel emerges around a well‑tuned system.
At a deeper layer, Jupiter also acts as a structural “gate.” Integration with Jupiter is permissioned: the team evaluates code quality, security audits, product traction, and team capability before opening up order‑flow distribution. Prop AMMs that meet this bar become part of the default routing universe; those that do not are effectively pushed to the margins. To end users, Prop AMMs are almost invisible; they just see a familiar swap interface, while Jupiter silently chooses the optimal route, with Prop AMMs being one of the destination venues. Architecturally, this is a legitimate choke point: a trusted routing layer at the top that can heavily shape the liquidity landscape underneath.
From the vantage point of a CTO or Web3 founder leading a small team on Solana, what is happening around Prop AMMs and Jupiter is not a one‑off DeFi fad; it is a meaningful architectural signal. The first thing to accept is that “good” liquidity – deep books, tight spreads, low slippage suitable for serious products – on Solana will increasingly migrate toward Prop AMMs. When you design your system, you should treat the Prop AMM + Jupiter combo as the default liquidity anchor unless you have extremely strong reasons to maintain a separate venue.
Second, the old mental model of “community LPs + passive AMMs” is no longer sufficient as the only baseline. For use cases that demand CEX‑like execution quality – real‑time payments in DePIN, RWA transactions where price integrity is critical, and so on – you should think of Prop AMMs as a new type of liquidity backend that coexists with Uniswap‑style AMMs rather than as a linear upgrade of them. Your routing design, price‑syncing strategy, and fallback mechanisms should be built with that distinction in mind from day one.
Third, if you are considering building a new DEX or liquidity venue on Solana, competing head‑on with Prop AMMs will be extremely challenging, not just technically but structurally. You would need to convince aggregators such as Jupiter to route meaningful volume your way, secure differentiated order flow, and simultaneously build a market‑making capability strong enough to exploit Solana’s architectural advantages as well as existing Prop AMMs already do.
Finally, for systems in DePIN, RWA, or AI Agents where on‑chain prices are not just for display but feed directly into business logic, leveraging Prop AMMs as a dynamic, near‑real‑time reflection of market conditions can be a material advantage. At the same time, you must consciously design escape hatches: graceful‑degradation paths when Jupiter or a major Prop AMM has issues, secondary routing through passive AMMs, and clear risk limits around dependency on a small number of venues.
From a systems‑architecture perspective, no model is free of trade‑offs, and Prop AMMs are no exception. One of the most uncomfortable aspects for those who grew up with the “code is law” ethos is the opacity of this model. Most Prop AMMs behave as black boxes: pricing strategies, swap logic, and how they react to edge conditions are typically not disclosed in detail. Downstream users and systems see only the final quotes and executions; most of the logic remains out of view.
On top of that, the concentration of liquidity and order flow in a small set of Prop AMMs and a handful of key aggregators such as Jupiter introduces a form of re‑centralization at the execution layer. Everything still runs on‑chain, but structural power – who gets volume, who appears as the default route – tilts toward a few entities. From a product perspective, this is not inherently bad: users enjoy better execution, and developers gain access to a stronger primitive. But as a system designer, you need to see this dependency clearly instead of betting your entire architecture on the assumption that “these actors will always behave perfectly.”
There is also the risk of ripple effects when a Prop AMM or Jupiter itself experiences a failure: a routing bug, an oracle issue, or some misconfiguration in a market‑making strategy. In a structure where a large share of volume flows through a single distribution channel, failures rarely stay localized; they propagate as systemic side effects. That is why, when you adopt Prop AMMs as a liquidity backend, you should explicitly design multiple fallback paths: routing through passive AMMs when necessary, enforcing conservative slippage thresholds, and preserving the ability to detach your product from any single venue when something goes wrong.
The key is to stop viewing Prop AMMs as a “better Uniswap” and instead treat them as a separate primitive with its own constraint set and trade‑off surface. If you see them only as a natural upgrade to existing AMMs, you are likely to underestimate both their power and their risk. If, instead, you treat them as a new generation of liquidity backend, you will naturally design with wider safety margins, and you will be more inclined to build monitoring, alerting, and fallback mechanisms from day zero.
The current dominance of Proprietary AMMs on Solana is not the by‑product of a clever marketing campaign or a temporary incentive program. It is the result of three tightly aligned architectural choices: an underlying chain that makes price updates cheap and fast; a market‑making model that moves trading logic from off‑chain to on‑chain, leveraging O(1) updates instead of O(N); and an aggregator layer – with Jupiter at the center – that funnels a large stream of non‑toxic retail order flow toward whichever venues deliver the best execution.
If you are building serious products on Solana, the question is no longer “Will Prop AMMs stick around?” but rather: how will you design your system so that it can both leverage Prop AMMs as a next‑generation liquidity primitive and still control the dependency and opacity risks that come with them? The more honestly and concretely you answer that question, the closer your product will get to the “fast but clean” standard – fast enough to keep pace with Solana’s rate of innovation, yet clean and robust enough to survive market shocks without collapsing under a naïve architectural assumption.
Looking to build a large-scale indexer capable of handling millions of on-chain events and queries per second — without sacrificing speed, cost efficiency, or reliability?
If you want to look for ways to implement a Large-scale Prop AMM into your business but aren’t sure where to begin, connect with us. With 5 years of experience and 60+ projects worldwide, Cyberk can plan, develop, optimize - from pivot to MVP in 30 days!
Contact us and transform your business today!