CIP-11: Runner Connectivity and Push Job Delivery (r1.3)

Revision history

• r1.3 (2026-06-06) — Presence redesigned around what consensus can carry; draft → final. A pre-finalization feasibility audit against the live node and commonware-monorepo sources found the r1.2 mechanism — per-validator presence bitmaps piggybacked on finalization votes and aggregated into a canonical P(H) — cannot be implemented as written (§2.1): consensus uses BLS12-381 threshold signatures, so a finalized block stores a single assembled Finalization { proposal, certificate } and individual votes carry no per-validator application payload (the whitepaper QC abstraction records at most signer membership, and current commonware retains only the recovered threshold certificate; neither carries arbitrary per-validator data); there is no on-chain validator registry (validator set hardcoded, EPOCH = 0, in consensus config, not execution-readable); and execution receives only &Block + receipts, with no access to parent votes. r1.3 keeps presence load-bearing but makes it a mode-aware, consensus-visible PresenceInput read by the dispatcher (§7): under a single validator (the launch and initial-mainnet topology) the lone validator’s live connection view is canonical presence and needs no new consensus primitive; under multiple validators the normative path keeps the same proposer-supplied PresenceInput (best-effort, fail-open); only an opt-in hard-exclude Mode A adds per-validator presence certificates (verified against the live §5.4 validator-set snapshot) carried separately from the threshold finalize signature (§8.3). Selection is present-first, fail-open (§7.3): presence orders the draw pool and routes push delivery, but the on-chain heartbeat is an eligibility floor (resilient to sustained BFT-minority censorship) that presence may never override. The wire format is hardened (app-layer role-scheme identity binding — runner secp256k1 / validator Ed25519 — with TLS-exporter channel binding, JobResultCommit, Goodbye, explicit signature domains, nonce-echoed HeartbeatPong, full JobAssignment payload coverage, deterministic MRU winner). A censorship-resistant hard-exclude mode (A) is documented for the multi-validator high-security regime; the small-k hard-exclude option (C) is rejected (§8.4).
• r1.2 (2026-05-26) — Block-time alignment to 1 s; all _BLOCKS constants rescaled ×5 to the canonical 1 s target. (Presence-vote constants superseded by r1.3; transport/MRU constants retain their 1 s calibration.)
• r1.1 (2026-05-11) — §9.3 weight base anchored to CIP-13 v2 effective_stake; block-time disclaimer (later superseded by r1.2).
• v0.2 (2026-04-14) — canonicalization, MRU, dispatch-outcome review findings.

​

1. Abstract

1. A runtime connectivity layer: each runner holds long-lived, mutually authenticated QUIC streams to a fixed-size, deterministically assigned subset of validators (§5, §6).
2. A consensus-visible presence signal (PresenceInput): a deterministic per-block input the on-chain Job Dispatcher reads to draw the runner committee present-first (§7). In the normative path it is proposer-supplied and best-effort/fail-open in all topologies — the lone validator’s live view (§8.1) or an off-chain-gossip aggregate under many (§8.2); an opt-in, governance-gated hard-exclude mode (§8.3) instead derives it from consensus-verified certificates. The dispatcher read-point is identical across modes, so launch upgrades without a dispatcher rewrite.
3. A push delivery path: validators with a live stream to a selected runner push the JobAssignment; the runner acknowledges, executes, and streams the result back (§10).
4. An MRU stickiness bias: the most-recently-successful runner for (submitter, job_kind) is favored on the first draw, improving cache locality (§9).

• No polling on the hot path. Dispatch latency drops from ~poll_interval to block-inclusion + application + one RTT (≈1–2 s at 1 s blocks; see §10.1), not literally a single RTT.
• Prefers active runners whenever presence evidence exists. Present-first selection plus push delivery makes the common path “selected ⇒ currently connected ⇒ immediate push”; a stale or false presence signal can at worst add a bounded first-attempt latency, and can never fail a job (§7.3).
• Ships on one validator with a minimal change, upgrades cleanly. Single-validator presence needs only a PresenceInput block field + execution read-point (plus the §9.2 consensus-seed plumbing — R_{S-1} for runners==1, an absolute future seed round r_seed for runners>1); multi-validator Mode B keeps that same committed, proposer-supplied field (sourced from off-chain validator gossip). A static genesis multi-validator network needs no dynamic-reconfiguration primitive — only changing the validator set over time does (§5.4) — and only the opt-in Mode A swaps the read-point’s source to consensus-verified certificate state (§8.2–§8.3).
• No exclusion of eligible runners (default Mode B). Selection’s eligibility floor is canonical chain state (the on-chain heartbeat), which no validator can forge or directly clear (staleness-by-censorship is bounded by proposer rotation — §7.1, §15.2); in Mode B presence only orders within eligible runners, so it cannot make a floor-eligible runner ineligible (§7.3, §15.2) — though a proposer can still deny a specific runner work via suppression when the present pool is full (bounded by proposer rotation, §15.9). (Mode A hard-exclude trades this away for strict semantics, §8.3.)
• Reuses on-chain identity and existing settlement. Runner identity/stake/capabilities stay in the Runner Registry (0x0000…0001); result settlement is the existing CIP-2 commit-reveal path (§10.3).

​

2. Motivation

1. The Job Dispatcher (0x0000…0002) selects M runners on-chain via stake-weighted Fisher-Yates over the registered candidate set and writes each assignment to runner_jobs_key(addr).
2. Each runner separately polls GET /runner/{addr}/jobs over plain HTTP every job_poll_interval_seconds.
3. When the runner has a result, it POSTs to /runner/{addr}/job_result (multi-runner jobs first POST /runner/{addr}/job_result_commit). The validator builds the corresponding transaction and forwards it to the mempool.

1. Polling latency is the floor on job start time. A multi-second poll interval is a large fraction of the budget for short interactive jobs (LLM completions, single MCP calls); driving it lower wastes bandwidth across thousands of runners.
2. Selection does not consult real-time reachability. The dispatcher already hard-filters heartbeat-derived health (registry.rs marks runners Unhealthy once last_heartbeat is stale; dispatcher.rs selects only Healthy runners), but that signal is coarse: a runner that dies between its last heartbeat and selection is still assigned, then times out and re-selects — a multi-block latency spike on every silent failure. Sharply reducing the user-visible cost of routing a job to a runner that is not actually there is a primary goal of this CIP (present-first selection plus fast ack-timeout correction, §8); it bounds rather than wholly eliminates that cost.
3. Heartbeats cost on-chain bandwidth. ~1,000 runners today (≈5,000 at the §6.6 design target) each posting a periodic heartbeat transaction is real consensus bandwidth.
4. No path to runner stickiness. “Most-recently-successful runner for actor A” is a natural cache-locality win that pull-based delivery cannot express.

​

2.1 Why presence is a mode-aware artifact, not a vote bitmap

1. No execution-readable validator registry. The validator set is hardcoded (EPOCH = 0, no reconfiguration), lives in consensus Config (participants: Set<PublicKey>), and is not execution-readable; there is no SYS_VALIDATOR_* instruction, so the state-transition function cannot today verify a validator-origin attestation.
2. Execution cannot read parent votes. apply_finalized_block receives &Block + receipts; the finalization proof is never threaded into execution.

• One validator (launch): there is nothing to aggregate and no Byzantine validator to defend against. The lone validator already observes every runner’s connection first-hand; it simply states presence as a block input. No registry, no threshold, no consensus change beyond the input field (§8.1).
• Many validators: the normative path keeps proposer-supplied, best-effort presence (no new consensus primitive — it is fail-open, §7.3); validator identities come from the live §5.4 ValidatorSetSnapshot. Only the opt-in hard-exclude Mode A carries per-validator evidence separate from the threshold finalize signature, verified against that same snapshot (no separate Mode-A registry); its certificate machinery is governance-gated (§8.3). That evidence path is a real consensus-visible addition, scoped to Mode A and enabled only by governance.

​

3. Definitions, Notation, and Conventions

​

3.1 Requirements language

​

3.2 Notation

• H — a block height; H−1 its parent, H+1 its child; current_block_height is the height being executed.
• E, E+1 — consecutive active validator-set snapshot epochs; subset_epoch is the active ValidatorSetSnapshot.epoch value (§5.3–§5.4), not a separate per-consensus-epoch tick.
• V — the active validator set (snapshot, §5.4); n = |V|; f — the BFT fault bound (f < n/3).
• R — a runner; |R| — the number of registered runners.
• Sub(R) / Sub_E(R) — runner R’s connectivity subset (in epoch E); k = |Sub(R)|.
• M — the committee size for a job (= job_spec.verification.runners); i — the zero-based weighted-draw iteration (§9.2).
• S — a job’s submission block height; for M > 1, the committee is assigned at a later pending-selection pass once the absolute seed round r_seed is readable (§9.2).
• Round(e, v) — the consensus round identified by commonware Seed.round = (epoch, view). A block height is not a round: a block at height S is proposed in one absolute round and can be certified/finalized in a later absolute round. Runner-selection randomness MUST name the absolute Round(e, v) whose seed is consumed (§9.2).
• R_X — a consensus threshold-VRF beacon/seed for round/anchor X (e.g. parent beacon R_{S-1}, absolute seed round r_seed); see canonical_seed_bytes (§9.2).
• multi_validator — the predicate n = |V| > 1 (more than one active validator in the §5.4 snapshot); distinguishes the multi-validator security paths from the single-validator launch case (f = 0).
• ‖ — byte concatenation; keccak256(...) — the Keccak-256 hash.
• load-bearing — a value that deterministically affects dispatcher output (the selected committee or its ordering) and is therefore committed to the block’s execution identity; contrast a best-effort hint.

​

3.3 Defined terms

• Connectivity Subset (Sub(R)): The deterministic, fixed-size set of validators runner R maintains QUIC connections to, computed off-chain from the active validator-set snapshot (§5). Bounds connection fan-out; under one validator it is that validator.
• Selection Liveness Floor (a.k.a. the eligibility floor, the on-chain heartbeat floor, or just floor): The on-chain heartbeat-derived eligibility gate the dispatcher applies: a candidate is eligible iff HealthStatus::Healthy and current_block_height − last_heartbeat ≤ HEARTBEAT_TIMEOUT_BLOCKS. Canonical and runner-self-attested. In Mode B it is the sole eligibility gate — presence can never make an ineligible runner eligible, nor exclude a floor-eligible one. In Mode A (§8.3–§8.4) presence is an additional gate on top of the floor (a runner must pass the floor and be present). (§7.1, §7.3)
• Selection posture — Mode B (normative) and Mode A (opt-in): The two postures for how PresenceInput affects selection. Mode B is the default, normative in all topologies (§7.3, §8.2): presence is present-first and fail-open — it orders the draw and routes delivery but never removes a floor-eligible runner. Mode A is the opt-in hard-exclude posture, governance-gated by PRESENCE_HARD_EXCLUDE_ENABLED (§8.3 machinery, §8.4 rationale): presence is a strict gate — a runner not proven present is not selectable — and is sound only with honest-majority subsets (large k). Unless stated otherwise, the spec describes Mode B.
• Present-first selection: Drawing the committee from the present pool first, falling back to the fallback pool only once the present pool is exhausted (§7.3, §9.2). It orders selection; it never excludes a floor-eligible runner. In multi-validator Mode B it does not determine membership for runners > 1 independence-verification jobs (the membership-steering bound, §7.3/§15.9).
• Fail-open: The property (Mode B) that a missing, stale, malformed, or even adversarially-false PresenceInput can never fail a job or exclude a floor-eligible runner — at worst it wastes one delivery attempt (caught within ACK_TIMEOUT_BLOCKS) or de-prioritizes a runner into the fallback pool (§7.3). The opposite of the fail-closed / hard-exclude behavior of Mode A.
• Best-effort (presence): In Mode B, PresenceInput is a non-authoritative routing/ordering hint, not a Byzantine-verified fact; its only failure modes are bounded and self-healing (§8.2, §15.2). Authoritative eligibility is the Selection Liveness Floor, not presence.
• PresenceInput: The deterministic, consensus-visible per-block artifact the Job Dispatcher reads to identify currently-present runners (a bitmap/index set over the Runner Registry). Same execution read-point in all modes; its source and validation are mode-aware (§7.2, §8).
• Present pool / fallback pool: At selection, the present pool is the set of eligible candidates marked present by PresenceInput; the fallback pool is the remaining eligible candidates. Selection draws present-first, falling back only as needed (§7.3).
• Local Presence: A single validator’s off-chain, per-connection view of which runners it currently has a healthy QUIC control stream to. Used to route its own push delivery; it is also the source of that validator’s contribution to PresenceInput (§7.4).
• Consensus-Verified Presence State (Mode A only): presence_proven_until[runner], maintained on-chain by verified runner-submitted presence certificates (§8.3); the source of PresenceInput only when the opt-in hard-exclude Mode A is enabled.
• Push Dispatch: A validator opening a QUIC stream to a runner and writing a JobAssignment, replacing the poll (§10).
• MRU Weight Multiplier: A deterministic iteration-0 weight bump for the most-recently-successful runner for (submitter, job_kind) (§9.3).
• Dispatch Outcome: Success | Duplicate | SoftFailure | HardFailure — a validator’s classification of a push attempt (§10.6).
• Runner identity: a runner’s registered Address in RunnerRegistration (20-byte secp256k1/EVM address; live field owner node/runner/src/types.rs). RunnerRegistration does not store a secp256k1 public key; runner-originated CIP-11 frames carry a scheme-tagged compressed secp256k1 PubKey and/or a recoverable secp256k1 signature, and verifiers MUST derive/recover the EVM address and require it to equal RunnerRegistration.address. This address is the runner’s economic identity and the authority for runner-originated control-plane frames.
• Validator peer identity: the Ed25519 commonware identity key a validator uses for network peer identification and to sign validator-originated CIP-11 control-plane frames — asymmetric to the runner’s secp256k1 identity. The BLS12-381 threshold key is consensus-only (notarization) and is never used for control-plane signatures (§2.1, §12.6).
• Scheme-tagged key / role-scheme signature: public-key and signature fields are interpreted by the signer’s role — runner → secp256k1 (33-byte key, 65-byte recoverable ECDSA sig); validator → Ed25519 (32-byte key, 64-byte sig). Keys carry a 1-byte scheme tag and signed preimages include role + scheme; verifiers MUST reject any role/scheme/length/source mismatch (§12.6). Two key types appear in this spec: PubKey is the wire type — a scheme-tagged key (scheme_id ‖ key_bytes; 34 B secp256k1 / 33 B Ed25519) used in CIP-11 frames and receipts (§12.6); PublicKey is the raw commonware Ed25519 key type used for authoritative §5.4 snapshot state (ValidatorRecord.peer_pubkey). A validator wire PubKey MUST decode (after scheme validation and tag-strip) to the authoritative raw ValidatorRecord.peer_pubkey; a runner wire PubKey MUST be valid secp256k1 key material whose derived EVM address equals the authoritative RunnerRegistration.address.
• validator_set_hash: keccak256 over the active §5.4 ValidatorSetSnapshot’s ordered validator identities (peer_pubkey per ValidatorRecord, excluding the mutable stake) — at launch, the genesis single-validator snapshot. Identifies the shared validator-set configuration (§5.1, §5.4, §6.2).
• Proposer: The validator that authors the current block. Under one validator it is always that validator; in Mode B it supplies PresenceInput in the block it proposes (§8.1–§8.2).
• Committee: The set of M = job_spec.verification.runners runners the Job Dispatcher selects for a job (§9.2).
• On-chain system actors: the Runner Registry (0x0000…0001) — stores runner identity, stake, RunnerCapabilities, HealthStatus, and last_heartbeat (live field owner: node/runner/src/types.rs; state transitions in node/execution/src/runner/registry.rs); the Job Dispatcher (0x0000…0002) — runs selection and writes assignments and mru_key; the Result Verifier (0x0000…0003) — processes commit/reveal, finalizes results, and produces/consumes VerifiedResult.runners_to_slash. CIP-2 introduces these actors and selection concepts; CIP-11 extends their behavior but adds no new actor in the normative path.
• subset_epoch: The epoch value of the active ValidatorSetSnapshot(epoch) consumed by CIP-11. It is not a separate CIP-11 counter and does not advance on every consensus epoch tick; it changes only when consensus emits a new CIP-11-visible validator-identity snapshot whose canonical ordered peer_pubkey list changes (§5.4). It selects which snapshot Sub(R) / validator_set_hash are computed against (§5.3–§5.4).
• mru_key / MruRecord: Job Dispatcher state mapping (submitter, job_kind) → MruRecord { runner_address, set_at_block } — the most-recently-successful runner used for the §9.3 iteration-0 weight bump (§9.4).
• presence_anchor (Mode A): per-runner state holding the observation height of the newest accepted presence certificate; the strictly-monotonic anchor that bounds receipt replay (§8.3).
• CIP-11 wire frames: the runner↔validator QUIC messages defined in §6 and §10 and tabulated in §12.2. HeartbeatPing / HeartbeatPong are the QUIC-layer liveness frames — distinct from the on-chain heartbeat that drives the floor (§7.1).
• channel_binding / connection_id: channel_binding is the TLS-Exporter value that binds application-layer role-scheme identity proofs (runner secp256k1 / validator Ed25519) to a specific QUIC/TLS channel (§6.2); connection_id = keccak256(...) is the per-connection identifier derived from it plus the peer identities and epoch (§12.6). Both appear in frame signature preimages and are the reason HeartbeatPong is not chain-verifiable (§8.3).
• Reconfiguration & Mode-A objects (defined where introduced, listed here for discoverability): ValidatorSetSnapshot / ValidatorSetActivated — the consensus interface CIP-11 consumes (§5.4); ValidatorRecord — a snapshot entry (§8.3); PresenceReceipt and the SubmitPresenceCertificate system instruction — Mode-A presence evidence (§8.3); OverlapExpired — a GoodbyeReason for reconfiguration teardown (§5.3, §12.5).
• Imported terms (defined in other CIPs; used here normatively):
  • RunnerRegistration, RunnerCapabilities, HealthStatus (Healthy / Unhealthy / Paused / Deregistered), and last_heartbeat — live Runner Registry record and fields (node/runner/src/types.rs; heartbeat/state transitions in node/execution/src/runner/registry.rs). CIP-2 §4 owns the health-filter concept; CIP-11 consumes it as the floor (§7.1).
  • JobSpec, JobType, VerificationMode (None, EconomicBond, MajorityVote, StructuredMatch, Deterministic, SemanticSimilarity) — job/verification shapes (CIP-2); JobSpec.verification.runners = M.
  • runners_to_slash — VerifiedResult.runners_to_slash, produced by the Result Verifier for minority/mismatch runners and consumed by verifier/aggregator code to exclude dissenters from consensus-matching completion/bonus selection (node/runner/src/types.rs, node/execution/src/runner/verifier.rs, node/execution/src/runner/aggregator.rs); not a CIP-2-defined type.
  • effective_stake = registration.stake + delegation_totals.total_active — VRF weight base (CIP-13 v2 §3.2; mirrored by CIP-2 concentration math).
  • CapabilityKey (CIP-11-local string key for advisory capability deltas using the runtime RunnerCapabilities / dispatcher-filter namespace) and EntitlementId ([u8; 32]; CIP-2 / node/types/src/entitlement.rs) — runner advisory capability and pool/entitlement identifiers. Storage and secret capability semantics remain owned by CIP-9/CIP-24.
  • Fisher-Yates VRF selection, commit-reveal settlement, timeout-based re-selection — the CIP-2 §4–§6 mechanisms CIP-11 extends.
  • keccak256, secp256k1 (ECDSA with ecrecover), QUIC (RFC 9000), TLS 1.3 (RFC 8446) and its TLS-Exporter — standard primitives used across Cowboy.
  • Address — a Cowboy chain account address; PublicKey — the commonware Ed25519 consensus/peer participant key type (the validator peer identity above). Runner wire public keys are secp256k1 PubKeys authenticated by derived-address equality against RunnerRegistration.address.
  • Frame codec — CIP-11 runner↔validator wire frames are QUIC application frames with the envelope defined in §12.1. The payload CBOR canonicalization authority is CIP-11’s deterministic CBOR profile (§12.6), not commonware-p2p or commonware-codec (commonware-p2p carries no CBOR). commonware-codec is relevant only where a field explicitly names an existing codec-owned object, e.g. tx_bytes = Transaction::write(...) (§10.3).
  • SystemInstruction::{RunnerHeartbeat, JobSubmit, JobResultSubmit, JobResultCommit, JobCancel} — live node system-instruction variants (node/types/src/execution.rs); SubmitPresenceCertificate is the new Mode-A system instruction this CIP specifies, to be added to the same namespace when Mode A is implemented.
  • Transaction::payload_bytes(...) — the node transaction signing preimage builder (node/types/src/execution.rs); includes nonce, instruction, cycles/cells limits, max-fee and priority-fee fields, and signer addresses. CIP-11 result and heartbeat transaction replay protection relies on this ordinary transaction signature/nonce path unless this CIP explicitly defines a separate application-frame nonce.
  • execution_hash() / extra_data — block identity fields/functions (node/types/src/execution.rs). Because PresenceInput is load-bearing it MUST be committed in the execution identity / block digest, not carried only in extra_data.
  • selection_reputation_x1e9(runner.reputation, ReputationConfig_at(H), H) — the live dispatcher reputation normalizer used by the CIP-2 v3 selection weight (node/execution/src/runner/dispatcher.rs); ReputationConfig is the governance-updatable config type (node/types/src/execution.rs).

​

4. Design Overview

​

4.1 Architecture

​

4.2 Lifecycle

1. Bootstrap. Runner reads the configured validator set, computes validator_set_hash and Sub(R) (§5), and opens a long-lived QUIC connection to each validator in Sub(R) (the sole validator, at launch).
2. Handshake. Mutually authenticated, channel-bound, pubkey-bound handshake on each connection (§6.2).
3. Heartbeat (two layers). On the QUIC control stream the runner MUST emit HeartbeatPing at least once every HEARTBEAT_BLOCKS (default: once per block); the validator MUST update per-connection liveness and local presence for each valid Ping, subject to the backpressure omission rule (§6.4). Independently, the runner submits the on-chain heartbeat that maintains its canonical last_heartbeat/health — the eligibility floor (§7.1).
4. Presence input. The dispatcher reads a PresenceInput identifying currently-present runners (§7.2); in the normative path its source is the proposer’s view carried in the block — the lone validator’s live connections (§8.1) or an off-chain-gossip aggregate under many (§8.2). The opt-in hard-exclude Mode A (§8.3) instead derives it from consensus-verified certificate state.
5. Selection. The Job Dispatcher filters by the eligibility floor (§7.1), then runs the normative weighted VRF draw present-first using PresenceInput, with the MRU iteration-0 bias (§9). runners == 1 jobs select immediately in the submission block S from the parent beacon R_{S-1}; runners > 1 jobs record a pending selection in S and are assigned only at the pending-selection pass once block S is finalized/applied, the seed for the absolute future round r_seed is readable, and the committed candidates-snapshot root verifies (commit-then-reveal, §9.2). Present-first is subject to the §7.3 membership-steering bound: in multi-validator Mode B, runners > 1 committee membership is drawn by VRF over the full floor-eligible set and presence is delivery-only. Presence never excludes a floor-eligible runner (§7.3).
6. Push dispatch (after finalization & application). Once the assignment block is finalized and applied, validators holding a live stream to the selected runner push a fully-covered, signed JobAssignment (§10.1); the runner dedupes and verifies before executing.
7. Result. Runner streams the existing commit/reveal material back (§10.3); the validator forwards the existing CIP-2 transaction(s); settlement is unchanged.
8. MRU update. The Result Verifier deterministically picks the winning runner and updates mru_key (§9.4).
9. Re-selection. If no result by the per-job timeout, the existing CIP-2 §6 timeout re-selection runs (§11.2).

​

4.3 Relationship to Existing CIPs

• CIP-2. CIP-11 strictly extends CIP-2: candidate list, Fisher-Yates VRF, commit-reveal verification, and timeout re-selection are preserved. Push replaces polling on the hot path; the poll endpoint is retained as a delivery-only fallback (§14). The on-chain heartbeat health gate becomes the codified eligibility floor (§7.1).
• CIP-9. Push reduces cold-start before CBFS reads; MRU bias improves read-cache hit rates.
• CIP-10. Lower job-start latency reduces idle container cost; base images SHOULD ship the CIP-11 client transport.
• CIP-13. Delegated stake is opaque to CIP-11; CIP-13 supplies the effective_stake stake term consumed by the CIP-2 v3 VRF weight (§9.3).

​

5. Connectivity Subset Assignment

​

5.1 Subset Function

Sub(R) = first k validators in sort_by(v ∈ V, key = keccak256(R.auth_pubkey ‖ v.peer_pubkey))
k      = min(|V|, clamp(ceil(log2(|V|)) + 1, MIN_SUBSET, MAX_SUBSET))

​

5.2 Properties

• Stable under runner churn. A new runner’s subset is independent of others’.
• Load-balanced in expectation. Each validator handles |R|·k/|V| connections in expectation.
• Validator-side DoS gate. A validator MUST reject connections from a runner not in that runner’s expected Sub(R) for the validator’s own identity — a purely local check bounding Sybil storms to k connections per registered identity (§15.1).

​

5.3 Subset Epochs and Reconfiguration

1. Connections. Runners MUST open connections to Sub_{E+1}(R) while keeping Sub_E(R) open — i.e. maintain the union Sub_E(R) ∪ Sub_{E+1}(R) for the window — then drop epoch-E-only validators.
2. Admission (§6.2) — epoch-paired, never cross-product. A connection is valid iff (offered hash == validator_set_hash(E) and this validator ∈ Sub_E(runner)) OR (offered hash == validator_set_hash(E+1) and this validator ∈ Sub_{E+1}(runner)). The offered (subset_epoch, validator_set_hash) selects exactly one snapshot; the validator’s peer_pubkey and its subset membership MUST both resolve in that same snapshot. The union Sub_E(R) ∪ Sub_{E+1}(R) is merely the set of simultaneously-valid connections — it is never a license to mix epoch-E’s hash with epoch-E+1 membership (which would break the connection_id / HelloAck identity binding). The runner applies the same epoch-paired rule when verifying the validator.
3. Routing & presence. A validator routes/attests for a runner only over an epoch-paired-valid connection (point 2); in Mode A, a PresenceReceipt counts only if its own (subset_epoch, validator_set_hash) is epoch E or E+1 and the signing validator is in Sub_epoch(runner) (where epoch is E or E+1 as selected by the offered (subset_epoch, validator_set_hash)) (§8.3).
4. After the window (at block activation_height + OVERLAP_BLOCKS, a height-tied cutoff identical for all nodes — no grace period): only Sub_{E+1}(R), validator_set_hash(E+1), and epoch-E+1 receipts are valid. Either side MAY initiate closing an epoch-E-only connection (one whose validator is not in Sub_{E+1}(R)) with Goodbye { reason: OverlapExpired } (§12.5); the peer abandons in-flight work on that stream (it drains via §11.5) and MUST NOT reconnect under the epoch-E hash — a Hello offering validator_set_hash(E) past the cutoff is rejected at §6.2 admission.

​

5.4 Validator-Set Snapshot (Consensus Interface)

ValidatorSetSnapshot(epoch) {
  epoch:             u64,
  participants:      [ ValidatorRecord ],   // canonically ordered by peer_pubkey (§8.3)
  activation_height: u64,                    // block at which this epoch's set becomes active
}
// event observable by nodes and execution:
ValidatorSetActivated(epoch, activation_height)

• Validator identity snapshot: CIP-11 needs execution to read a canonical list of validator identities (ValidatorSetSnapshot(epoch) with ordered Ed25519 peer_pubkeys). Static genesis topologies need only ValidatorSetSnapshot(0), derived from the fixed genesis/commonware participant configuration. This is required for multi-validator Sub(R), validator_set_hash, QUIC admission, JobAssignment.validator_pubkey verification, and Mode-A receipt verification. It is not the dynamic reconfiguration primitive, but it is not exposed as execution state in Cowboy today.
• Dynamic validator-set reconfiguration: changing the set over time (E → E+1) is separately gated on the consensus reconfiguration primitive named in Requires (epoch advancement + BLS threshold resharing/DKG emitting ValidatorSetSnapshot / ValidatorSetActivated). Cowboy currently runs at epoch 0 and does not consume this primitive.

​

6. The QUIC Connection Layer

​

6.1 Transport

​

6.2 Handshake and Authentication

channel_binding = TLS-Exporter("cowboy-cip11-handshake-v1", "", 32)

Hello {
  version: u16, chain_id: u64,
  validator_set_hash: [u8; 32], subset_epoch: u64,   // §5; subset_epoch v1 = 0
  party_pubkey: PubKey, party_role: Role,            // scheme-tagged wire PubKey (§12.6): Runner→secp256k1 (34B: tag+33B key), Validator→Ed25519 (33B: tag+32B key)
  block_height: u64, challenge_nonce: [u8; 32],
}
HelloAck {
  version: u16, chain_id: u64,
  validator_set_hash: [u8; 32], subset_epoch: u64,
  party_pubkey: PubKey, party_role: Role, block_height: u64,
  signed_challenge: Sig,                               // role-scheme sig (§12.6): Runner→secp256k1 65B, Validator→Ed25519 64B; over §12.6 HelloAck preimage
}

enum Role { Runner, Validator }

​

6.3 Heartbeats

HeartbeatPing  { block_height: u64, nonce: u64, signed: [u8; 65] }            // R→V; secp256k1 over §12.6 preimage
HeartbeatPong  { block_height: u64, nonce_echo: u64, accepting_new: bool, validator_signed: [u8; 64] } // V→R; accepting_new = validator's current view of runner capacity; Ed25519 over §12.6 preimage

The QUIC heartbeat feeds local presence (and, in multi-validator mode, presence evidence). The eligibility floor used by selection is the separate on-chain heartbeat (§7.1).

​

6.4 Backpressure

BackpressureSignal { block_height: u64, active_jobs: u32, max_concurrent: u32, accepting_new: bool, reason: Option<String>, signed: [u8; 65] } // R→V; secp256k1 over §12.6 preimage

​

6.5 Capability and Entitlement Updates

CapabilityKey = String   // CIP-11-local advisory key; canonical UTF-8 key in the RunnerCapabilities/dispatcher-filter namespace

CapabilityDelta {
  block_height:          u64,
  added_capabilities:    Vec<CapabilityKey>,
  removed_capabilities:  Vec<CapabilityKey>,
  added_entitlements:    Vec<EntitlementId>,
  removed_entitlements:  Vec<EntitlementId>,
  signed:                [u8; 65],             // secp256k1 over §12.6 preimage
}

​

6.6 Operational Considerations (single validator, ~5,000 runners)

• Connection count. With k = 1 the sole validator holds one QUIC connection per runner (≈ |R|, ≈5,000 at target scale). Operators MUST raise file-descriptor limits (e.g. ulimit -n ≥ 2× runner count) and budget connection-state memory (~0.5–1 MB/connection). QUIC connection migration (§6.1) avoids reconnect storms on transient network changes.
• Pre-auth flood resistance. The §6.2 per-peer Hello rate limit and the §5.2 subset DoS gate together bound connection-storm cost; operators SHOULD additionally cap concurrent half-open handshakes and accept-queue depth, since the subset gate only rejects after the peer’s claimed identity is known.
• On-chain heartbeat volume. At ~5,000 runners, on-chain heartbeat volume is cadence-bound, not merely timeout-bound. The “tens per block” target assumes an effective on-chain cadence near the HEARTBEAT_TIMEOUT_BLOCKS window (default 100 blocks) and staggered runner phases: 5,000 / 100 ≈ 50 heartbeat transactions per block. The current runner implementation still defaults to a fixed 10 s cadence (runner/crates/runner-node/src/config.rs; runner/crates/runner-node/src/node.rs; runner/crates/chain-client/src/client.rs), which is about 10 blocks at the default 1 s block time and therefore yields 5,000 / 10 ≈ 500 heartbeat transactions per block before launch, restart, or partition-heal bursts. Governance MAY widen HEARTBEAT_TIMEOUT_BLOCKS and the effective runner heartbeat cadence in Phase 3 (§14) once push/ack provides the fast-liveness signal, while preserving a floor-safety margin before staleness. The QUIC HeartbeatPing (§6.3) is off-chain and free; only the on-chain floor heartbeat consumes block space.
• Heartbeat staggering. Runner implementations SHOULD decorrelate on-chain heartbeat submissions with a deterministic per-runner phase bucket. Define safety_margin_blocks large enough for normal inclusion/finality delay, bounded jitter, and expected short mempool congestion; define effective_cadence_blocks ≤ HEARTBEAT_TIMEOUT_BLOCKS − safety_margin_blocks; then derive a phase such as phase = keccak256(chain_id ‖ runner_address) mod effective_cadence_blocks and schedule steady-state on-chain heartbeats in that runner’s phase bucket rather than on a short fixed timer. Implementations SHOULD still force an emergency refresh before current_block_height − last_heartbeat > HEARTBEAT_TIMEOUT_BLOCKS if normal cadence is missed. The staggering key MUST be runner-specific; implementations MUST NOT use a runner-independent schedule such as “submit when block_height mod N == C”, because that preserves correlated launch, partition-heal, and chain-restart herds instead of spreading them. QUIC reconnect jitter (§11.3) is not a substitute for on-chain heartbeat staggering.
• Selection cost. Present-first partitioning is O(|eligible|) per job with O(1) bitmap lookups (§7.2 encoding); implementations SHOULD decode PresenceInput once per block and reuse it across all jobs in that block.

​

7. Presence and the Liveness Floor

​

7.1 Eligibility Floor (Canonical, On-Chain, Never Overridable)

​

7.2 PresenceInput (Consensus-Visible, Mode-Aware Source)

• Mode B — single OR multiple validators (NORMATIVE, §8.1–§8.2): carried in the proposed block body and supplied by the proposer — its own live view (single validator) or an off-chain-gossip aggregate (multiple). Best-effort and fail-open (§7.3). Because it is load-bearing for selection, it MUST be part of the block’s deterministic pre-execution input and committed in both the execution identity used by propose/verify (execution_hash or its successor) and the block digest. It MUST NOT live only in uncommitted proposer metadata (e.g. the current excluded extra_data path) — otherwise propose/verify could cache or replay a different selection than was committed.
• Mode A — hard-exclude (governance-gated optional, §8.3): fully specified but inactive unless PRESENCE_HARD_EXCLUDE_ENABLED is set (§13). When active, the proposer-supplied field is ignored and PresenceInput is derived from consensus-verified presence_proven_until state maintained by runner-submitted certificates.

• kind = 0x00 (bitmap): body is exactly ⌈|registry(H−1)|/8⌉ bytes; within each byte bit j (LSB-first) is registry index 8·byte + j; every bit at a position ≥ |registry(H−1)| MUST be 0.
• kind = 0x01 (sparse): body is a u32 count (big-endian) followed by count strictly-ascending u32 registry indices (big-endian).

1. While CIP11_PRESENT_FIRST_ENABLED is false, PresenceInput is not a block-validity requirement. If the field is absent, malformed, or present only for shadow logging, execution MUST treat the present set as empty for any non-shadow selection behavior.
2. When CIP11_PRESENT_FIRST_ENABLED is true and PRESENCE_HARD_EXCLUDE_ENABLED is false (active Mode B), each block MUST contain exactly one committed, well-formed PresenceInputV1. A proposer that has no present runners MUST encode a valid empty set. An absent or malformed field is block-invalid in this phase because it is a load-bearing deterministic execution input.
3. When Mode A is effective (PRESENCE_HARD_EXCLUDE_ENABLED == true and the §8.4 K_HARD_MIN activation guard is satisfied), the proposer-supplied Mode-B field is ignored for selection. PresenceInput(H) is derived from parent-state presence_proven_until (§8.3); block validity depends on that state derivation, not on any proposer field. A block MAY omit the proposer field in effective Mode A. If the flag is set but the guard is not satisfied, Mode A is inactive: active present-first selection remains Mode B, the bullet-2 proposer-field requirements still apply, and any block/state transition that hard-excludes a floor-eligible runner due to missing Mode-A proof is invalid.

​

7.3 Present-First, Fail-Open Selection (Normative)

1. Partition eligible candidates into the present pool (marked present) and the fallback pool (the rest).
2. Run the normative §9.2 weighted VRF committee draw (weighted_draw) over the present pool first; if it cannot fill the committee size M, continue the draw over the fallback pool.
3. In default Mode B, PresenceInput therefore orders selection and routes push delivery; it never removes a floor-eligible runner from eligibility. (Mode A, §8.3, is the documented exception where presence does hard-exclude.)

• Presence MUST NOT be a hard exclusion of floor-eligible runners. A runner that passes the floor (§7.1) MUST remain drawable from the fallback pool even if it is absent or suppressed from PresenceInput; an implementation MUST NOT use PresenceInput absence (or a backpressure/Goodbye signal) to veto a floor-eligible runner’s selection from the fallback pool. A fabricated or stale “present” bit only wastes a first push attempt, caught by the ack timeout and fallback (§10.6, §11).
• If PresenceInput is absent or malformed in a phase where §7.2 does not make that block-invalid, the present pool is treated as empty and the committee is drawn entirely from floor-eligible runners. In active Mode B with CIP11_PRESENT_FIRST_ENABLED, absence/malformedness is already block-invalid (§7.2); a valid empty set is the fail-open representation. Either way a missing presence signal degrades to today’s behavior and MUST NEVER fail a job.
• A runner omitted from PresenceInput for any reason — a proposer’s stale local view, a restart, a backpressure signal, or deliberate proposer suppression — remains in the fallback pool in Mode B, so omission cannot make a floor-eligible runner ineligible; at worst it is de-prioritized when enough present runners exist (though see the slot-steering caveat below and in §15.9).

​

7.4 Local Presence (Per-Validator, Delivery Routing + Evidence Source)

​

7.5 Optional Observability Gossip (Non-Normative)

​

8. Presence Derivation by Mode, and Security Posture

​

8.1 Single Validator (Launch and Initial Mainnet)

• The proposer sets PresenceInput to its current local-presence set (§7.4). Its proposed, signed block is already its authoritative statement; no validator registry, threshold, or aggregation is required.
• Selection is present-first/fail-open (§7.3). Because the present pool is the validator’s live connections, the common path is “selected ⇒ connected ⇒ immediate local push.” The only residual is at most a one-block snapshot lag — a runner that disconnects between the proposer’s presence snapshot and dispatch is caught by ACK_TIMEOUT_BLOCKS + fallback (§15.2) — so the active-runner UX holds in the common case without claiming a hard pre-assignment reachability guarantee.
• The on-chain heartbeat floor (§7.1) still applies as defense-in-depth and as the artifact that makes the multi-validator upgrade a source-swap rather than a redesign.

​

8.2 Multiple Validators — Mode B (Normative)

• Determinism. Every verifier executes against the committed PresenceInput bytes — not its own live view or gossip — so all nodes select the same committee for the block.
• Bounded Byzantine impact. Because Mode B presence is best-effort and fail-open (§7.3), a Byzantine or mistaken proposer can only fabricate present bits (→ a wasted first push attempt that self-heals via the ack timeout) or suppress them (→ the runner stays floor-eligible in the fallback pool, never censored). Damage is bounded to that proposer’s own slots and never affects safety or eligibility.

​

8.3 Mode A Machinery (Opt-in Hard-Exclude)

ValidatorRecord {
  peer_pubkey:     PublicKey,     // Ed25519 commonware consensus/peer identity (§3); ALSO signs CIP-11 control-plane frames
  stake:           u128,          // not consumed by any CIP-11 rule; carried for consensus / other-CIP use
}

PresenceReceipt {            // validator-issued; on-chain verifiable (§12.6 domain)
  validator_pubkey:   PubKey,     // Ed25519 wire PubKey (§12.6); MUST decode to a §5.4 snapshot peer_pubkey
  runner_pubkey:      PubKey,      // secp256k1 wire PubKey (§12.6); derived EVM address MUST equal `runner` (= RunnerRegistration.address)
  subset_epoch:       u64,        // epoch this receipt is bound to (epoch-paired, §5.3)
  validator_set_hash: [u8;32],    // the epoch's snapshot hash
  block_height:       u64,        // validator's observed head when it signed
  nonce_echo:         u64,        // signed entropy/binding only — NOT verified against a challenge on-chain (see below)
  accepting_new:      bool,       // MUST be true to count toward presence (§6.4)
  validator_signed:   [u8;64],    // Ed25519 over the §12.6 PresenceReceipt domain
}

SubmitPresenceCertificate {      // system instruction, runner-submitted
  runner:    Address,
  height:    u64,                // certificate height; receipts must be within RECEIPT_FRESHNESS_BLOCKS of it
  receipts:  Vec<PresenceReceipt>,   // from distinct validators (epoch-paired, see below)
  runner_signed: [u8;65],            // ordinary chain tx signature; MUST recover `runner` over the tx payload
}

A validator presence sidecar (validators signing per-block runner bitmaps included by the proposer) is a non-normative alternative, noted only for completeness. It is more invasive and needs proposer-inclusion rules; runner-submitted certificates need only the live §5.4 snapshot and keep the proposer out of the presence path.

PresenceInput(H) = { runner | presence_proven_until[runner] ≥ H }

1. Before iterating receipts, execution charges PRESENCE_CERT_BASE_CYCLES and decodes the SubmitPresenceCertificate through the ordinary transaction path (the runner transaction signature/nonce is the normal account anti-replay).
2. For every submitted receipt entry, execution charges PRESENCE_RECEIPT_PRECHECK_CYCLES before any receipt-specific signature verification. Malformed encodings, wrong scheme tags/lengths, runner-key mismatch, accepting_new != true, stale/future heights (the freshness rule above), inactive/non-overlap (subset_epoch, validator_set_hash), unknown validator keys, and validators outside Sub_epoch(runner) are rejected using only decoded fields and snapshot state. Duplicate raw validator keys are bucketed here, but a higher-block_height candidate MUST NOT discard lower-height candidates until the higher one’s signature has verified.
3. Only prechecked candidates reach Ed25519 verification. Immediately before each attempt, execution MUST charge PRESENCE_RECEIPT_ED25519_VERIFY_CYCLES whether the signature succeeds or fails, and MUST NOT attempt a verification without enough remaining cycles to pay for it.
4. Distinctness remains keyed by raw tag-stripped peer_pubkey. For each raw validator key, execution considers prechecked candidates in descending block_height order and verifies until it finds the greatest valid signed receipt for that validator, then ignores the rest for that validator. A forged higher-height receipt therefore cannot suppress a lower-height valid one; it only costs the submitter the charged verification attempt.
5. Threshold counting, strictly-newer-anchor checking, and the presence_anchor / presence_proven_until updates use only the retained, signature-valid per-validator receipts.

​

8.4 Security Posture and the k ↔ Security ↔ Fan-out Trade-off

• (B) Present-first, fail-open — NORMATIVE (§7.3). Presence orders and routes; the heartbeat floor governs eligibility. Secure at k ≤ 8 and bounded fan-out: fabrication self-heals (wasted first attempt), suppression cannot make a floor-eligible runner ineligible (suppressed runner stays in the fallback pool), though it can deny work in a proposer’s slot when the present pool can fill the committee (§15.9). Under one validator this is exactly the active-runner gate (§8.1). This is the normative posture in every topology.
• (A) Hard-exclude — DOCUMENTED high-security upgrade. Presence is a strict gate (no presence ⇒ not selectable). To be censorship-resistant it requires honest-majority subsets, i.e. large k (tens to ~100+ depending on target failure probability), raising per-validator connections to ~|R|·k/n. Mode A is additionally guarded by K_HARD_MIN (§13): let effective_k = min(|V|, clamp(ceil(log2(|V|))+1, MIN_SUBSET, MAX_SUBSET)); hard-exclude behavior is effective only when effective_k ≥ K_HARD_MIN (default 20) and t_hard ≥ floor(effective_k/2)+1, so the default MAX_SUBSET = 8 cannot accidentally instantiate the rejected small-k hard-exclude posture (C). A block that applies hard-exclude while the guard is false is invalid. The normative certificate evidence path generates gas-bearing transactions; at |R| ≈ 5,000 the block-space cost is approximately |R| · (t_hard · 188 B + envelope) / PRESENCE_PROOF_TTL_BLOCKS(=60) per block — roughly 172 KB/block at k=20/t_hard=11, and 800 KB/block at k=100/t_hard=51. Mode A is gated by PRESENCE_HARD_EXCLUDE_ENABLED (default false, §13); only a governance vote may enable it, and governance MUST satisfy the K_HARD_MIN guard, size k for the target censorship-resistance, and budget for the on-chain byte volume. While the flag is false (always, at launch), presence cannot remove a floor-eligible runner and the §7.3 fallback-pool guarantee holds unconditionally.
• (C) Hard-exclude at small k — REJECTED. Hard exclusion with k ≤ 8 exposes ~25% of runners to suppression/censorship with no adequate in-protocol mitigation: subset rotation (§5.3) only reshuffles across epochs and cannot fix an adversary-heavy subset within an epoch. Not specified.

​

8.5 Indexing Across Registry Mutations

​

9. Updated Selection Algorithm

• The candidate filter chain: the heartbeat-derived eligibility floor is codified/parameterized (existing filter made normative, §9.1).
• The committee draw is made present-first using PresenceInput (§7.3, applied in §9.2), subject to the §7.3 membership-steering bound (multi-validator runners > 1 jobs draw membership over the full eligible set).
• The base draw weight remains the CIP-2 v3 §2 VRF weight effective_stake · sqrt(reputation); CIP-11 adds only the iteration-0 MRU multiplier on top of that base (§9.3).

​

9.1 Candidate Filter Chain (Eligibility Floor)

Dispatcher filters (existing chain, reproduced for context):
  0.   Exclusion list (re-selection)            — CIP-2 §6 timeout re-selection
  0.5. Probation                                — current dispatcher implementation
  1.   Liveness floor (CODIFIED by CIP-11):  HealthStatus::Healthy
                                   AND (current_block_height − last_heartbeat) ≤ HEARTBEAT_TIMEOUT_BLOCKS
  2.   Reputation ≥ threshold                   — CIP-2
  3.   Capability supports JobType              — CIP-2
  4.   TEE requirement                          — CIP-23: tee_required ⇒ runner advertises TEE support;
                                   required_tee_type=None accepts any TEE, else exact type match (dispatcher.rs)
  5.   Price ≤ max_price                        — CIP-2
  6.   Concurrency: active_jobs < max_concurrent_jobs — CIP-2
  7.   Entitlement (+ attested-entitlement subset)   — CIP-2; attested subset per current dispatcher
  8.   Storage support                          — CIP-9 (storage_support + valid encryption_pubkey)
  9.   Stake ≥ 1.5 × max_price                  — current dispatcher (effective stake incl. active delegation)
  9.5. DNS min-resolver-count                   — CIP-2 v2 DNS checks: dns_verifier_resolvers ≥ max(min_resolvers) (dispatcher.rs)

​

9.2 Selection Algorithm

beacon = R_{S-1}   // parent execution-readable consensus beacon, known before executing block S
seed   = keccak256("cowboy-runner-select-v3:" ‖ 0x00 ‖ canonical_seed_bytes(beacon) ‖ job_id ‖ submitted_at_le8)

• S = submitted_at, the block height that includes JobSubmit;
• r_submit = Round(epoch, view), the absolute consensus round in which block S was proposed;
• T = S, the CIP-2 selection-state snapshot height;
• K = SELECTION_SEED_DELAY_VIEWS;
• r_seed = advance_round(r_submit, K).

1. block S is finalized and applied to canonical local state;
2. the verified commonware threshold seed for exactly r_seed is available to the proposer and committed in the assignment block (consumed-seed commitment below); verifiers and replayers evaluate this condition solely against the committed ConsumedSeedsV1 entry;
3. the candidate snapshot derived from canonical block-S state matches the committed candidates_snapshot_root.

seed = keccak256("cowboy-runner-select-v3:" ‖ mode_u8 ‖ canonical_seed_bytes(R) ‖ job_id ‖ submitted_at_le8)

beacon_hash_v1(R)   = keccak256("cowboy-beacon-v1" ‖ seed_material_v1(R))
seed_material_v1(R) = epoch_be8 ‖ view_be8 ‖ scheme_id_u8 ‖ signature_len_be2 ‖ signature_bytes

leaf_i = keccak256("cowboy-candidates-leaf-v1" ‖ index_be4 ‖ runner_address_20
                   ‖ effective_stake_u128_be ‖ selection_reputation_x1e9_u64_be ‖ base_weight_u128_be)

PendingSelectionV1 {
  version:                  u8 = 1,
  job_id:                   [u8; 32],
  submitted_at:             u64,      // S
  selection_state_height:   u64,      // T = S
  committee_size:           u32,      // M = job_spec.verification.runners
  submission_epoch:         u64,      // r_submit.epoch
  submission_view:          u64,      // r_submit.view
  seed_epoch:               u64,      // r_seed.epoch
  seed_view:                u64,      // r_seed.view
  seed_delay_views:         u64,      // K, a view count
  candidates_snapshot_root: [u8; 32],
}

pending_by_job_key          = keccak256("cip11:pending-selection:v1:job" ‖ job_id)
pending_due_round_index_key = "cip11:pending-selection:v1:due-round" ‖ seed_epoch_be8 ‖ seed_view_be8 ‖ submitted_at_be8 ‖ job_id

T = submitted_at                                          // selection-state snapshot block; fixed at S for first selection
H = assignment block                                      // S for M == 1; the pending-selection pass block for M > 1
eligible = filter_chain(candidates_at(T))                 // §9.1, address-sorted; candidate/reputation filters fixed at T = S
mode_a_effective = PRESENCE_HARD_EXCLUDE_ENABLED          // §8.4 activation guard: the flag alone is NOT sufficient
                   and effective_k ≥ K_HARD_MIN
                   and t_hard ≥ floor(effective_k/2) + 1

if mode_a_effective:                                       // Mode A (§8.3–§8.4): presence is a HARD gate
    // Flag set but guard false ⇒ Mode A INACTIVE: selection falls through to the Mode-B branches
    // below (§7.2 rule 3); a block that hard-excludes a floor-eligible runner below the guard is
    // invalid (§8.4).
    // PresenceInput(H) = { runner | presence_proven_until[runner] ≥ H } (§8.3) — consensus-verified,
    // NOT proposer-set, so the §15.9 steering bound does not apply and hard-exclude is safe for all M.
    present, fallback = (eligible ∩ PresenceInput(H)), []  // non-present runners are NOT selectable
elif multi_validator and job.verification.runners > 1:     // Mode B independence-verification jobs
    // Membership-steering bound (§7.3, §15.9): presence does NOT determine membership.
    // For these jobs H is the pending pass block and seed uses r_seed; membership over the FULL block-S eligible set.
    present, fallback = eligible, []                       // draw membership by VRF over the FULL eligible set
else:                                                      // Mode B present-first membership: M == 1 in any topology, or single-validator M > 1
    // Timing/seed set by M above: M == 1 ⇒ H = S, R_{S-1}; M > 1 ⇒ pending pass, seed for absolute r_seed.
    present, fallback = partition(eligible, PresenceInput(H)) // present-first, fail-open (non-present stays drawable)
selected = []
for i in 0..M:                                            // single global counter i
    pool = present if present is non-empty else fallback   // PRESENT-FIRST: fallback only once present is exhausted
    if pool is empty: break                               // |eligible| < M — see below
    weights = [ cip2_v3_weight(effective_stake(r, T), selection_reputation_x1e9(r, T), ReputationConfig_at(T))
                for r in pool ]                           // CIP-2 v3 §2 base weight at T = S; paired with its runners
    if i == 0 and mru in pool:                            // §9.3 — once, only at global i == 0
        weights[index_of(mru, pool)] = weights[index_of(mru, pool)].saturating_mul(MRU_WEIGHT_MULTIPLIER)
    idx = weighted_draw(pool, weights, seed, i)           // normative draw, defined below (fixed seed; swap_remove)
    selected.append(pool[idx]); remove pool[idx] from its pool        // drawn runner leaves its pool (swap_remove)

1. pool.len() == weights.len() MUST hold; each weight is paired with the runner at the same index.
2. total_weight = sum(weights) as u128.
3. If pool is empty or total_weight == 0, the draw returns None; the loop stops and any shortfall falls to the CIP-2 under-fill / timeout re-selection path (§11.2).
4. h = keccak256(seed ‖ i_le8), where i_le8 is the unsigned 64-bit little-endian global draw iteration.
5. ticket = u128(u64::from_le_bytes(h[0..8])) % total_weight.
6. Walk weights in current pool order; select the first index j with ticket < weights[j], subtracting each non-selected weight from ticket as you pass it.
7. Return the index j (or None per step 3). The caller (the draw loop above) appends pool[j] to selected and removes the runner together with its paired weight via swap_remove(j); the residual pool order after the first draw is therefore not address-sorted and MUST be replayed exactly.

​

9.3 MRU Weight Multiplier

base_weight(r, T) =
  cip2_v3_weight(
    effective_stake(r, T),
    selection_reputation_x1e9(r, T),
    ReputationConfig_at(T)
  )

• effective_stake(r, T) = r.registration.stake_at(T) + r.delegation_totals.total_active_at(T) (CIP-13 v2 §3.2). Until delegation is live, delegation_totals.total_active = 0, so effective_stake(r, T) = r.registration.stake_at(T).
• selection_reputation_x1e9(r, T) is the same reputation value used by the CIP-2 v3 candidate reputation filter for this selection at block T: the lazy-decayed EMA reputation read from RunnerRegistration.reputation under the active ReputationConfig_at(T) (CIP-2 v3 §3). Implementations MUST NOT use one reputation snapshot for filtering and another for weighting.
• cip2_v3_weight is the CIP-2 v3 §2 formula effective_stake · max(sqrt(reputation / REPUTATION_NORMALIZER), w_min_floor).

scaled            = (selection_reputation_x1e9 * 1_000_000^2) / (REPUTATION_NORMALIZER * 1_000_000_000)
sqrt_factor_x1e6  = isqrt(scaled)
factor_x1e6       = max(sqrt_factor_x1e6, 100_000)   // CIP-2 v3 w_min_floor = 0.1
base_weight       = (effective_stake * factor_x1e6) / 1_000_000

mru = lookup_mru(submitter, job_kind, current_block_height)               // §9.4
for each r in pool being drawn:
    base[r] = base_weight(r, T)                                          // base weight at the selection-state snapshot T = S
    if i == 0
       and mru == Some((addr, set_at))
       and r.address == addr
       and (current_block_height - set_at) ≤ MRU_TTL_BLOCKS:
        weight[r] = base[r].saturating_mul(MRU_WEIGHT_MULTIPLIER)
    else:
        weight[r] = base[r]

Implementation note. Current select_runner_committee_with_seed already uses the CIP-2 v3 helper v3_runner_weight(stake, reputation_x1e9, reputation_normalizer, w_min_floor_x1e6) and deterministic u128::isqrt. The CIP-11 implementation diff is to pass effective_stake(r, T) instead of raw registration.stake once CIP-13 delegation is live, preserve the same reputation snapshot used by Filter 2, and apply the iteration-0 MRU multiplier. This changes neither the CIP-2 v3 weight owner nor the §9.2 weighted_draw semantics (which pin the live draw).

​

9.4 New Dispatcher State: mru_key

mru_key(submitter: Address, job_kind: u8) → MruRecord { runner_address: Address, set_at_block: u64 }

CIP-2 reconciliation (follow-up, CIP-2-owned). CIP-2 currently enumerates only Llm/Http/Mcp/Custom; PublishChainRoot and Agent exist in code but not yet in CIP-2 (CIP-2 is stale here, and an EthSend once discussed never landed). The table above reflects the deployed node enum and is authoritative for job_kind in CIP-11. A separate CIP-2 cleanup SHOULD reconcile the canonical JobType set and its governance so the two specs do not drift; this is not a CIP-11 implementation prerequisite.

​

9.5 MRU Scope (Future Refinement)

​

10. Push Job Delivery

​

10.1 Dispatch

JobAssignment {
  job_id: [u8; 32], job_spec: JobSpec, job_spec_hash: [u8; 32],   // keccak256(canonical_job_spec)
  assignment_height: u64, assignment_hash: [u8; 32],              // §12.6 preimage
  deadline_block: u64, runner_pubkey: PubKey, validator_pubkey: PubKey,   // wire PubKeys (§12.6): runner secp256k1; validator Ed25519 (decodes to snapshot peer_pubkey)
  validator_signed: [u8; 64],                                     // Ed25519 over §12.6 preimage
}

​

10.2 Runner Acknowledgment

JobAck {
  job_id:          [u8; 32],
  assignment_hash: [u8; 32],          // echoes the JobAssignment being acked (binds the ack to it)
  status:          AckStatus,
  reason:          Option<String>,
  signed:          [u8; 65],          // secp256k1 over §12.6 JobAck preimage
}
enum AckStatus { Accepted, Duplicate, Reject(RejectReason) }
enum RejectReason { AtCapacity, MissingEntitlement, MissingCapability, UnverifiableAssignment, Other }

​

10.3 Result Commit and Reveal

JobResultCommit { job_id: [u8; 32], tx_bytes: Vec<u8> }
JobResult       { job_id: [u8; 32], tx_bytes: Vec<u8> }

​

10.4 Streaming Progress (Optional)

JobProgress { job_id, fraction: u8 (0–100), detail: Option<String> }

​

10.5 Cancellation

JobCancel {
  job_id:          [u8; 32],
  assignment_hash: [u8; 32],          // identifies the assignment being cancelled
  reason:          CancelReason,       // Reassigned | Expired | Failed
  validator_signed: [u8; 64],         // Ed25519 over §12.6 JobCancel preimage
}
enum CancelReason { Reassigned, Expired, Failed }

​

10.6 Dispatch Outcome Classification

​

11. Failure Handling and Re-selection

​

11.1 Per-Dispatch Timeout

​

11.2 Per-Job Timeout

​

11.3 Connection Loss

​

11.4 Reputation and Slashing

​

11.5 In-Flight Jobs Across an Epoch Boundary

• Settlement is epoch-independent. SystemInstruction::JobResultCommit and SystemInstruction::JobResultSubmit are ordinary runner-signed mempool transactions (§10.3), distinct from the QUIC JobResultCommit / JobResult frames that carry their tx_bytes. They settle regardless of which validator subset is active; an epoch change never invalidates an in-flight job’s settlement path.
• Delivery survives the boundary. During the OVERLAP_BLOCKS window the runner still holds its Sub_E(R) connections (§5.3), so the dispatching epoch-E validator can continue to receive result frames on the Accepted stream. If that stream drops, the runner MUST use the §10.3 transaction-admission/rebroadcast path for the retained SystemInstruction::JobResultCommit / JobResultSubmit transaction via any epoch-E+1 validator it is now connected to, or via the REST fallback (§14) — the result is a transaction, not bound to the original stream.
• Cancellation. JobCancel for such a job MAY be sent by a validator in either subset during overlap; after the window, only epoch-E+1 validators (or the chain’s timeout re-selection, §11.2) drive cancellation/re-selection.

​

12. Wire Format

​

12.1 Frame Encoding

Frame {
  length:  u32 (big-endian),
  type:    u8,
  payload: bytes,
}

​

12.2 Frame Type Table

CIP-11 adds no inter-validator consensus vote field. All runner↔validator framing is over QUIC. The normative path carries presence as a committed PresenceInput block field (§7.2); the only inter-validator messaging it may add is the off-chain presence aggregation gossip (§8.2) used by a multi-validator Mode-B proposer (advisory, never consensus). The optional observability gossip (§7.5) is separate and non-normative. Mode-A presence evidence (§8.3) is a runner-submitted SubmitPresenceCertificate system-instruction transaction (or, non-normatively, a block sidecar). None of these is a consensus vote extension.

​

12.3 Versioning

​

12.4 (Reserved)

​

12.5 Goodbye

Goodbye {
  reason: GoodbyeReason, detail: Option<String>, retry_after_blocks: Option<u64>, signed: Option<Sig>,   // role-scheme sig (§12.6): sender Runner→secp256k1 65B, Validator→Ed25519 64B
}
enum GoodbyeReason { UnsupportedVersion, WrongChain, AuthFailed, NotInSubset, OverlapExpired, RateLimited, ProtocolError, Draining, Shutdown }

​

12.6 Signature Domains

Role:          Runner=0x01  Validator=0x02
AckStatus:     Accepted=0x00  Duplicate=0x01  Reject=0x02
RejectReason:  AtCapacity=0x00  MissingEntitlement=0x01  MissingCapability=0x02
               UnverifiableAssignment=0x03  Other=0x04          (0xFF = reserved "not-applicable")
CancelReason:  Reassigned=0x00  Expired=0x01  Failed=0x02
GoodbyeReason: UnsupportedVersion=0x00  WrongChain=0x01  AuthFailed=0x02  NotInSubset=0x03
               OverlapExpired=0x04  RateLimited=0x05  ProtocolError=0x06  Draining=0x07  Shutdown=0x08

• signer_role / any Role: 1 byte (Runner = 0x01, Validator = 0x02).
• accepting_new (bool, in HeartbeatPong/PresenceReceipt): 1 byte (false = 0x00, true = 0x01).
• retry_after_blocks_or_zero (Option<u64> in Goodbye): 8 bytes big-endian; None collapses to 0 (0x0000000000000000) — the deliberate None ≡ Some(0) collapse.
• canonical_reason_or_empty / detail_or_empty (Option<String>): the §12.6 “CIP-11 deterministic CBOR profile” text-string encoding; None first collapses to the zero-length text string "", then encodes — so None/empty hashes the deterministic-CBOR empty text value (0x60), not raw zero bytes and not a CIP-2 encoding.

connection_id = keccak256("cowboy-cip11-connection-v1" ‖ chain_id ‖ version ‖
                          runner_pubkey ‖ validator_pubkey ‖ validator_set_hash ‖ subset_epoch ‖ channel_binding)

HelloAck:        "cowboy-cip11-hello-ack-v1" ‖ chain_id ‖ version ‖ sender_role ‖ sender_pubkey ‖
                 recipient_role ‖ recipient_pubkey ‖ validator_set_hash ‖ subset_epoch ‖ peer_challenge_nonce ‖ channel_binding
HeartbeatPing:   "cowboy-cip11-heartbeat-ping-v1" ‖ connection_id ‖ runner_pubkey ‖ validator_pubkey ‖ block_height ‖ nonce
HeartbeatPong:   "cowboy-cip11-heartbeat-pong-v1" ‖ connection_id ‖ validator_pubkey ‖ runner_pubkey ‖ block_height ‖ nonce_echo ‖ accepting_new

PresenceReceipt (Mode A; on-chain verifiable, NO channel_binding):
                 "cowboy-cip11-presence-receipt-v1" ‖ chain_id ‖ validator_pubkey ‖ runner_pubkey ‖
                 subset_epoch ‖ validator_set_hash ‖ block_height ‖ nonce_echo ‖ accepting_new
Backpressure/CapabilityDelta:
                 "cowboy-cip11-control-v1" ‖ connection_id ‖ runner_pubkey ‖ validator_pubkey ‖ frame_type ‖ block_height ‖ keccak256(canonical_frame_body)
                 // frame_type is the §12.2 frame-type byte (0x12 BackpressureSignal, 0x13 CapabilityDelta) — load-bearing:
                 // it is the only field separating the two frames' preimages in the shared control-v1 domain.
JobAssignment:   "cowboy-cip11-job-assignment-v1" ‖ chain_id ‖ job_id ‖ keccak256(canonical_job_spec) ‖
                 assignment_height ‖ deadline_block ‖ runner_pubkey ‖ validator_pubkey
JobAck:          "cowboy-cip11-job-ack-v1" ‖ connection_id ‖ job_id ‖ assignment_hash ‖ runner_pubkey ‖ validator_pubkey ‖
                 ack_status_byte ‖ reject_reason_byte ‖ keccak256(canonical_reason_or_empty)
                 // ack_status_byte: AckStatus byte. reject_reason_byte: the RejectReason byte when status == Reject(r),
                 // else 0xFF (not-applicable). The free-text reason string is covered by keccak256(canonical_reason_or_empty).
JobCancel:       "cowboy-cip11-job-cancel-v1" ‖ connection_id ‖ job_id ‖ assignment_hash ‖ validator_pubkey ‖ runner_pubkey ‖ cancel_reason_byte
Goodbye:         "cowboy-cip11-goodbye-v1" ‖ connection_id ‖ sender_pubkey ‖ recipient_pubkey ‖ goodbye_reason_byte ‖ retry_after_blocks_or_zero ‖ keccak256(detail_or_empty)

​

13. System Constants

Removed in r1.3: presence_threshold(|Votes(H)|) (global-quorum threshold from the infeasible vote design) and STALE_HEARTBEAT_BLOCKS (subsumed by HEARTBEAT_TIMEOUT_BLOCKS).

​

14. Migration and Coexistence

​

Phase 1 — Additive Transport (CIP11_TRANSPORT_ENABLED)

• QUIC transport ships; runners connect and authenticate; the validator pushes JobAssignment to runners in local presence.
• GET /runner/{addr}/jobs remains the primary path; push is best-effort alongside it.
• With CIP11_PRESENCE_SHADOW_ENABLED, proposers SHOULD populate PresenceInput and the present-first draw is computed on a side path for telemetry only; live selection uses an empty present pool and behavior is otherwise unchanged. While CIP11_PRESENT_FIRST_ENABLED is false, the field MAY be absent or malformed without invalidating the block, and execution MUST treat the present set as empty outside shadow metrics (§7.2).

​

Phase 2 — Hot Path (CIP11_PRESENT_FIRST_ENABLED)

• Push is the primary delivery path; poll is delivery-only fallback.
• Present-first/fail-open selection (§7.3) is enforced using a committed PresenceInput. In active Mode B this is now a required, well-formed block field (§7.2); in active Mode A the proposer field is ignored and PresenceInput is derived from parent-state certificates (§8.3). The eligibility floor (§9.1) remains the normative, tuned HEARTBEAT_TIMEOUT_BLOCKS check.
• Goal: shift the job-start floor from poll_interval to block-inclusion + application + one RTT (≈1–2 s; §10.1), routing to active runners.

​

Phase 3 — Sunset & (later) Multi-Validator / Mode A (CIP11_POLL_DISABLED, PRESENCE_HARD_EXCLUDE_ENABLED)

• With CIP11_POLL_DISABLED, the poll endpoint returns 410 Gone.
• Governance MAY widen HEARTBEAT_TIMEOUT_BLOCKS/heartbeat cadence to reclaim bandwidth (push/ack now provides fast liveness).
• Static multi-validator at genesis: needs no new consensus primitive — multi-validator Mode B uses the same committed, proposer-supplied presence (off-chain-gossip-aggregated, §8.2) over the fixed genesis validator set.
• Changing the validator set over time (E → E+1): gated on the §5.4 reconfiguration primitive (a consensus Requires dependency); CIP-11’s reaction — subset rotation + the OVERLAP_BLOCKS window (§5.3) — is automatic once snapshots advance past epoch 0. Only if governance wants censorship-resistant hard-exclude does it additionally enable Mode A (§8.3). The dispatcher read-point is unchanged in all cases.

​

15. Security Considerations

​

15.1 Sybil Connection Storms

​

15.2 Presence Integrity, Censorship, and Mode Dependence

• Eligibility floor resilience. Selection eligibility is the runner’s own on-chain heartbeat (§7.1) — canonical chain state no validator can forge or directly write. Floor freshness depends on heartbeat-transaction inclusion, so the launch sole validator or an inclusion-controlling majority can floor-exclude a runner by censoring it for HEARTBEAT_TIMEOUT_BLOCKS (=100); but under mandatory proposer rotation no BFT minority can sustain 100 consecutive censoring proposers (probability ≈ γ¹⁰⁰). Presence can only order/route within eligible runners (§7.3), so no validator or coalition can make an eligible runner ineligible in the default mode. A proposer can still deny a specific runner work via suppression when the present pool can fill the committee, but this slot-steering is bounded by proposer rotation and removed for runners>1 by §15.9. This is a deliberate improvement over the r1.2 hard-presence design, whose P0 findings were exactly suppression/fabrication of the presence bit.
• Single validator (f = 0) — explicit trust assumption. With one validator there is no Byzantine validator, so PresenceInput is trustworthy by construction (§8.1). But that lone validator also controls selection, delivery, MRU, and presence: it is fully trusted at launch, and a malicious operator could favor its own runners or extract MEV. This is acceptable only because the operator is the network operator at launch and f = 0; it is not a Byzantine-robust property. Multi-validator (Mode B) removes this single point of trust; an operator running its own runner SHOULD be subject to the governance conflict-of-interest expectations noted in §16. The only mechanical residual is a runner that disconnects between the proposer’s snapshot and dispatch — caught by ACK_TIMEOUT_BLOCKS and fallback.
• Multi-validator default (B). Fabrication (mark offline-present) self-heals via push timeout; suppression (mark online-absent) only de-prioritizes (the runner stays in the fallback pool). Secure at bounded k.
• Multi-validator hard-exclude (A). If governance enables A, suppression can censor, so A is sound only with honest-majority subsets (large k, §8.4); this is the documented cost of the strict semantics.

​

15.3 Delivery Griefing

​

15.4 MEV / MRU Front-Running

​

15.5 Connection Hijack and MITM

​

15.6 Plaintext Wire (Closed)

​

15.7 Presence-Evidence Authenticity (Multi-Validator)

​

15.8 PresenceInput and Reorgs

​

15.9 Proposer Present-Set Steering and Submitter Grinding (Mode B)

• M == 1: select immediately in submission block S using parent beacon R_{S-1}. This preserves latency for None / EconomicBond jobs.
• M > 1: bind the job in block S and select from the seed of an absolute future round r_seed = advance_round(r_submit, K), where r_submit is the round in which S was proposed and K = SELECTION_SEED_DELAY_VIEWS.

• Single validator (launch): vacuous under the protocol threat model — f = 0, the lone proposer is the trusted operator (§15.2). The operator can still favor its own runners operationally; that is governance/operations trust, not Byzantine robustness.
• M == 1 (None/EconomicBond): present-first can steer which eligible runner serves a given job, and the submitter may know R_{S-1} before submitting. A submitter can also grind mutable job bytes / job_id against the known parent beacon to target a specific eligible runner; the clearest abuse is fairness/availability griefing (e.g. aiming paid one-runner jobs at a victim to occupy its max_concurrent_jobs), but each attempt is an ordinary paid job, the selected runner stays economically accountable (bond/slashing), and timeout/reputation rules still apply. An MRU-wash variant does not create cross-submitter steering because MRU is keyed by (submitter, job_kind): repeatedly completing colluder-submitted jobs only biases that same submitter’s future iteration-0 draw. The residual is MEV/fairness, bounded by per-job market cost and the bond: proposer rotation bounds how often a given proposer can exercise present-first steering but does not undo the harm inside its own slot — single-block proposer MEV, which the whitepaper §“MEV Reduction” explicitly does not defend against. (The whitepaper’s §6.5-style out-of-scope list covers transaction inclusion/ordering, not committee-input steering, which is a new CIP-11 surface, so it does not pre-exempt this.) Submitters that need selection neutrality SHOULD request M > 1 verification or operate under effective Mode A (§8.3), where the proposer does not control PresenceInput; M == 1 remains a latency-optimized path with bounded MEV/fairness residuals, not a committee-independence path.
• M > 1 in Mode B: committee membership is over the full floor-eligible set and selected from the absolute future seed round r_seed; proposer present-set steering, submitter pre-grinding, and certifying-leader re-roll are all removed from the committee-membership path (the only residual is the generic, non-attributable chain-wide last-revealer above). Presence is delivery-only.
• Mode A: PresenceInput is consensus-verified and not proposer-set, so present-set steering does not arise; seed timing still follows §9.2.

​

16. Dependencies, Governance, and Optional Extensions

1. Consensus/execution dependencies. CIP-11 consumes (a) execution-readable consensus beacons/seeds for runner-selection seeding (§9.2) — parent beacon R_{S-1} for immediate M == 1 selection, and verified threshold seeds by absolute round (notarization, finalization, and nullification certificates) plus a consensus-owned advance_round API for commit-then-reveal M > 1 selection — and (b) an execution-readable validator-identity snapshot ValidatorSetSnapshot(epoch) (§5.4). For a fixed genesis set, the snapshot is ValidatorSetSnapshot(0) and does not require epoch advancement or resharing; for dynamic validator-set changes (E → E+1), the consensus integration must additionally expose epoch advancement plus BLS threshold resharing/DKG and emit ValidatorSetActivated. Consensus, epochs, beacons, and the validator-set lifecycle are owned by the technical whitepaper (§“Consensus and Networking”, §“Validator Set”) and the commonware engine — not by any CIP (there is no consensus CIP); commonware has the underlying consensus/VRF/resharing primitives, but Cowboy must wire these interfaces into execution (a known mainnet-readiness item — including exposing the parent beacon, verified seeds by absolute round including nullification-certificate seeds, the proposal round of each block, finality information, and a consensus-owned advance_round, all of which the §9.2 selection path consumes). Consumed M > 1 seeds are additionally committed in the assignment block (ConsumedSeedsV1, §9.2), so block verification and historical replay depend only on chain data — live certificate exposure is needed only by the proposer at assignment time. This is a prerequisite, not unfinished CIP-11 behavior; CIP-11’s connectivity reaction is specified here.
2. Mode A enablement (governance + pre-activation tests). Mode A (§8.3–§8.4) is fully specified and gated by PRESENCE_HARD_EXCLUDE_ENABLED; enabling it requires the §5.4 validator-identity snapshot and Mode-A certificate state/instructions. In a static genesis validator set this can use ValidatorSetSnapshot(0) and does not require dynamic reconfiguration; once the set changes, the dynamic reconfiguration dependency in item 1 applies. Before enabling it, governance fixes the k ↔ security ↔ fan-out operating point (§8.4), satisfies the K_HARD_MIN activation guard (§8.4/§13), and confirms the receipt anti-replay and freshness parameters (§8.3, §13). An implementation MUST ship cross-epoch replay property tests first: a stale receipt cannot extend presence_proven_until; the signed receipt preimage binds subset_epoch + validator_set_hash; the monotonic presence_anchor rejects an older-or-equal anchor; and a receipt whose (subset_epoch, validator_set_hash) does not match the active/overlap snapshot is rejected (the OVERLAP-window boundary, §5.3, is the most error-prone case).
3. Validator–runner conflict of interest (governance). Because the launch validator is fully trusted (§15.2), governance SHOULD set expectations (disclosure, auditable push-latency, or a neutral push router) before any operator runs both a validator and runners, to deter self-favoring/MEV. Relevant as the validator set decentralizes.
4. MRU scope (optional extension). The coarse (submitter, job_kind) default (§9.4) is complete; a future revision MAY add a finer mru_scope (e.g. (submitter, model_id), (submitter, primary_volume_id)) per §9.5. An enhancement, not a correctness gap.
5. Observability gossip (optional, non-normative). §7.5’s advisory dashboard channel MAY be standardized for cross-implementation agreement, or left to implementations.

​

17. Reference Implementation Notes

• node/types/src/execution.rs (+ block body/metadata) — add the PresenceInput and ConsumedSeedsV1 (§9.2) block fields and the deterministic execution read-points consumed by the dispatcher. Because both are load-bearing, each MUST be committed in the execution identity (execution_hash) and block digest — not the existing excluded extra_data path (which is omitted from both digest() and execution_hash() and would let propose/verify cache or replay a different selection than committed).
• node/execution/src/runner/dispatcher.rs — codify the §9.1 eligibility floor against HEARTBEAT_TIMEOUT_BLOCKS; implement the §9.2 seed model (M == 1: immediate R_{S-1}; M > 1: pending-selection record in S, selected via commit-then-reveal from the absolute future seed round r_seed, using the iterable due-round index) and the present-first/fail-open draw over PresenceInput, including the §7.3 membership-steering bound (multi-validator M > 1 ⇒ draw membership over the full floor-eligible set, presence for routing only); add lookup_mru() + iteration-0 multiplier; store committee order for deterministic MRU (§9.4). Thread the decoded PresenceInput as an immutable per-block PresenceView (decoded once at block start against the parent-state registry) through the execution call chain (TransactionExecutor / execute_system_instruction) into handle_job_submit and the pending-selection pass. Fix the existing weight/index pairing so weights attach to runners after present/fallback ordering (§9.2, point e).
• node/execution/src/runner/verifier.rs — write the deterministic consensus-matching mru_key on verified result (§9.4). Note: the current select_aggregator helper (in aggregator.rs, called from verifier.rs) is order-independent and cannot implement the MRU winner rule — add a separate calculation over the stored selected-committee order and the verified matching set.
• node/runner/src/storage_keys.rs — add the mru_key family.
• node/runner/src/types.rs — QUIC wire-frame types (§12) and MruRecord.
• node/types/src/constants.rs — reuse the existing HEARTBEAT_TIMEOUT_BLOCKS for the floor; add ACK_TIMEOUT_BLOCKS, PRESENCE_TIMEOUT_BLOCKS, and the MRU constants. CIP-11’s only reconfiguration-related constant is the transport-side OVERLAP_BLOCKS, which becomes live once §5.4 snapshots advance past epoch 0. Snapshot-emission cadence and churn thresholds are consensus-owned (whitepaper / commonware), not CIP-11 constants.
• Wire enum byte tables (§12.6). When the AckStatus / RejectReason / CancelReason / GoodbyeReason control enums are implemented in node/runner, pin each §12.6 discriminant-byte table with a test against both the node and runner definitions (the same dual-enum pin pattern §9.4 uses for job_kind), so source-order divergence cannot silently change a signed byte.
• Selection seed (§9.2). Expose consensus seeds to execution (e.g. a BlockExecutionContext carrying parent_beacon, the current block’s proposal Round(epoch, view), verified threshold seeds by absolute round including nullification-certificate seeds, finality information, and a consensus-owned advance_round, alongside block_height/block_hash/timestamp_ms, identical on propose/verify/finalized-fallback). Replace the dispatcher’s height-only block_hash_proxy seed with cowboy-runner-select-v3: derivation: M == 1 uses R_{S-1} in block S; M > 1 persists a pending record in S (committing r_submit/r_seed) and assigns from the absolute r_seed seed once S is finalized and the snapshot root verifies, committing the consumed seed bytes in the assignment block’s ConsumedSeedsV1 field — covered by execution_hash and the block digest, the same commitment rule as PresenceInput (§9.2). This is node consensus→execution plumbing plus dispatcher scheduling; not a commonware protocol change.
• Single-validator source — the proposer populates PresenceInput from local presence (§8.1); no validator registry needed.
• Multi-validator Mode B (normative): no new on-chain machinery — the proposer aggregates off-chain validator presence gossip into the committed PresenceInput (same field/read-point as §8.1). Only the off-chain gossip transport is added.
• Mode A (opt-in hard-exclude, §8.3) — only if governance enables it: consume the live §5.4 ValidatorSetSnapshot for validator identities (no separate registry to build); add SystemInstruction::SubmitPresenceCertificate (verify PresenceReceipts against the snapshot; set presence_proven_until); derive PresenceInput(H) = { runner | presence_proven_until[runner] ≥ H } from parent state at block start — feeding the same dispatcher read-point. No change to the consensus vote message or finalization certificate.
• Reconfiguration reaction (§5.3–§5.4) — once consensus provides ValidatorSetSnapshot / ValidatorSetActivated: recompute Sub(R) + validator_set_hash on each subset_epoch change; in the runner/validator transport, maintain the Sub_E ∪ Sub_{E+1} connection union and dual-validator_set_hash admission for OVERLAP_BLOCKS, then close stale connections with Goodbye { OverlapExpired }; drain in-flight jobs per §11.5. CIP-11 does not implement the snapshot or BLS resharing — that is the Requires consensus dependency (§5.4).
• node/rpc/src/handlers/runner.rs — gate GET /runner/{addr}/jobs behind the Phase-3 flag; keep commit/reveal REST endpoints as the canonical tx-construction path the QUIC frames feed.
• runner/crates/runner-node/src/node.rs — QUIC client; replace polling with JobAssignment consumption (poll retained as fallback through Phase 2); maintain both QUIC and on-chain heartbeats; (Mode A only) assemble/submit presence certificates.
• runner/crates/chain-client/src/client.rs — keep REST result/commit fallback; add the stream-based commit/reveal path.
• A reference QUIC client/server lives in a new crate node/runner-transport, consumed by both validator and standalone runner.
• Verify-before-relying (non-normative checklist; the normative MUST is in §6.2): confirm the §6.2 TLS-Exporter property in the selected QUIC/TLS stack (quinn/rustls, RFC 8446 §7.5 exporters) — connection-specific, stable only within the authenticated session, unavailable to a TLS-terminating proxy — before enabling CIP-11 transport.

Launch scope = §8.1–§8.2 Mode B (single validator): PresenceInput block field + present-first dispatcher + QUIC push + MRU. Multi-validator Mode B additionally consumes the §5.4 identity snapshot but no certificate machinery. The Mode-A presence-certificate machinery (§8.3) and the consensus reconfiguration dependency (§5.4) are not needed to ship single-validator.