CIP-24: Cowboy Secret Service (CBSS)

A threshold-IBE secret release service for actors, using BLS12-381 with a drand-style “tlock” construction. Secrets are account-level; owners encrypt to a per-account master public key (MPK) whose master secret (MSK) is never reified — only Shamir-shared across a committee of staked CBSS proxies via threshold BLS DKG (vetted libraries: blstrs, Commonware BLS DKG, tlock). At job time, t of n proxies return BLS partial signatures on a per-version identity; the runner Lagrange-combines them into the IBE decryption key. The dispatcher is not in the trust path and TEE is not the trust root. Defines the on-chain registry, the new SecretsProxy operator role, the threshold cryptography stack, the runner pull flow with per-proxy receipts, the liveness-challenge protocol, and the SDK surface.

Status: Draft Type: Standards Track Category: Core Created: 2026-04-29 Requires: CIP-2 (off-chain compute), CIP-6 (SDK + entitlements), CIP-9 (CBFS-backed runner storage), CIP-12 (governance) Related: whitepaper §9.2 (master opcode allocation), CIP-23 (TEE Execution — optional additional gate, not the trust root)

1. Abstract

CIP-24 specifies the Cowboy Secret Service (CBSS): how an account stores third-party API credentials such that

plaintext is never visible on chain or to validators,
secrets can be deleted forever (no archival ciphertext that becomes decryptable as cryptography ages),
only the specific keys an actor names at the call site are released to the runner,
release is just-in-time and the dispatcher is not in the trust path,
cross-account sharing is supported, and
the trust root is t-of-n proxy non-collusion, not a hardware enclave.

The on-chain surface is the system actor at 0x0000…0004. Off chain, CBSS introduces a new staked operator role — the CBSS Proxy (SecretsProxy) — running the cbssd daemon. Secrets are owned by accounts, not actors; an account’s actors are consumers gated by per-secret ACL. Each per-account release keypair (MPK ∈ G2, MSK ∈ scalar field) is established by a single threshold BLS DKG ceremony among n proxies — once per account, regardless of how many actors or secrets that account ever has. MSK is never reified, only Shamir-shared. At release time, any t proxies return BLS partial signatures on the per-version identity; the runner Lagrange-combines them into the IBE decryption key and unwraps the DEK. Defaults: n = 5, t = 4, BLS12-381. The threshold follows the vetted Commonware N3f1 DKG quorum for the five-proxy default. For high-value secrets where the per-account blast radius is unacceptable, an owner MAY specify a per-secret committee override at SetSecret time. The override triggers a one-off DKG for that specific secret-version with its own (MPK, MSK, committee, t, n), isolated from the account default. This is the escape hatch for owners who want a unique committee for STRIPE_LIVE_KEY while letting SLACK_API_KEY ride the account default. CBSS rejects TEE as the trust root for secret release. CIP-23 TEE attestation remains available as an additional gate per secret (the tee_required flag), but the underlying release is unconditionally non-TEE. Rationale in §10. Crypto stack: CBSS uses BLS12-381 with a threshold identity-based-encryption (IBE) construction, equivalent to drand’s “tlock” scheme. Vetted libraries are required — blstrs for curve ops, the pinned Commonware BLS DKG state machine (or an equivalent vetted threshold-BLS DKG), and tlock (drand) for the IBE construction. BLS12-381 is a new curve dependency for Cowboy but does not replace secp256k1 (account keys remain secp256k1); it lives alongside it as a CBSS-specific primitive. See §3.4. The whole design rests on one structural decision: the cryptographic principal is a stable on-chain identity (account by default, secret on override) whose private key is never reified — only Shamir-shared across the proxy committee. This is the load-bearing change that makes pull-without-dispatcher and pull-without-TEE both work. The owner is offline at job time so cannot be the principal; the runner is VRF-selected at job time so per-recipient material cannot be pre-issued; therefore the principal is an on-chain identity whose key materializes only as a t-of-n threshold operation.

2. Motivation

2.1 The problem

Actors call third-party APIs (Slack, OpenAI, GitHub, Stripe, etc.) that require credentials. Today there is no protocol surface for storing them. Naive solutions — hard-coding into actor source, reading from a CBFS plaintext file, decrypting in actor PVM Python — all violate at least one of:

Validator privacy: validators replay actor execution; anything readable in the PVM is readable on chain.
Eventual decryptability: anything written to chain history is decryptable forever as cryptography ages. Secrets leak retroactively.
Runtime isolation: an actor that can read OPENAI_API_KEY should not also be able to read STRIPE_LIVE_KEY just because the same account owns both.
Dispatcher trust: CIP-9 v1’s dispatcher-unwrap scheme put the dispatcher in the trust path for DEK release — never acceptable for third-party credentials, and since superseded for volume DEKs too (CIP-9 now releases them via CBSS committee seal, §9.3). CBSS keeps the dispatcher off the key path for both.

2.2 Design philosophy

The protocol provides the minimal release surface: encrypted at-rest in CBFS, threshold-released through a registered proxy network, and delivered into an in-memory runner bundle for a single runner-op (with explicit subprocess env maps only when required). Every other concern — rotation policies, audit pipelines, HSM-backed wrapping, DAO-controlled secrets — is built by application-layer actors on top of this primitive. Following the precedent set by CIP-13 §2.1: protocol provides hooks, ecosystem builds products.

2.3 Why not TEE-rooted release

CIP-23 ships TEE-attested execution. That solves a different problem: bounding the runner host’s introspection of in-flight actor state. Using the same anchor for secret release would mean every secret on the network becomes retroactively exfiltratable on a single CPU-vendor microarchitectural break (Foreshadow / Plundervolt / SGAxe / CipherLeaks have all happened to deployed TEEs). Secret ciphertext is durable; an enclave compromise is forever for the secrets it ever wrapped. CBSS instead anchors trust in t-of-n proxy non-collusion plus economic slashing. The failure mode (≥ t simultaneous proxy compromises) is independent of any single hardware vendor and is hardenable through operator diversity policy. §9 quantifies the trade.

3. Specification

Normative conventions. The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119. Parameters marked governance-tunable can be changed by on-chain governance (§4).

3.1 New data structures

SecretId

SecretId {
    account:   Address
    key_hash:  Bytes32             // == keccak256(account || key_name); chain never sees plaintext key_name
}

KeyName (plaintext, regex [A-Z][A-Z0-9_]{0,127}, case-sensitive ASCII) appears in CLI / SDK input, in actor manifest entitlements, and in the runner sandbox during a runner-op. Chain instructions (§3.5) take key_hash directly, never plaintext, so the mempool, tx args, storage paths, and event fields don’t observe literal key names. The CLI computes keccak256(account || key_name) locally before submitting any tx. Plaintext names are still visible in deployed manifests (validator-readable) and dictionary-guessable for common names (e.g., OPENAI_API_KEY); see §3.2 (“H(key) honesty”) for the realistic privacy boundary and COW-2442 for the tracked stronger-privacy follow-up. Keys are namespaced per owning account via the account field. Cross-account access is granted at the policy layer (§3.1.5), not the namespace layer.

SecretKeyRef

The wire-level secret reference carried inside a job spec — secret_refs (the secrets= read set, §5.1/§5.2) and JobPrecondition.secret_ref (§5.5) — as opposed to SecretId, which keys CBSS’s own on-chain storage. Same logical {account, key_hash} pair as SecretId, kept as a distinct named type because it is defined and versioned on the job-spec wire — its canonical bytes are owned by cowboy-protocol-codec::job_spec, the canonical JobSpec encoding (CIP-11 §12.6) — rather than in CBSS storage, but it MUST use the byte-identical key_hash derivation so a SecretKeyRef submitted in a job resolves to the matching SecretId in CBSS storage:

SecretKeyRef {
    account:   Address (20 bytes)
    key_hash:  [u8; 32]
}

key_hash = keccak256( account || key_name )   // byte-identical to SecretId's key_hash recipe above — same inputs, same order, no separator

SecretKeyRef is a plain struct on the wire (positional account then key_hash, no enum tag). It carries no plaintext key name, satisfying the “chain instructions take key_hash directly” rule above. On the SDK surface (§5.2) a caller writes either a bare "KEY_NAME" or the explicit cross-account form {"account": ..., "key": ...}; a bare name resolves to the owning account of the actor issuing the runner-op — the actor’s manifest secrets.* entitlements are what authorize the release (§5.1), so the actor’s owning account is the only sound default, and implementations MUST NOT resolve a bare name to any other account (e.g. the transaction submitter). In both forms the client library fills account and computes key_hash locally before the job spec is submitted — the job-spec-layer counterpart of the CLI’s own local SecretId hashing described above — so the wire shape is always the explicit pair: account is required on every SecretKeyRef, and there is no implicit-account variant on the wire.

SecretMetadata

The on-chain record for a secret. Stored at 0x04 keyed by SecretId.

SecretMetadata {
    id:                SecretId
    latest_version:    u64
    active_versions:   Vec<u64>                    // index of currently-active version numbers (NOT inlined SecretVersion records); each version's full state lives at secret_version:{account}:{H_key}:{version_be8}. Pruned per MAX_VERSIONS_PER_SECRET.
    created_at:        BlockHeight
    last_updated_at:   BlockHeight
}

SecretVersion

Immutable per (SecretId, version). Created by SetSecret; deletable by DeleteSecretVersion.

SecretVersion {
    version:         u64
    pending:         bool                 // true between SetSecret(override-path) and FinalizeSecretVersion; false otherwise. Release attempts on pending versions fail with SecretPending.
    recipient:       ReleaseKeyRef        // always set; points to AccountReleaseKey (default) or per-secret SecretReleaseKey (override). For override path, the SecretReleaseKey may not exist yet (DkgPending) until RotateCommittee commits it.
    policy:          SecretPolicy         // always set
    // The following three fields are populated when pending=false. On the override path they are None at SetSecret time and filled in by FinalizeSecretVersion. Default-path SetSecret populates them immediately.
    wrap_epoch:      Option<u64>          // committee_epoch at the time this version was wrapped; IMMUTABLE once set
    cbfs_pointer:    Option<CbfsPointer>  // CIP-9 envelope; private volume. The CIP-9 envelope carries the outer DEK→plaintext encryption's nonce/AAD bytes (CBSS does not duplicate them here), but their value is fixed by this CIP: the outer AAD MUST equal the extended U-bound aad of §3.4.3 step 4 (see step 5).
    wrapped_dek:     Option<WrappedDek>   // single envelope (DEK encrypted under IBE-derived K); WrappedDek carries its own nonce, ephemeral_u, and aad (see §3.5). aad is canonically derivable from (account, key_hash, version, wrap_epoch, ephemeral_u) so SecretVersion does not store it separately.
    created_at:      BlockHeight
    creator_sig:     Bytes                // tx-level sender signature is the source of truth; the chain records the signing block and signer in event metadata. NO separate finalizer_sig — FinalizeSecretVersion is itself a tx and its sender signature serves the same role.
}

// Invariant: pending == true ⇔ wrap_epoch.is_none() ⇔ cbfs_pointer.is_none() ⇔ wrapped_dek.is_none()
// On override-path SetSecret: pending = true and ALL three Option fields are None until FinalizeSecretVersion lands. wrap_epoch is set THEN, not at SetSecret time.

enum ReleaseKeyRef {
    Account(Address),                     // wraps under AccountReleaseKey[Address].mpk (default path)
    SecretSpecific(SecretId, u64),        // wraps under SecretReleaseKey[(SecretId, version)].mpk (override path)
}

A single wrapped_dek regardless of ACL size: ACL is purely a runtime gate, not a cryptographic recipient list. Adding or removing an actor from the ACL is a metadata-only update with no chain re-wrap. Storage cost per version is O(1).

SecretPolicy

SecretPolicy {
    actors:        Option<Vec<ActorAddress>>     // None = all of owner's actors at release time
    tee_required:  bool                          // additional gate; layered on top of threshold release
}

actors == None resolves at release time to “any actor whose owning account == this secret’s owning account.” actors == Some([...]) is an explicit allowlist and MAY include actors owned by other accounts (cross-account grant; unilateral, no acknowledgment from the recipient account required). Effective access = (actor’s CIP-6 manifest declares the key under the entitlement matching the release purpose — secrets.read for the secrets=[...] read set, secrets.verify for a verify= MAC check, §5.5) AND (SecretPolicy allows the actor) AND (if tee_required, runner provides a valid CIP-23 attestation). The purpose is derived from the stored JobSpec, precondition-first: a key named by JobPrecondition.secret_ref releases as the verify key (gated by secrets.verify); a key named in secret_refs releases as a read-set key (gated by secrets.read) — unambiguous because the §5.5 overlap rule forbids the same {account, key_hash} in both roles within one job. A key held only under secrets.verify is releasable for the MAC check but MUST NOT be substituted via secrets=[...], and vice-versa.

AccountReleaseKey (default path)

The threshold-shared per-account keypair. Stored at 0x04 keyed by Address. Created by the DKG ceremony (§3.6.1); rotated by reshare (§3.6.2). Reused across all of an account’s secrets that don’t specify a per-secret override.

AccountReleaseKey {
    account:              Address
    mpk:                  G2Point                  // BLS12-381 G2, 96 B compressed (master public key); preserved across reshare
    committee:            Vec<ProxyId>             // current committee, exactly `n` distinct entries; mutable on reshare
    threshold:            u8                       // `t`, with 1 ≤ t ≤ n
    committee_epoch:      u64                      // increments on each successful reshare; tracks share-polynomial version, NOT ciphertext binding
    last_reshare_block:   BlockHeight
    vss_commitments:      Vec<G2Point>             // per-proxy VSS commitments S_i = s_i · G2 under the current committee_epoch; n entries
}

committee_epoch is bookkeeping for the share polynomial. It does not appear in the IBE identity or AEAD AAD — the identity is bound to a per-version wrap_epoch, and the AEAD AAD is that same canonical base plus the per-wrap ephemeral_u (see §3.4.3). PSS preserves MSK across reshare, so a proxy’s current share validly partial-signs any identity ever wrapped under MPK, regardless of the wrap_epoch on the original SecretVersion.

SecretReleaseKey (override path)

Same shape as AccountReleaseKey but scoped to a single (SecretId, version). Stored at 0x04 keyed by that pair. Created lazily when an owner submits SetSecret with committee_override = Some(...). Allows per-secret committee parameters (size, threshold, member preference) for high-value secrets that should not share blast radius with the rest of an account’s secrets.

SecretReleaseKey {
    secret_id:            SecretId
    version:              u64
    mpk:                  G2Point
    committee:            Vec<ProxyId>             // exactly `n` distinct entries
    threshold:            u8
    committee_epoch:      u64
    last_reshare_block:   BlockHeight
    vss_commitments:      Vec<G2Point>
}

A SecretReleaseKey is single-use in the sense that it is only consumed by its one owning (SecretId, version). Deleting that secret-version (DeleteSecretVersion or DeleteSecret) cascades to the deletion of the corresponding SecretReleaseKey and emits a ShareZeroizationRequested event; share zeroization on committee members is best-effort, not chain-enforced (see DeleteSecret Effects in §3.5).

CbssProxy

The on-chain record of a registered proxy operator. Stored at 0x04 keyed by ProxyId.

CbssProxy {
    id:               ProxyId
    operator:         Address
    pubkey:           PublicKey                 // secp256k1; used for runner→proxy authentication
    hpke_pubkey:      HpkePublicKey             // X25519 HPKE key used for recipient-specific DKG/reshare payloads
    tls_spki:         Bytes                     // DER SubjectPublicKeyInfo pin for QUIC TLS verification
    network_addr:     NodeAddr                  // QUIC endpoint
    stake:            U256                      // CBY wei; ≥ MIN_PROXY_STAKE
    registered_at:    BlockHeight
    eligible_after:   BlockHeight               // registered_at + PROXY_SOAK_PERIOD
    health:           ProxyHealth               // updated by liveness pings; affects VRF weight
    suspended:        bool                      // true while a slashing case is open
    unbond_at:        Option<BlockHeight>       // Some iff DeregisterCbssProxy called
}

WrappedDek (IBE envelope)

The encrypted DEK on chain. AES-256-GCM with the IBE-derived key K (see §3.4.3). No public-key envelope per recipient — the IBE construction means there is exactly one ciphertext regardless of ACL size, and the recipient is implicit in the per-version identity

I = hash_to_G1( u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2, domain = "cbss/ibe/v1" )

. The encrypted wrap still needs the Boneh-Franklin encryption ephemeral U = r · G2_gen; U is public KEM material, not a recipient key.

WrappedDek {
    version:      u8           // format-version tag == 2 (WRAPPED_DEK_FORMAT_VERSION); leading byte/field of every serialization
    ciphertext:   Bytes        // AES-256-GCM(K, DEK, nonce, aad)
    nonce:        [u8; 12]
    ephemeral_u:  [u8; 96]     // = compress(U), U = r · G2_gen ∈ G2; canonical compressed BLS12-381 G2 encoding, length-validated
    aad:          Bytes        // == u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2 || ephemeral_u
}

Notation: U denotes the G2 group element and ephemeral_u = compress(U) denotes its stored 96-byte canonical compressed encoding; formulas over the struct field use ephemeral_u directly. In aad, u64_le(version) is the secret version number (SecretVersion.version, u64) — not this envelope’s 1-byte format-version tag, which is never part of aad or the key derivation. u64_be(chain_id) is the deploying chain’s 8-byte big-endian chain identifier (the same value bound into tx signatures and release requests), and mpk_g2 is the 96-byte canonical compressed encoding of the resolved release key’s master public key MPK (i.e. compress(MPK) — the exact bytes of the mpk field on the AccountReleaseKey/SecretReleaseKey this version is wrapped to). Endianness is deliberate and load-bearing: chain_id is big-endian, version and wrap_epoch are little-endian, and mpk_g2 is raw 96-byte compressed G2. Owner-side encryption and chain-side validation MUST agree byte-for-byte; any change here is wire-breaking. The serialized WrappedDek format version is 2, carried as a leading 1-byte version tag on every serialization (the first byte of the on-chain codec, the leading field of CBOR/JSON forms). Readers MUST reject any other tag value with a typed error (UnsupportedWrappedDekVersion; §5 error table) — the tag is the dispatch point that makes future format changes (KDF, curve, post-quantum constructions) deployable without a chain reset. The tag is wire framing only: it is NEVER part of the AEAD aad or the key derivation. v1 three-field envelopes are not valid for CIP-24 IBE wraps and there is no v1→v2 migration path: any state wrapped under v1 MUST be discarded (devnet reset) or re-wrapped under v2 before an implementation of this amendment serves it; pre-mainnet, no backwards compatibility is maintained. aad validation is full equality, not suffix equality:

aad == u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2 || ephemeral_u

Implementations MUST reject malformed AAD with AadMismatch when len(aad) != 172 + 96 (i.e. != 268), when the prefix is not the canonical 172-byte base_aad the chain re-derives for the (chain_id, SecretId, version, wrap_epoch, mpk_g2) tuple, or when the final 96 bytes do not equal ephemeral_u. (The length condition is exact equality — a longer AAD with a valid prefix and valid ephemeral_u suffix is still malformed, per the full-equality rule above.) The chain derives chain_id (its own) and mpk_g2 (from the resolved release key’s committed mpk, never from the envelope), so an envelope wrapped under a substituted mpk' produces a base_aad that does not match the chain’s re-derivation and is rejected here with AadMismatch — the same fail-closed check that gives the IBE identity its release-key binding (§3.4.3).

3.2 Storage layout in `0x04`

Privacy scope. Plaintext key names are kept off chain in storage paths and tx args — see §3.5 instructions, all of which take key_hash: Bytes32 directly. Plaintext key names DO appear in:

CLI / SDK input (the user types OPENAI_API_KEY into cowboy secrets set).
Actor manifest entitlements (secrets.read.keys: [...]). Manifests are owner-deployed and validated by the chain; their entitlement keys are visible to validators, indexers, and any node that fetches the manifest. Owners who require unguessable key names should use random suffixes there too (see §5.1).
The runner sandbox during a single runner-op (as the substituted plaintext value’s identifier).

The chain’s storage paths and tx args use key_hash = keccak256(account || key_name). Validators and chain observers see only key_hash in storage paths, tx args, and event fields. This is dictionary-guessable for common names — see “H(key) honesty” below — but does prevent passive scraping.

secret:{account_hex}:{H(key)_hex}                       → SecretMetadata (JSON)
secret_version:{account_hex}:{H(key)_hex}:{version_be8} → SecretVersion (JSON)
secret_version_tombstone:{account_hex}:{H(key)_hex}:{version_be8} → {deleted_at_block: u64, was_pending: bool} (permanent; lets lookups return SecretVersionDeleted instead of SecretNotFound)
account_release_key:{account_hex}                       → AccountReleaseKey (JSON)
secret_release_key:{H(key)_hex}:{version_be8}           → SecretReleaseKey (JSON, override path only)
cbss_proxy:{proxy_id_hex}                               → CbssProxy (JSON)
cbss_proxy_index_by_operator:{operator_hex}             → Vec<ProxyId>
committee_membership_account:{account_hex}              → Vec<ProxyId> (mirrors AccountReleaseKey.committee)
committee_membership_secret:{H(key)_hex}:{ver_be8}      → Vec<ProxyId> (mirrors SecretReleaseKey.committee)
release_receipt:{release_id_hex}                        → { quorum_epoch: u64, entries: Map<ProxyId, ReleaseReceipt> } (per-(release_id, proxy) dedup + audit; quorum_epoch is initialized to body.serve_epoch on the first accepted receipt — runner-pinned, NOT first-receipt-wins. All subsequent receipts must have committee_epoch_at_serve == quorum_epoch == body.serve_epoch or are rejected with MixedEpochReceipts.)
liveness_challenge:{challenge_id_hex}                   → LivenessChallenge (JSON; carries the verbatim SignedReleaseRequest)
liveness_challenge_index:{release_id_hex}:{proxy_hex}   → challenge_id (per-(release_id, proxy_id) dedup; one open challenge per logical release per proxy)
prior_committee_epochs:{release_key_id_hex}             → Vec<{epoch: u64, committee: Vec<ProxyId>, vss_commitments: Vec<G2Point>, expires_at: BlockHeight}> (multi-slot, capped at MAX_PRIOR_COMMITTEE_EPOCHS; each entry retained for RESHARE_GRACE_BLOCKS after its RotateCommittee then GC'd; if cap is hit before GC, RotateCommittee fails — see §3.5)

For tee_required secrets, CBSS also reads TEE Verifier (0x05) state at tee_att:{job_id_32}:{runner_20}. The value is a TeeAttestationRecord { job_id, runner, tee_type, measurement_hash, attested_at_block, expires_at_block, revoked }; CBSS never accepts a proxy-supplied TEE assertion. The TEE Verifier owns the companion trust store tee_key:{tee_type}:{measurement_hash_32} → Vec<EncodedEcdsaPublicKey>: SGX/TDX entries are uncompressed P-256 SEC1 public keys, and SEV-SNP entries are uncompressed P-384 SEC1 public keys. Records are written only by a signed-attestation path that verifies the canonical cbss/tee-attestation/v1 payload over the job, runner, normalized TEE type, measurement, expiry, and quote bytes. This is the current devnet verifier boundary. Full Intel DCAP/TDX collateral validation and AMD SEV-SNP VLEK certificate-chain validation are deferred to the v1.1 / pre-mainnet TEE milestone. Plaintext key names appear only in: (a) the owner’s local CLI, (b) actor manifest entitlements (which are owner-controlled and meant to be public anyway), (c) the runner sandbox during a single runner-op. Chain state never holds them. H(key) honesty. The statement above — “validators and chain observers see only key_hash, not the key name” — is a true wire-format claim, but it MUST NOT be read as a privacy guarantee. key_hash = keccak256(account || key_name) is dictionary-recoverable: account is a public on-chain address that appears in the very same storage path/tx/event as key_hash, and key_name is, by the §3.1 regex, a short, human-chosen, typically low-entropy string (OPENAI_API_KEY, STRIPE_LIVE_KEY, SLACK_SIGNING_SECRET, and similar). There is no salt, per-account or otherwise, in this hash. A validator — or anyone who knows the account address and holds a wordlist of common key names — can recompute keccak256(account || guess) for each candidate and test it against the on-chain key_hash in negligible time; this is a brute-force dictionary attack against a known, small input space, not a preimage attack against keccak256 itself. Consequently, key-name privacy under CIP-24 is best-effort, not absolute, and is only meaningfully strong for high-entropy key names (e.g., an owner-appended random suffix, as suggested in point 2 above). Owners who need confidentiality of which service a secret is for SHOULD NOT rely on a common or guessable name being hidden by key_hash alone. What key_hash reliably provides is protection against passive, non-targeted scraping — hiding the literal string from the wire so a chain indexer, log line, or casual observer doesn’t see it verbatim — not resistance to an adversary who is deliberately guessing that account’s key names. A salted or otherwise name-concealing key_hash construction (a CBSS-keyspace change so key_hash is no longer computable from public inputs plus a guess alone) is tracked as follow-up work in COW-2442 and is out of scope for this amendment.

3.3 Master opcode allocation update

CIP-24 claims opcodes 68–84 from the master table maintained in whitepaper §9.2. The amended row block (to be merged in the same PR as this CIP):

Opcode	Instruction	Source
68	`SetSecret`	CIP-24 §3.5
69	`UpdateSecretPolicy`	CIP-24 §3.5
70	`DeleteSecretVersion`	CIP-24 §3.5
71	`DeleteSecret`	CIP-24 §3.5
72	`RegisterCbssProxy`	CIP-24 §3.5
73	`DeregisterCbssProxy`	CIP-24 §3.5
74	`RotateCommittee`	CIP-24 §3.5
75	`SlashCbssProxy`	CIP-24 §3.5
76	`SubmitReleaseReceipt`	CIP-24 §3.5 (per-proxy submission)
77	`RequestAccountDkg`	CIP-24 §3.5
78	`FinalizeSecretVersion`	CIP-24 §3.5 (supports two-phase override flow)
79	`SubmitLivenessChallenge`	CIP-24 §3.5 (anchors a runner’s liveness challenge against a proxy)
80	`LivenessChallengeResponse`	CIP-24 §3.5 (proxy’s response to a challenge)
81	`ExpireDkgPending`	CIP-24 §3.5 (permissionless cleanup of an expired DkgPending record + bond settlement)
82	`ExpireLivenessChallenge`	CIP-24 maintenance (permissionless transition of expired pending challenges)
83	`RequestReshare`	CIP-24 reshare maintenance (owner-triggered committee refresh for an existing release key)
84	`ForcedDeregisterCbssProxy`	CIP-24 / CIP-12 governance remediation (governance-mediated proxy removal for persistent faults or disclosed leaks)
152 (provisional)	`RegisterTlockRelease`	CIP-24 §3.4.6 / §3.5 (time-lock release registration; consumed by CIP-34 sealed auctions)
153 (provisional)	`SubmitTlockRelease`	CIP-24 §3.4.6 / §3.5 (committee posts a height-gated partial; permissionless read)
158 (provisional)	`GovRequestSystemDkg`	CIP-24 §3.5 / CIP-34 §Sealed-Bid (governance-authorized DKG bootstrap for a keyless system-actor committee, e.g. `0x14`)

The two time-lock opcodes 152/153 are provisional placeholders, not a fixed reservation. Like every system-instruction opcode, they are allocated next-free against the SystemInstruction enum and the opcode-uniqueness test at implementation time (there is no central normative opcode table to amend — see CIP-34 §Protocol Allocations). They are shown as 152/153 only to keep them clear of the currently-documented ranges and of CIP-34’s own (also unpinned) Intent* settlement opcodes; CIP-34 and this amendment are authored under the same effort, so the actual contiguous CIP-34 ↔ CIP-24 opcode ordering is reconciled at impl time. The opcode-uniqueness test is the binding gate. TEE Verifier support instructions take opcodes 60–63 and are consumed by the 0x05 actor state that CIP-24 reads: RegisterTeeTrustedKey (60), RevokeTeeTrustedKey (61), SubmitTeeAttestation (62), and RevokeTeeAttestation (63). These are live in node/types/src/execution.rs (SYS_REGISTER_TEE_TRUSTED_KEY=60 etc.) and are the canonical assignments for these slots — superseding earlier draft claims in CIP-13 v2 §1 / CIP-23 v2 / CIP-10 v2 that proposed GcNonces / container ops at these opcodes. The pre-activation drafts of those CIPs need their own renumbering against the code-based master table; see CIP-13 §1 (revised 2026-05-26).

3.4 Cryptography

3.4.1 Vetted-library mandate

CBSS does not roll its own crypto. The protocol is built as a thin (~few hundred lines) integration layer over published, externally-reviewed primitives:

Primitive	Library	Vetted-ness
BLS12-381 curve operations + pairings	`blstrs` (Filecoin-maintained)	Production at Ethereum, Filecoin, Drand mainnet scale
Hash-to-curve (G1)	`blstrs` (RFC 9380)	Same
Threshold BLS DKG	Commonware BLS DKG or equivalent vetted threshold-BLS DKG	Pinned Commonware `N3f1` state machine in the devnet implementation; external integration review before mainnet
Threshold IBE construction	`tlock` (drand reference)	Drand mainnet randomness beacon ships this in production for time-lock encryption
Symmetric encryption	`aes-gcm` (RustCrypto)	RustCrypto-reviewed; ubiquitous
KDF / hash	`hkdf`, `sha2`, `sha3` (RustCrypto)	Standard

The integration glue (~few hundred lines: identity construction, ciphertext envelope, validation, share storage layer) lives in runner/crates/cbss-crypto. Proactive secret sharing (committee resharing) is the one sub-protocol where a vetted Rust library does not yet exist; CBSS implements a thin wrapper following drand’s published resharing protocol. External crypto review deferred to June 2026; this is a pre-mainnet governance gate, not a current implementation-completion blocker.

3.4.2 Curve choice: BLS12-381

CBSS uses BLS12-381, not secp256k1 (which Cowboy account keys use). Reasons:

Vetted threshold-encryption libraries exist on BLS12-381. Drand, Lit, the Ethereum-adjacent ecosystem, and Filecoin all ship BLS12-381 threshold tooling at production scale. On secp256k1 the equivalent threshold-encryption tooling does not exist in vetted form; a CBSS implementation on secp256k1 would require hand-rolling the DKG, partial decryption, and NIZK glue — exactly the cryptographic engineering anti-pattern this CIP rejects.
Pairing-friendly groups make threshold IBE possible with the simple Boneh-Franklin construction: encryption to an “identity” plus a threshold BLS signature on that identity is the IBE decryption key. No bespoke key-switching primitive required.
Production scale — Ethereum’s beacon chain, Filecoin proofs, Drand all use BLS12-381 at ≥ million-share scale, so library quality is high and corner cases are well-understood.

The cost: BLS12-381 is a new curve dependency for Cowboy. It does not replace secp256k1 — account keys, runner registry keys, and proxy registry keys remain secp256k1. BLS12-381 lives alongside as a CBSS-internal primitive used only for threshold encryption. Pairings are 1–3 ms on modern hardware; well within the 250 ms p50 release latency budget.

3.4.3 Construction: threshold IBE (“tlock” applied to secret release)

The construction is standard Boneh-Franklin-style threshold IBE plus threshold BLS signatures, applied with a CBSS-specific identity binding instead of a future-round binding. As in Boneh-Franklin IBE and drand tlock, each owner-side encryption includes a fresh encryption ephemeral r and publishes U = r · G2_gen in the envelope. Pairing orientation (used throughout this CIP): the BLS12-381 pairing is e: G1 × G2 → GT. I lives in G1; MPK, S_i, and U live in G2; σ and σ_i live in G1. All pairing expressions follow this orientation: G1 element first, G2 element second. Epoch model: a SecretVersion is bound at SetSecret time to the wrap_epoch = the release key’s committee_epoch at that moment. wrap_epoch is then immutable. Reshare changes the release key’s committee_epoch and rotates the share polynomial, but PSS preserves MSK, so a proxy’s current share validly partial-signs any identity ever derived under any historical wrap_epoch of the same release key. The IBE identity binds chain_id, wrap_epoch, and mpk_g2; the AEAD AAD binds all of those plus the per-wrap ephemeral_u; neither binds the live committee_epoch. Why mpk_g2 is the right release-key field to bind (soundness of the serve-vs-wrap asymmetry). The base AAD binds the raw mpk_g2 rather than a committee/threshold/VSS commitment because mpk is the only reshare-invariant piece of release-key material: a reshare provably preserves MPK (the chain rejects a reshare whose new_mpk != prior_release_key.mpk; §3.5 RotateCommittee), while committee membership, threshold, and vss_commitments all rotate under PSS. At release time the identity’s wrap_epoch field is historical (read from the immutable SecretVersion) while the mpk_g2 fed to the pairing comes from the current release-key record — this is sound precisely because reshare preserves mpk, so the current mpk equals the wrap-time mpk for every epoch the chain will still serve. The one case where they diverge is a force_rekey re-DKG, which installs a fresh MPK and simultaneously strands every ciphertext bound to the old one (§3.5) — so the mpk_g2 binding never fails a release that would otherwise have succeeded. Binding any rotating field instead (e.g. release_key_material_hash) would strand a secret the moment its wrap-epoch’s material ages out; account secrets have no re-wrap path, so they MUST bind the invariant mpk. (CIP-7 and CIP-9, which do have epoch-scoped re-wrap models, bind release_key_material_hash instead — see §9.3 and CIP-7. The rule that generates all three: bind the strongest release-key commitment the family’s re-wrap model can carry.) Setup (per AccountReleaseKey or SecretReleaseKey):

The n CBSS proxies in the committee run a threshold BLS DKG (the devnet implementation uses the pinned Commonware BLS DKG state machine; an equivalent vetted threshold-BLS DKG may be substituted by governance-reviewed implementation update). Round-2 share payloads are recipient-specific and HPKE-encrypted to each recipient’s on-chain CbssProxy.hpke_pubkey. If timeout or complaint handling excludes a dealer, the daemon finalizes over an explicit qualified dealer set of at least t members. Output: master public key MPK ∈ G2, Shamir shares s_1 … s_n ∈ Fr of the implicit master secret key MSK ∈ Fr. Threshold t. MSK is never reified.
MPK and the per-proxy commitments S_i = s_i · G2 ∈ G2 are published on chain in AccountReleaseKey or SecretReleaseKey.

Storage (per secret-version):

Let wrap_epoch = the release key’s committee_epoch at SetSecret/FinalizeSecretVersion time, and mpk_g2 = compress(MPK) the 96-byte compressed master public key of that release key (AccountReleaseKey.mpk on the default path, SecretReleaseKey.mpk on the override path). Define the 172-byte base AAD: base_aad = u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2 where canonical(SecretId) = account(20) || key_hash(32) (§3.5), so the fixed-width layout is chain_id(8) ‖ account(20) ‖ key_hash(32) ‖ version(8) ‖ wrap_epoch(8) ‖ mpk_g2(96) = 172 bytes. The leading chain_id is the chain separation binding: a secret wrapped for chain A is rejected by chain B’s validation and its released σ cannot unwrap it. The trailing mpk_g2 is the release-key binding: a secret wrapped under a substituted mpk' hashes to a different identity, so the real committee’s σ can never open it. Owner derives the per-version identity using this canonical encoding (§3.5 SubmitReleaseReceipt): I = hash_to_G1( base_aad, domain = "cbss/ibe/v1" ) (RFC 9380 hash-to-curve). I ∈ G1. The owner, the proxies, and the chain all compute I from these same inputs in the same byte encoding. I is derived from the 172-byte base_aad, not from the extended AEAD AAD below.
Owner samples a fresh encryption ephemeral scalar r ←$ Fr from a CSPRNG for every wrap, with r != 0, and computes U = r · G2_gen ∈ G2 (96-byte compressed). The owner MUST NOT reuse r across secret versions. Define the AEAD AAD: aad = base_aad || compress(U). Owner computes the IBE encryption key for I: K = HKDF-SHA256( serialize(e(I, MPK)^r), "cbss/ibe/v1" || aad ) where e(I, MPK)^r ∈ GT is equivalently e(I, r · MPK) or e(r · I, MPK), and serialize is the canonical compressed GT encoding (exactly 288 bytes; blstrs implements Compress for Gt). The notation HKDF-SHA256( ikm, info ) is normative throughout this CIP and means RFC 5869 HKDF with salt = the ASCII bytes "cbss/ibe/v1" (the same 11-byte domain string as the info prefix — not absent, not empty), info as written, and output length L = 32 bytes. The salt is load-bearing: a derivation with salt = None/empty produces a different K, so omitting it makes every wrap undecryptable cross-implementation.
Owner generates a fresh DEK (256 bits, CSPRNG). AES-256-GCM-encrypts the plaintext value with DEK + a fresh nonce + the 172-byte base_aad (the value envelope binds base_aad, not the U-extended aad — the value envelope’s key DEK is independent of U, so it binds only the chain- and release-key-bound base). Uploads the AES-GCM ciphertext to a private CBFS volume → cbfs_pointer. Because the stored value envelope binds base_aad, any change to chain_id, canonical(SecretId), version, wrap_epoch, or mpk_g2 invalidates the ciphertext of the secret value itself — not merely its DEK wrap — which is why this base-AAD layout can only be introduced on a wiping re-genesis (there is no re-wrap path that reconstructs the value envelope without the plaintext).
Owner AES-256-GCM-encrypts DEK with K + a separate nonce and the 268-byte extended aad from step 4 (base_aad || compress(U)), producing wrapped_dek. Only the DEK wrap binds the extended AAD; the chain re-derives and full-equality-checks all 268 bytes at SetSecret/FinalizeSecretVersion (§3.5).
Owner publishes wrapped_dek + cbfs_pointer + wrap_epoch + recipient + policy on chain via SetSecret (default path) or FinalizeSecretVersion (override path; see §3.5). wrapped_dek includes ephemeral_u = compress(U).

Release (per job):

Runner signs the ReleaseRequestBody directly with its runner-registry key (the secp256k1 key registered with 0x01 Runner Registry, the same key it uses for any other authenticated runner→chain interaction). No runner-binding ephemeral keypair is involved — the IBE construction does not require a runner-bound ciphertext, so there is no per-request runner ephemeral. This is distinct from the owner-chosen Boneh-Franklin encryption ephemeral r in step 4. Both proxies (at PartialSign serve time) and the chain (at SubmitReleaseReceipt validation) verify runner_sig against the runner registry.
Runner reads the SecretVersion (carrying wrap_epoch) and the referenced ReleaseKey (carrying current committee + S_is) from chain. Runner sends a release request to t proxies. Each proxy validates ACL/manifest/job-assignment/anti-replay (§3.7).
Each proxy computes the identity exactly as the owner did, using the SecretVersion’s wrap_epoch and the canonical encoding from step 3: I = hash_to_G1( u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2, domain = "cbss/ibe/v1" ), then its partial signature: σ_i = s_i · I ∈ G1 (using the proxy’s current share s_i — PSS guarantees this works regardless of the relationship between wrap_epoch and the proxy’s current share epoch).
Each proxy returns σ_i to the runner. Verification is the standard BLS partial-signature check: validate e(σ_i, G2_gen) == e(I, S_i) where S_i ∈ G2 is the proxy’s published VSS commitment. Implementations MUST reject identity/point-at-infinity S_i and σ_i before the pairing check; otherwise e(0, G2_gen) == e(I, 0) passes vacuously. No bespoke NIZK required — the BLS pairing equation is its own proof of correctness.
Runner combines t partial signatures via Lagrange interpolation in G1: σ = Σ λ_i · σ_i = MSK · I ∈ G1 (the full threshold BLS signature on I, equivalently the IBE decryption key for I).
Runner reads wrapped_dek.ephemeral_u (decoding it to U; §3.1 notation), reconstructs the same extended aad = base_aad || ephemeral_u, and derives K = HKDF-SHA256( serialize(e(σ, U)), "cbss/ibe/v1" || aad ). By bilinearity, e(σ, U) = e(MSK · I, r · G2_gen) = e(I, G2_gen)^(MSK · r) = e(I, MPK)^r — the same K the owner computed at step 4.
Runner AES-256-GCM-decrypts wrapped_dek with K → DEK.
Runner fetches the CBFS object via cbfs_pointer, AES-256-GCM-decrypts ciphertext with DEK + the 172-byte base_aad (the value envelope’s AAD; §3.1) → plaintext.

Implementations MUST reject degenerate pairing inputs before any pairing or key derivation: identity/point-at-infinity MPK, U, σ, I, S_i, and σ_i; non-canonical compressed encodings; or points outside the prime-order subgroup. blstrs compressed decoding enforces curve/subgroup membership but accepts the identity, so identity rejection is an additional requirement. Implementations MUST also enforce MAX_IBE_AAD_BYTES = 4096 and MAX_IBE_CIPHERTEXT_BYTES = 1 MiB (§4) for every CBSS IBE envelope.

3.4.4 Security properties

t-of-n threshold: any t honest proxies can complete a release; t-1 cannot reconstruct σ and therefore cannot derive K. Given public (I, MPK, U), deriving K without σ requires computing e(I, MPK)^r = e(I, G2_gen)^(MSK · r) from (G2_gen, MPK = MSK · G2_gen, U = r · G2_gen), reducing to the co-BDH assumption on BLS12-381.
Owner-chosen U: a malformed owner-chosen r/U weakens or bricks only that owner’s own secret. Binding compress(U) into the AAD makes post-publish tampering a hard AEAD failure rather than a silent mis-derivation.
No new steering surface: r is supplied by the secret owner for that owner’s own secret. Proxies and runners treat U as opaque KEM material; reshare/PSS properties are unchanged because the committee still releases σ for the same identity I.
Per-(secret_id, version, wrap_epoch) σ: a leaked σ decrypts only the wrapped DEK for that exact identity. Compromising a different secret version requires a separate t-of-n collusion to derive its σ. Reshare does NOT invalidate σ values for prior identities; PSS preserves MSK and hence preserves σ for any identity I.
No bespoke NIZK: BLS partial-signature verification is a single pairing check, covered by blstrs and the vetted threshold-BLS implementation.
Anti-replay, ACL, audit: enforced at the proxy validation layer (§3.7) and via per-proxy receipts (§3.5). Cryptographic envelope intentionally does NOT bind to a runner ephemeral key — see §3.4.5 for why.
Reshare: proactive secret sharing on MSK rotates shares without changing MPK. Stored secrets remain decryptable. In-flight release requests are NOT invalidated by reshare; a proxy’s freshly-resharded share still produces valid partials for any prior-epoch identity.
Insider rotation: the value of reshare is bounding the window during which a specific share-holder’s compromised share is useful. After reshare, that specific s_i is replaced; the attacker must re-compromise the new s_i’ to keep contributing to t-of-n.

3.4.5 Why threshold IBE, not threshold ElGamal with key-switching

The candidate alternative is threshold ElGamal on secp256k1 with a custom “key-switching to runner ephemeral pubkey” construction. Two problems:

No vetted Rust library exists. Threshold ElGamal on secp256k1 requires hand-rolling the DKG, partial-decrypt construction, and Chaum-Pedersen NIZK. Standard cryptographic-engineering hygiene says: don’t roll your own crypto when a vetted equivalent exists. BLS12-381 + threshold IBE has vetted equivalents (Commonware BLS DKG, tlock, blstrs); secp256k1 + threshold ElGamal does not.
Key-switching to runner ephemeral pubkey was solving a problem we don’t actually have. The runner is the legitimate recipient of DEK; cryptographically binding the ciphertext to a runner-ephemeral pubkey adds protocol complexity without buying additional security beyond what proxy-side anti-replay/ACL already provide. Threshold IBE produces DEK directly to the runner; the runner zeroizes after use; revocation/replay/audit happen at validation time, not in the envelope.

This does not remove the Boneh-Franklin encryption ephemeral. Every owner-side wrap still MUST sample a fresh r and publish U = r · G2_gen in WrappedDek. That ephemeral is independent of runner identity; it is the KEM randomness that makes K unrecoverable from public (I, MPK, U). The threshold-IBE construction is what drand’s tlock ships in production. CBSS uses the same primitive with a CBSS-specific identity binding.

3.4.6 Time-Lock Release mode (height-gated, public identity)

§3.4.3 applied threshold IBE “with a CBSS-specific identity binding instead of a future-round binding.” This subsection re-introduces tlock’s native time-lock binding as a second release mode on the same committee — for consumers (e.g. CIP-34 sealed-bid auctions) that need a key which becomes available at a future height, bound to a caller-chosen identity, and released permissionlessly, independent of any participant. It adds no new key material, no new DKG, and no new trust assumption: it reuses the committee’s existing MPK, shares s_i, and PSS guarantees. Two modes, disjoint by domain separation.

	Secret release (§3.4.3)	Time-lock release (this subsection)
Identity domain	`"cbss/ibe/v1"`	`"cbss/tlock/v1"`
Identity binding	`chain_id ‖ SecretId ‖ version ‖ wrap_epoch ‖ mpk_g2`	caller `tag ‖ target_height`
Release trigger	signed `ReleaseRequest`, ACL-gated (§3.7)	chain height ≥ `target_height`, permissionless
Who may obtain `σ`	the authorized runner only	anyone (public)
Protects	confidentiality (access)	time (until a height)

The domains are distinct, so a release σ for one mode can never derive the key for the other — the two identity spaces are disjoint in G1 by RFC 9380 domain separation. A tlock identity MUST NOT be used to wrap an account secret (its key is public at target_height); the domain tag enforces this structurally, not by policy. Identity. For a caller-chosen tag: Bytes (e.g. a CIP-34 request_id) and reveal height target_height: u64:

I_tlock = hash_to_G1( canonical(tag) || u64_le(target_height), domain = "cbss/tlock/v1" )   ∈ G1

Encryption reuses the §3.4.3 Boneh-Franklin construction — the encryptor samples a fresh r ←$ Fr, publishes U = r · G2_gen, and derives K = HKDF-SHA256( serialize(e(I_tlock, MPK)^r), "cbss/tlock/v1" || aad ) against the committee’s existing MPK. (The HKDF salt/info domain is "cbss/tlock/v1", matching the identity domain — load-bearing, as in §3.4.3.)

Scope boundary (normative): time-lock release does NOT inherit the §3.4.3 account-secret AAD. “Identical to §3.4.3” above scopes to the pairing/HKDF construction, not to the AAD contents. Time-lock release keeps its own base AAD — base_aad_tlock = tag ‖ u64_le(target_height) (for CIP-34 sealed bids, tag = request_id, so base_aad_tlock = request_id(32) ‖ u64_le(reveal_height); CIP-34 §Sealed-Bid), extended to aad = base_aad_tlock ‖ compress(U) for the AEAD. It does not gain chain_id and does not gain mpk_g2; the §3.4.3 chain-separation and release-key bindings apply only to the account-secret family. Base AADs in this CIP are per-family and do not inherit across families (the same rule that keeps CIP-9’s volume path on its own base AAD, §9.3). The tlock/CIP-34 key-substitution exposure is therefore not closed by an AAD change (a submit-time mismatch would arrive too late, and there is no on-chain envelope validation to attach it to); it is addressed by authenticating the committee MPK at the encryptor against the release key’s release_key_material_hash before sealing, and by an independent committee-side reveal-height check — both tracked as separate workstreams, not as changes to this base AAD. See CIP-34 for the sealed-bid scoping statement.

Release — the only structural difference. Once chain height ≥ target_height, each committee proxy computes its partial on the tlock identity with its current share and posts it on chain:

σ_i = s_i · I_tlock   ∈ G1          (SubmitTlockRelease, §3.5)

verified by the chain with the standard BLS check e(σ_i, G2_gen) == e(I_tlock, S_i) (identity/point-at-infinity rejection as in §3.4.3). The accumulated partials are a public chain artifact: anyone reads ≥ t of them, Lagrange-combines σ = Σ λ_i · σ_i = MSK · I_tlock, and derives K = HKDF-SHA256( serialize(e(σ, U)), "cbss/tlock/v1" || aad ). There is no §3.7 validation (no ACL, no job-assignment, no runner-binding, no anti-replay on the reader) — time-lock release is public by construction; the only gate is the height. Single-epoch quorum (consensus-critical, twin of §9a’s MixedEpochReceipts): the partials MUST all be from one committee_epoch — the Lagrange x-coordinates are proxy positions in that epoch’s committee, so a cross-epoch combine yields the wrong σ. The partial set records the committee_epoch of its first accepted partial as its quorum_epoch; if a reshare advances the committee while the set is below threshold, the set is RESET to the new epoch (stale, now-uncombinable partials discarded) so collection can still complete. A combiner MUST combine only same-quorum_epoch partials; if the live committee has advanced past a threshold-reached set’s quorum_epoch, the release is treated as not-yet-releasable (deterministic) rather than silently mis-combined — the consumer retries or hits its grace fallback (CIP-34 §Sealed-Bid). Registration + bounded committee work. A tlock release is registered on chain (RegisterTlockRelease { tag, target_height }, §3.5) so the committee knows what to sign and when. Registration is fee-bearing and bounded: a per-block cap on new registrations, and a registered request (plus its posted partials) is GC’d after target_height + TLOCK_RETENTION (§4). A proxy MUST reject SubmitTlockRelease while head < target_height (premature reveal) and for an unregistered (tag, target_height). Reuse + reshare. A proxy’s current share s_i validly partial-signs any identity under MPK, tlock identities included (PSS preserves MSK; §3.4.4). Reshare does not invalidate a registered tlock request — a freshly-resharded share still produces a valid partial for I_tlock. Liveness is the consumer’s to handle. The committee-liveness assumption is identical to secret release. If fewer than t partials are posted by target_height + GRACE, the consumer owns the fallback — e.g. CIP-34 cancels the auction (CancelledGraceExpired) at reveal_height + AUCTION_GRACE (CIP-34 §Sealed-Bid); as built it does not re-open a plaintext OPEN round. CBSS itself adds no time-lock fallback; it exposes the height-gated release and the consumer composes the timeout. Security delta vs §3.4.3. Confidentiality holds only until target_height (by design); before it, the co-BDH argument of §3.4.4 applies unchanged (t-1 proxies cannot derive σ). Because the identity binds tag, the release for one tag reveals nothing about another tag at the same height — so one auction’s reveal cannot expose another auction’s still-sealed bids. The public-at-height property is exactly why the domain separation from account-secret identities is mandatory.

3.5 New system instructions

Each instruction’s Sender column gives who is authorized to submit it. Gas costs in §4.1.

SetSecret (opcode 68)

The instruction is shape-asymmetric across the two recipient types because in the override path the recipient MPK does not exist at SetSecret time — it must be produced by a fresh DKG ceremony first. The default path stays one-shot; the override path is two-phase, with FinalizeSecretVersion (opcode 78) attaching the ciphertext after DKG finalizes.

SetSecret {
    key_hash:             Bytes32                        // == keccak256(sender || key_name); plaintext key_name never crosses the wire
    recipient:            ReleaseKeyRef                  // Account(sender) for default; SecretSpecific(SecretId, next_version) for override
    policy:               SecretPolicy
    // Default path (recipient = Account(_)) carries ciphertext immediately:
    cbfs_pointer:         Option<CbfsPointer>            // Some on default path; None on override path. CIP-9 envelope; carries the outer plaintext-encryption nonce internally.
    wrap_epoch:           Option<u64>                    // Some on default path (== AccountReleaseKey.committee_epoch); None on override path
    wrapped_dek:          Option<WrappedDek>             // Some on default path (carries inner DEK-wrap nonce + ephemeral_u + aad); None on override path
    // Override path carries committee parameters:
    committee_override:   Option<CommitteeOverride>      // Some on override path; None on default path
}

struct CommitteeOverride {
    n:                 u8                     // 5 ≤ n ≤ MAX_OVERRIDE_N
    t:                 u8                     // MIN_OVERRIDE_T ≤ t ≤ n
    preferred_proxies: Option<Vec<ProxyId>>   // hints; final committee is VRF-selected from this set if Some
}

struct WrappedDek {
    version:      u8                 // format-version tag == 2 (WRAPPED_DEK_FORMAT_VERSION); leading byte/field of every serialization (§3.1)
    ciphertext:   Bytes              // AES-256-GCM ciphertext of the DEK
    nonce:        [u8; 12]
    ephemeral_u:  [u8; 96]           // = compress(U), U = r · G2_gen ∈ G2; canonical compressed BLS12-381 G2 encoding
    aad:          Bytes              // == u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2 || ephemeral_u
}

Sender: owner of the account. Effects:

Default path (recipient = Account(sender)): must carry cbfs_pointer + wrap_epoch + wrapped_dek (DEK encrypted under the IBE key derived from the account’s existing MPK; nonces, ephemeral_u, and AAD are inside WrappedDek and the CIP-9 CBFS envelope). The instruction is rejected with MissingAccountReleaseKey if the sender has no AccountReleaseKey on file (the cowboy CLI auto-issues RequestAccountDkg on first use). Creates SecretVersion(version = latest + 1) under SecretId(sender, key) with pending = false. Emits SecretCreated.
Override path (recipient = SecretSpecific(SecretId, next_version)): must NOT carry cbfs_pointer / wrap_epoch / wrapped_dek. Instead carries committee_override. Effects:
1. Creates SecretVersion(version = next_version) with pending = true, wrap_epoch = None, cbfs_pointer = None, wrapped_dek = None. (The §3.1 invariant requires all three Option fields are None on a pending version.) wrap_epoch is populated by FinalizeSecretVersion once MPK exists.
2. Locks DKG_BOND from the sender, VRF-selects an n-proxy committee per the override spec, and writes a DkgPending(SecretSpecific(SecretId, next_version), committee, deadline, bond_amount, requester = sender) record.
3. Off-chain DKG runs (§3.6.1). On commit, the committee submits RotateCommittee { scope: SecretSpecific(...), new_committee_epoch: 1, ... }, which writes the new SecretReleaseKey and exposes MPK on chain.
4. Owner reads MPK + committee_epoch from chain, sets wrap_epoch = committee_epoch (= 1 here), samples fresh r != 0, computes U = r · G2_gen, derives K = HKDF(serialize(e(I, MPK)^r), "cbss/ibe/v1" || aad) with aad = u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2 || compress(U), encrypts DEK to K, uploads CBFS ciphertext, and submits FinalizeSecretVersion (opcode 78) to attach cbfs_pointer + wrapped_dek + wrap_epoch and clear pending.
5. Until step 4 lands, release attempts against this version fail closed with SecretPending.

Validation rules (chain-enforced):

Default path: wrapped_dek.version == 2 (§3.1; rejects with UnsupportedWrappedDekVersion otherwise); wrap_epoch == account_release_key.committee_epoch at SetSecret block; wrapped_dek.ephemeral_u is the canonical compressed encoding of a non-identity G2 point in the prime-order subgroup (subgroup membership REQUIRED; §3.4.3); and wrapped_dek.aad == u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2 || wrapped_dek.ephemeral_u, where chain_id is this chain’s identifier and mpk_g2 = compress(account_release_key.mpk) — both taken from committed state loaded one step above (the AccountReleaseKey already in hand for the wrap_epoch check), never from the envelope. Rejects with WrapEpochMismatch / AadMismatch otherwise. A wrapped_dek sealed under a substituted mpk' (or for another chain) therefore fails this full-equality check with AadMismatch — the chain-side half of the release-key binding (§3.4.3).
Override path: committee_override.n and t within (MIN_OVERRIDE_T, MAX_OVERRIDE_N); preferred_proxies (if Some) all eligible.
Both paths: key_hash is a well-formed 32-byte value; quotas not exceeded. (Plaintext KeyName regex enforcement is CLI/SDK-side, since the chain never sees plaintext.)

Emits SecretCreated { id, version, recipient_kind, pending: bool, ... }.

FinalizeSecretVersion (opcode 78)

Attaches ciphertext to a pending = true SecretVersion after its DKG ceremony has committed. Used only on the override path.

FinalizeSecretVersion {
    key_hash:      Bytes32
    version:       u64
    wrap_epoch:    u64                  // == secret_release_key.committee_epoch at this submission's block
    cbfs_pointer:  CbfsPointer          // CIP-9 envelope; carries outer plaintext-encryption nonce internally
    wrapped_dek:   WrappedDek           // carries inner DEK-wrap nonce + ephemeral_u + aad
}

Sender: owner of the account. Effects: validates that:

SecretVersion exists, has pending = true, and recipient = SecretSpecific(_, version).
The corresponding SecretReleaseKey is committed (exists on chain) and its committee_epoch ≥ 1.
wrap_epoch == secret_release_key.committee_epoch at FinalizeSecretVersion block (no resharing in between, OR the owner explicitly accepts re-wrapping under the new epoch).
wrapped_dek.version == 2 (§3.1); rejects with UnsupportedWrappedDekVersion otherwise.
wrapped_dek.ephemeral_u is the canonical compressed encoding of a non-identity G2 point in the prime-order subgroup (subgroup membership REQUIRED; §3.4.3).
wrapped_dek.aad == u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2 || wrapped_dek.ephemeral_u, with chain_id this chain’s identifier and mpk_g2 = compress(secret_release_key.mpk) derived from committed state (the override path’s SecretReleaseKey), never from the envelope; a substituted mpk' or wrong-chain wrap fails with AadMismatch.

On success, sets cbfs_pointer, wrap_epoch, wrapped_dek on the SecretVersion and clears pending. From this point release proceeds normally. Emits SecretVersionFinalized { id, version }. If the owner never finalizes (e.g., abandons the secret), the version remains pending indefinitely and consumes a quota slot. A future garbage-collection mechanism MAY reclaim long-pending versions; out of scope here.

UpdateSecretPolicy (opcode 69)

UpdateSecretPolicy {
    key_hash:    Bytes32
    version:     u64
    new_policy:  SecretPolicy
}

Sender: owner of the account. Effects: replaces the policy on the named SecretVersion. No re-wrap is required — the cryptographic recipient is the account (or per-secret override key), not the individual ACL actors. ACL changes are pure metadata and propagate atomically to all subsequent release attempts. ACL semantics on update: replace, not merge (the new policy fully supersedes the old). This is one of the operational wins of per-account anchoring vs per-actor: granting or revoking an actor’s access is a single chain tx with no proxy round-trips, no re-encryption, no chain-storage fan-out. Emits SecretPolicyUpdated.

DeleteSecretVersion (opcode 70)

DeleteSecretVersion { key_hash: Bytes32, version: u64 }

Sender: owner. Effects: removes SecretVersion from chain state, adds an entry to secret_version_tombstone:{account_hex}:{H(key)_hex}:{version_be8} (singular path; matches §3.2 storage layout). Tombstone carries {deleted_at_block, was_pending} so future lookups can distinguish “deleted” from “never existed”, never the ciphertext. If pending == false, also emits a CBFS drop instruction for the cbfs_pointer; if pending == true, no CBFS object exists, so the CBFS drop is skipped. Subsequent release attempts against this version fail closed with SecretVersionDeleted (the tombstone is what makes this distinguishable from SecretNotFound). Pending releases that referenced this version (already in flight at proxies) fail at the proxy validation step.

DeleteSecret (opcode 71)

DeleteSecret { key_hash: Bytes32 }

Sender: owner. Effects: atomically deletes all versions of the secret. Drops each version’s CBFS pointer (skipping pending versions which have none). Each version gets a tombstone entry as in DeleteSecretVersion. SecretMetadata removed. The account’s AccountReleaseKey is not removed (it may serve other secrets). Any per-secret SecretReleaseKey records owned by the deleted versions ARE cascaded into deletion: the chain emits a ShareZeroizationRequested { release_key_id } event per affected SecretReleaseKey. Committee members SHOULD respond by zeroizing their local shares and recording the action in their cbssd audit log; the chain does NOT enforce zeroization (no quorum signature or attestation is required by the protocol — false attestations would be evidence in a future leak case but cannot be objectively verified at deletion time). This is documented and accepted: deletion is a request to the operator network, not a cryptographic guarantee. Owners should treat zeroization as best-effort and not rely on it for forward secrecy.

RegisterCbssProxy (opcode 72)

RegisterCbssProxy {
    pubkey:        PublicKey
    hpke_pubkey:   HpkePublicKey
    tls_spki:      Bytes                  // DER SubjectPublicKeyInfo pin for QUIC TLS verification
    network_addr:  NodeAddr
    stake_amount:  U256                  // ≥ MIN_PROXY_STAKE; locked from operator's account
}

Sender: any account with sufficient CBY balance. Effects: locks stake_amount CBY in the proxy’s escrow, mints a fresh ProxyId, writes CbssProxy with eligible_after = current_block + PROXY_SOAK_PERIOD. The proxy is not VRF-eligible until soak completes.

DeregisterCbssProxy (opcode 73)

DeregisterCbssProxy { proxy_id: ProxyId }

Sender: the registered proxy operator. Effects: sets unbond_at = current_block. Stake remains locked for UNBOND_COOLDOWN. If the proxy is currently a member of any AccountReleaseKey.committee or SecretReleaseKey.committee, RotateCommittee is enqueued for each affected release key. After cooldown elapses with no slashing case, stake is returned and the CbssProxy record is purged.

RotateCommittee (opcode 74)

RotateCommittee {
    scope:               ReleaseKeyScope
    new_committee:       Vec<ProxyId>          // exactly `n` distinct, all eligible
    new_committee_epoch: u64                   // == old + 1; for fresh DKG (initial), == 1
    new_mpk:             G2Point               // 96 B compressed; on initial DKG this is the freshly-generated MPK; on reshare this MUST equal the prior MPK (chain enforces; PSS preserves MSK so MPK is preserved)
    vss_commitments:     Vec<G2Point>          // n entries, S_i = s_i · G2 ∈ G2 (matches §3.4 verification e(σ_i, G2_gen) == e(I, S_i))
    new_committee_sigs:  Vec<Signature>        // ≥ t signatures FROM new_committee MEMBERS attesting to the DKG output. REQUIRED on both initial DKG and reshare. Each sig is over the unified `rotate_hash` (domain "cbss/rotate-committee/v1"; full big-endian preimage in §"Canonical domain-separated signature payloads") under the proxy's registered identity key.
    prior_committee_sigs: Vec<Signature>       // ≥ t signatures from PRIOR committee attesting they zeroized old shares. REQUIRED on reshare; OMITTED on initial DKG (no prior committee exists). Each sig is over the SAME `rotate_hash` as new_committee_sigs (domain "cbss/rotate-committee/v1", not a separate preimage) under the prior proxy's identity key.
}

enum ReleaseKeyScope {
    Account(Address),
    SecretSpecific(SecretId, u64),
}

Sender: any one member of the new committee, on behalf of the committee. The submitter’s authority comes from the threshold signature set in new_committee_sigs, not from being the lone submitter. Effects: verifies VSS commitments (each S_i ∈ G2) and quorum signatures (when applicable), atomically updates the targeted AccountReleaseKey or SecretReleaseKey and increments committee_epoch. Reshare grace: before overwriting, the prior (committee_epoch_old, committee_old, vss_commitments_old, expires_at = current_block + RESHARE_GRACE_BLOCKS) is appended to prior_committee_epochs:{release_key_id} (a Vec, NOT a single slot — handles back-to-back reshares within one grace window). On append, any entries whose expires_at < current_block are GC’d first. If the resulting Vec would exceed MAX_PRIOR_COMMITTEE_EPOCHS (§4.2, default 4), the RotateCommittee instruction is rejected with ReshareGraceCapacity — the operator must wait for at least one prior epoch to expire, OR governance can override via a CIP-12 emergency proposal that prunes oldest entries. This bounds storage growth while preventing the one-slot-overwrite bug. Receipts whose committee_epoch_at_serve matches any retained entry in prior_committee_epochs (and whose submission is before that entry’s expires_at) are accepted; outside any retained entry’s window, they’re rejected with StaleCommitteeEpoch. Old committee members MUST zeroize their old shares before signing the quorum attestation; failure to do so is not directly slashable but the signing under false attestation is future-evidence for a leak case. Existing SecretVersion records keep their original wrap_epoch (immutable per version); the IBE identity for those versions is unchanged. New SetSecret calls after this RotateCommittee bind to the new committee_epoch as their wrap_epoch. mpk is preserved across reshare (proactive secret sharing); only the share polynomial changes. This is true for both account-scoped and secret-scoped keys. This instruction is also used to commit the result of an initial DKG ceremony triggered by RequestAccountDkg or by the override path of SetSecret. In that case, prior_committee_sigs is empty (there is no prior committee to attest zeroization from), but new_committee_sigs is still required — at least t signatures from members of the freshly-DKG’d new committee over the canonical DKG-commit payload (see the field comments in the struct above). This is what authenticates the initial DKG output; without it, a single nominated proxy could commit an arbitrary (MPK, S_i) set.

SlashCbssProxy (opcode 75)

On-chain-provable fault classes are limited to those that admit objective, on-chain evidence. Liveness is excluded from automatic slashing entirely — packet-delivery non-receipt is fundamentally not provable on chain (a malicious or broken runner can submit a valid signed request without ever delivering it to the proxy; the proxy cannot prove a network negative). Liveness instead drives a health score (§4.4) that affects VRF selection weight, and persistent extreme degradation triggers governance review (CIP-12 Tier 1 ForcedDeregisterCbssProxy). The on-chain SubmitLivenessChallenge / LivenessChallengeResponse remain as the audit trail that feeds the health score, but they do not by themselves cause stake loss. PlaintextLeak is also removed from protocol-level slashing because its evidence (“here is the recovered DEK plus t-1 partials”) would publish the secret on chain. Off-chain disclosure → governance → ForcedDeregisterCbssProxy is the channel.

SlashCbssProxy {
    proxy_id:    ProxyId
    fault_class: FaultClass
    evidence:    SlashEvidence
}

enum FaultClass {
    InvalidPartialReencrypt,             // BLS partial-sig pairing check fails on a submitted σ_i
    DkgSabotage,                         // VSS commitment / share mismatch in DKG round 2
    Equivocation,                        // Two distinct signed responses (same request_hash, distinct payloads)
}

Sender: any account that holds the corresponding evidence. Effects: evaluates the evidence per fault class (§4.3). On valid evidence, applies the schedule penalty to CbssProxy.stake, sets suspended = true pending governance review.

SubmitLivenessChallenge (opcode 79)

Anchors on chain that a runner experienced a non-response from a proxy. Feeds the proxy’s health score; does NOT by itself trigger slashing.

SubmitLivenessChallenge {
    runner_request:             SignedReleaseRequest  // the original signed request the runner claims went unanswered (body + runner_sig)
    proxy_id:                   ProxyId               // proxy alleged non-responsive
    challenge_sig:              Signature             // exact byte layout: see "Canonical domain-separated signature payloads"
                                                      // following the request hash definitions earlier in §3.5.
                                                      // Signed under the runner registry key with the "cbss/liveness-challenge/v1" domain prefix.
                                                      // (No challenged_at in the signed payload — chain assigns it on inclusion.)
}

challenged_at is NOT a tx arg — the chain sets it to the inclusion block height when the instruction is processed. This prevents future-dating or backdating attacks on the response-deadline timing. Sender: the runner identified by runner_request.body.runner_id. Effects: all validation at current head (no historical reads), matching the receipt model:

runner_request.runner_sig verifies request_hash = keccak256(serialize(runner_request.body)) against the on-chain runner registry pubkey for body.runner_id at current head.
ACL/manifest/job-assignment for (body.actor, body.runner_id, body.job_id, body.secret_id) valid at current head.
SecretVersion[body.secret_id, body.version].pending == false — challenges against pending versions are rejected with SecretPending (a pending version is never releasable, so a missed-request claim against it is meaningless).
body.request_block + MIN_CHALLENGE_DELAY_BLOCKS ≤ submission_block ≤ body.request_block + LIVENESS_CHALLENGE_MAX_AGE_BLOCKS. The lower bound (premature → ChallengePremature) gives the proxy time to serve + submit a receipt before being challenged. The upper bound (default MIN_CHALLENGE_DELAY_BLOCKS + LIVENESS_RESPONSE_BLOCKS, ~32 min) bounds how stale a challenge can be; older challenges fail with StaleChallenge. (challenged_at is set to submission_block by the handler.)
body.recipient == SecretVersion[body.secret_id, body.version].recipient (same recipient-consistency check as receipts; prevents committee-substitution challenges).
proxy_id is a member of the referenced release key’s current committee OR any retained prior committee (i.e., any entry of prior_committee_epochs:{release_key_id} whose expires_at > submission_block). The challenge does NOT carry a committee_epoch_at_serve (unlike receipts); the chain accepts membership in any currently-recognized committee. Rationale: the challenge is alleging the proxy failed to respond at SOME point during its tenure; pinning a specific epoch would require the runner to know which committee_epoch the proxy was supposed to serve under, which the runner doesn’t necessarily know at challenge time.
challenge_sig verifies the outer challenge envelope under body.runner_id’s registry key.
Per-release liveness dedup. No prior liveness_challenge_index:{release_id}:{proxy_id} entry exists. A (release_id, proxy_id) pair admits at most ONE on-chain liveness challenge regardless of whether the previous challenge is pending or terminal. Duplicate submissions are rejected with LivenessChallengeAlreadyOpen. This bounds health-score impact to one challenge per logical release per proxy and prevents repeated false-alarm bond transfers.
The chain checks whether release_receipt:{release_id}.entries[proxy_id] already exists. An existing receipt is not a rejection: it proves the proxy already served and makes the challenge immediately Resolved; the runner forfeits the bond to the challenged proxy.

On success, locks LIVENESS_CHALLENGE_BOND from the runner’s account and writes liveness_challenge_index:{release_id}:{proxy_id} → challenge_id so subsequent duplicate challenges are rejected. If a receipt for (release_id, proxy_id) already exists, the handler writes

LivenessChallenge { id, runner_request, bond_amount, challenged_at = submission_block, status: Resolved, deadline = submission_block }

and transfers the bond to the challenged proxy. Otherwise it writes

LivenessChallenge { id, runner_request, bond_amount, challenged_at = submission_block, status: Pending, deadline = submission_block + LIVENESS_RESPONSE_BLOCKS }

. The proxy has until deadline to dispute. Admission-time receipt resolution. Because MIN_CHALLENGE_DELAY_BLOCKS is strictly greater than REQUEST_FRESHNESS_BLOCKS, every receipt that can pass receipt freshness validation is already either on chain or impossible to submit by the time a liveness challenge is admissible. Runners are expected to check release_receipt:{release_id}.entries[proxy_id] before challenging. If they challenge despite an existing receipt, the chain resolves the challenge immediately and transfers the bond to the proxy. The receipt itself does NOT need to be fresh per REQUEST_FRESHNESS_BLOCKS for this purpose — persistent release_receipt state is the authoritative record of “did the proxy ever submit a paid receipt for this release_id.” Resolved is therefore an admission-time state, not a response-time state. If a proxy served but failed to submit a receipt before the receipt freshness window closed, it cannot later create chain-verifiable receipt evidence. Its only on-chain response path is an Unverifiable reason (typically NeverReceived or structured local-failure evidence), which is health-neutral but does not produce a positive liveness signal. After deadline, a still-Pending challenge transitions to Unanswered, refunds the bond to the runner, and applies the standard negative health-score decrement to the proxy. No automatic slash follows. The challenge is recorded in the proxy’s audit history. Persistent unanswered challenges may justify a governance proposal under CIP-12.

LivenessChallengeResponse (opcode 80)

A proxy’s structured response to a liveness challenge. Records chain-unverifiable response evidence; does NOT by itself prevent governance action.

LivenessChallengeResponse {
    challenge_id:  Bytes32
    proxy_id:      ProxyId
    reason:        ChallengeReason
    evidence:      ChallengeResponseEvidence
    proxy_sig:     Signature                         // see "Signed payload" below
}

enum ChallengeReason {
    // NOT chain-verifiable (logged for governance pattern detection):
    InvalidRequest,           // proxy claims the request failed validation at serve time (ACL, manifest, job assignment, sig). NOT auto-resolving because chain re-derivation at response time would use later state and the admission-time snapshot is not stored. Logged with the proxy's structured reason for governance pattern detection.
    RateLimited,              // proxy claims its local rate-limiter rejected the request. Per-actor rate limits are proxy-local sliding-window state and the chain has no way to verify the proxy's claim.
    NeverReceived,            // proxy claims the network request did not arrive; not provable on chain.
}

// Domain-separated signed payload. Implementations MUST sign exactly these bytes:
proxy_sig := sign(proxy_priv,
              keccak256( "cbss/liveness-response/v1" ||
                         challenge_id ||
                         proxy_id ||
                         u8(reason) ||
                         keccak256(serialize(evidence)) ))

Sender: the challenged proxy. Effects: validates proxy_sig over the exact byte layout above against CbssProxy.pubkey, then evaluates evidence per reason. The chain transitions the challenge to a terminal state with bond disposition that matches the chain’s view of who was right:

Resolved — not produced by LivenessChallengeResponse; produced only by the admission-time receipt check in SubmitLivenessChallenge. Chain dereferences release_receipt:{release_id} and confirms the entry exists with proxy_id matching. Health-score impact on the proxy: small positive (proved liveness via receipt). Bond disposition: forfeited to the challenged proxy.
Unverifiable — proxy submits LivenessChallengeResponse with InvalidRequest / RateLimited / NeverReceived before deadline. Chain cannot re-derive any of these. Bond → refunded to the runner (the runner submitted a good-faith challenge; whether the proxy’s response is honest is unknowable on-chain). Health-score impact on the proxy: NEUTRAL — no automatic decrement. Pattern detection lives in off-chain governance.
Unanswered — proxy submits no response by deadline. The runner was right — the proxy is genuinely silent. Bond → refunded to the runner. Health-score impact on the proxy: standard negative decrement. Persistent unanswered patterns flag the proxy for governance review per §4.4.

The runner loses money only when the chain can prove the runner was wrong (Resolved via an existing receipt); in all other cases (proxy went silent or proxy gave an unverifiable response) the runner gets the bond back. Anti-spam friction. A naive runner could still try to challenge proxies before they’ve had time to submit their receipts. To prevent this, SubmitLivenessChallenge enforces body.request_block + MIN_CHALLENGE_DELAY_BLOCKS ≤ submission_block (see §4.2). Challenges submitted too soon after the original request are rejected with ChallengePremature. The default delay is REQUEST_FRESHNESS_BLOCKS + 32 (~12 min), giving honest proxies a generous window to either serve + submit a receipt (which then resolves any later challenge at admission) or fail loudly. Only the admission-time receipt check is chain-verifiable and resolves to Resolved. Unverifiable captures “the proxy responded with chain-unverifiable evidence” without penalizing either party. Repeated Unverifiable patterns by the same proxy escalate via off-chain governance, not protocol-level slashing or health-score automation.

SubmitReleaseReceipt (opcode 76)

Per-proxy submission, not aggregate. Each proxy that served a partial submits its own receipt independently. The receipt carries the runner’s original signed release request verbatim AND the proxy’s BLS partial signature σ_i. The chain re-derives the request hash, verifies the runner’s signature, and verifies the BLS pairing equation e(σ_i, G2_gen) == e(I, S_i) — providing cryptographic proof that the proxy actually computed honest work, not just that the runner asked for it. A proxy that submits a receipt without computing σ_i cannot pass the pairing check.

SubmitReleaseReceipt {
    runner_request:             SignedReleaseRequest    // the original, replayed verbatim
    proxy_id:                   ProxyId                 // this submitter
    sigma_i:                    G1Bytes                 // 48-byte compressed BLS12-381 G1 point; the partial sig the proxy returned to the runner
    committee_epoch_at_serve:   u64                     // the release key's committee_epoch when the proxy computed σ_i
    served_at_block:            BlockHeight             // when the proxy computed σ_i
    proxy_sig:                  Signature               // see "Canonical domain-separated signature payloads" later in §3.5; signed under the proxy identity key with "cbss/partial-sign-response/v1" prefix.
    // Note: tee_attested is NOT a field — chain computes it (§3.5 step 10) from TEE Verifier state
}

struct ReleaseRequestBody {                   // unsigned; this is the message the runner signs
    secret_id:       SecretId                 // == { account, key_hash }; carries the secret-owning account, NOT the requesting actor's account
    version:         u64
    actor:           ActorAddress             // the requesting actor (may be cross-account)
    runner_id:       RunnerAddress
    recipient:       ReleaseKeyRef
    job_id:          JobId
    release_nonce:   Bytes32                  // fresh CSPRNG per fetch_for_op call
    request_block:   BlockHeight              // chain block runner pinned; freshness-checked at submission
    serve_epoch:     u64                      // committee_epoch the runner intends partials to come from; pins the quorum_epoch up front. Proxies whose current committee_epoch differs MUST reject the PartialSign with EpochMismatch.
}

struct SignedReleaseRequest {
    body:        ReleaseRequestBody
    runner_sig:  Signature                    // see "Canonical domain-separated signature payloads" later in §3.5; signed under the runner registry key with "cbss/release-request/v1" prefix.
}

request_hash := keccak256(serialize(ReleaseRequestBody))
              // Defined OVER THE BODY ONLY (not the signature). No circularity.

release_id   := keccak256(canonical(body.secret_id) || u64_le(body.version) || body.actor || body.runner_id || body.job_id || body.release_nonce)
              // Stable per release attempt; does NOT include request_block. Used for proxy bloom + chain dedup.

canonical(SecretId) := secret_id.account || secret_id.key_hash       // 20 + 32 = 52 bytes, fixed encoding

Canonical domain-separated signature payloads. All sigs use a domain-string prefix to prevent cross-protocol replay; implementations MUST sign exactly these byte layouts:

runner_sig (in SignedReleaseRequest):
    sign(runner_registry_priv,
         keccak256("cbss/release-request/v1" || request_hash))

proxy_sig (in PartialSignResponse, also reused in SubmitReleaseReceipt verbatim):
    sign(proxy_identity_priv,
         keccak256("cbss/partial-sign-response/v1" ||
                   request_hash ||
                   proxy_id ||
                   serialize(sigma_i) ||
                   u64_le(committee_epoch_at_serve) ||
                   u64_le(served_at_block)))

challenge_sig (in SubmitLivenessChallenge):
    sign(runner_registry_priv,
         keccak256("cbss/liveness-challenge/v1" ||
                   request_hash ||
                   proxy_id))

response proxy_sig (in LivenessChallengeResponse):
    sign(proxy_identity_priv,
         keccak256("cbss/liveness-response/v1" ||
                   challenge_id ||
                   proxy_id ||
                   u8(reason) ||
                   keccak256(serialize(evidence))))

new_committee_sig / prior_committee_sig (in RotateCommittee):
    BOTH the new committee AND the prior committee sign the SAME rotate_hash,
    domain-separated under the single tag "cbss/rotate-committee/v1"
    (node/execution/src/cbss.rs::rotate_committee_hash). Exact preimage
    (all integers big-endian, no length prefix on the domain):
    rotate_hash = keccak256(
        "cbss/rotate-committee/v1" ||
        scope.encode() ||
        u8(force_rekey) ||
        u32(new_committee.len()) || new_committee[i] (each 32-byte proxy_id, in order) ||
        u64(new_committee_epoch) ||
        new_mpk (96-byte G2) ||
        u32(vss_commitments.len()) || vss_commitments[i] (each 96-byte G2, in order))

Identity binding (used by IBE encryption AND receipt pairing-check, must agree byte-for-byte): base_aad := u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2 I := hash_to_G1( base_aad, domain = "cbss/ibe/v1" ) The owner (at SetSecret/FinalizeSecretVersion), the proxy (at PartialSign), and the chain (at SubmitReleaseReceipt pairing-check) all compute I from the same 172-byte base_aad in the same encoding. Here chain_id is the chain’s own identifier and mpk_g2 = compress(MPK) is taken from the release key the chain resolves for the pairing check (§3.6.2 reshare-aware lookup) — not from any client input — so the identity all parties hash is bound to the exact release key. AAD on the AES-GCM wrapped_dek envelope extends the same canonical encoding with the Boneh-Franklin encryption ephemeral: aad = base_aad || wrapped_dek.ephemeral_u. The chain and runner MUST reject the envelope with AadMismatch unless this full equality holds; len(aad) != 172 + 96 (i.e. != 268) is malformed AAD. Sender: the proxy identified by proxy_id (its proxy_sig must verify against CbssProxy.pubkey). Chain validation (current-head; the chain does not read historical state):

request_hash and release_id are recomputed from runner_request.body (NOT including the signature; see request_hash definition above).
body.request_block ∈ [head − REQUEST_FRESHNESS_BLOCKS, submission_block]. Out of range → StaleRequestBlock.
runner_request.runner_sig verifies request_hash against the runner registry at current head.
Recipient consistency. Look up SecretVersion[body.secret_id, body.version]. The receipt’s body.recipient MUST equal the stored SecretVersion.recipient. Reject with RecipientMismatch otherwise. (Without this, a malicious runner could request a partial under a different release key’s MPK; the partial passes pairing under that other MPK but doesn’t decrypt this SecretVersion’s wrapped_dek.) Also require SecretVersion.pending == false.
ACL/manifest/job-assignment for (actor, runner_id, job_id, secret) valid at current head. Trade-off: if the ACL was permitted at request_block but revoked within the freshness window before the proxy submits, the receipt is rejected — the proxy ate the work for that one request. This is the cost of avoiding a historical-read API. Bounded by REQUEST_FRESHNESS_BLOCKS (~6 min); proxies should submit promptly, and runners who try to weaponize this lose more from gas + grief than they gain.
Reshare-aware committee lookup. Resolve (committee, vss_commitments) for committee_epoch_at_serve:
- If committee_epoch_at_serve == release_key.committee_epoch (current): use the live committee + commitments.
- Else if prior_committee_epochs:{release_key_id} contains an entry with epoch == committee_epoch_at_serve AND submission_block < entry.expires_at: use that entry’s committee + commitments. (Vec lookup; multiple prior epochs may be retained simultaneously per §3.5 RotateCommittee.)
- Else: reject with StaleCommitteeEpoch. proxy_id must be a member of the resolved committee at that epoch.
proxy_sig verifies over (request_hash, proxy_id, sigma_i, committee_epoch_at_serve, served_at_block) under proxy_id’s registered pubkey.
BLS partial-signature pairing check: chain reads wrap_epoch from the SecretVersion (chain has it; it’s immutable) and mpk_g2 = compress(MPK) from the release key resolved for this receipt (step 6). Computes I = hash_to_G1( u64_be(chain_id) || canonical(body.secret_id) || u64_le(body.version) || u64_le(wrap_epoch) || mpk_g2, domain = "cbss/ibe/v1" ) — identical encoding to the one the owner used at encryption time. (The wrap_epoch field is historical while mpk_g2 comes from the resolved — current — release-key record; this is sound because reshare preserves MPK, so the two agree for every epoch the chain will still serve; §3.4.3.) Looks up the proxy’s S_i ∈ G2 from the resolved release key’s vss_commitments (current epoch or grace-window prior). Rejects identity/point-at-infinity sigma_i or S_i before pairing. Checks e(sigma_i, G2_gen) == e(I, S_i). Fail → InvalidPartialReencrypt (chain emits a slashing-evidence event automatically; receipt rejected; no payment).
(release_id, proxy_id) not previously recorded in release_receipt. Dedup is on release_id (which includes release_nonce), not request_hash — a runner who re-pins a fresh request_block for the same nonce cannot get a second receipt billed by the same proxy. A runner who issues a fresh release_nonce for a legitimate second pull within the same job CAN receive a second receipt — that’s the intended use of the nonce. 9a. Single-epoch quorum (runner-pinned). committee_epoch_at_serve == body.serve_epoch. The quorum_epoch is fixed by the runner up front in the signed body; the chain enforces every receipt’s committee_epoch_at_serve matches the runner’s declared serve_epoch. Mismatch → MixedEpochReceipts. Lagrange combine works only over partials from the same Shamir polynomial; pinning the epoch in the signed request prevents a racing off-epoch proxy from locking the quorum_epoch to a value the runner did not intend. If a reshare lands between the runner’s request_block and PartialSign serve time, proxies whose current committee_epoch no longer matches body.serve_epoch reject with EpochMismatch (see §3.7); the runner must re-issue with a fresh release_nonce and updated serve_epoch. 9b. Quorum cap. release_receipt:{release_id}.entries.len() < threshold (where threshold is read from the referenced release key for body.serve_epoch, the same epoch stored as quorum_epoch once the first receipt is accepted). Once t receipts are recorded for a release_id, additional receipts (from any of the other n-t proxies the runner may have fanned out to) are rejected with QuorumAlreadyReached. This caps payment at exactly t receipts per logical release, regardless of fanout. Proxies that respond after the t-th have already submitted have done valid work but are not paid — they MUST observe this and stop attempting submission once they see the t-th receipt on chain.
served_at_block ≤ submission_block, and served_at_block ≥ body.request_block.
tee_attested is chain-derived, not proxy-asserted. The chain looks up 0x05 TEE Verifier state at tee_att:{body.job_id}:{body.runner_id} AT submission time. If the SecretVersion’s policy.tee_required = true, the record must exist, be non-revoked, match the request’s job_id and runner_id, have attested_at_block <= submission_block <= expires_at_block, and use a TEE type matching the runner registration. TEE Verifier records are produced by SubmitTeeAttestation, which verifies a registered ECDSA attestation key over the canonical attestation payload before writing: P-256 for SGX/TDX, P-384 for SEV-SNP. Otherwise the receipt is rejected with SecretRequiresTEE. The resulting boolean is what gets emitted in events; proxies do not declare it.

On success: if release_receipt:{release_id} does not yet exist, initializes it with quorum_epoch = body.serve_epoch and an empty entries map. Then inserts (proxy_id → ReleaseReceipt) into entries. Debits RELEASE_FEE_PER_RECEIPT from actor.account; credits proxy_id. Overdraft / delinquency. If actor.account.balance < RELEASE_FEE_PER_RECEIPT, the receipt is still recorded and the proxy is still credited, with the actor’s release-payment balance going negative (capped at MAX_RELEASE_OVERDRAFT, governance-tunable, default 16 × RELEASE_FEE_PER_RECEIPT). Implementations whose base account codec cannot represent negative balances MAY store the negative portion in a separate release-debt ledger; the Cowboy node currently stores this as CBSS ActorReleaseDebt. The actor account transitions to delinquent status, which suspends new job dispatching to that actor until the negative balance is repaid. On Cowboy, JobSubmit rejects outstanding ActorReleaseDebt; FundActor repays that debt before any newly funded balance becomes spendable and emits cbss.actor.debt_repaid when repayment is applied. If overdraft would exceed MAX_RELEASE_OVERDRAFT, the receipt is rejected with ActorAccountInsufficient and no payment occurs — proxies that observe this on chain SHOULD stop accepting PartialSign requests from this actor until repayment is observed. This separates “honest proxy was paid for honest work” (always succeeds within overdraft cap) from “actor pays its bills” (enforced by delinquency suspension + cap). Each receipt emits one event:

event ReleaseReceiptRecorded {
    release_id:    Bytes32             // stable across t receipts for the same logical release
    request_hash:  Bytes32             // identifies the specific signed request this receipt fulfilled
    account:       Address
    actor:         ActorAddress
    runner:        RunnerAddress
    key_hash:      Bytes32             // == secret_id.key_hash; same caveat as §3.2 (dictionary-guessable)
    version:       u64
    proxy_id:      ProxyId             // single proxy per event
    tee_attested:  bool                 // chain-derived from TEE Verifier state at submission
    block:         BlockHeight
}

SecretReleased (quorum event) is emitted when the t-th receipt for a given release_id lands, carrying the actual proxy_set: [ProxyId; t] accumulated in release_receipt:{release_id}:

event SecretReleased {
    release_id:    Bytes32
    account:       Address
    actor:         ActorAddress
    runner:        RunnerAddress
    key_hash:      Bytes32
    version:       u64
    tee_attested:  bool                 // chain-derived; aggregates true iff every contributing receipt observed valid TEE attestation
    proxy_set:     Vec<ProxyId>         // exactly the t proxies whose receipts crossed the quorum threshold
    block:         BlockHeight
}

This separates “proxy was paid for honest work” (per-receipt event, one per receipt) from “the secret was successfully released” (quorum event, one per release). The chain knows the threshold t from the referenced release key, so the threshold-cross detection is deterministic.

RequestAccountDkg (opcode 77)

RequestAccountDkg {}                           // sender = the account itself

Sender: the account owner. Triggered explicitly by an owner or implicitly by the cowboy CLI on first SetSecret if no AccountReleaseKey exists yet. Effects: Locks DKG_BOND from the requesting account. VRF-selects n = DEFAULT_N proxies from the eligible set, weighted by stake × health_score (see §4.4). Writes a

DkgPending { scope, force_rekey, committee, threshold, deadline = current_block + DKG_FINALIZE_BLOCKS, bond_amount, requester }

record at dkg_pending:{scope_serialized} (the record persists force_rekey and threshold so the off-chain ceremony and any later RotateCommittee see the quorum size and re-key intent). Off-chain, the selected committee runs the DKG ceremony (§3.6.1) and posts the result via RotateCommittee with scope = Account(sender) and new_committee_epoch = 1. On successful RotateCommittee, the chain refunds DKG_BOND in full and clears the DkgPending record. If the DKG ceremony fails to commit by deadline, the DkgPending record stays on chain until expired by ExpireDkgPending (see below). Both RequestAccountDkg and the governance path below emit a cbss.dkg.requested event with payload DkgRequestedEventData { scope, epoch, force_rekey, threshold, committee_metadata } — epoch is the ceremony epoch, committee_metadata carries the selected proxies’ connection details (id / operator / network address / HPKE + DKG public keys), and force_rekey signals a re-key vs first bootstrap. Note the event does not carry deadline (a consumer needing the ceremony deadline reads the DkgPending record, not the event). The off-chain committee daemon consumes this event to run the ceremony (§3.6.1).

GovRequestSystemDkg (opcode 158, provisional)

GovRequestSystemDkg {
    scope: ReleaseKeyScope    // the release-key scope to bootstrap, e.g. Account(0x14)
    force_rekey: bool         // false = first-time bootstrap; true = re-DKG an existing key
}

Sender: GOVERNANCE_SYSTEM_ACTOR (0x09) only — any other tx.from is rejected with Unauthorized. Invocation (how a 0x09-origin tx arises). 0x09 is itself keyless, so — like every 0x09-authorized instruction (UpdateSettlementConfig, SetGovParam) — a GovRequestSystemDkg tx is not externally signed. It is produced by CIP-12 governance-proposal enactment: a passed proposal’s payload is applied deterministically by 0x09 with tx.from = 0x09 (CIP-12 §“payloads are executed deterministically by 0x09”). This REQUIRES a CIP-12 ProposalPayloadKind (e.g. SystemDkgBootstrap { scope, force_rekey }) that ExecuteProposal maps to this instruction — this enactment mapping is a hard implementation dependency and MUST be added alongside the handler, or opcode 158 is unreachable (the handler exists but nothing can originate a 0x09 tx to reach it). See the open item in §9.6. Motivation. RequestAccountDkg derives its scope from sender (scope = Account(sender)) and is authorized by the account’s own signature. A keyless system actor — one whose address holds native ledger/registry state but has no private key and therefore can never be tx.from — cannot use it. The concrete instance is the CIP-34 sealed-bid INTENT_SETTLEMENT committee (Account(0x14)): sealed-bid reveal (CIP-34 §Sealed-Bid) decrypts every bid against 0x14’s CBSS committee, so that committee’s AccountReleaseKey (committee + MPK + shares) MUST exist before any sealed auction can clear — but 0x14 cannot self-issue RequestAccountDkg. GovRequestSystemDkg is the only path that establishes a committee for such a scope, authorized by governance rather than by an owner signature. Effects. Mirrors RequestAccountDkg exactly, with three differences: (i) tx.from MUST equal GOVERNANCE_SYSTEM_ACTOR; (ii) the scope is taken from args.scope rather than from sender; (iii) no DKG_BOND is locked (bond_amount = 0) — governance has no user account to debit, and the permissionless-cleanup incentive is unchanged because ExpireDkgPending on a zero-bond pending simply refunds/slashes nothing. Concretely, on a valid request the chain: VRF-selects n = DEFAULT_N proxies weighted by stake × health_score; writes

DkgPending { scope, force_rekey, committee, threshold = DEFAULT_T, deadline = current_block + DKG_FINALIZE_BLOCKS, bond_amount = 0, requester }

at dkg_pending:{scope_serialized} (requester is the scope’s account, used only for the — here zero — bond accounting); persists the COW-1057 ceremony record so a sabotaging dealer stays slashable after the pending clears; and emits cbss.dkg.requested. Off-chain, the selected committee runs the DKG (§3.6.1) and commits via RotateCommittee with new_committee_epoch = 1 and empty prior_committee_sigs — the same initial-commit path RequestAccountDkg uses. ExpireDkgPending (opcode 81) applies unchanged if the ceremony misses deadline. Validation. The request is rejected with InvalidData if (a) a DkgPending already exists for scope (dedup — one ceremony in flight per scope); (b) a release key already exists for scope and force_rekey == false; or (c) no release key exists for scope and force_rekey == true. In other words force_rekey MUST be set iff the scope already has a live committee — first-time bootstrap uses force_rekey = false, re-establishment uses force_rekey = true. Scope MUST be a keyless system actor (least-privilege). scope MUST resolve to a keyless system-actor address — i.e. an address in the reserved system-actor range (< 0x20, per WP §9.1) that has no private key, such as Account(0x14). The handler MUST reject any other scope (e.g. Account(<user>), or a SecretSpecific under a user account) with Unauthorized. Rationale: without this bound, a passed proposal could GovRequestSystemDkg { scope: Account(<user>), force_rekey: true } and re-DKG a normal user’s account committee — installing a fresh MPK that permanently strands every secret that user ever wrapped. Keyed accounts never need this path (they self-issue RequestAccountDkg), so restricting scope to keyless system actors costs nothing and removes an unnecessary governance power over user secrets. (This is a validation the chain can check locally, unlike the force_rekey-during-open-auction hazard below.) force_rekey is destructive — a safety MUST. A force_rekey re-DKG produces a fresh, independent MPK (via the RotateCommittee initial-commit path, new_committee_epoch = 1), not a reshare of the existing MSK. Every ciphertext bound to the old MPK becomes permanently undecryptable — see §10.7 (MPK is preserved only on reshare, never on a fresh DKG). For the 0x14 sealed-auction committee this means any in-flight sealed bid (a WrappedDek encrypted to the old MPK under identity = request_id) can no longer be revealed, and its auction cancels with no funds moved (both cancel terminals delete state only). The exact terminal depends on the new committee: if it posts partials for the pre-existing tlock request, reveal_auction combines σ under the new MPK, every old-MPK bid fails AEAD, and the auction ends CancelledNoValidBid at reveal_height; if it posts nothing, the reveal stays TlockNotReleased and cancels CancelledGraceExpired after reveal_height + AUCTION_GRACE (CIP-34 §Sealed-Bid). Either way the bids are stranded. Therefore governance MUST NOT force_rekey the 0x14 committee while any sealed auction is open (i.e. any OpenAuction whose reveal_height + AUCTION_GRACE has not passed); doing so silently cancels those auctions. Routine committee refresh that must preserve decryptability MUST use RequestReshare (opcode 83), which rotates the share polynomial while holding MPK fixed (§10.7); force_rekey is reserved for deliberate key replacement (e.g. a disclosed-MSK incident) where stranding old ciphertext is the intent. The chain cannot itself observe cross-subsystem auction state, so this is a governance-procedure invariant, not an on-chain check.

ExpireDkgPending (opcode 81)

Permissionless cleanup of an expired DkgPending record. Settles the bond and emits a public failure event so the requester can retry.

ExpireDkgPending {
    scope: ReleaseKeyScope    // identifies the DkgPending entry to expire
}

Sender: any account. Effects: validates that:

dkg_pending:{scope_serialized} exists.
current_block >= DkgPending.deadline.
No RotateCommittee for this scope has landed (i.e., the DKG didn’t complete in some other path).

On success: refunds (DkgPending.bond_amount - DKG_TIMEOUT_SLASH) to DkgPending.requester; routes DKG_TIMEOUT_SLASH to the slashing pool (a small fraction, default 5% of the bond, governance-tunable); also pays a small fixed reward to the calling account from the slashing pool to incentivize permissionless cleanup. Deletes dkg_pending:{scope_serialized}. If the scope was an override-path SecretSpecific(secret_id, version), the corresponding pending SecretVersion is erased without a tombstone — pending versions are not “real” versions until finalized, so they’re treated as never-having-existed when expired. The chain also rolls back SecretMetadata.latest_version if it was advanced by the abandoned SetSecret, freeing the version slot for retry. Emits DkgExpired { scope, requester, refunded, slashed }. The requester may retry by submitting a fresh RequestAccountDkg (default path) or SetSecret with committee_override (override path). VRF re-selects a committee — likely overlapping but possibly different given health-score and stake updates. Per-secret DKG (override path) is initiated by SetSecret itself with committee_override; there is no separate instruction for it. The same DkgPending record is created (keyed by (SecretId, version) instead of account) and the same off-chain ceremony commits via RotateCommittee with scope = SecretSpecific(...).

ExpireLivenessChallenge (opcode 82)

ExpireLivenessChallenge { challenge_id: Bytes32 }

Auth: permissionless (anyone may crank an expired challenge; there is no sender check). Effects (node/execution/src/cbss.rs::handle_cbss_expire_liveness_challenge):

Charge CBSS_GAS_EXPIRE_LIVENESS_CHALLENGE = 5_000.
Load the challenge; require status == Pending AND current_block > challenge.deadline, else InvalidData.
Transition status → Unanswered and clear the response fields.
proxy.health.unanswered_challenges += 1; apply the capped liveness-attrition penalty (COW-1058: CBSS_LIVENESS_HEALTH_PENALTY_BPS = 100 per unanswered, bounded by CBSS_MAX_HEALTH_LOSS_PER_EPOCH_BPS = 1000) to health.score_bps.
If the penalty crosses below MIN_HEALTH_FLOOR_BPS (or sustained sub-threshold ≥ GOVERNANCE_REVIEW_BLOCKS), write a ProxyGovernanceReviewFlag and emit cbss.proxy.governance_review_required.
Refund the challenge bond to runner_request.body.runner_id.
Delete the liveness dedup-index entry; emit cbss.liveness.expired { challenge_id }.

No stake is slashed — a missed liveness response is a health-score signal only (§4.4).

RequestReshare (opcode 83)

RequestReshare { scope: ReleaseKeyScope }

Auth: release-key owner only. Effects (handle_cbss_request_reshare):

Charge CBSS_GAS_REQUEST_RESHARE = 30_000; ensure_cbss_actor_exists.
Load the release-key material for scope; InvalidData if absent.
Require tx.from == material.owner, else Unauthorized.
Push a reshare_requested event into the CBSS actor event log (which cbssd polls — COW-2338: this is the third reshare trigger alongside the churn and deregister paths). No bond is locked and the committee state is not mutated on-chain; the event signals cbssd to orchestrate the off-chain reshare, which lands via a subsequent RotateCommittee.

ForcedDeregisterCbssProxy (opcode 84)

ForcedDeregisterCbssProxy { proxy_id: ProxyId }

Auth: governance only (tx.from == GOVERNANCE_SYSTEM_ACTOR = 0x09). This is the CIP-12 Tier-1 remediation path for persistent faults or disclosed leaks (§4.3, §5.2). Effects (handle_cbss_forced_deregister_proxy):

Charge CBSS_GAS_DEREGISTER_PROXY = 8_000.
Require tx.from == GOVERNANCE_SYSTEM_ACTOR, else Unauthorized.
Load the proxy (InvalidData if absent); set proxy.suspended = true and proxy.unbond_at = Some(current_block) — immediate unbond, no delay (contrast the voluntary DeregisterCbssProxy path, which still respects the cooldown). If the proxy sits on any live committee, RotateCommittee is enqueued for each affected release key (as in voluntary deregister).
Emit cbss.proxy.forced_deregistered { proxy_id }.

RegisterTlockRelease (opcode 152, provisional)

Registers a time-lock release request (§3.4.6) so the committee knows what identity to sign and when. Permissionless (any account), fee-bearing, rate-limited per block.

RegisterTlockRelease {
    scope:          ReleaseKeyRef    // which committee's MPK this tlock binds to (Account or SecretSpecific)
    tag:            Bytes            // caller identity, ≤ MAX_TLOCK_TAG_BYTES (e.g. a CIP-34 request_id)
    target_height:  u64              // reveal height; MUST be > head + MIN_TLOCK_LEAD_BLOCKS
}

The chain records TlockRequest { scope, tag, target_height, registered_at } keyed by (scope, tag, target_height); a duplicate key is rejected. The record (and any partials posted against it, below) is GC’d at target_height + TLOCK_RETENTION (§4). MIN_TLOCK_LEAD_BLOCKS ensures the committee has time to observe the request before the reveal height.

SubmitTlockRelease (opcode 153, provisional)

A committee proxy posts its partial signature on a registered tlock identity, only once chain head ≥ target_height. Permissionless to read the result; only committee members may submit.

SubmitTlockRelease {
    scope:          ReleaseKeyRef
    tag:            Bytes
    target_height:  u64
    proxy_id:       ProxyId
    partial:        [u8; 48]         // σ_i = s_i · I_tlock ∈ G1, canonical compressed
}

The chain validates: (a) a TlockRequest exists for (scope, tag, target_height); (b) head >= target_height (reject TlockNotYetReleasable otherwise); (c) proxy_id is a current member of the referenced release key’s committee; (d) the BLS partial check e(partial, G2_gen) == e(I_tlock, S_proxy) with identity/point-at-infinity rejection, where I_tlock = hash_to_G1(canonical(tag) || u64_le(target_height), "cbss/tlock/v1"); (e) (scope, tag, target_height, proxy_id) not already submitted (per-proxy dedup). Accumulated partials are public; once ≥ t are posted, any reader Lagrange-combines them into σ = MSK · I_tlock (§3.4.6) — no further authorization. No per-proxy receipt/audit record is written (unlike SubmitReleaseReceipt): time-lock release is public, so there is no access to audit.

3.6 Threshold ceremonies

3.6.1 DKG (initial keypair establishment)

Triggered by RequestAccountDkg (account-scoped) or by SetSecret with committee_override (secret-scoped). Off-chain protocol: The protocol is the standard threshold BLS DKG (FROST-derived for BLS sigs) as exposed by the chosen vetted library. The devnet implementation uses the pinned Commonware BLS DKG state machine. Sketch:

Round 1. Each proxy i samples a random degree-t-1 polynomial f_i(x) over the BLS12-381 scalar field and broadcasts Feldman/Pedersen commitments to its coefficients (peer-to-peer over the committee mesh; no on-chain anchor).
Round 2. Each proxy i sends f_i(j) to each peer j, encrypted under j’s registry pubkey. Recipients verify the share against the broadcast commitments using a single G2 multi-scalar multiplication.
Aggregation. Each proxy computes its share s_i = Σ_j f_j(i) (a scalar), summing only the qualified dealers when timeout/complaint handling excluded a dealer. The group MPK = Σ_j C_{j,0} ∈ G2 (sum of each qualified polynomial’s constant-term commitment in G2). Each proxy’s published VSS commitment S_i = s_i · G2 is computable from the aggregated polynomial commitments at index i.
On-chain commit. Once each proxy has its share s_i and the group MPK, the committee assembles new_committee_sigs — t-of-n signatures over the canonical DKG-commit payload (see RotateCommittee). One proxy posts RotateCommittee(scope, new_committee_epoch = 1, new_mpk, vss_commitments = [S_1..S_n], new_committee_sigs). The chain verifies: (a) each S_i is a valid G2 point, (b) new_committee_sigs.len() >= threshold and all sigs are from members of new_committee over the canonical payload, (c) on a reshare, new_mpk == prior_release_key.mpk. The chain does NOT verify Shamir consistency on chain — that’s the committee’s responsibility off-chain via VSS during DKG, attested to by the threshold signatures. (A naive “sum(S_i) == MPK” check would be mathematically wrong since S_i are polynomial evaluations, not coefficient commitments.)

If any proxy is detected sending malformed shares (verifiable: VSS commitment mismatch), it can be slashed for DkgSabotage (§4.3) by any party submitting the equivocation evidence. Implementation note: cbss-crypto exposes qualified-set finalization so an offline or excluded dealer no longer forces unanimous abort. This does not weaken the ship requirement that the final DKG be vetted and bias-free; the qualified-set hook is ceremony liveness plumbing, not a replacement for the audited DKG protocol. Triggered by:

Scheduled rotation: every RESHARE_INTERVAL_BLOCKS (default ~6 months) for both AccountReleaseKey and SecretReleaseKey records.
Committee churn: when the count of healthy committee members drops to t + RESHARE_SAFETY_MARGIN.
Owner request: the owner of the account (or of the secret in the override case) pays for an immediate reshare.

Protocol: standard proactive secret sharing on the existing MPK. Output is a fresh share polynomial of the same secret, distributed to a possibly-different committee of n proxies. MPK is preserved; committee_epoch increments. Existing SecretVersions retain their wrap_epoch — reshare does not invalidate stored ciphertext or in-flight release requests; PSS guarantees the new shares produce valid partials for any historical identity under the same MPK. The prior epoch’s release-key material is retained for a grace window, so CIP-9 volume wraps keep serving across a reshare for that window; a volume’s epoch-pinned material hash means it must re-wrap to a current epoch before the window closes (contrast the immediate re-wrap forced by a re-key, §9.3.1).

3.6.3 Threshold partial signature (release)

The runtime release operation, per the threshold-IBE construction in §3.4.3. Inputs at the proxy:

The runner’s release request (signed; carries recipient, job_id, request_block, serve_epoch, and request-binding fields). serve_epoch pins which share-polynomial epoch the runner expects partials from; proxies reject with EpochMismatch if their current release-key committee_epoch differs. The IBE identity still comes from the SecretVersion’s immutable wrap_epoch, not from serve_epoch.
The proxy’s local Shamir share s_i ∈ scalar field of BLS12-381 of the implicit MSK.

Each proxy:

Validates the request (§3.7), looking up the relevant AccountReleaseKey or SecretReleaseKey per the request’s recipient field and checking body.serve_epoch == release_key.committee_epoch at current head.
Reads wrap_epoch from the SecretVersion on chain and mpk_g2 = compress(MPK) from the release key looked up in step 1. Computes the identity using the canonical encoding: I = hash_to_G1( u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2, domain = "cbss/ibe/v1" ).
Computes its partial BLS signature on the identity: σ_i = s_i · I (a point in G1).

Returns the canonical PartialSignResponse wire shape:

PartialSignResponse {
    sigma_i:                 G1Bytes
    proxy_id:                ProxyId
    committee_epoch_at_serve: u64                   // current release_key.committee_epoch at the time of partial-sign
    served_at_block:         BlockHeight
    proxy_sig:               Signature              // exact byte layout: see "Canonical domain-separated signature payloads" earlier in §3.5; signed under the proxy identity key with the "cbss/partial-sign-response/v1" domain prefix. SAME bytes as the receipt's proxy_sig — proxy can hand the response into the receipt verbatim.
}

The proxy does NOT include its own VSS commitment in the response — the chain looks up S_i from the release key’s vss_commitments (current or retained-prior epoch) keyed by proxy_id + committee_epoch_at_serve. This prevents a malicious proxy from substituting a different commitment.

No NIZK construction is required — verification (at receipt-submission time) is the standard BLS partial-signature pairing check e(σ_i, G2_gen) == e(I, S_i) against the on-chain VSS commitment S_i ∈ G2. The runner rejects identity/point-at-infinity σ_i partials before combining. It combines t partials via Lagrange interpolation in G1 to obtain the threshold signature σ = MSK · I ∈ G1, reads wrapped_dek.ephemeral_u (decoding it to U), reconstructs aad = u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2 || ephemeral_u, then derives the IBE key K = HKDF(serialize(e(σ, U)), "cbss/ibe/v1" || aad) and AES-GCM-decrypts wrapped_dek with K.

3.7 Proxy-side validation of release requests

Each proxy enforces, on every PartialSign RPC, that: Proxies validate release requests against chain state at the current head (not historical). The table below is the canonical proxy-side validation checklist.

Check	Source of truth
`request_block ∈ [head - REQUEST_FRESHNESS_BLOCKS, head]`	proxy local clock + chain head
Runner registry membership and active status	`0x01` (Runner Registry) at current head
Runner currently assigned to `job_id`	`0x02` (Job Dispatcher) at current head
Actor’s CIP-6 manifest declares the requested `key` under the entitlement matching the release purpose (`secrets.read` for substitution, `secrets.verify` for a `verify=` MAC check; §3.1, §5.5)	actor’s deployed manifest at current head
`SecretPolicy.actors` permits this actor (or `None` and same-account)	`SecretVersion.policy` at current head
If `tee_required`, runner has a live non-revoked `tee_att:{job_id}:{runner}` record written through a trusted-key signed-attestation path	`0x05` (TEE Verifier)
Anti-replay: `(release_id, proxy_id)` not previously served	proxy local bloom (24h) + chain `release_receipt` (dedup is on `release_id`, the stable per-(secret, version, actor, runner, job) tuple — `request_hash` is fresh per `request_block` and is NOT used for dedup)
Per-actor rate limit: ≤ `MAX_RELEASES_PER_ACTOR_PER_HOUR`	proxy local
Proxy is a member of the referenced release key’s `committee` at current head	`0x04`
`body.serve_epoch == release_key.committee_epoch` at current head (proxy rejects with `EpochMismatch` if reshare landed between request_block and serve time)	`0x04`
`SecretVersion.pending == false`	`0x04`

Revocation propagation semantics. Revocations (e.g., UpdateSecretPolicy removing an actor) are effective at chain finality. Proxies MAY cache chain reads with TTL ≤ PROXY_CACHE_TTL_BLOCKS. Net worst-case revocation latency is finality_blocks + PROXY_CACHE_TTL_BLOCKS × block_time. There is no “instant atomic” revocation claim — revocation is “effective at finality + cache TTL of any participating proxy.” A runner who tries to use a revoked credential between revocation and propagation gets a partial that’s authorized at the now-stale cached state; this is a documented and bounded window, NOT a vulnerability. Failures are reported with structured error codes (StaleRequestBlock, SecretAccessDenied, SecretPending, SecretCommitteeUnavailable, etc.); the runner retries with corrected inputs.

3.8 Runner pull flow

1. Actor task invokes runner.http(..., secrets=["SLACK_API_KEY"]).
2. Runner R looks up the secret-owning account (the actor's owning account by default,
   or the explicit cross-account owner if the entitlement uses {account, key} form).
   The runner-side SDK computes key_hash = keccak256(account || "SLACK_API_KEY") locally;
   plaintext key never leaves the runner sandbox.
3. Runner R syscalls SYS_FETCH_SECRET_METADATA(secret_id = SecretId{account, key_hash},
   version_or_latest) → SecretMetadata + the referenced ReleaseKey snapshot
   (Account or SecretSpecific). The syscall takes SecretId, not plaintext.
4. Runner R picks t of n committee proxies (prefers non-suspended, healthier, low-latency proxies; fall-through to remaining n-t on failure).
5. Runner R generates a fresh release_nonce (CSPRNG, 32 B), reads the release key's
   current committee_epoch as serve_epoch, assembles ReleaseRequestBody
   with request_block = current chain head and serve_epoch = committee_epoch,
   signs it with its runner-registry key
   (NOT an ephemeral key — see §3.4.5 / §3.5 for the registry-key requirement).
   Sends SignedReleaseRequest = { body, runner_sig } to t of n committee proxies in parallel
   (preferring non-suspended, healthier, low-latency proxies; fall-through to remaining n-t on failure).
6. Each proxy validates (§3.7), decrypts its local sealed share with AAD bound to `(release-key scope, committee_epoch)`, verifies the scalar against the VSS commitment polynomial, and returns its BLS partial signature σ_i on the identity
   (PartialSignResponse with sigma_i, committee_epoch_at_serve, served_at_block, proxy_sig).
7. Runner R verifies each σ_i with a single pairing check against the proxy's VSS commitment
   (looked up on chain by proxy_id + committee_epoch_at_serve);
   rejects duplicate proxy indexes, and Lagrange-combines σ_i to produce σ = MSK · I.
8. Runner R reads `wrapped_dek.ephemeral_u` (decoding it to `U`), reconstructs `aad = u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2 || ephemeral_u`, derives K = HKDF(serialize(e(σ, U)), "cbss/ibe/v1" || aad), and AES-GCM-decrypts wrapped_dek → DEK.
9. Runner R fetches CBFS object, AES-GCM-decrypts with DEK + AAD verification → plaintext.
10. Runner R passes plaintext to the in-memory ${SLACK_API_KEY} substitutor at request-construction
    in runner-http / runner-mcp. NO process-wide env var injection on the default path
    (see §3.9).
11. Runner R executes the templated request.
12. Runner R zeroizes plaintext, DEK, σ partials.
13. Each of the t participating proxies independently submits SubmitReleaseReceipt
    (handing the SignedReleaseRequest verbatim into the receipt). Runner does NOT submit
    any audit/payment tx; payment flows directly proxy ← actor account, capped at quorum t.

Latency target: < 250 ms p50 for the threshold round (5 proxies, 3 same-continent, parallel) + pairing-verify + AES-GCM-decrypt + CBFS fetch. Bottleneck: the threshold round-trip and CBFS fetch (parallelizable with the threshold round).

3.9 Runtime sandbox: in-memory secret bundle (default), env vars only for spawned subprocesses

Default path: in-memory template substitution, no process env vars. Process-wide environment is leaky — other threads, libraries, signal handlers, /proc/$pid/environ reads, and crash dumps can all observe it; serialization mutexes only help cooperating code. The default release path therefore:

Holds plaintext in a Zeroizing<Vec<u8>> SecretBundle keyed by KeyName.
Performs ${KEY} substitution at request-construction time inside runner-http / runner-mcp (against headers, URL, body, JSON tool args) — the substitution layer reads the bundle directly without touching the process environment.
Drops the bundle (zeroizes) at the end of the runner-op.
Never sets os.environ[KEY] for HTTP / MCP / LLM tool calls.

Subprocess path: explicit env map, no process env mutation. Some integrations (notably MCP stdio servers spawned by the runner) require a child process that reads its credentials from the environment. For these:

Build an explicit env: HashMap<String, Zeroizing<String>> for the child.
Pass via Command::env_clear().envs(env) — the child inherits ONLY the named entries, not the parent’s environment.
The parent’s process environment is never mutated.
Drop the Command builder immediately after spawn and zeroize the source env map.
Residual exposure: Rust’s std::process::Command copies env values into its own platform-specific storage before spawning, and the standard library does not guarantee that copy is zeroized. Treat subprocess env delivery as an explicit compatibility exception, not the default secret path.

PVM Python guardrails:

The actor’s PVM Python code observes only ${KEY} placeholders. The PVM does not have a SecretBundle reference; substitution happens at the runner layer, after the syscall boundary.
Direct os.environ[KEY] reads from PVM Python are blocked by the sandbox for any key declared in the actor’s secrets.read entitlement (deny-list installed at sandbox init).
Logging adapters scrub strings matching active bundle values from spans and trace events on a best-effort basis. The primary defense is preventing PVM Python from ever holding the value.

Process-wide env injection is unsafe by default for the reasons listed above. The bundle-and-substitute pattern keeps plaintext bounded to the request-construction code path.

4. Parameters

All parameters governance-tunable via CIP-12 Tier 0 proposals.

4.1 Gas

Instruction	Default cost	Notes
`SetSecret` (default path)	`12_000`	Single wrapped_dek, no DKG.
`SetSecret` (override path, intent only)	`8_000 + 30_000 + DKG_BOND`	No ciphertext yet; just enqueues DKG.
`FinalizeSecretVersion`	`8_000`	Attaches ciphertext post-DKG; cheap.
`UpdateSecretPolicy`	`6_000`	Pure metadata; no re-wrap.
`DeleteSecretVersion`	`5_000` + CBFS-drop fee	CBFS-drop reuses CIP-9 §6 cost. Cascades to `SecretReleaseKey` deletion if override.
`DeleteSecret`	`5_000 × num_versions`	Linear in versions; bounded by `MAX_VERSIONS_PER_SECRET`.
`RegisterCbssProxy`	`15_000`	One-time.
`DeregisterCbssProxy`	`8_000`	Plus reshare costs incurred by `RotateCommittee`.
`RotateCommittee`	`25_000 + 1_000 × n`	Heavy because of VSS verification.
`SlashCbssProxy`	`12_000 + evidence-verification cost`	Verification varies per `FaultClass`.
`SubmitReleaseReceipt`	`8_500`	Two pairing checks (BLS partial-sig verify) + runner sig verify + proxy sig verify per receipt. Submitted independently by each of t proxies.
`RequestAccountDkg`	`30_000 + DKG_BOND`	DKG bond returned on success, partially slashed on timeout.
`GovRequestSystemDkg`	`30_000`	Same DKG cost as `RequestAccountDkg`, but no `DKG_BOND` — governance (`0x09`) has no user account to bond; the fee is paid from the governance actor.
`SubmitLivenessChallenge`	`5_000`	Anchors a challenge; deducted from runner.
`LivenessChallengeResponse`	`4_000`	Proxy’s response.

4.2 Stake / committee

Block-time basis (normative): this chain runs at 1 second per block (BLOCKS_PER_YEAR = 31_536_000, 1 day = 86_400 blocks, node/types/src/constants.rs). Every duration-in-blocks below is computed against 1 s/block. (Earlier revisions derived some counts at ~12 s/block; those blocks values were 12× too small even where the wall-clock annotation was right — e.g. REQUEST_FRESHNESS and GOVERNANCE_REVIEW.) ⚠️ Deployed-value deltas (2026-07): a few defaults below are governance-tunable and the deployed value differs; the deployed value is authoritative until governance sets otherwise. PROXY_SOAK_PERIOD — deployed 100 (execution/src/cbss.rs, a devnet/launch-short soak), vs the ~30-day mainnet target. RESHARE_INTERVAL_BLOCKS — deployed 1_296_000 (~15 days, a deliberate demo-scale cadence), vs the ~6-month production default. MIN_PROXY_STAKE — deployed 1_000 CBY (CBSS_MIN_PROXY_STAKE), not 10,000; open decision cowboy#238. GOVERNANCE_REVIEW_BLOCKS — corrected to 2_592_000 in code (see cowboy#243). These economic/launch values are governance decisions, not spec-edited here.

Parameter	Default	Description
`MIN_PROXY_STAKE`	`10,000 CBY × 10⁹ wei`	Minimum operator stake.
`PROXY_SOAK_PERIOD`	deployed `100` (devnet/launch-short); mainnet target ~30 days = `2_592_000` at 1 s/block (see §4.2 note)	Before VRF-eligibility.
`UNBOND_COOLDOWN`	`100,800 blocks` (~14 days)	Stake locked during slashing window.
`MIN_COMMITTEE_SIZE_FLOOR`	`5`	If eligible-set < 5, new DKGs are queued; existing keys continue to function.
`DEFAULT_N`	`5`	Default committee size for account-scoped DKG.
`DEFAULT_T`	`4`	Default release threshold for the five-proxy account DKG. This matches the vetted Commonware `N3f1` quorum for `DEFAULT_N = 5`; override path admits up to `MAX_OVERRIDE_N`.
`MIN_OVERRIDE_T`	`3`	Floor on per-secret override threshold.
`MAX_OVERRIDE_N`	`15`	Ceiling on per-secret override committee size. Bounds DKG cost. Spec-only — not currently a hard on-chain check (no `MAX_OVERRIDE_N` / `MAX_COMMITTEE_N` constant in code; `n` is bounded by DKG / `RotateCommittee` args). The former secrets-WP §13 `MAX_COMMITTEE_N = 16` divergence was resolved when that table was aligned to deployed code (#261).
`RESHARE_INTERVAL_BLOCKS`	prod target ~6 months (`15_552_000` at 1 s/block); deployed `1_296_000` (~15 days, demo-scale — see §4.2 note)	Scheduled reshare cadence (per release key, account or secret-scoped). Governance-tunable.
`RESHARE_SAFETY_MARGIN`	`1`	Trigger reshare when healthy < `t + margin`.
`DKG_FINALIZE_BLOCKS`	`7_200` (~2 hours at 1 s/block)	DKG ceremony deadline.
`LIVENESS_RESPONSE_BLOCKS`	`64` (~64 s)	Window for a proxy to respond to a `SubmitLivenessChallenge` before the challenge transitions to `Unanswered`. Note: NO automatic slash follows — it’s a health-score signal only.
`REQUEST_FRESHNESS_BLOCKS`	`384` (~6.4 min at 1 s/block)	Maximum age of `request_block` accepted by proxies and chain receipts. Bounds revocation propagation latency.
`RESHARE_GRACE_BLOCKS`	`100` (~20 min)	Window after a `RotateCommittee` during which receipts under that prior epoch are still accepted (paired against retained prior commitments). After expiry, the entry is GC’d and stale-epoch receipts are rejected.
`MAX_PRIOR_COMMITTEE_EPOCHS`	`4`	Maximum simultaneously-retained prior committee epochs per release key. Allows up to 4 reshares within one `RESHARE_GRACE_BLOCKS` window without losing prior-epoch receipts. Exceeding the cap causes `RotateCommittee` to fail with `ReshareGraceCapacity` until at least one prior epoch’s grace window expires.
`PROXY_CACHE_TTL_BLOCKS`	`4` (~48 s)	Maximum staleness of proxy-cached chain reads.
`RELEASE_FEE_PER_RECEIPT`	`governance-tunable`	Fee debited from actor account on each `SubmitReleaseReceipt`. Goes to the submitting proxy.
`MAX_RELEASE_OVERDRAFT`	`16 × RELEASE_FEE_PER_RECEIPT`	Maximum negative release-payment balance an actor may incur from receipts before further receipts are rejected with `ActorAccountInsufficient`. Below this cap, the proxy is paid even on insufficient balance and the actor is marked `delinquent`. Implementations may represent this with negative account balance or a separate release-debt ledger.
`LIVENESS_CHALLENGE_BOND`	`governance-tunable` (lean: 10× standard tx fee)	Bond locked from the runner at `SubmitLivenessChallenge`. On `Resolved`, forfeited to the challenged proxy. Refunded to the runner on `Unverifiable` and `Unanswered`.
`MIN_CHALLENGE_DELAY_BLOCKS`	`REQUEST_FRESHNESS_BLOCKS + 32` = `416` (~7 min)	Minimum elapsed blocks between a `body.request_block` and a `SubmitLivenessChallenge` referencing it. MUST be greater than `REQUEST_FRESHNESS_BLOCKS`, so valid receipts are either already on chain or impossible to submit by the time a challenge is admissible. Premature challenges rejected with `ChallengePremature`.
`LIVENESS_CHALLENGE_MAX_AGE_BLOCKS`	`MIN_CHALLENGE_DELAY_BLOCKS + LIVENESS_RESPONSE_BLOCKS` = `480` (~8 min)	Maximum elapsed blocks between `body.request_block` and challenge submission. Must be meaningfully greater than `MIN_CHALLENGE_DELAY_BLOCKS`; older requests can no longer be challenged.
`DKG_BOND`	`governance-tunable`	Refundable bond locked at `RequestAccountDkg` / override-`SetSecret` time. Refunded on successful DKG commit; reduced by `DKG_TIMEOUT_SLASH` on `ExpireDkgPending`.
`DKG_TIMEOUT_SLASH`	`5%` of `DKG_BOND`	Portion of the DKG bond forfeited to the slashing pool when `ExpireDkgPending` settles an expired `DkgPending` record. Caller of `ExpireDkgPending` receives a small fixed cleanup reward from this pool.
`MIN_HEALTH_FLOOR`	`0.05`	Floor on the per-proxy health-score multiplier applied to VRF weight. Prevents complete exclusion that would block reshare unanimity.
`GOVERNANCE_REVIEW_BLOCKS`	`2,592,000` (~30 days at 1 s/block)	Window of sustained `health_score < 0.1` required to flag a proxy for an automatic CIP-12 Tier 1 deregistration proposal.
`MAX_LEAK_REIMBURSEMENT`	`100,000 CBY × 10⁹ wei`	Cap on the remediation-pool payout per disclosed plaintext-leak incident (governance-mediated; see §4.3).
`MAX_IBE_AAD_BYTES`	`4096`	Hard cap on the AEAD AAD length accepted by the IBE kernel for any CBSS envelope (§3.4.3). CIP-24 secret wraps use exactly 268 bytes (172-byte `base_aad` + 96-byte `compress(U)`) and CIP-9 volume wraps exactly 128 (§9.3); the cap bounds the shared-kernel surface (CIP-7 AADs are variable-length).
`MAX_IBE_CIPHERTEXT_BYTES`	`1 MiB` (`1,048,576`)	Hard cap on IBE-envelope ciphertext length (§3.4.3).

4.3 Slashing schedule

Provable on-chain only. PlaintextLeak and liveness non-receipt are NOT auto-slash:

PlaintextLeak: evidence requires publishing the secret. Handled via off-chain disclosure → CIP-12 Tier 1 ForcedDeregisterCbssProxy.
Liveness non-receipt: not provable on chain (packet delivery is not chain-witnessable). Handled via the §4.4 health score → governance review.

Fault	Penalty	Detection
`InvalidPartialReencrypt`	5%	BLS partial-signature pairing check fails on a submitted `σ_i` (any party can submit the failing partial as evidence)
`DkgSabotage`	5%	VSS commitment / share mismatch in DKG round 2
`Equivocation`	50%	Two distinct signed responses to the same `request_hash`

PlaintextLeak handling: a disclosed leak triggers a CIP-12 Tier 1 proposal that, if passed, calls ForcedDeregisterCbssProxy(proxy_id) and routes the entire stake to a remediation pool. The remediation-pool payout itself is governance-mediated (lean: capped at MAX_LEAK_REIMBURSEMENT = 100,000 CBY per incident). Liveness handling: see §4.4 health score. No automatic stake loss on liveness; persistent degradation drives governance review.

4.4 Health score

Each proxy carries a health score in [0.0, 1.0], decayed and updated based on observable behavior. Used as a multiplier on VRF selection weight; persistent low scores escalate to governance review.

Signal	Effect
`SubmitReleaseReceipt` (positive completion)	small positive
`SubmitLivenessChallenge → Resolved` via admission-time receipt check (chain-verifiable; proved liveness via receipt)	small positive on the proxy; bond forfeited to the challenged proxy.
`SubmitLivenessChallenge → Unverifiable` via `LivenessChallengeResponse` with `InvalidRequest`, `RateLimited`, or `NeverReceived` (chain-unverifiable)	NEUTRAL on proxy — no automatic decrement. Bond refunded to runner. Pattern detection in off-chain governance.
`SubmitLivenessChallenge → Unanswered` (proxy submits no response by `deadline`)	negative on proxy; bond refunded to runner.
Slashing event (any FaultClass)	large negative
Sustained healthy uptime (per epoch)	small positive

Concrete coefficients are governance parameters (CIP-12). The protocol enforces only that VRF weight = stake × max(MIN_HEALTH_FLOOR, health_score), where MIN_HEALTH_FLOOR (default 0.05) prevents complete exclusion that would block reshare unanimity. Persistent extreme degradation (health < 0.1 for ≥ GOVERNANCE_REVIEW_BLOCKS ≈ 30 days) flags the proxy for an automatic CIP-12 Tier 1 deregistration proposal. Governance vote follows.

4.5 Quotas / limits

Carrying forward from the design notes §5.4 with no changes:

Parameter	Default	Description
`MAX_SECRETS_PER_ACCOUNT`	256	Total distinct keys per owner.
`MAX_VERSIONS_PER_SECRET`	32	Active versions retained.
`MAX_SECRET_VALUE_BYTES`	65,536	Per-version plaintext cap.
`MAX_ACL_ACTORS`	64	Distinct actor addresses per ACL.
`MAX_SECRETS_PER_RUNNER_OP`	8	`secrets=[...]` length.
`MAX_RELEASES_PER_ACTOR_PER_HOUR`	1,000	Per-proxy-enforced rate limit.
`MAX_TLOCK_TAG_BYTES`	64	Time-lock `tag` length (§3.4.6); a CIP-34 `request_id` is 32 B.
`MIN_TLOCK_LEAD_BLOCKS`	16	Min lead between `RegisterTlockRelease` and `target_height` (committee observe window).
`MAX_TLOCK_REGISTRATIONS_PER_BLOCK`	256	Per-block cap on new tlock registrations (anti-grief / bounded committee work).
`TLOCK_RETENTION`	256 blocks	A `TlockRequest` + its posted partials are GC’d at `target_height + TLOCK_RETENTION`.

5. SDK surface (CIP-6 extension)

5.1 New entitlement

{ "id": "secrets.read",
  "params": {
    "keys": [
      "SLACK_API_KEY",
      "OPENAI_API_KEY",
      { "account": "0xacct1...", "key": "SHARED_API_KEY" }
    ]
  }
}

Subset upgrade rule (CIP-6 §12.1) applies: an actor upgrade may remove keys from this list but never add them. Cross-account form {"account", "key"} is the canonical wire shape. secrets.verify (§5.5) grants verify-only use of a key as an inbound-MAC key. Same keys shape and subset-upgrade rule. A key listed under secrets.verify is releasable for a verify= MAC check but is not readable via secrets=[...] (no ${VAR} substitution) unless also listed under secrets.read — this is what stops an actor from exfiltrating a signing secret it can only verify with. A key MAY hold both grants; within a single job the §5.5 overlap rule still forbids the same key serving both roles.

{ "id": "secrets.verify",
  "params": { "keys": [ "SLACK_SIGNING_SECRET" ] } }

The CIP-6 §14.3 entitlement registry table MUST be amended in the same PR to add:

Entitlement	Scope	Action	Constraints	Role
`secrets.read`	secret	read	`params.keys: List<KeyName \| {account, key}>`	actor
`secrets.verify`	secret	verify	`params.keys: List<KeyName \| {account, key}>`	actor

5.2 Runner-op kwarg

await runner.http(
    "https://hooks.slack.com/services/...",
    headers={"Authorization": "Bearer ${SLACK_API_KEY}"},
    secrets=["SLACK_API_KEY"],
)

await runner.mcp(
    server="github",
    tool="create_issue",
    args={"token": "${GITHUB_TOKEN}", "title": "..."},
    secrets=["GITHUB_TOKEN"],
)

# Pin a specific version:
await runner.http(..., secrets=[("SLACK_API_KEY", {"version": 3})])

# Cross-account:
await runner.http(..., secrets=[("SHARED_API_KEY", {"account": "0xacct1..."})])

runner.llm accepts secrets=[...] only when the LLM op orchestrates server-side tool calls that need them (e.g., MCP tool plumb-through). Plain text-completion calls reject secrets=[...] with SecretsNotApplicableHere.

5.3 Errors

Canonical error names — implementations MUST use these to avoid divergent vocabularies. SDK / runner / proxy / chain handlers all map their failure modes to this set.

// Lookup / state failures
SecretNotFound                 // no SecretMetadata for (account, key_hash)
SecretVersionDeleted           // version was deleted by owner
SecretPending                  // override-path version awaiting FinalizeSecretVersion
SecretAccessDenied             // ACL or manifest entitlement does not permit (actor, runner) — including a
                               // purpose mismatch (§3.1, §5.5): a verify= key the actor does not hold under
                               // secrets.verify, or a secrets=[...] reference to a key held only under secrets.verify
SecretRequiresTEE              // policy.tee_required = true and runner has no valid CIP-23 attestation
SecretQuotaExceeded            // hit MAX_SECRETS_PER_ACCOUNT / MAX_VERSIONS_PER_SECRET / MAX_ACL_ACTORS / etc.
SecretCommitteeUnavailable     // < t proxies responsive at fetch time
SecretDkgInProgress            // initial ceremony in flight (account or secret-scoped override)
SecretsNotApplicableHere       // runner.llm with secrets=[...] but no server-side tool plumbing

// Setup-time failures
MissingAccountReleaseKey       // SetSecret-time failure on default path with no AccountReleaseKey on file
WrapEpochMismatch              // SetSecret/FinalizeSecretVersion: claimed wrap_epoch ≠ release_key.committee_epoch at submission
AadMismatch                    // wrapped_dek full-AAD mismatch (incl. wrong chain_id or substituted mpk_g2) or malformed len != 172 + 96 (268); expected u64_be(chain_id) || canonical(SecretId) || u64_le(version) || u64_le(wrap_epoch) || mpk_g2 || ephemeral_u, chain_id + mpk_g2 re-derived from committed state
UnsupportedWrappedDekVersion   // wrapped_dek.version != 2 — canonical typed error for unsupported envelope tags; implementations map local decode/validation failures to this taxonomy; §3.1
RecipientMismatch              // runner_request.body.recipient ≠ SecretVersion.recipient (anti-committee-substitution)

// Freshness / ordering
StaleRequestBlock              // body.request_block outside REQUEST_FRESHNESS_BLOCKS window
StaleChallenge                 // SubmitLivenessChallenge submitted after LIVENESS_CHALLENGE_MAX_AGE_BLOCKS from body.request_block
StaleCommitteeEpoch            // committee_epoch_at_serve neither current nor in retained prior_committee_epochs
EpochMismatch                  // proxy's current release_key.committee_epoch differs from body.serve_epoch (runner pinned a different epoch than the proxy's current view); runner must re-issue with fresh release_nonce + updated serve_epoch
ReshareGraceCapacity           // RotateCommittee would exceed MAX_PRIOR_COMMITTEE_EPOCHS; wait for grace window to expire

// Signature / proof failures
InvalidRunnerSignature         // runner_request.runner_sig fails verification against runner registry
InvalidProxySignature          // SubmitReleaseReceipt.proxy_sig or PartialSignResponse.proxy_sig fails verification
InvalidPartialReencrypt        // malformed identity/partial/commitment or BLS pairing check e(σ_i, G2_gen) == e(I, S_i) fails — auto-emits slashing-evidence event

// Receipt / dedup failures
ReceiptAlreadyRecorded         // (release_id, proxy_id) already exists in release_receipt
ReceiptOrderingInvalid         // served_at_block < request_block, or > submission_block
QuorumAlreadyReached           // release_receipt:{release_id} already has t entries; additional receipts rejected (caps payment at quorum)
MixedEpochReceipts             // committee_epoch_at_serve ≠ body.serve_epoch / quorum_epoch initialized from the runner-pinned serve_epoch; reject (Lagrange combine requires single-polynomial partials)
ActorAccountInsufficient       // SubmitReleaseReceipt would push actor release debt past −MAX_RELEASE_OVERDRAFT; receipt rejected, proxy not paid for this attempt
LivenessChallengeAlreadyOpen   // (release_id, proxy_id) already has an open challenge (per-release dedup)
ChallengePremature             // SubmitLivenessChallenge submitted before MIN_CHALLENGE_DELAY_BLOCKS elapsed since body.request_block

// Time-lock release failures (§3.4.6)
TlockTagTooLong                // RegisterTlockRelease tag exceeds MAX_TLOCK_TAG_BYTES
TlockLeadTooShort              // RegisterTlockRelease target_height not > head + MIN_TLOCK_LEAD_BLOCKS
TlockAlreadyRegistered         // a TlockRequest for (scope, tag, target_height) already exists
TlockRegistrationCapExceeded   // MAX_TLOCK_REGISTRATIONS_PER_BLOCK reached for this block
TlockNotRegistered             // SubmitTlockRelease for an unregistered (scope, tag, target_height)
TlockNotYetReleasable          // SubmitTlockRelease while head < target_height (premature reveal)
TlockPartialAlreadySubmitted   // (scope, tag, target_height, proxy_id) already submitted (per-proxy dedup); the BLS pairing failure reuses InvalidPartialReencrypt

// Decryption failures (runner-side / SDK)
CiphertextCorrupted            // AES-GCM auth tag mismatch on wrapped_dek or CBFS object

// Inbound verification (§5.5 verify= / JobPrecondition)
JobPreconditionFailed             // verify= MAC mismatch on the runner; fail-closed and terminal (§5.5) —
                                  // no executor work, no read-set release, no retry/reassignment
JobPreconditionUnsupportedAlgo    // verify.algo not in the closed enum; admission-time reject
                                  // (node admission maps its `unsupported_algo` validation code here)
JobPreconditionMessageTooLarge    // verify.message exceeds the 64 KiB cap; admission-time reject before
                                  // any CBSS release (node: `message_too_large`)

5.4 CLI

cowboy secrets set <key> <value> [--actors=A,B] [--account=...] [--tee-required] [--committee-override] [--threshold=T/N]
cowboy secrets list [--account=...]
cowboy secrets versions <key>
cowboy secrets policy <key> [--add-actor=...] [--remove-actor=...] [--tee-required=true|false]
cowboy secrets delete <key> [--version=N]
cowboy proxy register --stake 10000CBY  # operator-side; publishes network_addr + HPKE public key
cowboy proxy status
cowboy proxy reshare-status

5.5 Inbound-verification precondition (`verify=`)

Some runner-ops receive an inbound, externally-signed request (e.g., a Slack slash-command callback) and need to check the caller’s signature before proceeding — without pulling the underlying secret’s plaintext into the actor’s own code, only into the runner sandbox that already holds it for the op. CIP-24 adds an optional inbound-verification precondition to a job, exposed to callers as a verify= kwarg alongside secrets= (§5.2):

await runner.http(
    "https://internal.example.com/slack/handler",
    ...,
    verify=VerifyInput(
        secret=("SLACK_SIGNING_SECRET", {"account": "0xacct1..."}),
        message=raw_request_body,
        signature=x_slack_signature_header,
        # Provider-NEUTRAL crypto: Slack = HMAC-SHA256, hex, "v0=" prefix.
        # "Slack" lives in the actor, never on the wire or in consensus.
        algo=VerifyAlgo.Hmac(hash=Sha256, encoding=Hex, prefix=b"v0="),
    ),
)

verify= normalizes to an optional JobPrecondition on the job spec:

JobPrecondition {
    secret_ref:  SecretKeyRef   // §3.1 — {account, key_hash}; not a plaintext key name
    message:     Bytes          // exact bytes the signature was computed over
    signature:   String         // algo-specific encoding
    algo:        VerifyAlgo     // closed enum
}

VerifyAlgo carries provider-neutral crypto primitives only — never a provider name. This is the two-layer split: the provider-specific parts (the message preimage construction and the prefix choice) live in the actor / the connector’s integration definition at the control plane; the wire and consensus carry only neutral crypto. The single scheme today is Hmac:

VerifyAlgo = Hmac { hash: MacHash, encoding: SigEncoding, prefix: Option<Bytes> }
MacHash     = Sha1 | Sha256          // closed enum, tags 0/1
SigEncoding = Base64 | Hex           // closed enum, tags 0/1

The runner computes [prefix ‖] encoding(HMAC-<hash>(secret, message)) and compares it constant-time to signature. prefix is a small scheme-version tag (≤ 16 bytes), None for a bare encoded MAC. Provider profiles are just field values:

Provider	`hash`	`encoding`	`prefix`
Twilio (`X-Twilio-Signature`)	`Sha1`	`Base64`	none
Slack (`v0=`)	`Sha256`	`Hex`	`"v0="`
GitHub (`sha256=`), Stripe, generic HMAC	`Sha256`	`Hex`	scheme prefix / none

Adding an HMAC-based webhook provider requires no protocol change — it is a new set of field values chosen by the actor. Implementations MUST reject any unknown MacHash/SigEncoding/VerifyAlgo tag (fail-closed, same discipline as HttpMethod) and an over-cap prefix. A genuinely new crypto scheme (e.g. ed25519 / RSA webhook signatures) — not a new provider — would add a new VerifyAlgo variant (tag 1+) via a CIP-24 amendment. Admission checks. Both of the following are pure (no chain/registry state) and MUST be enforced in the same admission gate as the job spec’s other structural checks, before any secret lookup or release is attempted:

Message length cap. len(precondition.message) MUST NOT exceed 64 KiB (65536 bytes). A verify= request whose message exceeds the cap is rejected at admission, before verification is attempted.
Secret-ref-overlap rule (CIP-24 #37). precondition.secret_ref MUST NOT overlap — i.e., MUST NOT be the same {account, key_hash} pair — with any entry in the job’s secret_refs (the secrets= read set, §5.1/§5.2). A single job may verify a signature keyed by a given secret, or read that secret’s plaintext into the sandbox, but not both for the same {account, key_hash} in the same job.

Motivation. An actor that ingests an authenticated inbound webhook — e.g. a Slack Events request, HMAC-signed with a shared signing secret — cannot verify the signature in its on-chain handler: validators cannot threshold-decrypt CBSS secrets (§3.9), and storing the signing secret in plaintext actor state both leaks it (validator- and indexer-readable) and defeats the threshold model. Verification must therefore happen on a runner — the only tier that can release the secret — but without an extra round-trip and without trusting the gateway/ingress. verify= folds verification into the front of the runner op the actor was already going to dispatch. Why a distinct secrets.verify entitlement (not secrets.read). The signing secret is not an outbound credential. If it were grantable via secrets.read, an actor could list it in secrets=[...] and exfiltrate it by reflecting ${VAR} into a request header or body. secrets.verify grants only the right to use a key as a verify= MAC key (§5.1): the runner refuses to place a verify-scoped key into the substitution bundle, and the release authorizer denies any reference whose purpose does not match the key’s grant (§3.1, SecretAccessDenied). A key MAY hold both grants; the overlap rule above still forbids both roles for the same key within one job. Fail-closed ordering (normative). Within a runner op carrying verify=, the runner MUST, in order: (1) release verify.secret_ref under the secrets.verify purpose; (2) compute the MAC over message and compare it constant-time to signature; (3) on mismatch, abort with JobPreconditionFailed and invoke no executor — no HTTP request, no agent loop, no MCP call, no outbound side effect; (4) only on match, release the secrets=[...] read set, substitute, and execute. The runner MAY prefetch read-set secret metadata and plan committee fanout before the MAC check, but MUST NOT release or substitute any read-set plaintext until the MAC passes — a forged webhook never triggers a read-set release. The verify plaintext is confined to a verify-only ephemeral: it MUST be zeroized before the executor runs, and it never enters the ${VAR} SecretBundle (§3.9). JobPreconditionFailed is terminal: the assignment MUST NOT be retried or reassigned on MAC failure. Message canonicalization. message is opaque bytes on the wire (base64 in the SDK JSON surface; the runner decodes to exact bytes and never parses or re-serializes them). The runner is preimage-agnostic — it MACs the bytes it is handed — so the actor MUST construct message as the provider’s exact canonical preimage over the verbatim received body. For the Slack profile (Hmac{Sha256, Hex, "v0="}), the actor constructs message as exactly b"v0:" + ascii(timestamp) + b":" + raw_body and the runner accepts iff signature == "v0=" + lowerhex(HMAC_SHA256(secret, message)). For the Twilio profile (Hmac{Sha1, Base64, none}), message is the URL followed by each POST param name+value in sorted order, and the runner accepts iff signature == base64(HMAC_SHA1(secret, message)). Any JSON re-encode, unicode round-trip, or whitespace normalization changes the bytes and MUST fail; a conformance test SHOULD sign a body with duplicate keys, trailing whitespace, and non-ASCII to ensure a reparsing implementation cannot pass by accident. New HMAC-based providers (GitHub sha256=, Stripe, …) are new Hmac field values chosen by the actor, never new protocol variants. Threat model / DoS bound (normative, honest). The precondition authenticates the payload, not the dispatch: the actor still chooses to dispatch on an unverified inbound request, so a forged webhook costs one chain dispatch plus at most one verify-release attempt per assigned runner before the MAC fails and the op aborts terminally — and nothing more: no read-set release, no executor work, no outbound side effect, no plaintext leak. Because adaptive committee sizing MAY assign M runners to an op, verify-precondition ops SHOULD execute single-runner (redundancy buys nothing for a fail-closed gate), and JobPreconditionFailed being terminal prevents reassignment from multiplying attempts. Actors SHOULD further bound the residual with on-chain, secret-free prefilters applied before dispatch: a message-size cap, a timestamp-freshness window, exact-replay suppression keyed on (ts, signature, body_hash) — the only fields fixed before the MAC; it drops byte-identical resends but is not forgery prevention — and, the real ceiling, actor-level per-interval rate and spend caps. Per-channel / per-user limits are best-effort only: the attacker controls the body before the MAC passes, so sender identity cannot be authenticated pre-verification. The guarantee verify= provides is that no forged request ever produces an authenticated side effect or a read-set release; the cost it does not eliminate is the bounded dispatch + verify-release attempt(s), which the spend cap ceilings.

6. Implementation notes

6.1 Crate layout

Crate	Status	Purpose
`runner/crates/secrets-manager`	implemented for devnet	Hosts the runner-side `SecretsClient`. The pre-existing trait (`store_secret` / `get_secret` / `update_secret` / `delete_secret`) is removed; those owner-side operations are CLI/chain-client concerns. Current implementation has the threshold combiner/decrypt helper, a trait-based `ThresholdSecretsClient` core with bounded concurrent fanout/fallback and per-proxy timeouts across committee members, `HttpChainSecretMetadataResolver` for the node `GET /cbss/secret/{account}/{key_hash}?version=` metadata endpoint, `Secp256k1ReleaseRequestSigner` for chain-compatible runner request signatures, and encrypted ciphertext fetchers for the CBSS/CBFS blob path. `ProxyEndpoint` carries TLS SPKI pins plus chain health/suspension metadata, snapshots without pins fail closed, and suspended proxies are skipped while healthier active proxies are preferred before fanout. `cbssd` supplies the QUIC `PartialSign` proxy adapter with endpoint-derived SPKI-pinned client config, and `runner-node` can opt into this threshold path with `CBSS_THRESHOLD_ENABLED`. Local latency EWMA, adaptive retry tuning, and broader receipt-observation ergonomics remain v1.1/operator-hardening work.
`runner/crates/cbss-crypto`	implemented for devnet	Thin wrapper over vetted BLS / IBE libraries and the Commonware BLS DKG integration target (`blstrs`, Commonware, `tlock`, `aes-gcm`, `hkdf`). Identity construction, ciphertext envelope, validation, HPKE recipient-specific DKG/reshare payloads, and share storage are in place. Proactive secret sharing and the Commonware adapter are included in the June 2026 external review packet as a pre-mainnet governance gate.
`runner/crates/cbssd`	implemented for devnet	Operator daemon. Hosts Commonware-backed DKG ceremony orchestration, reshare orchestration, threshold-partial-sig service over QUIC+bincode, share storage at rest, audit log, slashing tx submission, and cbssd-native chain broadcasting. Current implementation has the transport-independent `PartialSignService` core, frame dispatcher, generic Tokio stream I/O helpers, `quinn` server/client adapters, `cbssd serve` health binding, persisted daemon TLS and secp256k1 operator identities, chain-compatible proxy-response signing, SPKI-pinned client verification, chain proxy TLS-SPKI metadata, endpoint-derived SPKI-pinned proxy-client construction, a runner-side QUIC `PartialSign` proxy adapter, a receipt submitter, and a current-head HTTP chain release authorizer that verifies runner signatures, freshness, ACL policy, job/runner assignment, actor manifest entitlements, TEE-required fail-closed state, and local committee membership before signing.
`node/execution/src/cbss.rs`	implemented for devnet	On-chain handlers for §3.5 instructions: secret registry, proxy registration/deregistration/slashing, release receipts, DKG/reshare commit, liveness challenge/response/expiry, TEE-attestation reads, and gas/receipt validation.
`node/rpc/src/handlers/cbss.rs`	implemented for devnet	CBSS RPC surfaces for proxy metadata, account/secret release keys, secret metadata resolution, and TEE-attestation lookup.
`node/cli/src/commands.rs`	implemented for devnet	`cowboy secrets `, `cowboy proxy `, and TEE-attestation submission surfaces.
`cbfs` `/v1/cbss/blob` route	implemented for devnet	HTTP route used by the owner upload / runner ciphertext-fetch path for encrypted CBSS blobs.
`cowboy/docs/cips/cip-9-runner-storage.md`	edit	§9.2 forward-reference: “CIP-TBD” → “CIP-24”.
`cowboy/docs/cips/cip-2-offchain-compute.mdx`	edit	§Specification system actor table: footnote on `0x04` → CIP-24.
`cowboy/docs/cips/cip-6-sdk.md`	edit	§12.3 entitlement registry table: add `secrets.read`.
`cowboy/docs/whitepaper/cowboy-technical-whitepaper.md`	edit	§9.2 master opcode allocation: insert rows 68–84 per §3.3 above.

6.2 Runner-side `SecretsClient` trait

#[async_trait]
pub trait SecretsClient: Send + Sync {
    async fn fetch_for_op(
        &self,
        ctx: &JobContext,
        actor: ActorAddress,
        keys: &[SecretRef],            // (account, key, optional version)
    ) -> Result<SecretBundle, SecretsError>;
}

pub struct SecretBundle {
    entries: Vec<(SecretRef, Zeroizing<Vec<u8>>)>,
}

impl Drop for SecretBundle {
    fn drop(&mut self) { /* explicit zeroize per entry */ }
}

Implementation: chain client metadata fetch → t parallel PartialSign RPCs over QUIC+bincode → BLS partial-signature pairing-verify → Lagrange combine → IBE decrypt of wrapped_dek (K = HKDF(serialize(e(σ, U)), "cbss/ibe/v1" || aad)) → fetch CBFS object and AES-GCM-decrypt with DEK → return Zeroizing<Vec<u8>> per key. The bundle drops at end of runner-op. No env-var injection on the default path — runner-http / runner-mcp perform ${KEY} substitution from the bundle directly at request-construction time (see §3.9). Only spawned subprocesses receive env vars, via an explicit env map (Command::env_clear().envs(...)).

6.3 No persistent owner-side DEK cache

The per-account anchoring + IBE construction means owners do not need a local DEK cache. ACL changes (UpdateSecretPolicy) are pure metadata and require no re-wrapping. The cowboy secrets set CLI holds a DEK in process memory only for the duration of one set/finalize operation, and zeroizes on exit. There is no on-disk cache to manage, prune, or seal.

6.4 RPC additions

In rpc/:

secrets_getMetadata(secret_id: SecretId, version_or_latest) → SecretMetadata
                  // SecretId = { account, key_hash }; raw RPC takes key_hash, not plaintext.
                  // SDK / CLI wrappers convert plaintext key_name → key_hash before calling.
secrets_getAccountReleaseKey(account) → AccountReleaseKey
secrets_getSecretReleaseKey(secret_id, version) → Option<SecretReleaseKey>   // Some iff override path
secrets_listProxies(filter) → Vec<CbssProxy>
secrets_getReleaseHistory(secret_id: SecretId, range) → Vec<SecretReleased>
proxy_health(proxy_id) → ProxyHealth
proxy_committees(proxy_id) → Vec<ActorAddress>     // which actors this proxy serves

7. Implementation tracking

Implementation is tracked in cbssd-implementation-plan.md as a single delivery split across parallelizable workstreams (chain skeleton, cbss-crypto, cbssd DKG/reshare, release path, SDK/CLI/docs). The current implementation is intended for devnet merge and wider devnet testing, not a mainnet feature-flag flip. The external crypto review is deferred to June 2026 as a separate pre-mainnet governance gate. See the plan for per-workstream deliverables and test scenarios. The CIP-9 volume-DEK integration (§9.3) is merged to devnet in its pre-amendment (v1-envelope) form: the cbssd volume seal service, the release-key material-hash binding and re-wrap-after-re-key flow (§9.3.1), share finality, and the node-side hold-until-key-delivery gate. The v2 WrappedDek envelope this amendment mandates is not yet merged anywhere — the reference PRs (see History) are in flight, and devnet stays on the superseded v1 wrap until they land and devnet state is reset. The implementation review now uses cbss-coverage-manifest.tsv as the B12 coverage index. That manifest maps the release-path, SDK/CLI/liveness, e2e, stress, and adversarial scenarios from the implementation plan to concrete source/test anchors, and cbss-review.sh validates those anchors on each run. Known v1.1 / pre-mainnet follow-ups are tracked outside this CIP text: full Intel DCAP/TDX and AMD SEV-SNP/VLEK vendor-collateral validation, restoration of the full spawned §5.9 DKG proof matrix in the current cargo harness, high-rate stress against a spawned validator, a fake-cbssd Byzantine binary over QUIC, and broader real-validator negative/recovery scenario coverage. External crypto review remains deferred to June 2026; it is a separate mainnet flag-flip gate. The reviewer packet is cowboy/docs/security/cbss-crypto-external-review-packet.md.

8. Security considerations

8.1 The t-collusion question

For the default (n, t) = (5, 4), an attacker needs to compromise 4 of 5 specific operators simultaneously. With per-account anchoring (§10.2), a successful t-collusion exposes all of the account’s default-path secrets for the duration of the compromise window, retroactively decrypting any wrapped DEKs the colluding proxies could observe at release time. Hardening levers:

Operator diversity (governance): jurisdictional, software-version, hardware-source, organizational. Governance MAY refuse to admit registrations that concentrate the proxy set.
Governance teeth on disclosed leaks: PlaintextLeak is NOT auto-slashable on chain (§4.3) because objective on-chain evidence would publish the secret. A disclosed leak triggers a CIP-12 Tier 1 governance proposal that, if passed, calls ForcedDeregisterCbssProxy(proxy_id) and routes the offending proxy’s stake to a remediation pool (default cap MAX_LEAK_REIMBURSEMENT). With MIN_PROXY_STAKE = 10,000 CBY and default t = 4, t-collusion still risks at least t × MIN_PROXY_STAKE plus permanent ban — but the slash is governance-mediated, not protocol-automatic.
VRF committee selection: attacker cannot pre-position; committee membership is determined per-account at DKG time.
Proactive reshare (insider rotation, NOT cryptographic invalidation): every RESHARE_INTERVAL_BLOCKS, the share polynomial rotates. PSS preserves MSK, so a retained old share can still partial-sign any historical-wrap_epoch identity off-chain — there is no cryptographic invalidation of old share material. What reshare DOES do: (a) replaces the share at-rest in cbssd’s storage (an honest proxy zeroizes per DeleteSecretVersion/reshare protocol), (b) rotates committee membership so previously-compromised proxies must be re-compromised under the new committee_epoch to keep contributing to t-of-n, (c) makes the prior committee no longer accepted by the chain for receipts past RESHARE_GRACE_BLOCKS. The honest-share-zeroization assumption is operational, not cryptographic. An attacker who exfiltrates a share before reshare retains an offline capability to threshold-sign historical identities indefinitely; deletion of the underlying secret (DeleteSecret) is the only way to actually invalidate.
Per-secret committee override: for secrets where the per-account blast radius is unacceptable, the committee_override path triggers a one-off DKG with its own committee, isolating that secret’s compromise surface from the rest of the account. Owners SHOULD use override for STRIPE_LIVE_KEY-class secrets and let routine credentials ride the account default.

8.2 Owner key compromise

If the owner’s account key is compromised, the attacker can issue UpdateSecretPolicy to add an attacker-controlled actor to the ACL, then fetch any of that owner’s secrets. CBSS does not defend against this and does not attempt to: account-key compromise is the limit of the model and is recovered from out-of-band (account-recovery flows are out of scope for this CIP).

8.3 Compromised runner

A compromised runner can exfiltrate the plaintext for the secrets it is currently authorized to fetch. It cannot:

Fetch secrets retroactively (release is anti-replayed per (job_id, secret_id, runner)).
Impersonate other runners (signatures over runner registry key).
Fetch secrets for jobs it isn’t currently assigned to (proxy validates dispatcher’s on-chain assignment).

This is consistent with the trust model of CIP-2: the runner is in the trust path for the duration of the job, period. CBSS does not change that.

8.4 Validator / dispatcher / chain-observer privacy

Party	Sees
Validator	`wrapped_dek` (AES-GCM under IBE-derived K, including public `ephemeral_u`; unrecoverable without σ under the co-BDH assumption), CBFS pointers, ACL, `key_hash` in storage/tx/events (dictionary-guessable for common names), audit events. Plaintext `KeyName` from deployed actor manifests (the entitlement params). NOT plaintext secret values, NOT DEKs, NOT shares.
Dispatcher	Job assignments only — no DEK material, no CBFS plaintext
Chain observer	Same as validator. `key_hash = keccak256(account	key_name) `hides literal key names from passive scraping but is dictionary-guessable for common names (`OPENAI_API_KEY`,` STRIPE_LIVE_KEY`, etc.) — an observer with the public account address can trivially reproduce the hash for any guessed name. Owners who require unguessability use random suffixes.

8.5 Anti-replay and freshness

Per release: (release_id, proxy_id) is the dedup key. release_id is defined canonically in §3.5 next to ReleaseRequestBody; it is stable across request_block re-pinning and includes release_nonce, so legitimate second pulls within a job get a distinct release_id. Proxies maintain a 24-hour bloom keyed on (release_id, proxy_id); chain release_receipt:{release_id} → { quorum_epoch, entries: Map<ProxyId, ReleaseReceipt> } provides eventual-finality dedup and single-epoch quorum enforcement. request_hash (which includes request_block) is used only for sig verification on the specific request, not for dedup.
Pinned-version pulls fail closed if the version was deleted (SecretVersionDeleted).
wrap_epoch is read from the SecretVersion on chain (immutable per version); reshare does NOT invalidate in-flight requests since PSS preserves MSK and the proxy’s current share validly partial-signs any historical identity.

8.6 DKG correctness and liveness

Correctness: Pedersen VSS commitments allow any party to verify share validity. A proxy submitting a malformed share is detectable and slashable for DkgSabotage.
Liveness: if the ceremony fails to finalize within DKG_FINALIZE_BLOCKS, the requesting tx’s DKG bond is partially slashed and refunded; the owner may retry. Lean: VRF-select n + 2 proxies and require n to complete (over-sample for ceremony liveness).

8.7 Future-shock: cryptographic break

A break of BLS12-381 (pairing-based co-BDH, the assumption IBE wrap confidentiality rests on per §3.4.4, or co-CDH for BLS signature unforgeability), AES-256-GCM, or secp256k1 ECDLP is a full-platform compromise — none unique to CBSS, all shared with the broader Ethereum/Filecoin/Cowboy ecosystems. The mitigation specific to secrets is DeleteSecret: dropping the CBFS object means a future cryptanalytic break finds nothing to decrypt. The chain history retains only the encrypted wrapped_dek, which without the CBFS ciphertext is useless. Curve agility (e.g., upgrading the IBE construction to BLS12-461 or a post-quantum threshold scheme) is a future CIP, out of scope here.

8.8 Comparison vs TEE-based release

Property	TEE-rooted release	CBSS (this design)
Trust root	CPU-vendor attestation	t-of-n proxy non-collusion + slashing
Failure mode	TEE break → all secrets exfiltratable retroactively for the lifetime of the wrap	t-collusion → secrets observed by colluders during their committee tenure
Hardware requirement	TEE-capable runner	Standard hardware
Latency	Single-hop unwrap on TEE	t-of-n threshold round (~250 ms target)
Operational footprint	TEE provisioning per runner	New operator role; DKG ceremonies
Ecosystem	TEE vendors (Intel, AMD)	CBY-staked operators
Auditability	TEE attestation logs	On-chain `SecretReleased` events + per-proxy receipts carrying the runner-signed request

CIP-24 picks the right column. CIP-23 keeps the left column available for execution (and as an additional gate via tee_required); the two layer cleanly.

9. Interaction with other CIPs

9.1 CIP-2 (Off-chain compute)

CIP-24 fills the system-actor reservation at 0x0000…0004 declared in CIP-2 §Specification. CIP-2 §Specification table SHOULD be updated to footnote-reference CIP-24 in the same PR.

9.2 CIP-6 (SDK + entitlements)

secrets.read is registered in the entitlement registry. The subset-on-upgrade invariant (CIP-6 §12.1) applies: an actor cannot expand the keys it can request without redeploying.

9.3 CIP-9 (Runner storage)

CIP-24 is the key-delivery layer for CIP-9 private volumes: a volume’s data-encryption key (DEK) is a CBSS-released secret. CIP-9’s earlier “CIP-TBD” forward-reference to a Secrets Manager is fulfilled here (the placeholder reads “CIP-24”). The CIP-9 v1 dispatcher-unwrap design is superseded — in the current CIP-9 spec the runner obtains the volume DEK only via a committee seal, and the Dispatcher is never on the key path. Volume DEK as a committee secret. At volume creation the DEK is IBE-wrapped to the owner account’s CBSS master public key (MPK), like any SecretVersion (§3.4). The wrap is stored on the volume’s StorageCommitment as wrapped_dek, bound to the account’s cbss_committee_epoch. StorageCommitment.wrapped_dek uses the same WrappedDek format version 2: it carries ephemeral_u, uses K = HKDF(serialize(e(I, MPK)^r), "cbss/ibe/v1" || aad) owner-side, and validates/decrypts with K = HKDF(serialize(e(σ, U)), "cbss/ibe/v1" || aad) runner-side. The volume path keeps CIP-9’s own identity and base AAD — not the 172-byte secret base_aad of §3.4.3. The IBE identity is I_vol = hash_to_G1( volume_dek_identity, domain = "cbss/ibe/cip9-volume-dek/v1" ), and the base AAD is base_aad = cip9_hash( "cowboy.cip-9.volume-dek-aad.v1", volume_dek_identity ) — a 32-byte value, where volume_dek_identity is CIP-9’s 32-byte volume-DEK identity hash (“Release at mount” below). The full AEAD AAD is base_aad || compress(U) (32 + 96 = 128 bytes), validated by full equality exactly as in §3.1 (len(aad) != 32 + 96 is malformed and MUST be rejected with AadMismatch). The HKDF salt and info prefix remain "cbss/ibe/v1" (§3.4.3) — only the hash-to-curve domain and base AAD differ on the volume path. Release at mount. When a storage-attached job is dispatched, the node builds a SealRequest for the volume (carrying owner, volume_id, dek_version, committee_epoch, and the material hash below) rather than unwrapping anything itself. The committee serves threshold partials per §3.6.3 against the volume-DEK identity

volume_dek_identity(chain_id, owner, volume_id, dek_version, committee_epoch, release_key_material_hash, committee_override_hash)

; the runner Lagrange-combines t partials to recover the DEK. Hold-until-key-delivery: the node holds the job — it is not exposed to a runner — until the release finalizes (idempotent on duplicate delivery), so a runner receives a storage job only once it can actually decrypt the volume.

9.3.1 Release-key material-hash binding (re-key safety)

A volume wrap is pinned to the exact committee key material it was created against, via a 32-byte release-key material hash:

cip9_hash("cowboy.cip-9.release-key-material.v1", chain_id ‖ account ‖ committee_epoch ‖ threshold ‖ committee ‖ MPK ‖ VSS_commitments)

. The volume’s StorageCommitment records cbss_release_key_material_hash (the material the DEK is wrapped against) and cbss_rewrap_required. At mount, a private attachment requires:

cbss_release_key_material_hash is set (a zero hash is rejected);
cbss_rewrap_required == false;
the recorded hash equals the release-key material retained for the volume’s committee_epoch (release_key_view.material_hash).

Otherwise the mount is refused. Reshare vs. re-key. A reshare (§3.6.2) preserves MPK and increments committee_epoch. A volume’s wrap is pinned to a specific epoch’s material hash — unlike a general SecretVersion, whose wrap_epoch-bound identity makes reshare fully transparent (§10.7) — so reshare is transparent to a volume only while the prior epoch’s material is retained, during the grace window: the volume keeps serving against its recorded epoch for that window, after which its wrap is stale and must be re-wrapped to a current epoch. An account re-key (recovery: the release-key material fundamentally changes) is the harder case — existing wraps can no longer be served, so affected volumes are flagged cbss_rewrap_required = true immediately and mounts are blocked until the owner re-wraps. Either path resolves the same way: re-wrapping the DEK to the current material updates cbss_release_key_material_hash and clears cbss_rewrap_required (the CBFS CLI ships the flow). Share finality. Proxies finalize their shares before serving partials (bounded pending share promotions), so a release never combines partials against a half-promoted share across a ceremony boundary.

9.4 Whitepaper §9.2 (Master opcode allocation)

CIP-24 claims opcodes 68–84 in the master allocation table. The table in whitepaper §9.2 MUST be amended in the same PR (§3.3 of this CIP shows the exact rows to insert).

9.5 CIP-23 (TEE Execution)

CIP-23 attestation is optional per secret via the tee_required flag. When set, the runner MUST present a CIP-23 attestation valid for the active job_id; the chain validates it against 0x05 (TEE Verifier) at receipt submission, and proxy serving must fail closed unless the node authorizer path can confirm a live attestation. The current devnet TEE Verifier validates registered P-256/P-384 ECDSA attestation keys over canonical CBSS attestation bytes. It does not yet validate Intel DCAP/TDX or AMD SEV-SNP/VLEK vendor collateral; that is a v1.1 / pre-mainnet milestone. TEE here is defense-in-depth on top of threshold release, not the trust root.

9.6 CIP-34 (Intent Settlement)

CIP-34’s sealed-bid auctions (v1) consume the time-lock release mode (§3.4.6): a bid is IBE-encrypted to identity request_id with target_height = reveal_height, and the committee posts the height-gated release at reveal_height so the native reveal handler (and any observer) can decrypt all bids at once — “the key becomes available independent of any bidder.” This is the dependency CIP-34 §Sealed-Bid names; before this amendment, CIP-24 exposed only the ACL-gated, fixed-identity secret-release path, which cannot serve a caller-chosen auction identity released automatically at a height. No new committee, key, or trust is introduced — sealed auctions ride the same staked CBSS committee. CIP-34 owns the liveness fallback (AUCTION_GRACE → cancel the auction, CancelledGraceExpired; no OPEN re-open, no escrow held) if the committee fails to release by reveal_height + AUCTION_GRACE. Bootstrapping the 0x14 committee. The sealed-bid path presumes Account(0x14) already has a live CBSS committee / MPK, but 0x14 is keyless and cannot self-issue RequestAccountDkg. GovRequestSystemDkg (opcode 158, §3.5) closes this: governance (0x09) issues one GovRequestSystemDkg { scope: Account(0x14), force_rekey: false } to establish the committee via the ordinary DKG → RotateCommittee path (no bond, no new trust). This MUST happen before the first OpenAuction. Governance MUST NOT force_rekey the 0x14 committee while auctions are in flight (see §3.5 — a re-DKG installs a new MPK and strands in-flight bids); routine refresh uses RequestReshare (§10.7).

Open item — enactment bridge (blocks the SEALED path). GovRequestSystemDkg’s handler (node #909) is merged, but a 0x09-origin tx can only be produced by CIP-12 proposal enactment via a ProposalPayloadKind (§3.5, Invocation), and no such payload kind yet maps to opcode 158. Until that enactment mapping is added, opcode 158 is unreachable, so the 0x14 committee cannot be bootstrapped and no sealed auction can clear (open_auction hard-requires the committee). This mapping (and the keyless-scope restriction in §3.5) are the remaining implementation items for the SEALED path.

History

2026-06-11: erratum-01 was folded directly into this CIP body instead of shipping as a separate erratum. The defect was that the earlier IBE wrap key used no per-message encryption ephemeral, making K publicly recomputable from (MPK, aad) and causing the threshold release to add availability/policy gating but zero cryptographic confidentiality. The root-cause lesson: §3.4.5 correctly rejected a runner-binding ephemeral key, then over-generalized “no runner ephemeral” into “no ephemeral at all”, dropping the Boneh-Franklin encryption ephemeral r (owner-chosen and independent of runners). Boneh-Franklin IBE (CRYPTO 2001) and tlock (Cryptology ePrint 2023/189, presented at Real World Crypto 2023) require e(I, MPK)^r plus a public U = r · G2_gen; CIP-24 now does too. Reference implementation PRs (in flight, not yet merged, at the time of this amendment): cowboyinc/cbss#23, cowboyinc/node#689, cowboyinc/python-sdk#83. Companion docs PR aligning the secrets whitepaper and the CIP-7 spec to the v2 envelope: cowboyinc/cowboy#165. 2026-06-12: WrappedDek gained the leading 1-byte format-version tag (version == 2; §3.1) so future envelope-format changes dispatch on the tag instead of breaking the chain (COW-2259). Reference implementation PRs: cowboyinc/cbss#25, cowboyinc/node#706, cowboyinc/python-sdk#87. 2026-07-03: v1 amendment — governance-bootstrapped system committee (GovRequestSystemDkg, opcode 158). Adds the one DKG-bootstrap path for a keyless system-actor release-key scope: governance (0x09) issues GovRequestSystemDkg { scope, force_rekey } to establish a committee that cannot self-issue the owner-keyed RequestAccountDkg. The concrete consumer is CIP-34 sealed-bid auctions, whose reveal decrypts against Account(0x14)’s committee (§9.6) — before this, that committee’s MPK had no way to come into existence. Mirrors RequestAccountDkg (same DKG → RotateCommittee path) with governance authorization, an explicit target scope, and no DKG_BOND. Documents the force_rekey safety MUST (a re-DKG installs a fresh MPK and strands ciphertext bound to the old one — §3.5, §10.7 — so governance must not force_rekey 0x14 while auctions are in flight; routine refresh uses RequestReshare) and the cbss.dkg.requested DKG-request event both DKG paths emit. Authored under the 2026-06-29 cross-team mandate; this is the CIP-24 side of the CIP-34 v1 SEALED committee bootstrap. Reference implementation: codec cowboyinc/cowboy-protocol#19 (opcode 158 wire), node cowboyinc/node#909 (0x04 handler + pin bump). 2026-06-29: v1 amendment — time-lock release mode (§3.4.6). Re-introduces tlock’s native future-height identity binding as a second, domain-separated (cbss/tlock/v1), height-gated, permissionless release mode alongside the existing ACL-gated secret release — for CIP-34 sealed-bid auctions (§9.6), which need a key bound to a caller-chosen request_id that becomes available automatically at a reveal height, independent of any participant. Reuses the same committee / MPK / DKG / PSS (no new key or trust). Adds RegisterTlockRelease (opcode 152) and SubmitTlockRelease (153), the §4.5 TLOCK_* parameters, and the §9.6 CIP-34 interaction. Authored under the 2026-06-29 mandate to initiate cross-team work; this is the CIP-34 side of the CIP-34 v1 dependency. Reference implementation: TBD (cbss cbss-crypto tlock identity + node 0x04 handlers + the consumer wiring in CIP-34’s 0x14). 2026-08-03: Single canonical account-secret format at genesis (chain separation + release-key binding). The account-secret base AAD is finalized as the one canonical layout — base_aad = u64_be(chain_id) ‖ account(20) ‖ key_hash(32) ‖ u64_le(version) ‖ u64_le(wrap_epoch) ‖ mpk_g2(96) = 172 bytes, extended AEAD aad = base_aad ‖ compress(U) = 268 bytes, IBE identity I = hash_to_G1(base_aad, "cbss/ibe/v1"), HKDF salt/info "cbss/ibe/v1". Two release-integrity bindings are folded into that single layout: chain separation (COW-2660 — the leading chain_id, so a secret wrapped for one chain cannot be validated or unwrapped on another) and release-key binding (COW-2923 — the trailing raw mpk_g2, so a secret sealed under a substituted mpk' produces a different identity and AAD and the real committee’s σ can never open it; the chain re-derives chain_id and mpk_g2 from committed state and rejects mismatches with AadMismatch). The endianness split (chain_id big-endian; version/wrap_epoch little-endian; mpk_g2 raw) is load-bearing and wire-breaking to change. Single-version decision: the DST stays cbss/ibe/v1 — there is deliberately no v2/v3 DST tree. The interim COW-2660 chain-bound layout and the COW-2923 draft never shipped to a live boundary, and this layout can only be introduced on a wiping re-genesis (the stored secret value envelope binds the 172-byte base_aad, not just the DEK wrap, so a base-AAD change invalidates the ciphertext of every secret value and there is no re-wrap path without the plaintext — §3.4.3 step 5); with state wiped there is nothing to disambiguate, so a single unambiguous v1 is the whole version tree, and the cross-repo drift tripwire is the golden-vector byte-gate rather than a DST bump. Scope: time-lock release / CIP-34 sealed bids (cbss/tlock/v1, base AAD tag ‖ u64_le(target_height)) and CIP-9 volume DEKs (cbss/ibe/cip9-volume-dek/v1, 32-byte base AAD) are explicitly out — each keeps its own per-family base AAD and does not gain chain_id or mpk_g2 (§3.4.6, §9.3). CIP-7 wrapped-DEK AADs bind release_key_material_hash (COW-2924) and keep DST cip-7-wd-v1 (CIP-7 §Content-key Identity). Reference implementation: the merged foundation crate cowboyinc/cowboy-protocol crates/cowboy-protocol-cbss-crypto (aad.rs, identity.rs, cip7.rs), which is the single canonical source the node, cbss, and SDK builders delegate to; this docs amendment is byte-consistent with, and does not gate, that kernel.

10. Rationale

10.1 Why threshold IBE on BLS12-381

See §3.4.5 for the full argument. Short version: vetted libraries exist for threshold BLS signatures and IBE on BLS12-381 (blstrs, Commonware BLS DKG, tlock); they do not exist for threshold ElGamal on secp256k1. The cryptographic-engineering rule “don’t roll your own crypto” trumps the curve-reuse argument that originally motivated secp256k1. The IBE construction does not use kfrags or proxy re-encryption; it uses BLS signature shares as IBE decryption keys. The recipient-targeting problem that kfrag-based PRE designs address is solved here by binding the IBE identity to per-version metadata that all parties can compute deterministically.

10.2 Why per-account by default, with per-secret override

Three candidate granularities: per-secret, per-actor, per-account. We picked per-account default + per-secret override.

Per-secret committees scale O(num_secrets × n) system-wide with a fresh DKG every time someone stores a credential. Bootstrap-prohibitive.
Per-actor committees isolate an actor’s secrets from the rest of an account’s secrets, but the isolation only materializes when ACLs are narrow. Once a secret’s ACL fans out across multiple actors, an attacker just attacks the weakest of those committees — per-actor is no better than per-account in the wide-ACL case. Per-actor also pays a DKG every time you deploy a new actor, and forces a chain re-wrap on every ACL edit (since each ACL actor needs its own wrapped DEK). Operationally heavy with limited security gain in realistic usage patterns.
Per-account committees match the practical sharing patterns of production secret management (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault are all account/project-scoped). Bootstrap is one DKG amortized over the account’s lifetime. ACL edits are pure metadata. Storage is O(1) wrapped DEK per version regardless of ACL size.

The trade with per-account is bigger blast radius per t-collusion: an attacker who compromises ≥ t proxies in an account’s committee can decrypt every secret that account ever wrapped under its MPK. Mitigations:

Tunable (n, t) per account — high-value accounts can raise n and t through governance-supported account parameters once larger vetted DKG quorums are enabled, instead of using the default (5, 4).
Per-secret committee override — a single high-value secret (STRIPE_LIVE_KEY) can opt into its own committee at SetSecret time, isolating its blast radius from the rest of the account’s secrets. This is the escape hatch.
Proactive resharing — every RESHARE_INTERVAL_BLOCKS, the share polynomial rotates. An attacker has a finite window.
Operator diversity governance — committee admission policy can require jurisdictional / vendor / org diversity.

Per-account-with-override is the right default: cheap and simple in the common case, with explicit isolation available for the cases that need it.

10.3 Why a new operator role, not extending Relay Nodes

Different failure semantics, slashing math, and operator profile (§3.1). A node can register as both Relay and Proxy; the protocol roles stay distinct.

10.4 Why in-memory bundle by default (and explicit subprocess env when required)

Limits blast radius. Plaintext exists only in the runner-op execution context, only as the substituted final-form request. Never enters PVM Python state; cannot be accidentally logged, persisted, or echoed in error messages.

10.5 Why two-layer access control (manifest ∩ ACL)

Manifest is the actor’s advertised need (caught at deploy-time review). ACL is the owner’s consent (caught at the runtime gate). Both layers answer different threats: a malicious actor lying about its needs is caught at deploy time; a compromised owner key that grants too broadly is at least bounded by the manifest of each individual recipient actor.

10.6 Why CIP-24, not CIP-23

CIP-23 is occupied by TEE Execution (Created 2026-04-20). Earlier design notes proposed CIP-23 for the secrets manager because that slot was free at design-time; that proposal is now stale. CIP-24 is the next sequential available slot. Reusing freed slots (CIP-8, CIP-17, CIP-19) creates onboarding confusion with old links and PRs.

10.7 Why `MPK` is preserved on reshare

Owners encrypt to MPK. If reshare changed MPK, every existing wrapped DEK on chain would become un-decryptable, forcing owner re-encryption en masse. Preserving MPK across reshare (proactive secret sharing on the same MSK) means reshare is invisible to owners — only the share polynomial rotates. Note: the per-version IBE identity is bound to the SecretVersion’s immutable wrap_epoch, not to the live committee_epoch. Reshare changes committee_epoch but does NOT change any existing version’s wrap_epoch. New SetSecret calls after a reshare bind to the then-current committee_epoch as their wrap_epoch. The threshold-sig math works for any historical identity because PSS preserves MSK across reshare.

10.8 Why per-proxy receipts, not a single aggregate `RecordSecretRelease`

A single aggregate audit/payment instruction submitted “by the runner or any participating proxy” would leave payment dependent on either runner cooperation (which the runner has no incentive to provide once it has the plaintext) or implicit proxy coordination (unspecified, and prone to gas-bidding wars or drop-on-the-floor). SubmitReleaseReceipt (opcode 76) instead makes each proxy submit its own receipt independently. Each accepted receipt debits RELEASE_FEE_PER_RECEIPT from the actor’s account (subject to overdraft cap) and credits the submitting proxy. Payment is capped at quorum: only the first t receipts per release_id are paid; receipts t+1..n (which a runner may have triggered by over-fanning out) are rejected with QuorumAlreadyReached. Properties:

Runner is removed from the payment path. Cannot grief proxies by withholding submission.
No coordination required. Each proxy decides independently when to submit; the first t proxies to land on chain are paid; later submissions for the same release_id (whether from the n-t over-fanout or from the same proxy on a re-pin) are rejected. Proxies SHOULD watch release_receipt:{release_id}.entries and stop attempting once entries.len() == t.
Auditable. release_receipt:{release_id} → { quorum_epoch, entries: Map<ProxyId, ReleaseReceipt> } accumulates the full t-of-n proof of release on chain, each entry carrying the verbatim runner-signed request and the verified σ_i. The SecretReleased event fires when the t-th entry lands, carrying the actual proxy_set of t contributors.
Cost: t txs per release instead of one. Acceptable for a system whose default release rate is O(1 per actor-job); for very-high-frequency cases, an aggregator pattern is possible later without breaking the on-chain interface.

​1. Abstract

​2. Motivation

​2.1 The problem

​2.2 Design philosophy

​2.3 Why not TEE-rooted release

​3. Specification

​3.1 New data structures

​SecretId

​SecretKeyRef

​SecretMetadata

​SecretVersion

​SecretPolicy

​AccountReleaseKey (default path)

​SecretReleaseKey (override path)

​CbssProxy

​WrappedDek (IBE envelope)

​3.2 Storage layout in 0x04

​3.3 Master opcode allocation update

​3.4 Cryptography

​3.4.1 Vetted-library mandate

​3.4.2 Curve choice: BLS12-381

​3.4.3 Construction: threshold IBE (“tlock” applied to secret release)

​3.4.4 Security properties

​3.4.5 Why threshold IBE, not threshold ElGamal with key-switching

​3.4.6 Time-Lock Release mode (height-gated, public identity)

​3.5 New system instructions

​SetSecret (opcode 68)

​FinalizeSecretVersion (opcode 78)

​UpdateSecretPolicy (opcode 69)

​DeleteSecretVersion (opcode 70)

​DeleteSecret (opcode 71)

​RegisterCbssProxy (opcode 72)

​DeregisterCbssProxy (opcode 73)

​RotateCommittee (opcode 74)

​SlashCbssProxy (opcode 75)

​SubmitLivenessChallenge (opcode 79)

​LivenessChallengeResponse (opcode 80)

​SubmitReleaseReceipt (opcode 76)

​RequestAccountDkg (opcode 77)

​GovRequestSystemDkg (opcode 158, provisional)

​ExpireDkgPending (opcode 81)

​ExpireLivenessChallenge (opcode 82)

​RequestReshare (opcode 83)

​ForcedDeregisterCbssProxy (opcode 84)

​RegisterTlockRelease (opcode 152, provisional)

​SubmitTlockRelease (opcode 153, provisional)

​3.6 Threshold ceremonies

​3.6.1 DKG (initial keypair establishment)

​3.6.2 Reshare (proactive secret sharing)

​3.6.3 Threshold partial signature (release)

​3.7 Proxy-side validation of release requests

​3.8 Runner pull flow

​3.9 Runtime sandbox: in-memory secret bundle (default), env vars only for spawned subprocesses

​4. Parameters

​4.1 Gas

​4.2 Stake / committee

​4.3 Slashing schedule

​4.4 Health score

​4.5 Quotas / limits

​5. SDK surface (CIP-6 extension)

​5.1 New entitlement

​5.2 Runner-op kwarg

​5.3 Errors

​5.4 CLI

​5.5 Inbound-verification precondition (verify=)

​6. Implementation notes

​6.1 Crate layout

​6.2 Runner-side SecretsClient trait

​6.3 No persistent owner-side DEK cache

​6.4 RPC additions

​7. Implementation tracking

​8. Security considerations

​8.1 The t-collusion question

​8.2 Owner key compromise

​8.3 Compromised runner

​8.4 Validator / dispatcher / chain-observer privacy

​8.5 Anti-replay and freshness

​8.6 DKG correctness and liveness

​8.7 Future-shock: cryptographic break

​8.8 Comparison vs TEE-based release

1. Abstract

2. Motivation

2.1 The problem

2.2 Design philosophy

2.3 Why not TEE-rooted release

3. Specification

3.1 New data structures

SecretId

SecretKeyRef

SecretMetadata

SecretVersion

SecretPolicy

AccountReleaseKey (default path)

SecretReleaseKey (override path)

CbssProxy

WrappedDek (IBE envelope)

3.2 Storage layout in `0x04`

3.3 Master opcode allocation update

3.4 Cryptography

3.4.1 Vetted-library mandate

3.4.2 Curve choice: BLS12-381

3.4.3 Construction: threshold IBE (“tlock” applied to secret release)

3.4.4 Security properties

3.4.5 Why threshold IBE, not threshold ElGamal with key-switching

3.4.6 Time-Lock Release mode (height-gated, public identity)

3.5 New system instructions

SetSecret (opcode 68)

FinalizeSecretVersion (opcode 78)

UpdateSecretPolicy (opcode 69)

DeleteSecretVersion (opcode 70)

DeleteSecret (opcode 71)

RegisterCbssProxy (opcode 72)

DeregisterCbssProxy (opcode 73)

RotateCommittee (opcode 74)

SlashCbssProxy (opcode 75)

SubmitLivenessChallenge (opcode 79)

LivenessChallengeResponse (opcode 80)

SubmitReleaseReceipt (opcode 76)

RequestAccountDkg (opcode 77)

GovRequestSystemDkg (opcode 158, provisional)

ExpireDkgPending (opcode 81)

ExpireLivenessChallenge (opcode 82)

RequestReshare (opcode 83)

ForcedDeregisterCbssProxy (opcode 84)

RegisterTlockRelease (opcode 152, provisional)

SubmitTlockRelease (opcode 153, provisional)

3.6 Threshold ceremonies

3.6.1 DKG (initial keypair establishment)

3.6.2 Reshare (proactive secret sharing)

3.6.3 Threshold partial signature (release)

3.7 Proxy-side validation of release requests

3.8 Runner pull flow

3.9 Runtime sandbox: in-memory secret bundle (default), env vars only for spawned subprocesses

4. Parameters

4.1 Gas

4.2 Stake / committee

4.3 Slashing schedule

4.4 Health score

4.5 Quotas / limits

5. SDK surface (CIP-6 extension)

5.1 New entitlement

5.2 Runner-op kwarg

5.3 Errors

5.4 CLI

5.5 Inbound-verification precondition (`verify=`)

6. Implementation notes

6.1 Crate layout

6.2 Runner-side `SecretsClient` trait

6.3 No persistent owner-side DEK cache

6.4 RPC additions

7. Implementation tracking

8. Security considerations

8.1 The t-collusion question

8.2 Owner key compromise

8.3 Compromised runner

8.4 Validator / dispatcher / chain-observer privacy

8.5 Anti-replay and freshness

8.6 DKG correctness and liveness

8.7 Future-shock: cryptographic break

8.8 Comparison vs TEE-based release