# Secrets that Open Themselves [Launch App](https://peal.network/#/app) The problem ## In an open system, going first is a disadvantage. Everything you send arrives readable, so the order you send in decides what happens to you. Bid early and your number is public while the auction is still running. $4,200first to arrive $4,650second $4,400third $4,651arrives last, having read the rest every one of them legible on arrival The usual answer is commit now, reveal later. It fails the same way every time: revealing is a move, and whoever is losing declines to make it. What Peal does ## Peal holds it, and then opens it without asking anyone. A round is a moment. Everything sealed to it is encrypted in your own process, so what crosses the network is already a ciphertext. Nobody reads it early: not the other participants, not you, not the operators. $4,200sealed $4,650sealed $4,400sealed $4,505sealed unreadable until the deadline At the deadline, three of the five operators combine their shares and every submission opens at once. None of them is trusted: two together learn nothing, and every share is checked by a public pairing equation. The reveal is not a participant’s move, so there is nothing to withhold. Why this is not commit and reveal ## Nobody has to come back. Every commit and reveal scheme has the same hole. Revealing can be declined, and the person most likely to decline is the one who has just worked out they lost. _round opens__deadline_ sealed, and counting down A Peal round opens because the deadline arrived, not because anyone chose to. No reveal step to skip, no bond to slash for skipping it, no timeout branch to write. The trust model ## It takes three of five. Try it. No single operator holds a key that opens anything, and no operator is trusted. The key is distributed among five operators and takes three of them to use. Two can be offline, compromised or simply refusing, and the round still opens on time. 8f2c…a91dsealed _2 of 3 shares_ **2 of 5** is not enough. Turn on one more and it opens; it does not matter which. This shows the threshold rule. The threshold is arithmetic, so it is not a diagram. Turn operators off and watch: two never opens it, any three do. The key shares are distributed among five operators: Meridian Assay, Halcyon Registry, Northwind Trust, Ardent Notary and Vantage Archive, the five operators holding the committee's key shares. Peal runs them during testnet, and in v1 the shares come from a distributed key generation. The auction committee's signing keys are derivable from a published string, so nothing here is custody and nothing here should hold value. Why the cost does not grow ## One decryption opens _the whole batch_. A round is not opened one submission at a time. Sixty-four slots share a single threshold decryption, so a round holding sixty submissions costs what a round holding one costs. 64 slots, sealed every slot the same from outside, whether or not anything is in it The slots that carried nothing are padding, indistinguishable from the ones that did. From outside, a full slot and an empty one are the same ciphertext. Encrypted mempools ## A sandwich needs something to read. _Take it away_. A searcher reads a pending swap, buys in front of it and sells behind it. The swap fills worse and the difference is the searcher’s. It is the ordinary cost of a queue that is legible before it settles. a public mempool **buy**_in front of it_**swap 10 ETH**_readable while pending_**sell**_behind it_ filled at a price the searcher moved the same block, sealed **buy**_in front of what?_**0x7f3a…c210**_ciphertext until the block_**sell**_behind what?_ filled at the quote Peal seals the order to the block it belongs in. While it is pending it is a ciphertext, so there is no number to trade in front of. The searcher is not blocked from acting. There is nothing to act on. [Get sandwiched, then don't](https://peal.network/#/encrypted-mempool)[How the sealed lane works](https://peal.network/mempool) The demo is not a drawing. Both pools are real contracts on a public testnet, the searcher is a real bot, and the sealed order settles through `PealMempool.executeBatch`. The committee’s key shares are distributed among five operators, run by Peal during testnet, and v1 generates them with a distributed key generation. The cryptography and the settlement are real. Sealed bid auctions ## The last bid in _learns nothing_. An open book turns an auction into a waiting game. The winning bid is often not the one that valued the thing most, just the one that arrived last with everybody else’s number in front of it. _first in__last in_ **••••••**_day 1_4**••••••**_day 3_1**••••••**_day 6_3**••••••**_last minute_2**••••••**_day 8_5 five bids in arrival order, and not one of them readable, including by whoever is running the auction A Peal auction has a close rather than a race. Bids go in sealed and rank on the deadline, from numbers nobody could read while bidding was open, the seller included. [Run a sealed auction](https://peal.network/#/create)[How sealed bidding works](https://peal.network/auction) Bids in the live auction are sealed in the browser to the same committee, with the same batched threshold encryption, as everything else on this site. The committee itself is still a testnet prop with derivable keys, and the auction pages say so. Machine customers ## An agent cannot sign up. It can _pay for one call_. An agent cannot accept terms, hold a key it did not earn, or wait for somebody to approve an invoice. It can do exactly one commercial thing well, which is pay for a single request. x402 is HTTP 402 used as specified: the server states a price, the caller pays on chain, then asks again carrying the proof. Every route is mounted twice, free at `/v1`and metered at `/v1/x402`. `POST /v1/x402/rounds`**402 Payment Required**_the server says what the call costs_`transfer 0.001 USD`**paid on chain**_the agent pays, from its own wallet_`retry with X-PAYMENT`**201 Created**_the round is open. no account was made_ No account was created, no key was issued and no invoice exists. That is what makes it usable by software that did not exist when your signup form was written. [Wire up a paid call](https://peal.network/developers/x402)[The agent skill](https://peal.network/developers/agents) What it is for ## Anywhere the order of arrival should not decide the outcome - ### Procurement and tenders Suppliers price the work instead of pricing each other. Nobody sees another number before the deadline, the buyer included. tag: 'rfq:' · one condition per tender - ### Sealed bid auctions Spectrum, carbon, freight, secondary equity, domain names, liquidations. Every bid opens at the close and ranks at once, so arriving last buys nothing. tag: 'auction:' · one seal per bid - ### Encrypted order flow Orders seal to the block they belong in, so the queue is fixed before it is readable. There is no number to trade in front of. kind: 'at\_block' · one condition per block height - ### Agent commitments, paid per call Two agents commit to a price or an action, sealed until a stated moment, neither able to read the other first. x402 settles the call, so neither needs an account. POST /v1/x402/rounds · 0.001 USD per call - ### Compensation and offers Offers, counter-offers and salary bands open together on a stated date. Nobody negotiates against a number they were shown early. tag: 'offer:' · one condition per requisition - ### Governance and voting Ballots stay sealed until the poll closes, so no running tally can start a bandwagon. The count is computable by anyone afterwards. tag: 'vote:' · one condition per poll - ### Forecasts and research calls Analysts, desks and prediction tournaments submit into a sealed window. Nobody copies a better forecaster and nobody edits after the outcome. tag: 'round:' · one condition per window - ### Grants, bounties and admissions Applications and reviewer scores open together, so reviewers do not anchor on each other and nobody is ranked by who submitted first. tag: 'panel:' · scores as payloads - ### Embargoed disclosure Earnings, a security advisory, an index rebalance, a press release. The embargo holds itself, and lifts for everybody at the same instant. kind: 'at\_time' · one condition per embargo - ### Token launches and allocations Allocation requests are sealed until the window shuts, so the size of the book cannot be traded on while it is filling. tag: 'sale:' · slots padded to the batch The shape is the same every time: people commit to something they cannot take back, and nobody sees anybody else’s until they all open together. [Twelve of these are worked through in the documentation](https://peal.network/developers/usecases). What it costs ## Three HTTP calls, and nothing else. No API key, no account, no signup, no payment. Open a round, seal a payload to it, read it back after the deadline. That is the whole integration. `POST /v1/rounds``POST /v1/rounds/ID/seals``GET  /v1/rounds/ID` The client is one file with the encryption compiled in, served from this site. Skip it and every call above is plain JSON over HTTP. The boundary, exactly ## Sealed until the deadline. Public after it. Peal is not a way to keep something secret for ever, and that is the product rather than a gap in it. A round is unreadable until the moment it names, and public from then on. - That a round exists_public_ - Who created it and when it opens_public_ - What is sealed inside it_nobody, until the deadline_ - How many submissions it holds_nobody, until the deadline_ - Everything, after the deadline_public_ If you need data nobody ever sees, this is the wrong tool. If you need data nobody can act on early and everybody can verify afterwards, this is the whole of it. Questions ## The things people _ask first_ - Programmable privacy infrastructure. Agents submit encrypted bids, offers, votes and intents, and they open only when the conditions you define are met, with proof for every reveal. - No. Sealing happens in their browser or in your own code and goes over ordinary HTTPS. No wallet, no account, no gas, and they never touch a chain. That is usually the difference between a mechanism you can ship to your users and one you can only ship to crypto users. - No single party: the decryption key is distributed among five operators, no three of them combine their shares until the condition fires, and two of them together learn nothing. Peal runs the operators during testnet, and in v1 the shares come from a distributed key generation. - There is nothing for them to refuse. Opening a round is not a participant’s move, so a losing bidder walking away costs everyone else nothing. That single difference is what separates this from every commit and reveal scheme, all of which break in exactly that spot. - Three of the five are enough, so two can be down, unreachable or actively refusing and the round still opens on time. The committee above is interactive, so you can see the threshold rule for yourself; live share arrivals are on the activity dashboard. - Fastest is the quickstart, which runs the three calls against the live network from the page itself, so you can watch a round open before you have written anything. If you build with Claude Code, `curl -fsSL https://peal.network/skill/install.sh | sh` installs a skill carrying a reference for the API, the errors, timing, payments, verification and building the interface, and the assistant then knows the endpoints without you pasting documentation at it; any other coding agent can read the same skill from `https://peal.network/skill/SKILL.md`. There is an `llms.txt` at the root for any model that reads one, and `peal.js` if you would rather seal in the visitor’s own browser with no build step. If none of that appeals, it is three HTTP calls with no key and no account, so curl is a perfectly good client. - Nothing. No key, no account, no signup and no card. Every route is also mounted at `/v1/x402` for callers who want to pay per request, currently 0.001 USD, and that twin is opt in. The free API is not degraded to make the paid one look better. - Running. The quickstart executes against the live network from the documentation page itself, the encrypted mempool demo settles real transactions against real contracts on a public testnet, and the parameters and endpoints are published. It is a devnet, and none of it is carrying real money yet. - Somebody has to be holding that key, and holding it is the same thing as being able to use it early, lose it, or be compelled to produce it. Here no single party holds the key, and the release is triggered by the condition rather than by a person deciding the moment has come. - As many as it needs. Seals open in batches of sixty-four, each by a single threshold decryption, so a round holding sixty submissions costs what a round holding one costs, and a busier round is split into several batches that open together. Slots that carried nothing are padding and are indistinguishable from the ones that did, which is why an open round will not tell you how many submissions it is holding. ## Seal something and watch it open. [Run the three calls](https://peal.network/developers/quickstart)[Read the documentation](https://peal.network/developers) The quickstart runs against the live network from the page itself. Nothing to install and nothing to sign up for. Updates on [X, @pealnetwork\_](https://x.com/pealnetwork_). --- Source: https://peal.network