​

CIP-2: Verifiable Asynchronous Off-chain Computation Framework

​

Abstract

​

Motivation

1. Integrate Complex Logic: Run Python-based AI model inferences or heavy computations off-chain.
2. Preserve On-chain Stability: Utilize an asynchronous, deferred transaction model to prevent network congestion from off-chain interactions.
3. Achieve Verifiable Decentralization: Leverage a stake-weighted VRF-based system to eliminate centralized schedulers and allow anyone to verify task assignments.
4. Enforce Clarity: Mandate task and result schemas to reduce ambiguity and ensure Runners can reliably execute and be verified.
5. Choose Their Trust Model: Allow developers to select the number of Runners, the verification mode, and optional Runner pool constraints for their specific application’s security needs.

​

Specification

Normative conventions. The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119.

Address gap note: 0x0006 is allocated to DUAL_BASEFEE (CIP-3). The post-2026-04 address space extends through 0x13 and includes a virtual entry at 0x1D; the canonical assignments live in node/runner/src/system_actors.rs and the per-CIP specifications that introduce each address.

​

1. Task Definition and Result Schema

• max_return_bytes: Maximum result size to prevent gas-bombing attacks.
• expected_execution_ms: Target execution time to help Runners assess feasibility.
• data_format: Expected data structure (e.g., JSON schema, binary format).

​

2. Job Specification

​

3. Core Workflow (Asynchronous & Deferred)

Actor calls submit_job(job_spec)
    │  → Job Dispatcher (0x0000...0002)
    │
    ▼
1. Validate JobSpec (resource bounds within the §3.1 caps; verification.runners ≥ 1; threshold ∈ 1..=runners; max_price ≥ 0)
2. Record submission_block S → fixes the candidate snapshot (T = S)
3. Build candidate list (see §4)
4. M == 1: derive the selection seed from the parent beacon (see §5),
           run weighted VRF selection in block S → assign 1 runner,
           store job → JobStatus::Assigned
   M > 1:  bind the job — no assignment in block S; selection runs at the
           pending-selection pass once the verified threshold seed for the
           absolute round r_seed = advance_round(r_submit, K) is committed
           (CIP-11 §9.2) → assign M runners, store job → JobStatus::Pending

Runner polls get_assigned_jobs(runner_addr)
    │
    ├── Execute → submit commitment → Aggregator collects → submit_result
    └── Do not execute → job times out → automatic re-selection (see §6)

Result Verifier (0x0000...0003)
    └── Verify commitments → produce VerifiedResult → deferred callback to Actor

3.1 JobSpec Validation Caps (normative)

• verification.runners (≤ 64) bounds the request, not the committee that runs. The dispatcher computes the effective committee size adaptively and clips it to M_max (§5.1). A submitter may name up to 64 runners, but adaptive sizing governs how many are actually selected.
• bounds.max_retries (per-job execution retries, ≤ 10) is distinct from MAX_RETRIES (default 3) in §6.3 (Timeout-based re-selection), which counts runner-selection retry rounds before a job is marked Failed. They are unrelated knobs.

​

4. Runner Registry & Candidate List Construction

1. Health filter: HealthStatus::Healthy (heartbeat received within heartbeat_timeout_blocks)
2. Reputation filter: reputation ≥ 50 (against the EMA-updated reputation defined in §6.1)
3. Capability filter: Runner supports the required JobType
4. TEE filter: If tee_required, runner must declare TEE support (attestation verified by TEE Verifier 0x05)
5. Price filter: Estimated cost ≤ job_spec.max_price
6. Concurrency filter: active_jobs < max_concurrent_jobs
7. Entitlement filter (optional): If required_runner_pool = Some(pool_id), the Entitlement Registry (0x07) must confirm that the runner holds an Entitlement with Scope::RunnerPool(pool_id) and Action::RunnerJoinPool(pool_id) that has not expired and has not exceeded its max_uses (see §7.3)

​

5. Verifiable Runner Selection (Fisher-Yates VRF)

5.1 Adaptive committee sizing

M_target(N_active, HHI) = ceil(2 · log₂(N_active) / max(HHI, HHI_min))
M       = clip(M_target, M_min, M_max)
N_threshold = ceil(2 · M / 3)

shares       = effective_stake[i] / Σ effective_stake[i]    over registered + healthy runners
HHI_instant  = Σ shares[i]²                                  ∈ (0, 1]
HHI          = HHI_smoothing_alpha · HHI_instant + (1 − HHI_smoothing_alpha) · HHI_prior_epoch

5.2 VRF Seed (deterministic, no private key required)

• M == 1: selection is immediate in submission block S (no added latency), using the parent beacon R_{S-1} (notation below), known before executing S. Immediate mode trades proposer-inclusion neutrality for zero added latency (see Security Considerations).
• M > 1: commit-then-reveal. JobSubmit binds the job in block S; the committee is selected later from the verified seed of the absolute future round r_seed = advance_round(r_submit, K), where r_submit = Round(epoch, view) is the round in which block S was proposed and K = SELECTION_SEED_DELAY_VIEWS (value set in CIP-11 §13). commonware produces exactly one valid seed per absolute round — whether the round notarizes, finalizes, or nullifies — so a withholding leader can delay the reveal but cannot re-roll r_seed.

seed = Keccak256(
    "cowboy-runner-select-v3:"   // domain separator (prevents cross-context collisions)
    || mode_u8                   // 0x00 immediate (M == 1) / 0x01 delayed (M > 1)
    || canonical_seed_bytes(R)   // := beacon_hash_v1(R), 32-byte Keccak-256 of the verified threshold Seed (CIP-11 §9.2)
    || job_id                    // unique per job
    || submitted_at_le8          // 8-byte LE submission block height
)

Implementation note: Use cowboy_types::keccak256, which is the project-standard hash primitive (consistent with job ID generation, timer ID generation, token ID generation, etc.). The pvm_host::randomness() API uses HKDF-SHA256 specifically because it is a security-critical PRF exposed to Actor code; the runner selection seed has no such requirement.

5.3 Stake × √reputation weighted Fisher-Yates shuffle (select M from N)

w_i = effective_stake[i] · max(sqrt(reputation[i] / REPUTATION_NORMALIZER), w_min_floor)

• r^0 (stake-only) gives no reputation signal — vulnerable to pure stake-monopoly.
• r^1 rewards established runners too aggressively — locks out new entrants the way the old aggregator rule did.
• r^0.5 (= sqrt(r)) is the geometric-mean middle ground; a 4× reputation differential becomes a 2× selection-probability differential. Matches the heuristic Polkadot uses in NPoS phragmen and the staking-as-collateral literature.

candidates ← sorted filtered list (length N)
weights[i] ← stake · sqrt(reputation / REPUTATION_NORMALIZER) per the formula above

current_seed ← seed
for i in 0..M:
    total_remaining ← sum(weights[i..N])
    hash ← Keccak256(current_seed || i_le8)
    r ← u64_from_le(hash[0..8]) mod total_remaining
    j ← weighted_pick(weights[i..N], r)   // cumulative weight lookup → O(N)
    swap(candidates[i], candidates[i+j])
    swap(weights[i], weights[i+j])
    current_seed ← hash

selected ← candidates[0..M].addresses

• Selected runners are pairwise independent: no two selections are correlated
• Higher stake → higher probability of selection (Sybil resistance)
• Higher reputation → graceful merit signal without lockout
• Same seed + same candidates always produces the same result (determinism)
• Any node can independently verify the selection (verifiability)

​

6. Reputation and Non-Reveal Handling

6.1 EMA reputation with 14-day half-life

on each timer fire / job settlement, for runner i:
    score_i_block = f(success, latency, slash_event)    in [0, 100]

    α = ln(2) / HALF_LIFE_BLOCKS                          // = ln(2) / 1_209_600  ≈ 5.73e-7
    reputation_i = reputation_i + α · (score_i_block − reputation_i)
    reputation_i = clip(reputation_i, REPUTATION_FLOOR, REPUTATION_CEILING)

6.2 Non-reveal classification

classify_non_reveal(runner, job, commit_block, reveal_window_blocks):
    if reveal_received(runner, job) within commit_block + reveal_window_blocks:
        → success path (no penalty)

    if CrashAttestation(runner, sig, height ∈ [commit_block, commit_block + reveal_window_blocks])
       was submitted before commit_block + reveal_window_blocks:
        → "operational failure" path: reputation penalty per §6.1 (-= 0 deferred decay) + 
           `CrashAttestation` event emitted; no stake slash; runner exempted from slash this round

    otherwise:
        → "proven dishonesty" path:
           - reputation reset to 0
           - stake slash per §11 (non-reveal slash magnitude)
           - `NonRevealSlash` event emitted

CrashAttestation {
    runner:        Address
    job_id:        bytes32
    crash_signal:  enum { OOM, NetworkPartition, HardwareFault, TEEAttestationLost, Other }
    timestamp:     Block
    self_signature: Signature   // runner's own key signing the structure
}

• Without exemption, legitimate hardware faults cause runner stake destruction → discourages decentralised runner participation.
• Without slash by default, a denial-of-verification attack costs only reputation.
• With exemption: runners must take an explicit action to claim “crash” status, leaving an on-chain trail. Repeated CrashAttestations from the same runner trigger Tier-2 review (default: ≥ 5 attestations in 1,000-block window → automatic flag).

6.3 Timeout-based re-selection

1. Selected runners have timeout_blocks to submit their result commitment.
2. If no commitment is received within timeout_blocks:
   • All timed-out runners receive a reputation penalty per §6.1 (timeout outcome → score 0)
   • Dispatcher triggers re-selection:
     retry_seed = Keccak256(original_seed || "retry:" || retry_count_le4)
   • Timed-out runners are excluded from the retry candidate list
   • A new set of M runners is selected from the remaining candidates
3. After MAX_RETRIES (default: 3) consecutive failures, the job transitions to Failed and the persistent non-responders receive an additional reputation hit
4. After SLASH_THRESHOLD consecutive slashes, a stake slash is triggered per §11

​

7. Entitlement Registry (0x0000…0007)

7.1 Core Type System

/// Scope — defines the resource boundary a permission applies to
pub enum Scope {
    Global,                   // chain-wide
    Actor(Address),           // specific Actor
    Token([u8; 32]),          // specific Token (token_id)
    Runner(Address),          // specific Runner
    RunnerPool(Vec<u8>),      // Runner Pool membership (pool_id bytes)
    Namespace(Vec<u8>),       // custom named namespace
}

/// Action — defines the permitted operation (single action per Entitlement record)
pub enum Action {
    All,                                       // wildcard
    // Token actions
    TokenTransfer, TokenMint, TokenBurn,
    TokenFreeze, TokenSetHook, TokenTransferOwnership,
    // Actor actions
    ActorDeploy, ActorSendMessage,
    ActorExecuteHandler(Vec<u8>),              // handler name
    // Runner actions
    RunnerRegister { min_stake_override: Option<u128> },
    RunnerSubmitJob, RunnerSubmitResult,
    RunnerJoinPool(Vec<u8>),                   // pool_id — grants pool membership
    // System actions
    SystemTransfer, SystemCreateAccount, SystemUpgrade,
    // Custom
    Custom(Vec<u8>),
}

/// Constraints — use conditions attached to an Entitlement
pub struct Constraints {
    pub valid_from:          Option<u64>,   // block height activation
    pub valid_until:         Option<u64>,   // block height expiry
    pub max_uses:            u64,           // 0 = unlimited
    pub used_count:          u64,
    pub max_amount_per_use:  Option<u64>,
    pub max_total_amount:    Option<u64>,
    pub total_amount_used:   u64,
    pub rate_limit:          Option<RateLimit>,
    pub delegatable:         bool,
    pub delegation_depth_max: u8,           // max delegation chain depth (0 = non-delegatable)
    pub revocable:           bool,
}

/// A single Entitlement record (one scope + one action per record)
pub struct Entitlement {
    pub grantee:    Address,
    pub scope:      Scope,
    pub action:     Action,
    pub constraints: Constraints,
    pub parent_id:  Option<EntitlementId>,  // set when derived via delegation
}

pub type EntitlementId = [u8; 32];  // keccak256(grantee || scope || action || parent_id?)

/// Named permission set (RBAC role)
pub struct Role {
    pub name:        Vec<u8>,
    pub scopes:      Vec<Scope>,
    pub actions:     Vec<Action>,
    pub constraints: Constraints,
}

Design note: Each Entitlement record covers one (Scope, Action) pair. Granting multiple actions requires multiple Grant calls (or an AssignRole that references a Role collecting them). This keeps revocation granular: revoking one action does not affect others.

7.2 System Instructions (instruction numbers 30–39)

pub enum SystemInstruction {
    // ... existing instructions 0–29 ...

    // Entitlement instructions (30–39)
    EntitlementGrant {
        grantee:     Address,
        scope:       Vec<u8>,       // codec-encoded Scope
        action:      Vec<u8>,       // codec-encoded Action
        constraints: Vec<u8>,       // codec-encoded Constraints
    },                                              // 30
    EntitlementRevoke {
        entitlement_id: [u8; 32],
    },                                              // 31
    EntitlementDelegate {
        entitlement_id: [u8; 32],
        delegatee:      Address,
        constraints:    Vec<u8>,    // must be a strict subset of parent constraints
    },                                              // 32
    EntitlementCreateRole {
        name:          Vec<u8>,
        scopes:        Vec<u8>,     // codec-encoded Vec<Scope>
        actions:       Vec<u8>,     // codec-encoded Vec<Action>
        constraints:   Vec<u8>,
    },                                              // 33
    EntitlementAssignRole {
        role_id:  [u8; 32],
        assignee: Address,
    },                                              // 34
    EntitlementRevokeRole {
        role_id:  [u8; 32],
        assignee: Address,
    },                                              // 35
}

7.3 Runner Pool Membership Model

Scope::RunnerPool(pool_id) + Action::RunnerJoinPool(pool_id)

Pool Owner / Governance
    │
    └── EntitlementGrant {
            grantee:  <runner_address>,
            scope:    Scope::RunnerPool(pool_id),
            action:   Action::RunnerJoinPool(pool_id),
            constraints: Constraints {
                valid_until: Some(expiry_block),  // optional time-bound
                max_uses: 0,                      // unlimited while valid
                delegatable: false,               // pool membership is non-delegatable
                revocable: true,
                ..Default::default()
            },
        }

EntitlementRegistry.check(
    grantee = runner_address,
    scope   = Scope::RunnerPool(required_runner_pool),
    action  = Action::RunnerJoinPool(required_runner_pool),
    at_block = submission_block,
) → bool

7.4 Gas Costs

7.5 Safety Limits

7.6 Backwards Compatibility

1. Default pass-through: If the Entitlement Registry Actor does not exist, all checks return false (no runner is admitted via pool filter). Jobs with required_runner_pool = None are unaffected.
2. Existing subsystems: Token owner == caller checks remain the first-priority gate; Entitlement provides an additional delegation path, not a replacement.
3. Instruction numbering isolation: Instructions 30–39 do not conflict with existing instructions 0–29.

​

8. Result Submission: Commit-Reveal + Designated Aggregator

• Runners: All M selected runners execute the job independently.
• Aggregator: Selected from the committee per §8.1. Acts as the coordinator.

Step 1 – Commit (all M runners, on-chain, low cost):
    commit(runner_addr, job_id, hash(result_bytes || runner_sig))
    Deadline: submitted_at + commit_deadline_blocks

Step 2 – Collect (Aggregator, off-chain):
    Aggregator receives result_bytes from other runners via direct HTTP push
    Aggregator runs verification logic (majority vote, structured match, etc.)

Step 3 – Reveal (Aggregator, on-chain):
    submit_verified_result(job_id, VerifiedResult, reveals[])
    reveals[i] = { runner, result_bytes, runner_sig }
    Aggregator receives a bonus reward for honest aggregation (§8.2)

Step 4 – On-chain verification (Result Verifier):
    For each reveal[i]:
        assert hash(result_bytes || runner_sig) == stored_commitment[i]
        assert runner_sig is valid Ed25519 over result_bytes
    Run verification mode checks (MajorityVote, StructuredMatch, etc.)
    Produce VerifiedResult → trigger deferred callback (CIP-1)

• Runners cannot copy others’ results after seeing them (commitment pre-locks the result).
• Aggregator cannot forge other runners’ results (commitment-bound).
• Aggregator failure: other runners may submit individual reveals after aggregator_timeout_blocks; Result Verifier falls back to self-aggregation.
• Non-reveal handling: see §6.2 for the CrashAttestation-gated classification.

8.1 Aggregator selection — eligibility threshold + uniform random

eligible = { runner in committee : reputation[runner] >= aggregator_eligibility_percentile_of(committee) }
   where aggregator_eligibility_percentile = 50 (Tier-0 tunable; key `system:cip2:aggregator.eligibility_percentile`)

if eligible == ∅:
    eligible = committee     // fallback: no one meets p50; use full committee

aggregator = uniform_random_from(eligible, seed = Keccak256(job_id || "agg-select-v3"))

• “Highest reputation” gives new runners zero probability of aggregating — they cannot bootstrap their reputation by aggregating successfully.
• Eligibility threshold (p50) ensures aggregators are competent without locking new runners out permanently — once a new runner crosses p50, they enter the eligibility pool.
• Uniform random within the eligible set prevents any deterministic-tie-breaker from concentrating aggregator share at a single high-reputation runner.

8.2 Aggregator bonus — 1.5% of gross

aggregator_bonus = gross_job_payment · aggregator_bonus_bps / 10000     // default bps = 150 = 1.5%

​

9. Verification Modes

9.1 VerifierCheck variants

pub enum VerifierCheck {
    MajorityVote     { field: String },
    JsonSchemaValid  { schema: String },
    StructuredMatch  { fields: Vec<String> },
    NumericTolerance { field: String, tolerance: f64 },
    NumericRange     { field: String, min: f64, max: f64 },
    Custom           { actor_hex: String, method: String },

    DnsTxtRecordMatch {
        fqdn:           String,
        expected_value: String,
        min_resolvers:  u32,
    },

    DnsCnameMatch {
        fqdn:            String,
        expected_target: String,
        min_resolvers:   u32,
    },
}

9.1.1 DnsTxtRecordMatch semantics

9.1.2 DnsCnameMatch semantics

9.1.3 Resolver pool configuration

1.1.1.1            (Cloudflare)
8.8.8.8            (Google Public DNS)
9.9.9.9            (Quad9)
208.67.222.222     (OpenDNS)

9.1.4 Why MajorityVote and not Deterministic for DNS

9.2 SemanticSimilarity embedding pinning

system:cip2:semantic_similarity_embedding_model = "sentence-transformers/all-mpnet-base-v2"
                                                  (default; resolved via model registry)

• Default routing. Per CIP-12 §5.1, “model flags/bans” are Tier 1 (15% quorum / >55% approval). The general model-registry path remains Tier 1.
• Carve-out. The specific entry system:cip2:semantic_similarity_embedding_model is flagged Tier-3 (15% quorum / >60% approval) because changes alter consensus-verification semantics — a runner colluding with the embedding-model choice could swing similarity clustering. The carve-out is documented here (CIP-2 §9.2) rather than in CIP-12; the registry path remains Tier 1 for non-consensus-critical entries.

​

10. JobType::Custom Extension Pattern

1. Build the verifier as a deterministic executor binary (Rust → reproducible build).
2. Hash the binary with BLAKE3.
3. Pin the hash via governance: write a record at GOVERNANCE_SYSTEM_ACTOR=0x09 keyed system:executor_registry:<name>.
4. Issue jobs as JobType::Custom { executor_hash: PINNED_HASH, params: <serialized job-specific params> }.
5. Runners that have whitelisted the executor execute the job. Verification proceeds via the standard VerifierCheck chain — §9.1 adds DNS checks; future amendments add their own.

10.1 Governance pinning vs. open executors

​

11. Slash Distribution Schema

SlashDistribution {
    burn_bps:      u16,      // 0..10000; default 10000 (100% burn) — matches WP §8.4 C7
    submitter_bps: u16,      // 0..10000; default 0           — challenger/submitter share, inactive at launch
    treasury_bps:  u16,      // 0..10000; default 0           — treasury share, inactive at launch
    // invariant: burn_bps + submitter_bps + treasury_bps == 10000
}

non_reveal_slash_amount = min(
    runner_effective_stake · non_reveal_slash_bps / 10000,
    max_non_reveal_slash_cby
)

​

12. Stake Floor (HOLD on CBY-denominated)

• Monitoring cadence. The Cowboy Foundation publishes monthly the implied USD value of the 10,000-CBY floor and the median runner’s effective stake. If the implied USD floor drifts outside the target band [$1,000, $10,000] for two consecutive monthly reviews, a Tier-0 governance proposal MUST be filed to adjust MIN_RUNNER_STAKE_CBY.
• No oracle dependency. This CIP does NOT introduce a consensus-layer CBY/USD oracle. Re-pegging is a future option gated on a forthcoming oracle CIP.
• Failure mode. If CBY appreciates 10×+ and the 10,000-CBY floor becomes punitive for small runners, the monitoring cadence above triggers a Tier-0 adjustment. The dispatcher continues to admit runners meeting the formula until that proposal lands.

​

13. Randomness Source

​

14. Activation and Migration

​

15. Open Questions Deferred to Phase-5 Simulation

• HHI-based committee shock. If a single large runner exits/enters and HHI shifts 0.10 → 0.50 in one epoch, M halves. The smoothing factor α = 0.125 damps this, but extreme cases may still cause perceptible per-job cost swings. Phase-5: simulate with realistic runner-set dynamics.
• Reputation half-life calibration. 14 days is the launch default; longer is more stable but slower to recover from rare-event mistakes; shorter is more reactive but lets recent bad runners re-enter selection too fast.
• crash_exemption_blocks = 50 default. Long enough for hardware reboot signal propagation, short enough to deter “stall, observe, decide” tactical non-reveals. Phase-5: model attacker dwell time against block-time-to-attestation latency.
• VRF weight sqrt(reputation) calibration. Whether r^0.5 or r^0.4 better matches empirical merit signals — sensitivity to the exponent is high in the upper tail.
• SlashDistribution (10000, 0, 0) HOLD vs (5000, 2000, 3000) AMEND — gated on Decision Register #1 (WP §8.4 C7 amendment).

​

Rationale

• Fisher-Yates VRF over ring-buffer: A ring-buffer selection (selecting N consecutive indices) would be vulnerable to correlation attacks — an adversary controlling adjacent positions in the active list is always selected together for any N-runner job. Fisher-Yates with independent weighted draws eliminates this correlation entirely.
• Stake × √reputation weighting: Equal-probability selection ignores stake, making Sybil attacks cheap. Pure-stake weighting amplifies “rich-get-richer”. sqrt(reputation) provides a graceful merit signal — a 4× reputation differential becomes a 2× selection-probability differential — without enabling reputation-mining attacks or locking out new entrants.
• Adaptive committee sizing: A static M=5 committee is wrong at both extremes — too costly when the network is large and decentralised, too thin when stake is concentrated. The HHI-driven adaptive rule scales M with measured concentration; the M_min/M_max clip bounds the worst case.
• EMA reputation with 14-day half-life: Earlier revisions referenced reputation as a filter, penalty target, and aggregator selector but never defined update mechanics. The EMA model gives a smooth decay path that recovers from rare bad events without letting a recent bad runner re-enter selection too quickly.
• Eligibility + uniform-random aggregator: Pure “highest reputation” lock-in gives new runners zero probability of aggregating — they cannot bootstrap reputation. Eligibility threshold + uniform random preserves quality (only ≥ p50 runners aggregate) while allowing entry.
• Non-reveal classification with CrashAttestation: Pure reputation penalty for missed reveals is a denial-of-verification attack vector — commit garbage, observe others’ commits, refuse to reveal if unfavorable. Default-slash with a CrashAttestation exemption path closes the attack without destroying legitimate operators’ stake on hardware faults.
• No private key for VRF seed: Deriving the seed from the consensus threshold beacon (Keccak256(domain || mode || canonical_seed_bytes(R) || job_id || submitted_at)) instead of a dispatcher private key eliminates the hardcoded-key security hole. The threshold seed is consensus-verified, unique per absolute round, and globally consistent — unlike a block hash, no single proposer can grind the randomness source itself. For M > 1 the commit-then-reveal path closes proposer selection bias; M == 1 retains the bounded inclusion-timing residual described in Security Considerations.
• Timeout re-selection over skip_task: skip_task creates adverse incentives (runners selectively skip low-value jobs) and adds unnecessary on-chain transactions. Passive timeout with reputation penalty provides the same liveness guarantee with better economic alignment.
• Commit-reveal aggregator: All-runners-submit-to-chain would cost Gas × N and would allow result copying. Commit-reveal prevents copying; designating the aggregator off-chain is Gas-efficient. The eligibility-threshold selection (§8.1) is preferred over a highest-reputation tie-breaker because it allows new runners to bootstrap their reputation.
• Deferred Transactions (CIP-1): Callbacks are delivered as deferred transactions, decoupling off-chain execution latency from the main chain execution path.
• Mandatory Result Schemas: Creates a clear contract between developers and Runners, prevents gas-bombing, and simplifies result verification.
• MajorityVote for DNS, not Deterministic: DNS resolution is not byte-identical across resolvers. Deterministic would either fail constantly or force a single shared resolver, defeating multi-runner verification. MajorityVote is the structurally correct mode for non-deterministic external observations.
• JobType::Custom as the extension pattern: Adding a new JobType discriminant for every new built-in verifier fragments the type space. The existing JobType::Custom { executor_hash, params } covers all cases; governance pinning of the hash makes a verifier “built-in” without protocol changes.
• Pinned SemanticSimilarity embedding: Without pinning, a runner could collude with the embedding-model choice. The Tier-3 carve-out from the Tier-1 model registry path reflects that this specific entry is consensus-critical.
• Schema-level slash flexibility, C7-preserving defaults: SlashDistribution { burn_bps, submitter_bps, treasury_bps } is in code from the outset, but defaults (10000, 0, 0) preserve WP §8.4 C7. A future challenger-bounty amendment is a flag flip, not a CIP rewrite.
• Entitlement as membership proof (not just a flag): Pool membership is represented as an on-chain Entitlement record (with expiry, rate-limit, delegatability) rather than a simple boolean flag. This allows time-bounded trial access, revocable membership, and delegation to sub-pools without protocol changes.
• Single action per Entitlement record: Each record carries one (Scope, Action) pair. This enables fine-grained revocation without affecting co-granted actions, and keeps the membership check path O(1) per action.

​

Backwards Compatibility

• The skip_task interface is removed; existing task submissions that relied on skip behavior rely on timeout re-selection (§6.3) instead, which provides equivalent liveness guarantees.
• The new VerifierCheck variants (DnsTxtRecordMatch, DnsCnameMatch) are additive enum variants. Existing consumers must add match arms; otherwise unchanged. Runners that have not upgraded to support DNS executors simply do not advertise the resolver capability and are not selected for DNS verification jobs (existing capability-matching logic in runner-registry).
• JobType::Custom is unchanged; §10 documents an existing extension mechanism.
• The mechanism revisions (adaptive committee, stake · sqrt(reputation) weight, EMA reputation, aggregator reform, non-reveal classification, slash distribution schema, SemanticSimilarity pinning) activate at a single block H_v3 via Tier-3 governance proposal (§14). Runners that haven’t upgraded to the new rules see no API breakage at the runner protocol layer; the changes are protocol-internal mechanisms in 0x01/0x02/0x03 system actors. Runners SHOULD watch for CrashAttestation event reception (a new event type at 0x03) — operational tooling that does not emit CrashAttestation simply pays the slash cost on unexpected crashes.
• Existing reputation integers carry forward at H_v3 as the initial EMA value.
• No syscall, opcode, or message-format changes at the actor boundary.

​

Security Considerations

• VRF Grinding: Both grinding surfaces must be considered: a submitter choosing job bytes / submitted_at to influence the seed, and a proposer/leader influencing the randomness source itself (a block hash is proposer-assembled, and a height-anchored beacon can drift across rounds under a withholding leader — which is why neither is an acceptable seed source). The absolute-round threshold seed (§5; CIP-11 §9.2, §15.9) closes both paths for M > 1 committees: the job binds before the seed for the named future round exists, and that round’s seed is unique — a withholding leader can delay it but cannot re-roll it. For M == 1, two residuals remain: the submitter may know the parent beacon before submitting, and the proposer of the including block — who sees the pending JobSubmit and already knows the parent beacon — can include, omit, or defer the transaction to sample a different parent beacon (inclusion-timing selection). Immediate mode therefore does not provide proposer-inclusion neutrality. Both residuals are MEV/fairness-bounded (each attempt is an ordinary paid job, deferral is bounded by normal mempool/liveness/economic costs, and the selected runner stays economically accountable), not a committee-independence break — submitters that need selection neutrality SHOULD request M > 1 verification.
• Stake Concentration: The stake · sqrt(reputation) weight (§5.3) gives a graceful reputation signal without enabling reputation-mining or pure stake monopoly. The adaptive committee rule (§5.1) further mitigates concentration by scaling M with the measured HHI of effective stake.
• Aggregator Collusion: The Aggregator sees all results before submitting to chain. Mitigations: (1) other runners’ commitments are locked before Aggregator submits; (2) other runners can independently reveal if Aggregator is unresponsive; (3) Aggregator’s extra reward is forfeit if the submitted VerifiedResult is later challenged; (4) the eligibility-threshold + uniform-random selection (§8.1) prevents permanent aggregator capture by a single high-reputation runner.
• Active List Manipulation: Minimum stake (MIN_STAKE = 10,000 CBY) and reputation threshold (min_reputation = 50) provide economic deterrence. The Entitlement pool mechanism (§7) allows job submitters to further restrict runner eligibility.
• Callback Griefing: A malicious developer could write a callback that always fails, preventing runners from being paid. The failed_callbacks counter accrues as a reputational penalty, and runners may blacklist actors with high failure rates.
• Historical Snapshot Integrity: The candidate list is fixed at submission_block. The Merkle root of the candidate list must be stored on-chain at submission time to enable re-selection verification. Runners who join or leave post-submission do not affect the snapshot.
• Slash distribution governance: The default SlashDistribution = (10000, 0, 0) preserves WP §8.4 commitment C7. Any non-trivial change requires Tier-3 governance that also amends C7 in lockstep — the schema-level flexibility does not unilaterally override the C7 commitment.
• Stake-floor drift: The CBY-denominated floor may drift relative to USD purchasing power. The §12 monitoring cadence and the lack of consensus-layer oracle dependency are the v3 trade-off; re-pegging is gated on a forthcoming oracle CIP.
• Entitlement Inflation: Each address is limited to 256 active Entitlements and 64 assigned Roles. EntitlementGrant consumes 500 Cells to deter spam. Expired Entitlements are lazily cleaned on first post-expiry check.
• Delegation Chain Depth: delegation_depth_max (max 5) and the requirement that delegated constraints be a strict subset of parent constraints prevent privilege escalation through chained delegation.
• Pool Membership Expiry: Pool Entitlements with valid_until set are automatically ineligible after the specified block. Node operators running compliance-sensitive pools should set time-bounded grants and renew via governance.