Skip to main content

CDR network

Sealed bids and sealed reserves are confidential only as long as the CDR validator set does not collude to decrypt early. This page documents who operates that set, how the read condition works, and what cannot be read on-chain from the marketplace.

At a glance​

PropertyValue
NetworkCDR (Confidential Data Rails)
Operatorpiplabs
SchemeTDH2 (Threshold ElGamal)
Thresholdt-of-n, operated by piplabs; see Validators
On-chain contract0xCCCcCC0000000000000000000000000000000005 (not verified on Storyscan)

The CDR network is operated by piplabs and provides threshold decryption as a service to Story Protocol apps. SealedIP does not run its own validator set; it delegates confidentiality to CDR.

What the marketplace can and cannot read on-chain​

The CDR contract is not verified on Storyscan. The marketplace therefore cannot read validator-set size, current threshold, or global public key from on-chain state at runtime. The NEXT_PUBLIC_CDR_THRESHOLD environment variable (default 3) is used for display purposes only. It is a configuration hint, not an on-chain read, and may not match the real threshold in CDR governance.

How threshold decryption protects you​

Your bid and the seller's reserve are each encrypted under a single threshold public key collectively held by n validators. To decrypt, at least t of them must each contribute a partial decryption share. No validator can decrypt alone; no party (including the orchestrator or SealedIP) ever possesses the complete decryption key.

The label binding on each ciphertext ties it to a uuid that is also gated by an on-chain read condition. Validators check that condition before contributing a share. For SealedIP, that condition is the AuctionRevealCondition contract.

AuctionRevealCondition: multi-step reveal gate​

This is the custom read condition that replaced the old time-only TimeBasedReadCondition (which is deleted from the codebase).

Address: 0x1A3cCd475CCFb47D1353f62F3bca6DEfAC3D69bC

A CDR vault registered with AuctionRevealCondition is opened only when BOTH of the following are true:

  1. block.timestamp >= deadline
  2. SealedAuction.isTriggered(auctionId) == true

Validators call checkReadCondition(uint32 uuid, bytes, bytes, address) view returns (bool) before publishing a share. If either gate is false, the method returns false and the validator withholds their share.

This means the deadline passing alone does not open the vault. Someone must also call trigger(auctionId) on SealedAuction. See Triggering auctions.

Registration is handled by SealedAuction during createAuction: register(uint32 uuid, uint256 auctionId, uint256 deadline). The registrar is the SealedAuction contract. Registration is one-shot and reverts on re-register or a zero deadline.

CDR contract surface used by SealedAuction​

SealedAuction uses three CDR primitives:

  • CDR.allocate(writeConditionAddr, readConditionAddr, uuid) — allocates a vault slot. SealedAuction passes address(this) as the write condition; CDR does not block writes in this setup. Write-access rules (caller is the slot's allocator or the seller; before deadline; single write) are enforced in SealedAuction Solidity, not via a CDR write condition contract.
  • Write ciphertext — bidder or seller pushes encrypted bytes to the vault.
  • Read plaintext — once the read condition is satisfied, the orchestrator reads the reconstructed plaintext via CDR.

What changes if CDR rotates keys​

During a key rotation:

  • New ciphertexts encrypt under the new key.
  • Old ciphertexts decrypt against the old key, which CDR retains for the transition window.

In practice, rotation has no visible impact on SealedIP auctions unless the rotation happens between bid submission and deadline. CDR's retention of the old key for in-flight ciphertexts should mean clean decryption. Watch CDR's governance feed for rotation announcements if operating high-stakes auctions.

What if CDR is unavailable​

If CDR is down:

  • New bid and reserve encryptions fail (the encryption service cannot fetch the threshold key).
  • New ciphertext submissions fail.
  • Triggered auctions cannot settle (no validator shares published).

Existing escrowed deposits are safe in the SealedAuction contract. They will be refunded once CDR is back up and auctions can settle. This is the central availability dependency. SealedIP cannot operate without CDR.

How CDR compares to operator-held secrets​

The naive alternative is "the auctioneer holds the decryption key." CDR's advantage:

  • No single key custodian. Validators must coordinate.
  • The contract enforces decryption gating via read conditions.
  • Operator availability matters but operator integrity does not: the orchestrator cannot peek even if it wanted to.

CDR's tradeoff:

  • More complexity than a single trusted party.
  • Requires a separate validator set with its own security model.
  • Off-chain coordination for share publishing.

For SealedIP's use case the tradeoff is worth it. Privacy guarantees that depend on operator integrity are weaker than guarantees that depend on a threshold-crypto assumption with an explicit, documented validator set.

Reading deeper​