Skip to main content

Sealed-bid auctions

In an English auction (the kind you've seen in movies), bidders shout prices in the open. The winner pays what they bid.

In a sealed-bid auction, bidders submit their bids privately. Nobody — not other bidders, not the auctioneer — can see what was bid until the deadline. At reveal, the highest bid wins.

SealedIP goes one step further: it is two-sided sealed. Not only are bids hidden, but the seller's reserve price is also hidden. Neither side sees the other's number until settlement. See Sealed reserve for the full explanation.

Sealed-bid auctions are the standard format in real estate, government procurement, mineral rights, and many high-value art sales. They reward genuine valuation over gaming the room.

Why on-chain auctions need sealing​

Naive on-chain auctions are worse than open shout-auctions in two ways:

  1. The mempool leaks. Anyone running a node sees pending bids before they land. Specialized "MEV" actors can re-order, front-run, or sandwich your bid for free.
  2. The contract leaks. Even after bids land, anyone can read them. A late bidder always has perfect information about the leading bid. Bidding becomes a race to the last block, not to your honest valuation.

The result: in practice, on-chain auctions degenerate into last-block sniping. Most "auctions" on-chain are really "buy at the last second" markets.

What sealing changes​

When bids are encrypted at submission and revealed simultaneously:

  • Mempool sniping is impossible. The bid amount is not in the cleartext payload, anywhere.
  • Last-block sniping has no edge. You cannot see the leading bid, so being last has no informational advantage.
  • The auctioneer learns nothing extra. They get the same view as anyone else: a list of opaque ciphertexts.

The auction becomes a true private-valuation contest.

How SealedIP implements it​

SealedIP uses a commit-and-reveal scheme backed by threshold cryptography:

Public during bidding:

  • That a particular wallet bid (participation cannot be hidden)
  • The deposit amount (an upper bound on the bid; see over-deposit tip)
  • That a seller sealed a reserve (visible via reserveHasCiphertext, though not the amount)
  • The ciphertext bytes (useless without the threshold key)

Hidden during bidding:

  • Every bid amount
  • The seller's reserve price
  • All signatures and nonces

Revealed only at deadline:

  • Every bid's amount, all at once, never one at a time
  • The reserve price, simultaneously with the bids
  • The full 149-byte payload (signer, amount, nonce, signature) for each vault

Why simultaneous reveal matters​

If bids could be revealed one at a time, the first revealer would gain information about the leading bid before others had to commit. Threshold cryptography prevents this: no single party can decrypt a single bid. Decryption requires a quorum of validators to act together. Every bid and the reserve are reconstructed in the same settle() call.

The honest tradeoffs​

Sealing isn't free. Three honest caveats:

  1. You trust the validator set. Threshold cryptography assumes a quorum of validators won't collude to decrypt early. SealedIP delegates this to CDR, operated by piplabs.
  2. Bidders need to handle encryption. The SealedIP SDK and web app do this for you. A custom client must implement TDH2 encryption correctly.
  3. Operator availability matters. Once the deadline passes, the orchestrator needs to coordinate validators to publish shares. If it goes offline, trigger() can be called by anyone, but actual decryption stalls until validators publish. See orchestrator availability.

For a full treatment of what we defend against vs. what we don't, see the Threat model.