​

Abstract

​

Introduction

​

Architectural Overview

​

Terminology

• Secret: A named, account-owned, versioned byte string (e.g. OPENAI_API_KEY). The chain never sees the plaintext.
• Owner: The Cowboy account that owns one or more secrets. The owner’s wallet key authorizes SetSecret, UpdateSecretPolicy, and Delete* transactions.
• Actor / Runner / Job: As in the Technical Whitepaper. An actor declares secrets it intends to read in its manifest; a job is dispatched to a specific runner; that runner is the one entitled to pull the declared secrets for the duration of the job.
• CBSS Proxy: A staked off-chain participant running the cbssd daemon. Proxies hold one BLS scalar share per release-key scope they serve and produce partial threshold signatures on demand.
• Committee: The ordered set of proxies serving a particular release key. Default 4-of-5 (matches Commonware N3f1 log/commitment quorum: n=5, t=4); configurable up to 16 with --committee-override.
• DKG (Distributed Key Generation): The multi-round protocol that produces the committee’s Master Public Key (MPK), per-proxy shares, and per-proxy VSS commitments without any single proxy ever holding the Master Secret Key (MSK).
• PSS Reshare: Proactive Secret Sharing. A protocol that replaces every committee share with a fresh share for the same MSK, optionally over a different committee, without ever materialising the MSK.
• Identity (I): A point in G1 derived deterministically from (account, key_hash, version, wrap_epoch). Each secret version under each committee_epoch has a unique identity.
• MPK / MSK: Master Public Key (MPK ∈ G2 = MSK · G2_gen) and Master Secret Key (MSK ∈ Scalar, never instantiated). Preserved across reshares.
• Wrapped DEK: AES-256-GCM ciphertext of a Data Encryption Key, encrypted under the symmetric key derived from the IBE pairing e(I, MPK)^r, where r is the owner’s per-wrap encryption ephemeral. The envelope (serialized format version 2) carries a leading 1-byte version tag, ciphertext, nonce, ephemeral_u (U = r · G2_gen, 96-byte compressed G2), and aad; readers reject unknown tag values.
• CBFS pointer: A CBFS object descriptor pointing to the AES-256-GCM ciphertext of the actual secret payload, encrypted under the DEK.
• Release request: A runner-signed structure naming the secret, version, actor, runner, job, release nonce, request block, and serve epoch. Hashed and signed under domain separator cbss/release-request/v1.
• Partial signature (σ_i): s_i · I where s_i is a proxy’s share. Verified individually via the pairing e(σ_i, G2_gen) == e(I, S_i) against the on-chain VSS commitment S_i.
• Threshold signature (σ): Lagrange combination of t partial signatures, equal to MSK · I.
• Receipt: A chain-submitted (release_request, sigma_i, proxy_id, committee_epoch_at_serve, served_at_block, proxy_sig) that earns the proxy a per-receipt fee and constitutes the canonical audit record.
• CBSS System Actor (0x04): The Cowboy system actor that owns secret metadata, release keys, proxy registry, DKG-pending records, release receipts, liveness challenges, and slashing.

​

Key Features

• Off-chain plaintext data path. Wrap is local to the owner; unwrap is local to the runner. The chain stores ciphertext (WrappedDek and cbfs_pointer); plaintext exists only in the owner’s CLI memory at write time and the runner’s process memory at read time, both bounded by Rust Zeroizing wrappers.
• Threshold IBE over BLS12-381. The same primitive used by drand for time-locked encryption: identity-based encryption where the “identity” is a per-version tuple, encryption uses only the public MPK, and decryption requires t of n proxies to produce partial BLS signatures on the identity. No single proxy holds enough information to decrypt; collusion requires ≥ t proxies.
• Per-account release keys with optional per-secret override. The default path generates one DKG per account and reuses its MPK for every secret the account wraps. High-value secrets can opt into a separate DKG with custom committee selection (--committee-override --threshold T/N), trading extra latency at write time for committee diversity.
• Chain-anchored authorization. Every release is preceded by a runner-signed SignedReleaseRequest and followed by chain-recorded ReleaseReceipts. Policy (actor allowlist, TEE requirement) is checked at receipt-submission current head, so revocation propagates within finality plus proxy cache TTL.
• Proactive secret sharing. Reshares are scheduled (every RESHARE_INTERVAL_BLOCKS) and triggered by churn; PSS preserves MPK across reshares so historic ciphertexts remain decryptable, but every share is replaced — a previously-compromised share is invalidated by the next reshare.
• Independent per-proxy receipt submission. No coordinator runs the receipt phase. Each of t participating proxies submits a per-proxy receipt independently, with up to 10 blocks of jitter to smooth chain throughput. The chain emits one ReleaseReceiptRecorded event per receipt and exactly one aggregate SecretReleased event when the t-th lands. Runners do not gate or sign-off the audit.

​

Differences vs. Existing Secret Stores

1. No re-encryption on ACL change. Vault and Lit both require re-wrapping when the access list changes. CBSS uses a fixed per-account release key and validates policy.actors at the moment a receipt is submitted. Adding or removing an actor is a metadata-only UpdateSecretPolicy instruction; no DEK is re-wrapped, no payload re-uploaded.
2. Scope-locked release. A release fires for one (actor, runner, job, secret, version) tuple, with a release nonce. The chain receipt encodes that scope; off-chain leakage is therefore tagged to specific responsible parties rather than dissolving into “someone with a token.”
3. Data plane has zero per-access chain transactions. The owner CLI submits one transaction at write time; the runner submits zero at read time; only the participating proxies submit (one each, asynchronously with jitter). For comparison, every Vault read is a service request to a centralized custodian; every Lit read is several HTTPS RTs to KFrag holders.

​

Related Work

​

Centralised Secret Stores (Vault, AWS Secrets Manager, Doppler, 1Password Secrets Automation)

• Single point of compromise. A vault breach exposes every secret it holds.
• No on-chain authorization link. A Vault token says “this account has read access”; it has no way to say “this runner address is dispatched to this job at this block height.”
• No native audit on the consumer chain. Vault audit logs live in the vault.
• Operationally Web2. A Cowboy actor that pulled secrets from Vault would need to bridge a service-account token into chain identity, defeating the point.

​

Threshold Cryptography for Decentralised Secrets (Lit Protocol, NuCypher / TACo, drand timelock)

• Lit Protocol uses a permissioned BLS threshold network. A user encrypts under the network’s MPK with an attached “access control condition” (an EVM eth_call-style predicate); to decrypt, a client requests partial decryptions from t of n Lit nodes, which each evaluate the condition before contributing. The trust model is similar to CBSS but the on-chain anchoring is weaker — the access condition is evaluated by each Lit node independently against any chain it can read, with no on-chain receipt that the release happened.
• NuCypher / TACo uses proxy re-encryption (ECIES-based KFrags). Granting access requires generating new re-encryption keys and distributing them; revoking access requires re-encryption. The model is elegant for sharing-style workloads (Alice grants Bob access to a document) but expensive for autonomous-agent workloads where an actor’s manifest may decide moment-to-moment which secrets it needs and the access list changes frequently.
• drand timelock uses tlock (Cryptology ePrint 2023/189, presented at Real World Crypto 2023) — threshold IBE keyed on future round numbers — to encrypt to a future time. CBSS reuses the same construction (BLS12-381 hash-to-curve identity + pairing-based KEM + AEAD) but keys identities on per-version-tuple rather than future rounds, and adds chain-anchored authorization, audit, and slashing.

​

Multi-Party Computation Secret Sharing (TSS Vaults, Pyrofex, ZenGo)

​

Hardware-Rooted Approaches (TEE-Sealed Vaults, Intel SGX SealedData)

• TEE attacks. Repeated side-channel breakthroughs against SGX (Foreshock, ÆPIC, Downfall, etc.) make any “TEE-only” custody model fragile. Threshold cryptography is a structural defense — compromising any t-1 proxies still discloses zero plaintext.
• No vendor lock-in. A multi-vendor proxy fleet running pure software is a deliberate property; threshold IBE is hardware-agnostic.
• TEE composes additively. A secret may carry policy.tee_required = true to require the runner to be TEE-attested at release time; the proxies themselves are not required to run in TEEs. Use TEE where it adds; don’t depend on it.

​

Tabular Summary

​

Cryptographic Construction

​

Curve and Primitives

• G1: 48-byte compressed points, used for identities I and partial / aggregate signatures σ_i, σ.
• G2: 96-byte compressed points, used for the generator G2_gen, the master public key MPK, and per-proxy VSS commitments S_i.
• Gt: target group of the pairing e: G1 × G2 → Gt.
• Scalar: Fr (the prime field of order r), used for shares s_i and the (notional) master secret MSK.

​

Identity Construction

canonical(SecretId)  = account || key_hash                     -- 52 bytes
base_aad             = canonical(SecretId)
                    || u64_le(version)
                    || u64_le(wrap_epoch)                      -- 68 bytes total
I                    = hash_to_G1(base_aad, domain = "cbss/ibe/v1")

​

Encryption (Owner Side)

r           ←$ Fr, r != 0                               -- fresh per-wrap encryption ephemeral
U           = r · G2_gen                                -- 96-byte compressed G2, published
aad         = base_aad || compress(U)                   -- 164 bytes
gt          = e(I, MPK)^r                               -- pairing in Gt
ikm         = serialize(gt)                             -- canonical compressed Gt encoding (288 bytes)
K           = HKDF-SHA-256(salt = "cbss/ibe/v1",
                           ikm,
                           info = "cbss/ibe/v1" || aad,
                           L = 32)
nonce       ← CSPRNG(12)
WrappedDek  = AES-256-GCM(key = K,
                          nonce = nonce,
                          aad = aad,
                          plaintext = dek)

​

DKG (Once Per Account / Per-Secret Override)

1. Samples a degree-(t-1) polynomial f_j(x) with t random coefficients.
2. Publishes Round 1: commitments_j = (g_2 · f_j(0), g_2 · coeff_j[1], …, g_2 · coeff_j[t-1]).
3. Sends Round 2: each recipient k receives f_j(k) (HPKE-encrypted to recipient k’s X25519 key registered in RegisterCbssProxy).
4. Each recipient verifies their share against the public commitments; mismatches yield slashable evidence.

​

Partial Sign and Threshold Combine (Runner Side)

σ_i = s_i · I               -- a G1 point, 48 bytes compressed

e(σ_i, G2_gen) == e(I, S_i)

σ = Σ (λ_i(0) · σ_i) over the t selected indices

​

Decryption (Runner Side)

U           = decode(WrappedDek.ephemeral_u)            -- canonical, non-identity, prime-order; rejected otherwise
aad         = base_aad || WrappedDek.ephemeral_u        -- must equal WrappedDek.aad EXACTLY (full equality)
gt          = e(σ, U)
ikm         = serialize(gt)
K           = HKDF-SHA-256(salt = "cbss/ibe/v1",
                           ikm,
                           info = "cbss/ibe/v1" || aad,
                           L = 32)
dek         = AES-256-GCM-decrypt(K, nonce, aad, WrappedDek.ciphertext)

​

Reshare via Proactive Secret Sharing

g_j(0)   = s_j · L_j               -- L_j is the Lagrange coefficient at zero for the chosen old subset
g_j(x)   = g_j(0) + r_j(x)         -- r_j is a fresh degree-(t-1) polynomial with r_j(0) = 0

​

System Architecture

              +-----------------------------------------------+
              |  Owner CLI  (cowboy secrets {set,policy,...}) |
              +------------------------+----------------------+
                                       |
                  SetSecret / Finalize / Update / Delete
                                       |
                                       v
+----------------------------------------------------------------------+
|  Cowboy Chain  --  System Actor 0x04 (CBSS)                          |
|  ------------------------------------------------------------------  |
|  - SecretMetadata, SecretVersion, ReleaseKeys                        |
|  - CbssProxy registry, DkgPending records                            |
|  - ReleaseReceiptSet, LivenessChallenge, slashing                    |
|  - Pairing-verifies sigma_i in SubmitReleaseReceipt                  |
+--------+-------------------------------+-----------------------------+
         |                               |
         | DkgPending events             | Release receipts +
         | RotateCommittee directives    | liveness challenges
         v                               v
  +-------------------+            +-------------------+
  |  cbssd (proxy 1)  | <-- DKG -->|  cbssd (proxy 2.n)|
  |  - QUIC server    |   reshare  |                   |
  |  - Sealed share   |   gossip   |                   |
  |  - Audit log      |            |                   |
  +---------+---------+            +---------+---------+
            |                                |
            |       PartialSign QUIC RPC     |
            |       (t parallel calls)       |
            +--------------+-----------------+
                           |
                           v
             +----------------------------------+
             |  Runner  --  secrets-manager     |
             |  - Verify sigma_i via pairing    |
             |  - Lagrange-combine to sigma     |
             |  - IBE-decrypt DEK, decrypt CBFS |
             |  - ${KEY} substitution into      |
             |    runner-http / runner-mcp / LLM|
             +----------------------------------+

​

On-Chain Component (System Actor 0x04)

​

Off-Chain Component (cbssd Daemon)

• Maintains an secp256k1 operator identity (registered on chain) and an X25519 HPKE identity (registered on chain) for DKG/reshare share encryption.
• Listens on a QUIC endpoint multiplexing four logical streams (PartialSign, Health, DkgRound, ReshareRound) on a single port (default 9601).
• Watches the chain for DkgPending records and RotateCommittee directives that name this proxy and orchestrates the corresponding ceremonies.
• Stores per-scope sealed shares at rest, sealed via AES-256-GCM under a key derived from the operator key.
• On PartialSign, validates the request against current head, computes σ_i = s_i · I, signs the response, and (after a 0–10 block jitter) submits a SubmitReleaseReceipt transaction.
• Maintains a 24-hour replay-bloom keyed on (release_id, proxy_id) so the same release is never partial-signed twice by the same proxy.
• Submits LivenessChallengeResponse for any chain-recorded challenge against this proxy.

​

Runner-Side Client (secrets-manager Crate)

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

​

1. Identifiers and Canonical Forms

• cbss/ibe/v1 — identity I and IBE key derivation.
• cbss/release-request/v1 — runner signature over ReleaseRequestBody.
• cbss/partial-sign-response/v1 — proxy signature over (request_hash, proxy_id, σ_i, committee_epoch_at_serve, served_at_block).
• cbss/rotate-committee/v1 — committee co-signature over RotateCommitteeArgs.
• cbss/liveness-challenge/v1 — runner signature over SubmitLivenessChallengeArgs.runner_request.
• cbss/share-storage/v1 — at-rest seal of operator share material.
• cbss/dkg-share-hpke/v1 — HPKE info for inter-proxy DKG share envelopes.

​

2. Storage Shapes

secret:{account_hex}:{key_hash_hex}                          → SecretMetadata
secret_version:{account_hex}:{key_hash_hex}:{version_be8}    → SecretVersion
secret_version_tombstone:{...}:{version_be8}                 → SecretVersionTombstone
account_release_key:{account_hex}                            → AccountReleaseKey
secret_release_key:{key_hash_hex}:{version_be8}              → SecretReleaseKey
cbss_proxy:{proxy_id_hex}                                    → CbssProxy
cbss_proxy_index_by_operator:{operator_hex}                  → ProxyId
release_receipt:{release_id_hex}                             → ReleaseReceiptSet
liveness_challenge:{challenge_id_hex}                        → LivenessChallenge
liveness_challenge_index:{release_id_hex}:{proxy_id_hex}     → ChallengeId
dkg_pending:{scope_serialized}                               → DkgPending

struct SecretMetadata {
    id: SecretId,
    latest_version: u64,
    active_versions: Vec<u64>,
    created_at: BlockHeight,
    last_updated_at: BlockHeight,
}

struct SecretVersion {
    version: u64,
    pending: bool,                     // true between override SetSecret and FinalizeSecretVersion
    recipient: ReleaseKeyRef,          // Account(_) or SecretSpecific{...}
    policy: SecretPolicy,              // actors allowlist + tee_required
    wrap_epoch: Option<u64>,           // immutable once set; None iff pending
    cbfs_pointer: Option<CbfsPointer>, // None iff pending
    wrapped_dek: Option<WrappedDek>,   // None iff pending
    created_at: BlockHeight,
}

struct AccountReleaseKey {
    account: Address,
    mpk: G2Bytes,
    committee: Vec<ProxyId>,
    threshold: u8,
    committee_epoch: u64,
    last_reshare_block: BlockHeight,
    vss_commitments: Vec<G2Bytes>,
    prior_committee_epochs: Vec<PriorCommitteeEpoch>, // capped at MAX_PRIOR_COMMITTEE_EPOCHS
}

struct PriorCommitteeEpoch {
    epoch: u64,
    committee: Vec<ProxyId>,
    vss_commitments: Vec<G2Bytes>,
    expires_at: BlockHeight,           // last_reshare_block + RESHARE_GRACE_BLOCKS
}

struct ReleaseReceiptSet {
    quorum_epoch: u64,                 // pinned to first accepted receipt's serve_epoch
    threshold: u8,
    entries: Vec<ReleaseReceipt>,      // capped at threshold
}

​

3. System Instructions (Opcodes 68–84)

• ≥ t signatures from the new committee under domain cbss/rotate-committee/v1.
• If updating an existing release key: ≥ t signatures from the prior committee, and new_mpk == old.mpk, and new_committee_epoch == old.committee_epoch + 1.
• Threshold reused from old.threshold (or, on first DKG, from DkgPending.threshold).
• vss_commitments valid: vss_commitments[0] == new_mpk, length = threshold, all decode to non-identity G2 points.

• body.request_block ∈ [head − REQUEST_FRESHNESS_BLOCKS, head].
• args.committee_epoch_at_serve == body.serve_epoch; both match a current or grace-window release key view.
• runner_sig recovers to body.runner_id under cbss/release-request/v1.
• proxy_sig recovers to proxy.operator under cbss/partial-sign-response/v1.
• SecretVersion exists, is non-pending, has recipient == body.recipient, and yields the wrap_epoch for identity derivation.
• policy.actors (if set) contains body.actor; policy.tee_required validates against the runner’s TEE attestation at submission-time current head.
• The pairing equation e(σ_i, G2_gen) == e(I, S_i) holds, with S_i = Σ_k vss_commitments[k] · proxy_index^k evaluated from the release-key view.
• The (release_id, proxy_id) pair has not already been recorded; the ReleaseReceiptSet has not yet reached threshold entries.

​

4. Events

​

5. The Release Path (Normative)

release_nonce      ← CSPRNG(32)
request_block      = chain_head_height
serve_epoch        = release_key.committee_epoch (at chain_head_height)
body               = ReleaseRequestBody { secret_id, version, actor, runner_id,
                                          recipient, job_id, release_nonce,
                                          request_block, serve_epoch }
runner_sig         = ECDSA-sign(runner_sk,
                                keccak256("cbss/release-request/v1" || encode(body)))
request            = SignedReleaseRequest { body, runner_sig }

1. body.request_block ∈ [head − REQUEST_FRESHNESS_BLOCKS, head].
2. runner_sig recovers to body.runner_id under cbss/release-request/v1.
3. Runner currently assigned to body.job_id (chain client, current head).
4. actor manifest declares body.secret_id.key_hash (chain client, current head).
5. policy.actors (if set) contains body.actor; policy.tee_required validates if set.
6. Proxy is a member of the referenced release key’s current committee.
7. body.serve_epoch == release_key.committee_epoch.
8. (release_id, proxy_id) not in 24-hour replay bloom.
9. Per-actor rate limit not exceeded.

• runner-http: substitutes ${KEY} in URL, headers (including Authorization), and request body bytes.
• runner-mcp: substitutes ${KEY} in MCP tool arguments (JSON-aware) and, for stdio MCP servers, spawns the child via tokio::process::Command::env_clear().envs(env) so the parent process environment is never mutated.
• runner-llm: only when server-side tool plumbing is active; otherwise rejects with SecretsNotApplicableHere.

​

6. The DKG and Reshare Path (Normative)

​

7. Slashing

​

8. Gas Pricing

​

9. Liveness, Health, and Slashing Fairness

​

10. Owner-Side Flows (CLI)

cowboy secrets set OPENAI_API_KEY <value>

cowboy secrets set STRIPE_LIVE_KEY <value> --committee-override --threshold 5/9

cowboy secrets policy OPENAI_API_KEY --add-actor 0x... --remove-actor 0x...

cowboy secrets versions OPENAI_API_KEY
cowboy secrets delete-version OPENAI_API_KEY --version 3
cowboy secrets delete OPENAI_API_KEY

cowboy proxy register --stake 10000 --network quic://1.2.3.4:9601
cowboy proxy status
cowboy proxy reshare-status

​

11. SDK Integration

{
  "secrets": {
    "read": {
      "keys": [
        { "type": "OwnAccount", "key": "OPENAI_API_KEY" },
        { "type": "CrossAccount", "account": "0x...", "key": "SLACK_API_KEY" }
      ]
    }
  }
}

result = runner.http(
    method="POST",
    url="https://api.openai.com/v1/chat/completions",
    headers={"Authorization": "Bearer ${OPENAI_API_KEY}"},
    json=payload,
    secrets=["OPENAI_API_KEY"],
)

​

12. Security Considerations

• 24-hour proxy-local replay bloom keyed on (release_id, proxy_id).
• Chain-side release_receipt:{release_id} map dedupes by (release_id, proxy_id) indefinitely.
• request_block freshness window REQUEST_FRESHNESS_BLOCKS constrains how far back a release request can target.

​

13. Parameters

⚠️ Value-drift, pending reconciliation (2026-07). Several defaults below are governance-tunable narrative targets that do not match the deployed constants; the deployed value is authoritative until governance sets otherwise. Known deltas: PROXY_SOAK_PERIOD_BLOCKS — deployed 100 (node/execution/src/cbss.rs, pinned as the launch value in the CIP-24 CBSS flag-flip governance proposal), not the 86,400 shown. MIN_PROXY_STAKE — deployed 1,000 (CBSS_MIN_PROXY_STAKE, node/types/src/constants.rs), not 10,000; this 10× gap is an open decision (cowboy#238, bound to COW-2497) — do not treat the table value as enforced. These are anti-Sybil economic parameters; the correct mainnet targets are a governance decision, not a spec-edit. The table below records the intended-scale narrative defaults, annotated where the deployed value differs.

​

14. Implementation Status and Mainnet Gate

• Cryptographic primitives (cbss-crypto): IBE encrypt/decrypt, threshold partial-sign and combine, DKG qualified-set finalization, PSS reshare, AAD binding, HPKE recipient-specific DKG/reshare payloads, and sealed share storage.
• Chain logic (0x04): all CBSS system instructions plus maintenance expiry paths, storage shapes, pairing-verified receipt acceptance, prior-committee grace window, signed RotateCommittee, signed runner_sig and proxy_sig recovery on SubmitReleaseReceipt, receipt-time ACL/job/TEE validation, liveness expiry, per-instruction gas pricing, release-debt accounting, and the three signed slashing evidence classes.
• Runner and daemon path: runner-side threshold client, QUIC PartialSign fanout, chain metadata resolution, CBFS ciphertext fetching, bounded fallback, health/latency-aware proxy ordering, ${KEY} substitution across runner HTTP/MCP/LLM paths, explicit-env subprocess spawning for stdio MCP servers, and rendered-argument zeroization where the current APIs allow it.
• cbssd production plumbing: DKG/reshare orchestration, QUIC server/client adapters, SPKI-pinned TLS identity, OS-keychain-backed operator identity, current-head chain release authorizer, chain watcher, and receipt submitter.
• Operator and owner surfaces: signed cowboy secrets / cowboy proxy commands, operator runbook, cross-document updates, governance flag-flip proposal draft, and the external review packet.

​

14.1 Out of Scope

• Forward-secret reshare (would require re-encryption of all anchored ciphertexts on every rotation).
• Plaintext leak slashing (handled by on-chain governance, not on-chain evidence).
• Zero-knowledge proofs of correct partial-sign computation (the pairing check on chain is sufficient for the threat model).
• Hierarchical secrets (sub-keys, scoped namespaces beyond per-account).
• Push-based re-fetch on policy change (runners pull at op time; ACL changes propagate via cache TTL).

​

15. Relationship to the Technical Whitepaper

• Actors, messages, timers, reentrancy, and per-handler resource limits follow Technical Whitepaper §3. The PVM environment-isolation requirement for declared secret keys is an additional sandbox constraint at handler entry.
• Fee markets (Cycles, Cells) and per-block basefee adjustment follow Technical Whitepaper §4 and §17. CBSS instructions consume both meters per §8 of this document.
• State rent for CBSS chain storage (metadata, release keys, receipts, challenges) follows the standard system-actor accounting at 0x04. Off-chain plaintext incurs no rent (it does not exist on chain); CBFS objects holding wrapped payloads bill under CBFS storage rent.
• The Runner Marketplace (Technical Whitepaper §5) is the consumer of release requests. Job dispatch integrates with CBSS via the actor’s secrets.read manifest entitlement; the assigned runner is the only eligible signer of release requests for the job’s duration.
• CBFS (Storage Whitepaper) is the data plane for the encrypted payload. The owner CLI uploads via CapToken at write time; the runner downloads via CapToken at read time. The CBFS pointer on SecretVersion is the only chain-resident reference.
• Consensus, randomness, and networking follow Technical Whitepaper §6. Committee selection uses the QC-derived randomness beacon for VRF.
• Governance, upgrades, and system actor hot-code replacement follow Technical Whitepaper §11. CBSS’s mainnet flag-flip is a governance proposal contingent on external cryptographic review of cbss-crypto.
• Entitlements (Technical Whitepaper §15) gate secrets.read at the manifest level; CBSS is the second, fine-grained layer (per-key, per-version, per-actor).
• TEE attestation gates release when policy.tee_required = true; the chain consults the verifier state at receipt-submission current head.