PMVS: Prediction Market Vault Standard
Vault shares backed by prediction-market positions are priced from order books the chain never sees. PMVS is our pre-EIP draft standard for making every published number reproducible by anyone.
A vault that trades prediction markets has an awkward relationship with the chain it lives on. Its share is an ERC-20. Its deposits and withdrawals are transactions. But the prices that decide what a share is worth sit in an order book on Polymarket's servers, and the chain never sees them.
We ran into this while building ZEIT. The share token, the request queue, and settlement all live onchain. Net asset value does not. It comes from a backend that reads venue books, rebuilds custody from chain history, and marks every position. Holders had to take its output on faith.
PMVS, the Prediction Market Vault Standard, is our attempt to remove the faith part. It is a pre-EIP draft covering custody, valuation, and asynchronous settlement for ERC-20 vault shares backed by prediction-market positions.
Why wrap positions in a vault at all
A winner-take-all outcome token pays one unit of collateral or nothing, then stops trading. It gets redeemed or becomes worthless. A strategy that rolls capital from resolved markets into new ones would otherwise hand investors a fresh token every few weeks. A vault share survives those resolutions: one stable address that wallets, AMMs, and lending markets can integrate while the portfolio underneath turns over.
That convenience creates the pricing problem. The moment positions live inside a vault, someone has to say what the whole thing is worth, and on the largest venues the inputs to that answer are offchain.
Without disclosure rules, a holder is trusting three separate layers at once: that every custody account was declared, that the marks came from real order books at the stated time, and that settlement applied the arithmetic it claims. None of the three is visible from the chain, and a wrong number in any of them quietly reprices everyone.
The batching part of the answer is not new. ERC-7540 standardizes asynchronous vault requests, and regulated funds have long aligned redemptions with asset liquidity through periodic dealing. What did not exist was a standard for proving what happened inside each batch. That is the part PMVS adds.
Can anyone check what a share is worth?
This was our test for the whole design. Our answer: yes, after the fact, from public data. Nobody has to take the operator's word for it.
To be clear about what that buys: the standard does not stop an operator from publishing a wrong price. It makes a wrong price provable. Each epoch, the backend must publish its valuation method and the exact frozen inputs it used: pinned chain blocks, raw venue responses with their hashes, every custody account, every position mark. The price commitment goes onchain next to a hash of that evidence. Anyone can retrieve the inputs, rerun the method, and compare.
The design splits the vault into two parts with one narrow seam. The onchain contracts hold requests, issue and burn shares, and fund claims. They never query a venue. The offchain backend finds every asset, computes NAV, and proposes a settlement batch. It never touches user funds. The only thing that crosses the seam is a price commitment: epoch, price, evidence hash, expiry. Swap the backend for a different engine, a different venue, or fully onchain data, and the share contract does not change.
One epoch, start to finish
Requests do not settle instantly, and that is a choice. Prediction-market books are thin; Polymarket's own docs warn that a large order can move the price significantly. A vault that sold positions on every withdrawal would pass that impact to its holders. So PMVS batches. Users queue deposits and withdrawals, the backend freezes one snapshot and proposes one price, and the whole batch settles together.
Batching also nets flows. Say an epoch has 100 in deposits queued and 80 in withdrawals. Incoming cash funds the 80 on its way in, and the strategy only has to deploy the net 20. Nothing gets dumped into a thin book to raise exit cash.
The settlement transaction, the roll, is deliberately rigid. It reloads every request from storage, so calldata cannot rewrite amounts, and it settles only against the stored price commitment, never a caller-supplied one. The contract computes each output, checks the Merkle roots and totals, mints and burns, and lands every owed amount in a reserved claim pot; a single mismatch reverts the lot. Withdrawals become Merkle claims against that funded reserve, a pattern we adapted from Uniswap's MerkleDistributor, so a funded claim stays payable through pauses, configuration changes, and even a vault wind-down. In the request-liveness mode meant for production, queued requests also carry deadlines; once one passes, anyone can trigger the refund or the delivery, not just the operator.
Checking the operator's math
Every meaningful action produces a signed record: configuration, valuation, settlement, retirement. Each record is canonical JSON with a content hash, each hash is anchored onchain in sequence, and each record names the hash before it. Independent watchers can anchor their own observation streams next to the vault's.
A verifier walks that chain backward. Retrieve the bytes, reproduce the hash, check the signature and order, then redo the work: rebuild custody from the pinned blocks, reprice every position from the captured books, recompute NAV and the price per share, and compare against what settled.
The rules are strict about failure. Missing data never counts as zero. An unverifiable record does not just fail alone; every record after it is treated as unproven until someone publishes a correction. Honest operators produce receipts. Dishonest ones produce evidence.
What PMVS does not do
We want the limits stated as plainly as the mechanism. An operator can still publish wrong numbers; you can prove they were wrong afterward, and nobody is stopped in time. Verification only sees declared custody plus public chain data, so value hidden on an undeclared account is invisible. Venue prices arrive through APIs whose bytes the standard cannot authenticate end to end. And detection is not built in: a person or a service has to actually run the checks. Prevention, challenges, and recourse are reserved as future work under a separate name, PMVS-CHALLENGE, so nobody mistakes v1 for them.
Where it stands
PMVS is public as a pre-EIP review draft: a core specification, a settlement part, a valuation profile, venue and storage profiles for Polymarket and Arweave, machine-readable schemas, and byte-exact test vectors. ZEIT's first production deployment predates the final wire format and is documented as such inside the spec. Everything is CC0.
We are looking for the kind of readers who try to break specifications. If that is you, start here: