Who can read my bid?
Sealed-bid auctions only make sense if "sealed" actually means sealed. Here's exactly who can and can't see your bid amount, and the seller's reserve, when, and why.
Before the deadline: nobody.
When you place a bid, the amount is encrypted on your machine before it ever leaves it. The ciphertext goes on-chain, but the key needed to decrypt it doesn't exist with any single party. It's split across the validators of the CDR threshold network, and none of them holds the whole key.
That includes us. SealedIP can't decrypt your bid before the deadline any more than you can.
The seller's reserve is sealed too.
SealedIP is sealed on both sides. The seller's reserve price is encrypted into its own CDR vault under the same threshold scheme, so bidders never see the floor while bidding. The reserve is revealed and checked against the seller's signature only at settle, in the same step the bids are revealed.
Neither side gets an information edge: you can't anchor your bid to a visible reserve, and the seller can't watch the bids arrive. If a seller never seals a reserve, the floor is simply zero.
After the deadline: a quorum, all at once.
Once the auction closes, validators publish partial decryption shares to CDR. The contract's read condition only returns true after the deadline, so shares published earlier are rejected. Once a quorum of shares arrives per bid, the orchestrator can read every bid in the auction.
No single validator decrypts a single bid. They all act together, gated by the contract.
What's public the whole time
- That you bid. The contract emits an event with your address when you reserve a slot.
- How much you deposited. The deposit is the upper bound the contract will trust for your bid. If you bid 5 WIP, you must have escrowed at least 5 WIP.
- The ciphertext bytes. Useless without a quorum of validator shares; they reveal nothing on their own.
To hide the upper bound, over-deposit: escrow more than you intend to bid, and accept the overpayment refund at settle.
What's not public until the deadline
- Your actual bid amount.
- The nonce you signed against.
- Your signature over the bid payload.
All three are inside the ciphertext. They become public when the auction settles, at which point the contract has already picked the winner.
What this means in plain English
- You can't see other bids before the deadline. Neither can anyone else. No last-block sniping advantage.
- The marketplace can't front-run you. We don't hold the decryption key any more than you do.
- A single rogue validator gains nothing. One share is mathematically useless. They'd need the threshold quorum to collude.
- The deadline is a hard wall. Bid submissions past the deadline revert. There's no extension and no quiet update window.
The honest caveats
- Validator collusion above threshold. If enough validators secretly coordinate, they can decrypt early. This is the assumption every threshold-crypto system rests on. The CDR validator set is operated by piplabs; we delegate trust there.
- Your own machine. The plaintext exists on your device between signing and encryption. If your browser is compromised, the plaintext can be observed before it gets sealed. We can't fix that with cryptography.
- Deposit signal. Your deposit is public and caps your bid. A deposit exactly at reserve telegraphs a low-confidence bid. Over-depositing hides this, at the cost of higher escrow.
Where to verify
CDR is the threshold-decryption network. It's operated by piplabs ↗ and shared across Story Protocol apps. SealedIP delegates all bid confidentiality to CDR; we don't run our own validator set. The contract's ABI isn't verified on Storyscan, so the current validator membership and threshold parameters live in CDR's governance, not in our marketplace.
The deep-dive version
The points above are the participant's view. If you want the cryptographic and operational detail, the docs site has per-topic pages: