Jupiter's Limit Order v2 Traded Blockchain Guarantees for Privacy. Here's the Bill.

Jupiter JUP$0.188-3.5% published the second installment of its Limit Order v2 engineering series on June 18, a technical account of what it costs to move order state off-chain and what you have to build when the blockchain stops being your safety net.

The post, titled "LOv2 Part 2: Correctness Under Failure," follows Part 1 from June 3, which covered how LOv2 solved the price monitoring challenge by replacing per-pair exchange rate polling with a USD-denominated push stream. Part 2 is about the harder problem: once your order state is no longer on-chain, how do you guarantee that orders execute correctly when processes crash, RPC calls drop, and a Solana transaction might have confirmed while your service was mid-restart?

What LOv1 Got for Free From the Blockchain

In v1, the Solana program was the state machine. Every order creation, fill, and cancellation was an on-chain instruction, and the program enforced that each instruction either fully succeeded or fully reverted. The off-chain keeper (the service that monitored prices and submitted fill transactions) was stateless by design. If it crashed, it restarted, re-read the chain, and resumed from exactly where the state was. As Jupiter's engineering blog puts it: "The truth was never in memory. It was on-chain, and the chain doesn't forget."

That architecture gave v1 three properties for free: durability (orders survive crashes), atomicity (actions fully succeed or fully revert), and idempotency (retries don't create duplicates). The Solana Virtual Machine enforced all three. The keeper didn't have to.

The Privacy Trade-off That Made Correctness Jupiter's Problem

LOv2 moved order state off-chain to close an information leak. In v1, every open order was visible on the public ledger: trigger price, order size, input token, output token. Anyone watching with an RPC endpoint could reconstruct the full order book and trade against known price levels.

In LOv2, the critical details live in Jupiter's database rather than on-chain. Observers can see that a deposit of a given amount and input token was made, but not whether the user is selling at $200 or $2,000, or what the output token is. That is enough to prevent order book reconstruction and front-running.

The cost was immediate. Taking order state off-chain meant forfeiting every guarantee the on-chain program had been quietly providing.

Durability: A 19-State Machine in the Database

Every order in LOv2 is modelled as an explicit state machine with transitions stored in the database. The lifecycle covers nineteen distinct states, each with defined valid transitions enforced at the schema level, according to the Jupiter engineering blog. The database cannot move an order from "open" to "withdrawn" without passing through the intermediate states; invalid transitions are rejected by schema invariants rather than by application code that might have a bug.

To isolate failures further, Jupiter replaced shared token accounts with seeded accounts. Each order now has its own deterministic account created at deposit time, so a misread on one order's balance cannot cascade across every order sharing an input token.

Atomicity: Anchoring on Deterministic Signatures

Solana transaction signatures are deterministic, derived from the transaction content and the signer's key, so the signature is known before the transaction is broadcast. Jupiter uses this as a crash-recovery anchor: before submitting any transaction to the network, the system writes the signature to the database. If the process crashes after signing but before submission, the signature is there. If it crashes after submission but before confirmation arrives, the signature is still there.

On restart, the system checks each persisted signature on-chain. A landed transaction advances the order's state. A failed landing resets for retry. A signature with no chain record may still be in flight. A blockhash-expired signature (Solana transactions have a validity window of approximately 151 blocks, or around one minute, per the blog) is definitively dead, and the order can safely be retried.

When a Request for Quote is used, a market maker holds the final signature. Jupiter cannot pre-persist what it doesn't sign. Instead, the system persists the quote identifier before handing off the fill and reconciles against the quote's status and the chain on recovery. The principle is the same: never act on an order without first resolving what has already happened on-chain.

Idempotency: Action Identifiers as the Retry Gate

Every action (deposit, execution, withdrawal) carries a traceable action identifier. Duplicate requests find and continue the existing action rather than creating a new one. For deposits specifically, if a user's client loses connectivity after submitting the on-chain transfer but before receiving confirmation, a retry finds the existing in-progress deposit and re-confirms it inline rather than queuing a background job. The user gets an immediate answer rather than waiting for reconciliation.

Fault Isolation: Trigger and Executor as Separate Services

LOv2 splits trigger detection and execution into two separate services that communicate through database state and event queues. The trigger system watches prices and marks orders ready for execution, with no knowledge of execution progress. The executor picks up those marked orders and carries them through to confirmation, with no knowledge of how an order was triggered.

Either service can fail and restart without corrupting the other's work. This separation also makes correctness properties locally verifiable: the trigger system's logic can be tested in isolation given a set of prices and orders, and the executor's recovery logic can be tested in isolation given a set of persisted signatures.

When the System Still Fails

The blog is candid about what the architecture hasn't fully solved. With the state machine, signature anchoring, deduplication, and fault isolation all in place, Jupiter has still had double-execution incidents: transactions that confirmed on-chain while the service failed to see the confirmation, prompting a retry that also landed. Duplicate withdrawals followed from the same class of ambiguity.

Jupiter says those specific cases have been found and fixed, but draws a broader conclusion: continuous verification that cross-references database state against on-chain reality is now a permanent part of the system. They expect it to keep finding discrepancies.

LOv2 and Solana's Broader Privacy Infrastructure Arc

Jupiter's engineering series lands at a moment when privacy is becoming a live infrastructure question across Solana DeFi. As we covered when Helius acquired Light Protocol to build Solana's programmable privacy layer, the work of building privacy into the chain's application layer consistently proves more expensive than it looks from the outside. LOv2's experience is a concrete illustration of that cost: hiding order details from the public ledger required replicating, in software, a set of guarantees that the Solana runtime had been enforcing automatically.

The series has a third part teased. Jupiter's blog describes it as covering the "conceptual shift that made all of this worth it: how rethinking what an order means, from barter ratios to prices, unlocked capabilities that the old model couldn't even express." Both parts of the published series are available at developers.jup.ag/blog.