Skip to main content

Threshold cryptography

SealedIP uses threshold cryptography to seal bids. Specifically: TDH2 (Threshold Cramer-Shoup, a threshold variant of public-key encryption) as implemented by CDR (Confidential Data Rails).

The core idea​

In a normal public-key system there's one public key anyone can encrypt to, and one private key that decrypts. Whoever holds the private key has full control.

In threshold cryptography, the private key is split into n shares held by n independent validators. Decryption requires at least t of those validators to each contribute a partial decryption. No single validator can decrypt on their own; no party (including the orchestrator) ever sees the full private key.

The public key stays singular and public. Everyone encrypts to the same key. Decryption is a coordinated act.

Why this is the right primitive for sealed bids​

Naive sealed-bid auctions on-chain face a chicken-and-egg problem:

  • If a single auctioneer holds the decryption key, they can peek before the deadline. Sealing buys you nothing.
  • If bidders hold their own decryption keys (commit-reveal with bidder-driven reveals), the last bidder to reveal has total information about earlier reveals and can refuse to reveal if they would have lost.
  • If no one can decrypt, the auction can't settle.

Threshold cryptography splits the difference:

  • No single party can decrypt before deadline, because no single party has the key.
  • A predefined quorum can decrypt at deadline, because the contract's read condition tells validators when it's allowed.
  • The decryption is published to a contract, not to one party — every bid is revealed in the same step.

The CDR contract​

CDR exposes one on-chain entry point on Aeneid at 0xCCCcCC0000000000000000000000000000000005. The relevant operations from SealedIP's perspective:

  • Allocate a vault slot — the contract requests a unique ciphertext uuid bound to a specific read condition. SealedAuction calls this during allocateBidSlot (for bid vaults) and createAuction (for the reserve vault).
  • Submit ciphertext — the bidder or seller publishes encrypted bytes under that uuid.
  • Submit partial decryption — each validator publishes a share once the read condition is satisfied.
  • Read plaintext — the orchestrator reads the reconstructed plaintext and passes it to settle().

The CDR contract enforces:

  • Only validators in the active set can submit shares.
  • Shares can only be submitted after the bound read condition returns true.
  • Plaintext is only reconstructed after t valid shares arrive.

The CDR contract is not verified on Storyscan. Threshold and validator-set parameters live in CDR governance, not in a readable on-chain interface. The marketplace reads NEXT_PUBLIC_CDR_THRESHOLD for display only.

The auction reveal condition​

For SealedIP, the read condition requires both gates to pass:

  1. block.timestamp >= auction.deadline — the deadline has elapsed.
  2. SealedAuction.isTriggered(auctionId) == true — someone has explicitly called trigger().

This lives in our own contract, AuctionRevealCondition, which CDR queries before validators publish their shares. Validators that submit before either gate is satisfied are rejected.

The same condition contract covers all vaults in a given auction: every bid vault and the seller's reserve vault. All of them open at the same moment, when the deadline has elapsed AND trigger() has been called. Neither the passage of time alone nor an early trigger alone is sufficient.

What threshold cryptography does not protect against​

Threshold cryptography only solves confidentiality before the deadline. It does not protect against:

  • Validator collusion at or above the threshold. If t of n validators decide together to decrypt early, they can — same as any threshold scheme. This is why the validator set matters.
  • Side channels on the bidder's machine. If the bidder's browser or server is compromised, an attacker can read the plaintext before encryption.
  • Inference from deposit size. The deposit is public on-chain. A bidder who deposits exactly the reserve has revealed an upper bound on their bid.

We document these in detail on the Validators page and in Known limitations.

Reading deeper​

  • The TDH2 scheme: see the original paper by Shoup & Gennaro, "Securing Threshold Cryptosystems against Chosen Ciphertext Attack" (1998)
  • Story Protocol's general overview of CDR: piplabs.xyz
  • SealedIP's specific usage: Sealed-bid auctions and Settlement flow