AMM vs Protocol-Managed Liquidity walked through two common ways perp DEXes source liquidity today: passive LP pools that act as counterparty capital, and protocol-managed systems where execution and settlement happen at the protocol layer, referencing oracle pricing instead of pool depth.
A third model has been taking shape on Solana over the past year, and it's worth understanding on its own terms. It's called PropAMM — short for Proprietary AMM — a market structure category formalized in Jump Crypto research, not a single product. It swaps passive, crowd-sourced LP capital for a professional market maker running its own privately-operated pricing engine.
What PropAMM Actually Is
In a passive AMM (Uniswap-style), price is set by a public formula — x × y = k — and anyone can deposit capital to become a liquidity provider. In a PropAMM, the liquidity comes from a single professional market maker's own inventory, and the pricing logic itself runs off-chain, privately.
The mechanical pattern looks like this:
- Off-chain pricing engine. The market maker's system watches centralized exchange order books in real time and computes a price.
- High-frequency, low-cost updates. According to Ellipsis Labs' published architecture, price updates target a cadence of roughly every 100 milliseconds. Each update carries only a small signed payload, which the design intends to reduce on-chain update overhead relative to a full swap transaction.
- On-chain execution only. The chain's job is narrow: verify the signed price update and settle the trade against it. The pricing model that produced that price isn't visible on-chain.
- No external LP pool. There's no crowd-sourced pool a trader is transacting against — it's a single market maker's own capital, managed as proprietary inventory.
This is a meaningfully different design from both an AMM and a protocol-managed virtual liquidity architecture. An AMM sets price from a public, on-chain formula. A protocol-managed system like LeverUp's VMMV references a public oracle feed. A PropAMM sets price from a private, off-chain model whose full logic isn't publicly visible on-chain.
Two Different Questions, Not One Ladder
Before comparing the three side by side, it's worth being precise about what each one is actually answering, because they don't all sit on the same axis.
A perp DEX has to answer two separate questions: who quotes the price and updates it, and how execution, settlement, and risk management get handled once a trader's position is open. In a passive LP pool, one thing answers both — the pool sets the price (via its ratio) and the pool's capital is the counterparty. In a PropAMM, those two questions start to pull apart: the market maker's private engine is what's actually being upgraded — how the quote is produced and updated — and that market maker's own inventory happens to be what sits on the other side of the trade, largely because Solana-based PropAMM implementations today concentrate liquidity provision in a single professional operator rather than a crowd. Protocol-managed liquidity, by contrast, is defined by the second question first: execution, settlement, and risk management are handled at the protocol layer, with pricing handled separately by referencing a public oracle feed.
Put differently: PropAMM is best understood as a liquidity-provisioning and quoting architecture — it's an answer to "who quotes, and how." Protocol-managed liquidity is best understood as an execution, settlement, and risk-management architecture — it's an answer to how those functions are handled at the protocol layer. They're not strictly the same kind of thing, even though it's useful to compare them side by side. The table below groups them for that comparison, not to imply they're interchangeable rungs on one ladder.
How the Three Models Compare
| Dimension | Passive LP Pool | PropAMM | Protocol-Managed Liquidity Model |
|---|---|---|---|
| Liquidity source | Crowd-sourced external LP capital | Single professional market maker's private inventory | Protocol-managed virtual liquidity architecture; execution and settlement are handled at the protocol layer |
| Pricing logic | On-chain formula (pool ratio) | Off-chain, privately operated | Oracle-referenced, publicly verifiable |
| Capacity constraint | Bounded by LP capital deposited | Bounded by one market maker's inventory and risk appetite | Open interest scales with protocol risk parameters rather than with the size of an externally supplied LP pool |
| Transparency of pricing | Fully on-chain and verifiable | Pricing model itself is not visible on-chain | Oracle feed is public; pricing source is verifiable |
| Execution and settlement responsibility | LPs collectively | The market maker operating the system | Sits at the protocol layer |
None of these is a strict upgrade over the others, and the category boundaries aren't perfectly clean either — a design like GMX's, for instance, already combines LP capital with oracle-referenced pricing, so it could reasonably be filed under "oracle-based liquidity" too. Treat these three as useful shorthand for comparing real tradeoffs, not a rigid taxonomy.
Phoenix Perpetuals: PropAMM Applied to Perps
Ellipsis Labs — the team behind Phoenix, an earlier on-chain order book on Solana — has been building out the PropAMM model for spot trading through a product called SolFi, and is now extending the same architecture to perpetuals with Phoenix Perpetuals.
The spot track record is the reference point they point to: according to a March 2026 execution analysis examining roughly 20 million SOL/USDC and SOL/USDT trades, the reported median execution price was within 0.72 bps of the study's benchmark CEX midpoint, and 91.9% of trades cleared inside the study's stated comparison threshold against a CEX institutional-tier quote. Ellipsis Labs' stated goal for Phoenix Perpetuals is to bring total execution costs toward a 3–5 bps range — closer to what a centralized venue like Binance charges.
Worth being precise about what that comparison does and doesn't show. The cited analysis suggests this implementation narrowed the measured spread gap for the markets and period studied — it doesn't establish the same result for every PropAMM implementation, and it isn't the same as recreating CEX market structure generally. Large centralized exchanges generally aggregate quotes from many participants competing simultaneously, often at substantially lower latency than blockchain-slot-based systems allow; a PropAMM's price today typically comes from one professional operator without that same breadth of competing quotes. PropAMM can narrow the execution-quality gap with centralized venues in the cases it's been measured; it doesn't reproduce the market structure that produces CEX pricing in the first place.
Technically, closing that gap required solving a problem that's specific to Solana: without guaranteed ordering, a market maker updating a quote has no assurance that update lands before someone trades against the old price. Phoenix Perpetuals states that its transaction-level design is intended to prioritize quote updates relative to incoming trades, addressing the problem at the protocol layer.
The Open Question PropAMM Raises
Any system where the pricing logic is privately operated and off-chain raises the same structural question, independent of which team is running it: a trader can verify the execution result on-chain, but can't independently verify that the pricing model that produced it was fair in that moment. That's a different trust assumption than a public formula or a public oracle feed, and it's one the market is still working out — through track record, reputation, and increasingly through third-party analysis of execution data across the category.
This isn't a flaw unique to any one implementation — it's the structural tradeoff that comes with moving pricing off-chain and into a professional market maker's own system in pursuit of tighter spreads and lower update costs.
Where LeverUp Sits
LeverUp uses a protocol-managed virtual liquidity system powered by the VMMV, where trades reference oracle pricing while execution, settlement, and risk management are handled at the protocol layer. That places it closer to the "Protocol-Managed Liquidity Model" column above than either the passive-LP or PropAMM model: pricing comes from Pyth Pro's public oracle feed rather than pool depth or a private off-chain model, and open interest scales with protocol risk parameters rather than with a single market maker's inventory.
Worth stating plainly, given how easy it is to blur the two: LeverUp is not a PropAMM. Its pricing question and its execution/settlement question are answered by two different, separate parts of the architecture — a public oracle feed answers "what's the price," and the VMMV handles execution, settlement, and risk management at the protocol layer. A PropAMM collapses both questions into one operator's private engine. LeverUp deliberately keeps them apart.
The tradeoff runs the other way, too: a protocol-managed system depends on oracle quality and robust protocol-layer execution, settlement, and risk controls, the same way a PropAMM depends on its operator's pricing model holding up and an LP pool depends on LP capital staying put. For the full mechanical breakdown of how LeverUp's model works, see LeverUp Mechanism Explained and AMM vs Protocol-Managed Liquidity.
Three Models, Three Bets
Passive LP pools bet on crowd-sourced capital and public pricing formulas. PropAMM bets on professional market makers and private pricing models, accepting lower model transparency in pursuit of tighter spreads. Protocol-managed systems bet on public oracle feeds and open interest that scales with protocol risk parameters rather than the size of an externally supplied LP pool.
None of these has "won" — they're live, concurrent experiments in on-chain market structure, largely playing out across different chains for different structural reasons. For more on why that's happening specifically on Monad, see Monad Perps Landscape.
It's also worth naming the possibility that the next step isn't a fourth standalone model, but a hybrid of the last two — since they're already answering different questions, there's nothing stopping them from being combined. A protocol-layer risk engine handling margin, liquidation, and settlement, paired with a PropAMM-style engine handling quoting and pricing, would split those two questions across two specialized layers instead of asking one architecture to answer both. Whether that combination shows up in practice, and who builds it, is an open question — but the two-questions framing above is exactly why it's a coherent one to ask.
Trade on LeverUp: app.leverup.xyz