Skip to main content
This page’s conclusion has been superseded. The constraint below is real and still worth understanding — a contract that can add ciphertexts genuinely cannot compare them. What does not follow is therefore no order book, because matching never had to happen inside the contract. See V2: sealed orders.The page is kept rather than deleted: it describes V1, which is what runs today, and the reasoning error is more useful visible than quietly removed.
Atrum V1 is a parimutuel pool, not an order book. Under the assumption that matching must happen on-chain, it is the only mechanism that works.

​
The constraint

Atrum uses additively-homomorphic encryption. Given two ciphertexts the contract can compute the encryption of their sum, without ever learning either value. That is what lets a pool total exist while individual stakes stay hidden. What it cannot do is compare. There is no operation that takes two ciphertexts and tells you which is larger.

​
Why that rules out an order book

Order matching is comparison. Is this bid at least the ask? Every matching engine ever written is built on that question. A contract that can add but not compare cannot match orders. So:
  • No order book. Matching is comparison.
  • No AMM. Pricing curves need to compare a trade against reserves.
  • Parimutuel. Everyone stakes into a pool, and winners split it pro rata. Payouts need only addition and one division at settlement — no comparison at any point.
This is why nobody has retrofitted privacy onto an existing prediction market. It is not that it would be difficult; the market design itself has to change.

​
Everyone hits this wall

Look at what private trading systems actually do:
  • Penumbra batches trades into sealed auctions.
  • Renegade matches inside multi-party computation.
  • Atrum pools.
Nobody runs a private continuous order book in production, because continuous matching leaks by construction whatever cryptography is underneath.

​
What parimutuel costs you

Being honest about the trade:
  • No live price to trade against. You stake; you do not take a quote.
  • No partial fills or limit orders. You are in the pool or you are not.
  • Odds move after you commit. Later money changes your payout, and you cannot react.
That last one is real and it is not fixed by better cryptography — it is a property of the mechanism. A bettor who is right early is diluted by money that arrives later.

​
Would FHE change this?

In principle yes. Fully homomorphic encryption permits arbitrary computation on ciphertexts, including comparison, so an encrypted order book becomes expressible. Expressible is not practical. Comparison is the expensive FHE operation, and matching one order against a resting book needs many of them. The realistic first version is a periodic batch auction, not continuous matching — which is, again, a form of batching. FHE also does not remove the need for a decryption committee. It relocates the trust; it does not delete it.

​
Where this argument actually lands

Two things above point at the answer, and the page did not follow them. Penumbra is listed as batching trades into sealed auctions. The FHE section concludes that the realistic first version is “a periodic batch auction, not continuous matching.” Both are correct, and together they describe a mechanism that needs no on-chain comparison at all — a sealed batch auction clearing at a uniform price, where the clearing price is computed off the chain and verified on it. The wall this page describes is real. It sits between the contract and continuous matching, not between Atrum and a market. V2: sealed orders is what is on the other side of it.