Validators

The CDR validator set is what makes threshold cryptography concrete. This page documents who the validators are, what the marketplace can read about them, and how the set changes.

On-chain state: what is and is not readable

The CDR system contract (0xCCCcCC0000000000000000000000000000000005) is not verified on Storyscan. As a result:

• The marketplace UI cannot query validator-set size, threshold value, or global public key from on-chain state.
• The NEXT_PUBLIC_CDR_THRESHOLD environment variable (default 3) is used for display only. It is a configuration hint and does not reflect CDR governance.

The authoritative source for the current validator set is CDR governance and the CDR contract itself. Any documentation snapshot, including this page, goes stale when the set rotates.

Threshold parameters

CDR operates a t-of-n threshold scheme. The specific n (total validators) and t (quorum) are set by CDR governance and are not directly readable from the marketplace. Each ciphertext requires t valid partial decryptions to reconstruct plaintext.

What validators see

Validators see:

• Their own partial decryption share for each ciphertext.
• The public ciphertext bytes.
• The uuid and read condition binding.

Validators do NOT see:

• The plaintext bid or reserve amount (no validator has enough shares alone to decrypt).
• Other validators' shares (only published to the CDR contract, not broadcast peer-to-peer in cleartext).

When validators publish shares for SealedIP

CDR validators check AuctionRevealCondition.checkReadCondition before contributing a partial decryption share. That method returns true only when BOTH conditions are satisfied:

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

Until both gates pass, validators withhold shares even if the deadline clock has passed. This is the multi-step reveal gate that replaced the old time-only condition. See CDR network for details.

What "validator collusion" means

If t or more validators decide to act together, they can:

• Reconstruct the plaintext for any ciphertext before the deadline.
• Read the actual bid or reserve amount.
• Use that information to bid against a participant or sell it to another party.

This is the central trust assumption of threshold cryptography. It cannot be fixed with additional cryptography. The mitigations are:

1. Pick a validator set with diverse operators.
2. Make collusion economically costly (slashing, reputation).
3. Ensure the validator set is published and auditable.

CDR's governance handles these. SealedIP delegates the validator-set design entirely to CDR.

When the set rotates

CDR rotates the validator set when a validator unstakes, is slashed, or a new validator joins. During rotation, CDR retains the old threshold key for some window so in-flight ciphertexts can still decrypt. SealedIP auctions that span a rotation should be unaffected in practice. Watch CDR's governance feed for rotation announcements.

Threats this design defends against

Threat	Defended?
Single validator compromise	Yes
t-1 validator collusion	Yes
t or more validator collusion	No (cannot fix)
Validator going offline during reveal	Partial: t-of-n means some can fail
Validator publishing a fake share	Yes: verified at reconstruction
Validator publishing share before read condition is true	Yes: read condition gates publication

Reading deeper

• Threshold cryptography — the cryptographic primitive
• CDR network — the operator and network
• Triggering auctions — when validators start publishing shares
• Threat model — what we defend against