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.