# How a reveal is verified Every Peal reveal can be checked by anyone, in a browser, without trusting the server that produced it. Here is exactly what is checked, how, and where the limits are. ## The short answer Every reveal publishes the evidence needed to recheck it: every operator's decryption share, each of which must satisfy a public pairing equation; an ordering that is a function of the ciphertexts; and a merkle root over the result. It is direct cryptographic evidence rather than a zero-knowledge proof. Taken together they show that a threshold of the committee opened the batch, and that the published payloads are the ones that were sealed, in an order nobody chose. ## What you can check, and how claim the evidence what it rules out the committee opened it each 48-byte share satisfies a pairing equation against the batch headers and that operator's public verification key a coordinator inventing a reveal without three real operator shares each payload is what was sealed after opening, every slot passes the Fujisaki-Okamoto re-encryption check, or is marked invalid on its own a payload swapped for one that does not match its ciphertext this seal is in this batch a seal's id is the SHA-256 of its ciphertext, and the merkle root covers every (position, payload) leaf a seal quietly dropped or added after the fact nobody chose the order positions are the ciphertexts sorted by hash, and the ordering root is written when the batch freezes, before any operator gets work a coordinator reordering a batch to favour someone You do not have to take the table on trust either. Open any opened round in the explorer and it reruns the pairing check on every operator share in your browser, recomputes the hash order, and reads the anchored root straight from the chain's public RPC rather than through Peal. Where a check cannot be anchored to something the coordinator could not fake, the page says so instead of showing a green tick. `GET /v1/seals/{id}/proof` returns the same facts for your own seal. ## The limits - **That nobody read it early.** No proof can show that three operators did not collude before the deadline; that is the threshold assumption itself. Peal's key shares are distributed among five operators, run by Peal during testnet, and in [v1](https://peal.network/developers/roadmap) they come from a distributed key generation. - **When the order was fixed, cryptographically.** `commitment_precedes_reveal` compares two timestamps the coordinator writes. It is a consistency signal. The on-chain anchor is what turns it into something firmer, when a root is anchored. - **Which committee you encrypted to.** The client compares the parameters' digest with one the same coordinator serves. Pin the digest out of band if it matters, and in v0 a ciphertext is not bound to its round, so a sealed blob can be replayed into another one. ## On chain Two contracts carry reveals on chain today, and neither verifies pairings. `BteAnchor` lets anyone commit a ciphertext hash to a round and lets the coordinator publish the reveal's merkle root once; anyone can then check a revealed payload set against it. The encrypted mempool's `PealMempool.executeBatch` re-derives the merkle root from the revealed orders and refuses to settle anything else, so the swaps it executes are provably the revealed batch. In both, the coordinator is the one address allowed to publish, which is a trust assumption we state rather than hide. ## Why not a zero-knowledge proof? Because it is not needed to check a reveal: the shares are public and each is verified with a single pairing equation that anyone can run, with no extra circuit, setup or prover involved. Where a succinct proof would add something is on chain, letting a contract check a whole reveal in one verification instead of accepting the root from the coordinator's address. Peal does not have that today. ## Questions ### Is "proof for every reveal" just marketing? No. Every operator share is checked with a public pairing equation, every payload is checked against its ciphertext, and the order and set are bound by hashes and a merkle root, and the explorer reruns these checks in your browser. It is direct evidence rather than a zero-knowledge proof, and like any threshold system it cannot show that operators did not collude early. ### Does Peal attach a zero-knowledge proof to each reveal? No. The shares and payloads are verified directly. Peal Links, the private payments product, does use zero-knowledge proofs, for payments rather than reveals. ### Can I verify a reveal without trusting Peal's server? Mostly. The pairing checks, hash order and seal ids can be recomputed from public data, and an anchored root is read from the chain. The timestamps and the parameter digest come from the coordinator, and the page marks those as its claim rather than a verified fact. --- Source: https://peal.network/developers/verifying