Tetsuo Corporation - (AgenC)
Abstract
Decentralized autonomous agents are self-operating computer programs that work across multiple organizations, creating a new way to coordinate tasks without requiring mutual trust. However, these systems currently face a key performance problem: after each step, cryptographic proofs (digital confirmations of correctness) must be checked individually, which slows the process as it gets longer. This makes complex, multi-step agent operations too slow for applications that require quick results.
This paper presents Speculative Execution with Optimistic Proof Deferral, a new approach to running agents that allows subsequent steps to proceed before earlier results are officially confirmed by cryptographic proofs on the blockchain. Our method maintains the same finalized-state safety invariant, with additional off-chain rollback and economic-risk complexity while speeding up the entire process by 2.65× at pipeline depth 5, approaching 4.5× asymptotically as pipeline depth grows for jobs where proof checking takes longer by allowing multiple steps and proof creation to run in parallel.
We explain a formal system for how agents can promise to complete tasks, modeled as a network (directed acyclic graph) of linked activities. We provide mathematical guarantees on the order of proof checking and on how to undo steps (rollback) if something fails. An incentive model using growing financial deposits (exponential stake bonding) motivates honest behavior and limits risk. The system has five main parts: how tasks depend on each other (DependencyGraph), a record of promises (CommitmentLedger), a manager for waiting proofs (ProofDeferralManager), a component to undo actions if needed (RollbackController), and a scheduler that allows early starts (SpeculativeTaskScheduler), all built on top of the AgenC protocol using the Solana blockchain.
Our analysis demonstrates that for an n-task pipeline with average execution time T_exec, proof generation time T_proof, and confirmation time T_confirm, speculative execution reduces total latency from O(n x (T_exec + T_proof + T_confirm)) to n x T_exec + T_proof + T_confirm, with all intermediate proof generation fully overlapping subsequent task execution. For typical proof-dominant workloads, this yields a 2.65x speedup at a pipeline depth of 5, approaching (T_exec + T_proof + T_confirm) / T_exec asymptotically (4.5x for representative parameters). We present formal correctness arguments, failure-mode analysis, economic attack-resistance properties, and a comparative analysis with alternative approaches, including proof composition, incrementally verifiable computation, and hybrid optimistic/ZK models, establishing speculative execution as a practical and complementary approach for high-throughput decentralized agent coordination.
Limitations. The current system assumes cooperative pipelines where each task has a unique designated executor. In competitive task markets where multiple agents race to complete the same task, speculatively generated proofs from losing agents represent uncompensated wasted work. The expected overhead scales with both competition intensity and speculation depth. Deployments on competitive task markets should consider disabling speculative execution for tasks with multiple active claimants until the mechanisms described in Section 10.5 are developed.
Keywords: speculative execution, zero-knowledge proofs, agent coordination, blockchain, optimistic execution, distributed systems, formal verification
1. Introduction
1.1 The Rise of Autonomous AI Agents
Recent advances in large language models, verifiable computation, and blockchain technology have led to the rise of autonomous AI agents. These software entities can perceive, reason, and act within digital environments with little human supervision. Unlike traditional automation, which follows strict rules, autonomous agents are goal-directed. They adapt their strategies based on feedback and can handle complex, multi-step objectives.
The economic effects are significant. Agents can negotiate contracts, execute trades, manage portfolios, and coordinate resources across organizations without needing trust between their principals. This ability has increased interest in decentralized agent coordination protocols. These systems let agents owned by different parties work together on shared tasks while ensuring verifiable accountability.
1.2 The Verification Bottleneck
Decentralized agent coordination relies on cryptographic proofs for correctness. When Agent A finishes a task, it generates a zero-knowledge proof (ZKP) demonstrating that its computation meets the constraints. Agent A then sends the ZKP to the blockchain for on-chain verification, allowing any dependent task to proceed only after verification.
While cryptographically sound, this model introduces significant latency:
First, consider proof-generation latency: Modern ZKP systems (e.g., Groth16, PLONK) take 2-10 seconds to generate proofs, depending on computational complexity.
Next, there is confirmation latency: Blockchain transaction submission, propagation, and block finalization together add approximately 400ms-13 seconds per transaction on Solana, and longer on other chains.
Pipeline Multiplier: In workflows with n sequential tasks, these latencies compound serially across three terms, task execution, proof generation, and on-chain confirmation, impacting overall efficiency.
Consider a five-task agent pipeline. Each task requires 2 seconds to execute, 5 seconds for proof generation, and 2 seconds for on-chain confirmation. The total pipeline latency becomes 5 × (2s + 5s + 2s) = 45 seconds, since every task must finish before the next commences.
This 45-second latency renders the system unsuitable for applications that require real-time responsiveness, including trading, emergency response coordination, and interactive assistants.
1.3 Contribution: Speculative Execution with Safety Guarantees
Imagine streamlining the verification bottleneck through speculative execution. While on-chain verification must occur in dependency order, execution itself can forge ahead speculatively. This design lets a downstream agent optimistically use an ancestor’s uncommitted output, generating its own proof in parallel. If all ancestors later reach finality, the descendant’s proof becomes eligible for submission, speeding up and streamlining the process.
The main technical challenge from this approach is ensuring safety. If an ancestor’s proof fails, all dependent speculative work is invalid. To address this, our system introduces these mechanisms:
Agents produce local output commitments as part of Speculative Commitments, which become validated once ancestor confirmations occur.
Proofs are queued and submitted only after the ancestor tasks reach finality, ensuring proper ordering via Proof Deferral.
Cascade Rollback introduces efficient protocols to roll back speculative state when ancestor proofs fail.
With Economic Bonding, exponentially scaled collateral requirements limit risk and also align incentives.
In summary, we prove the system maintains correctness invariants under all execution scenarios. Furthermore, we show a 2.65-4.5x reduction in latency in typical proof-dominant multi-task pipelines.
2. Background
2.1 Decentralized Agent Coordination
Decentralized agent coordination lets several autonomous agents, each possibly managed by different parties, work together on complex tasks. They do this without needing a central authority. The AgenC protocol [1] offers the needed infrastructure and handles:
Task Definitions: Specifications of work units recorded on the blockchain (on-chain), describing the skills needed, payment offered, and deadlines.
Agent Registry: A public directory where agents register without needing permission. Agents provide a deposit (stake) as collateral and describe their skills.
Task Claims: A method allowing agents to commit to performing tasks by locking up their staked deposit as a guarantee of performance.
Proof-Based Completion: Zero-knowledge proofs (ZKPs) verify that tasks are completed correctly without revealing sensitive details.
The protocol enables trust-minimized coordination: agents need not trust each other; they rely only on the mathematical guarantees provided by cryptographic proofs and economic incentives.
2.2 Zero-Knowledge Proofs in Task Verification
Imagine a scenario where you need to prove you know a secret without revealing it; this is the power of zero-knowledge proofs (ZKPs). ZKPs let one party (the prover) demonstrate to another (the verifier) that a statement is true, while sharing nothing beyond that fact. In agent coordination, ZKPs serve multiple purposes:
First, ZKPs can be used for correctness verification, ensuring that computation satisfies task-specific constraints.
Additionally, they support privacy preservation by demonstrating correct behavior without revealing proprietary algorithms or sensitive inputs.
Furthermore, ZKPs enable computational integrity, allowing verification of expensive computations through succinct proofs.
The AgenC protocol employs RISC Zero's zkVM [14] with Groth16 [2] compression for on-chain verification. RISC Zero proofs are generated using a STARK-based prover and recursively compressed to constant-size Groth16 proofs (260 bytes: 4-byte selector + 256-byte proof) verified via the Verifier Router CPI on Solana [15]. On-chain verification requires approximately 200,000 compute units. However, proof generation remains computationally intensive, typically requiring 2-10 seconds for moderately complex circuits on a GPU, with hardware acceleration and proof markets (Section 9.4) rapidly reducing these times.
2.3 The Latency Problem in Proof Pipelines
Sequential proof verification creates a fundamental tension between security and performance. Consider the following task pipeline:
In the standard execution model:
Each task must wait for its predecessor's complete proof cycle before beginning execution. For n tasks with execution time T_exec, proof generation time T_proof, and confirmation time T_confirm:
This O(n) scaling on the latency-critical path creates an insurmountable barrier for deep task pipelines, limiting practical workflow depth regardless of available computational resources.
3. Problem Statement
3.1 Formal Definition of Task Dependency Graphs
We model task workflows as directed acyclic graphs (DAGs), where vertices denote tasks and edges denote dependencies.
Definition 3.1 (Task Dependency Graph). A task dependency graph is a tuple G = (V, E, σ) where:
V is a finite set of task vertices.
E ⊆ V × V is a set of directed edges representing dependencies.
σ: V → {PENDING, EXECUTING, PROVING, FINALIZING, FINALIZED, FAILED} assigns each node a status.
An edge (u, v) ∈ E indicates that task v depends on the output of task u; we call u an ancestor of v and v a descendant of u. Implementation scope note: The current AgenC implementation stores a single parent pointer per task (parentTaskId), restricting live dependency graphs to tree/forest structures. The formal model in this section is stated for arbitrary DAGs to establish generality and to cover the planned multi-parent extension (Section 10.1). All performance claims in Section 7 are derived under the linear pipeline model, which is fully supported by the current implementation. The diamond DAG scenario in Table 4b reflects the generalized model and is marked accordingly.
To capture execution constraints, we introduce the following: Definition 3.2 (Finalization Order). A valid finalization order for G is a total order π on V such that for all (u, v) ∈ E: π(u) < π(v). That is, ancestors must finalize before descendants.
To further analyze execution progress, consider: Definition 3.3 (Speculation Depth). For a task v ∈ V, the speculation depth depth(v) is defined as the length of the longest path from any finalized ancestor to v, counting only unfinalized nodes:
If all ancestors of v are finalized, depth(v) = 0.
3.2 Sequential Execution Model
The standard execution model enforces a strict invariant:
Invariant S1 (Sequential Execution). A task v may only begin execution when all tasks u such that (u, v) ∈ E satisfy σ(u) = FINALIZED.
While this invariant ensures correctness-no task ever operates on invalid inputs-it serializes execution along dependency chains.
3.3 Latency Analysis
Let n denote the number of tasks in a linear pipeline. Define:
T_exec: Average task execution time
T_proof: Average proof generation time
T_confirm: Average on-chain confirmation time
Under sequential execution, total pipeline latency is:
For typical values (T_exec = 2s, T_proof = 5s, T_confirm = 2s) and n = 5:
The critical observation is that proof generation and confirmation constitute the dominant terms, yet they cannot begin until execution completes. Our goal is to overlap these operations across pipeline stages.
4. Speculative Execution Model
4.1 Core Concepts
4.1.1 Speculative Commitments
A speculative commitment is a cryptographic commitment to a task's output made before ancestor proofs achieve finality. Formally:
Definition 4.1 (Speculative Commitment). For a task v with output O_v and random salt r, the speculative commitment is:
where H is a collision-resistant hash function, and SHA-256 (via Solana's hashv syscall) is used for commitment hashing [3]. This choice leverages Solana's native SHA-256 support for efficient on-chain verification.
The commitment, salted, hides the output while binding the agent to a value. Upon proof submission, the agent reveals O_v and r, allowing verifiers to confirm that C_v = SHA-256(H(O_v), r).
4.1.2 Proof Deferral
Proof deferral is the mechanism by which proofs generated by a node await the finalization of its ancestors before on-chain submission. This preserves the critical invariant:
Invariant P1 (Proof Ordering). For any task v with proof submitted at time t_s, all ancestors u of v have finalization time t_f(u) < t_s.
Proof deferral enables speculative execution and proof generation while ensuring on-chain transitions follow dependency order.
4.1.3 Dependency-Aware Scheduling
The speculative task scheduler uses several criteria to decide which tasks can start speculative execution. It evaluates whether each task meets requirements for allowable speculation depth, stake availability, claim expiry, and resource limits before allowing execution to begin.
Depth Bounds: Maximum allowable speculation depth
Stake Availability: Required bond for the given depth
Claim Expiry: Sufficient time remaining before deadline
Resource Limits: Memory, compute, and parallel branch constraints
If a task fails to meet any of the scheduler's criteria, it is rejected for speculation and must wait until its ancestor tasks have been finalized before it can begin execution.
4.2 System Architecture
The speculative execution system comprises five core components:
4.2.1 DependencyGraph
The DependencyGraph maintains the DAG of task dependencies, tracking:
Parent/child relationships between tasks (single-parent structure in current implementation)
Speculation depth for each node
Confirmation/finality status (PENDING, SPECULATIVE, FINALIZED, FAILED)
Key operations include cycle detection (to prevent deadlock), topological sorting (for proof submission ordering), and depth computation (for scheduling decisions).
Data Structure:
4.2.2 CommitmentLedger
The CommitmentLedger serves as the local source of truth for speculative commitment state, managing:
Commitment creation and lifecycle tracking
Stake bonding and release
TTL-based expiration
State transitions (CREATED → PROOF_GENERATED → SUBMITTED → FINALIZED)
4.2.3 ProofDeferralManager
The ProofDeferralManager implements the proof ordering invariant by:
Queueing generated proofs with their ancestor dependencies
Monitoring ancestor finality via blockchain events
Releasing proofs for submission when all ancestors are finalized
Coordinating with RollbackController on ancestor failures
Critical Invariant Enforcement:
4.2.4 RollbackController
The RollbackController handles failure recovery through cascade rollback:
Detecting rollback triggers (proof failure, timeout, claim expiry)
Computing the affected descendant set via graph traversal
Executing rollback in reverse topological order (leaves first)
Releasing or slashing bonded stake based on failure cause
Rollback Order Invariant: Descendants are rolled back before their ancestors to ensure consistent state unwinding.
4.2.5 SpeculativeTaskScheduler
The SpeculativeTaskScheduler coordinates speculative execution by:
Validating speculation eligibility against configured bounds
Computing required stake based on speculation depth
Coordinating task execution and proof generation
Enforcing resource limits (memory, concurrent operations)
Scheduling Decision Flow:
4.3 Execution Semantics
4.3.1 When to Speculate
The scheduler approves speculation when all of the following conditions hold:
Depth Constraint: depth(v) < max_depth
Stake Constraint: available_stake ≥ required_bond(depth(v))
Time Constraint: claim_expiry - now > claim_buffer
Resource Constraint: active_speculations < max_parallel
Parent Validity: Parent exists and is not in the FAILED state
The default configuration uses max_depth = 5, balancing latency reduction and rollback risk.
4.3.2 Proof Ordering Invariant
Proof Ordering: In the speculative execution system, for any task v whose proof is submitted at time t_s, all ancestors u of v satisfy t_f(u) < t_s, where t_f(u) is the finalization time of u.
Proof Sketch. The ProofDeferralManager maintains a set pendingAncestors for each queued proof. When this set becomes empty, the proof transitions to READY status, indicating it is prepared for submission. Submission can only occur once the READY status is reached. Ancestor finality events trigger removal from pendingAncestors, enabling this transition. Thus, by design, submission happens only after all ancestors have finalized. □
For a comprehensive understanding of the proof and supporting arguments, see Appendix B for the rough proof.
4.3.3 Rollback Cascade Semantics
Thus, if an ancestor task u fails (due to proof rejection, timeout, or claim expiry), all of its descendants must be rolled back to ensure system consistency.
Algorithm 4.1: Cascade Rollback
The reverse topological ordering ensures that descendants are rolled back before their ancestors, maintaining invariant consistency.
5. Safety and Correctness
5.1 The Fundamental Invariant
The speculative execution system is designed around a single fundamental invariant:
Fundamental Invariant (FI). At all times, for any task v with on-chain proof finalization, all ancestors u of v also have on-chain proof finalization, and t_f(u) < t_f(v).
This invariant ensures that on-chain state remains consistent with dependency ordering, even when off-chain speculative execution proceeds out of order.
5.2 Formal Correctness Arguments
We establish correctness through three key theorems:
Theorem 5.1 (No Premature Submission). Under the speculative execution protocol, no proof for task v is submitted to the blockchain while any ancestor of v remains unfinalized.
Proof. Let v be any task with proof π_v. The ProofDeferralManager gates submission on the condition:
Initially, pendingAncestors(v) = {u : u is an ancestor of v and σ(u) ≠ FINALIZED}. Elements are removed only upon receiving on-chain finality events. Therefore, pendingAncestors(v) = ∅ implies all ancestors are finalized. □
Theorem 5.2 (Rollback Completeness). If task u fails, all descendants of u are eventually rolled back.
Proof. The rollbackCascade algorithm computes the affected set via breadth-first traversal from u, visiting all reachable nodes through child edges. By the definition of descendant (reachable via child edges), all descendants are included in the affected set. The algorithm iterates over all elements in the affected set, executing rollback for each. Post-rollback validation confirms no orphans exist. □
Theorem 5.3 (Depth Bound Preservation). For all tasks v in speculative execution, depth(v) ≤ max_depth.
Proof. The SpeculativeTaskScheduler rejects any task v where computed depth exceeds max_depth. Depth computation follows the definition (longest path of unfinalized ancestors). The depth check occurs before task acceptance and commitment creation. On-chain commitment creation also validates depth. By defense in depth, no task can enter speculative execution with excessive depth. □
5.3 Depth and Stake Bounding
Speculation depth is bounded to limit cascading failure impact. We employ a depth limit of max_depth = 5 by default, configurable per deployment.
Stake Scaling: Required stake increases exponentially with depth:
This exponential scaling ensures that deeper speculation requires proportionally greater economic commitment, naturally limiting the depth that rational agents will pursue.
Table 1. Stake requirements by speculation depth (base_stake = 0.001 SOL)
5.4 Failure Mode Analysis
We conducted a comprehensive Failure Modes and Effects Analysis (FMEA), identifying 43 potential failure modes across six components. The top five risks by Risk Priority Number (RPN = Severity × Probability × Detection Difficulty) are:
Table 2. Critical failure modes and mitigations
Complete failure mode analysis with mitigations is provided in the supplementary materials.
6. Economic Model
6.1 Stake Bonding for Speculation
Economic security is provided through stake bonding. Agents must lock collateral proportional to their speculation depth:
Definition 6.1 (Bond Requirement). For task v at speculation depth d, the required bond is:
Parameter calibration note. The values used throughout this paper (B_base = 0.001 SOL ≈ $0.20 at time of writing, max depth 5, cumulative exposure ≈ 0.063 SOL ≈ $12.60) are reference parameters chosen to illustrate the model's structure. Production deployments should calibrate B_base against the expected economic value of the tasks being coordinated: B_base should be set such that the maximum cascade loss from a dishonest root agent is bounded by a fraction of the task reward. A recommended heuristic is B_base ≥ 0.1 × task_reward_floor, with max_depth set such that cumulative exposure remains below the expected cost of a successful attack. Calibration guidelines for common AgenC task classes will be published separately.
where B_base is the minimum stake (default: 0.001 SOL ≈ $0.20 at current prices).
This exponential scaling achieves several objectives:
Self-Limiting Depth: Rational agents naturally avoid excessive depth due to capital requirements.
Risk Proportionality: Deeper speculation, which affects more potential descendants, requires greater collateral.
Capital Efficiency: Shallow speculation (common case) requires minimal capital.
6.2 Slashing Conditions
Stake slashing occurs when an agent's speculative commitment is invalidated for preventable reasons:
Table 3. Slashing conditions and percentages
Zero slashing for ancestor failures is critical: agents should not be penalized for factors outside their control. This encourages participation by limiting downside risk from speculation.
6.3 Incentive Alignment
The economic model aligns incentives through several mechanisms:
Speculation Value Proposition: Agents speculate because latency reduction creates value. Faster completion enables:
Earlier reward collection
Higher throughput (more tasks per time unit)
Competitive advantage in time-sensitive markets
Risk/Reward Balance: Expected value of speculation at depth d:
where P(success) is the probability of successful confirmation. For typical scenarios where P(success) > 0.95 and V_completion >> Slash, speculation is positive expected value.
Reputation Effects: Persistent failure patterns (tracked off-chain) lead to reduced trust and potentially higher implicit costs through counterparty risk assessment.
6.4 Attack Resistance
6.4.1 Griefing Attack
Attack Vector: Malicious agent deliberately fails proofs to trigger cascading rollbacks, wasting honest agents' compute.
Defense (layered):
Exponential stake bonding makes deep griefing expensive
Slashed stake distributed to affected downstream agents (proportional to wasted compute)
Reputation tracking identifies chronic griefers, reducing their speculation eligibility
Speculation whitelist based on historical reliability scores
Depth-dependent slash escalation (deeper speculation → higher slash percentage)
Quantitative Analysis. Consider an attacker at depth d = 0 (root task) triggering rollback of k descendants:
For B_base = 0.001 SOL, slash_rate = 10%, k = 4 descendants, T_exec = 2s, and C_compute ≈ 0.0001 SOL/s (approximate cloud GPU cost):
In this scenario, the attacker's loss (0.0001 SOL) is insufficient to compensate victims' wasted compute (0.0008 SOL). This asymmetry is a known limitation of shallow-stake griefing.
Mitigation: Depth-Dependent Slash Escalation. We introduce escalating slash rates that account for downstream impact:
Table 3a. Enhanced slashing schedule
With cascade-aware slashing, the root attacker in the above example faces:
Combined with the exponential bond requirement for deeper speculation (where griefing has greater impact), the economics become unfavorable. At depth 3 with 8 descendants:
Remaining Limitation and Defense Scope. For very shallow, low-stake griefing (single root task, few descendants), the economic deterrence in the current model is insufficient. The enhanced slash covers 0.0003 SOL against 0.0008 SOL in victim compute costs in the example above -- partial but not complete compensation.
The reputation system serves as the second layer of defense: agents with a historical failure rate exceeding a configurable threshold (default: 2%) are excluded from speculating on ancestor tasks. The following properties of this mechanism are defined but not yet fully implemented on-chain in the current version:
Failure rate is computed over a rolling window of the agent's last N task attempts (default N=50), tracked in the off-chain agent registry
The 2% threshold applies to non-cascade failures only (proof rejections and timeouts; ancestor cascade failures are excluded from the rate calculation per the slashing table)
Sybil resistance relies on stake bonding: new agent identities begin with zero history and are therefore ineligible for ancestor speculation until N=50 tasks are accumulated at depth 0
A patient attacker who griefs just below the 2% threshold can evade the reputation filter indefinitely. Full griefing resistance at minimal stake levels is an open problem. The layered defense (economic + reputational) provides adequate deterrence for rational economic actors; defense against irrational or state-level adversaries is explicitly out of scope for this paper.
6.4.2 Front-Running
Attack Vector: Observer monitors speculative commitments and races to claim tasks first.
Defense:
Commitment-reveal scheme hides task details until proof submission
Private mempools (Jito) prevent transaction snooping
Short claim windows limit front-running opportunity
6.4.3 Resource Exhaustion
Attack Vector: Create many speculative tasks to exhaust system resources.
Defense:
Rate limiting per agent
Bounded queues with admission control
TTL-based expiration of stale commitments
Per-agent commitment limits
7. Performance Analysis
7.1 Theoretical Latency Reduction
Consider a linear pipeline of n tasks. Let:
T_exec: Execution time per task
T_proof: Proof generation time per task
T_confirm: On-chain confirmation time per task
7.1.1 Sequential Model
Under sequential execution:
Each task must complete its entire cycle before the next begins.
7.1.2 Speculative Model
Under speculative execution, tasks execute sequentially (each uses its predecessor's output), but proof generation begins immediately after each task completes and runs in parallel with subsequent task execution. Proofs are submitted in dependency order once both (a) the proof is generated and (b) all ancestor proofs are finalized.
Detailed Timeline. Task i begins execution at time t_i^exec and finishes at t_i^exec + T_exec. Proof generation for task i begins immediately upon execution completion and finishes at t_i^exec + T_exec + T_proof. Proof submission for task i occurs at:
For a linear pipeline, task i begins executing at time (i-1) × T_exec (since each task must await its predecessor's output, but not its proof). Task i's proof completes at time i × T_exec + T_proof. Task i can submit its proof once both (a) its proof is generated and (b) task i-1 is finalized on-chain, and then waits q_i for dispatch through the deferral queue. This yields the recurrence:
with base condition t_0^finalized = 0 and q_1 = 0.
where q_i ≥ 0 captures proof queue/dispatch delay (e.g., tx scheduling and queue contention). In the baseline model used throughout this paper, q_i = 0.
Closed-Form Solution (q_i = 0). When T_exec ≥ T_confirm (which holds whenever execution is not trivially fast compared to block finalization), proof availability is often the binding constraint. In this regime, each task's proof completes after the predecessor is finalized, and the recurrence resolves to:
The total pipeline latency is therefore:
This captures the critical path: all n executions in series (each needing its predecessor's output), plus the irreducible cost of the final task's proof generation and on-chain confirmation. Every intermediate proof generation is fully hidden behind subsequent execution and confirmation steps.
Simplification. When T_exec ≈ T_proof ≈ T_confirm = T:
Speedup Factor:
For n = 5: S = 15/7 ≈ 2.14×. As n → ∞, S → 3.0 in the equal-time case.
Validity condition. The closed form requires T_exec ≥ T_confirm. When T_exec < T_confirm, the confirmation chain becomes the bottleneck at some crossover point, and the latency increases to L_spec = T_exec + T_proof + n × T_confirm in the extreme case where T_exec ≪ T_confirm. In practice, Solana slot times (~400ms) and typical agent task execution times (seconds to tens of seconds for LLM inference, data retrieval, or contract calls) ensure T_exec ≥ T_confirm for the workloads AgenC targets. Tasks where this condition fails -- sub-400ms pure computation with no I/O -- are outside the scope of decentralized agent coordination and would not benefit from the protocol regardless. For completeness: when T_exec < T_confirm, the confirmation chain becomes the bottleneck and the pipeline latency trends toward T_exec + T_proof + n × T_confirm in the degenerate case, eliminating most of the speedup. Protocol deployments should validate T_exec ≥ T_confirm empirically before enabling speculative execution for a given task class.
7.1.3 Accounting for Proof Dominance
In practice, T_proof >> T_exec. For T_proof = 5s, T_exec = 2s, T_confirm = 2s, n = 5:
Sequential:
Speculative (traced timeline):
The timeline confirms the closed-form: L_spec = 5 × 2 + 5 + 2 = 17s. The steady-state cadence is T_exec = 2s per step (visible from t=9 onward), because each task's proof finishes exactly when the predecessor is finalized, proof generation (T_proof = 5s) is fully absorbed by the T_exec gap between consecutive tasks plus the T_confirm of the predecessor.
Table 4a. Pipeline latency analysis (T_proof = 5s, T_exec = 2s, T_confirm = 2s)
As n → ∞ with proof-dominant parameters, the speedup approaches (T_exec + T_proof + T_confirm) / T_exec = 9/2 = 4.5× for these values. The asymptotic speedup equals the ratio of sequential per-task cost to speculative per-task marginal cost (just T_exec), since proof generation and confirmation are entirely hidden in the pipeline's steady state.
7.2 Overhead Analysis
Speculative execution introduces overhead in several dimensions:
7.2.1 Rollback Costs
When an ancestor fails, descendants must roll back:
Cost Components:
Compute: Wasted execution time for k descendants
Memory: State snapshots for potential restoration
Economic: Potential slash (mitigated by cascade exemption)
Expected Rollback Cost:
For P(failure) = 0.02 (2% failure rate) and k = 3 average descendants:
This modest overhead is typically recovered through latency savings.
7.2.2 Memory Overhead
The system maintains additional state:
DependencyGraph: O(V + E) for graph structure
CommitmentLedger: O(V) for commitment records
ProofDeferralManager: O(V) for queued proofs
State snapshots: O(V × snapshot_size) for rollback recovery
For typical workloads with V = 1000 active tasks and 1KB per commitment:
7.2.3 Coordination Overhead
Component interaction adds latency:
Event propagation: ~1ms per event
Lock acquisition: ~0.1ms per operation
Queue operations: ~0.01ms per operation
Total coordination overhead is typically <10ms per task, negligible compared to execution and proof generation times.
7.3 Expected Performance
Table 4b. Expected performance by scenario (T_proof = 5s, T_exec = 2s, T_confirm = 2s)
†Requires multi-parent dependency support. Not yet supported in the current single-parent implementation; included to illustrate the generalized model's ceiling.
Diamond DAGs with parallel branches achieve maximum benefit because independent branches execute and prove concurrently. The diamond DAG (A→{B,C}→D) completes B and C in parallel after A, with D starting once both finish, proof generation for B and C overlaps entirely.
Best Case: Deep pipelines with proof-dominant workloads approach 4.5× speedup asymptotically. Wide parallel DAGs can exceed this.
Worst Case: High rollback rates (>10%) can eliminate latency benefits. The system automatically falls back to sequential execution when speculation becomes counterproductive.
7.4 Impact of Evolving Proof Generation Latency
The performance analysis above uses T_proof = 5s, which reflected typical CPU-based proving in early 2025. The proof generation landscape is evolving rapidly:
Table 4c. Proof generation latency by platform (2025-2026)
For AgenC's task completion proofs, which involve a 192-byte journal and relatively simple constraint logic, GPU-accelerated proving or proof market delegation can achieve T_proof ≈ 1s. Under these conditions:
Even with fast proofs (where T_proof refers to the time required for generating a cryptographic proof and T_confirm is the time needed to verify its correctness), speculation still yields meaningful speedup because all proof generation and confirmation, except for the final task's, are concealed behind subsequent task execution (also termed pipelining, the method of overlapping the execution of multiple tasks). The speedup diminishes compared to the proof-dominant case (2.65× with T_proof=5s) because there is less sequential cost per task, but the benefit of pipelining remains as long as T_proof + T_confirm is greater than zero.
Furthermore, for complex proofs (such as ML inference verification, large dataset processing, or multi-step constraint evaluation), T_proof remains significant even with hardware acceleration, preserving speculation's full value.
Speculative execution provides speedup whenever the pipeline has depth (meaning several stages are overlapped). As hardware reduces T_proof (proof generation time) for simple circuits, the maximum achievable speedup transitions from (T_exec + T_proof + T_confirm) / T_exec (where T_exec is the task execution time) toward a lower bound of (T_exec + T_confirm) / T_exec (for example, 2.0× using our chosen parameters). The technique's peak benefit applies to scenarios with deep pipelines and workloads dominated by proof generation time.
8. Implementation
8.1 On-Chain Components (Solana/Anchor)
The on-chain program extends the existing AgenC task infrastructure with speculation support:
8.1.1 Task Account Extension
The depends_on field establishes the on-chain dependency graph, enabling verifiable dependency ordering.
8.1.2 Speculative Commitment Account
8.1.3 Instructions
create_speculative_commitment: Creates a new speculative commitment with stake bonding.
confirm_speculative_commitment: Confirms a commitment after successful proof verification.
slash_commitment: Slashes stake for invalid commitments, distributing to protocol and affected parties.
8.2 Runtime Components (TypeScript)
The runtime implementation follows the architecture described in Section 4.2:
8.3 Integration with AgenC Protocol
The speculative execution system integrates with the existing AgenC protocol through:
Task Listener: Monitors TaskCreated events for tasks with dependencies.
Proof Submitter: Wraps the standard complete_task_private instruction with deferral logic.
Event Monitor: Subscribes to on-chain events for confirmation tracking.
Agent Manager: Coordinates speculation with agent stake management.
8.4 Validation Status
The off-chain engine described in this paper is fully implemented in TypeScript with approximately 200 dedicated unit and integration tests covering the five core components. The on-chain Solana/Anchor instructions (create_speculative_commitment, confirm_speculative_commitment, slash_commitment) are specified and the integration path is defined; on-chain deployment is in progress.
The latency figures in Section 7 are theoretical derivations based on the closed-form model, not empirical measurements. End-to-end benchmarking on Solana devnet with live RISC Zero proof generation is planned as the next validation step. Until that data is available, the speedup claims should be understood as the model's prediction under the stated parameter assumptions (T_exec = 2s, T_proof = 5s, T_confirm = 2s), not as measured results.
9. Related Work
9.1 Speculative Execution in Computer Architecture
The concept of speculative execution originates in computer architecture, where processors execute instructions before knowing whether the results will be needed.
Building upon this, Tomasulo's Algorithm [4] introduced out-of-order execution with register renaming, allowing instructions to execute speculatively while maintaining program correctness through a reorder buffer.
To further improve speculative execution, Branch prediction allows processors to execute instructions beyond conditional branches, yielding significant performance improvements when predictions are accurate. Modern processors typically achieve over 95% branch prediction accuracy.
However, this powerful speculation comes with risks. Spectre and Meltdown [5,6] demonstrated that CPU-level speculation can create security vulnerabilities through side-channel attacks. Our system avoids these issues through cryptographic commitments (not caching side channels) and explicit stake-based accountability.
Ultimately, the key insight from architecture is that speculation provides multiplicative speedup when the speculated path is usually correct, and rollback costs are bounded.
9.2 Optimistic Execution in Distributed Systems
Optimistic Rollups (Arbitrum [7], Optimism [8]) follow a similar philosophy: assume transactions are valid, allow challenges within a dispute window, and verify transactions only during a dispute.
Key differences from our approach:
Rollups assume validity by default; we require eventual proof.
Rollups have multi-day challenge windows; we confirm within seconds.
Rollups rely on fraud proofs; we use validity proofs.
Optimistic Concurrency Control [9] allows transactions to execute without locking, validating at commit time, and aborting on conflicts. Our rollback mechanism shares conceptual similarities but operates at the task level rather than at the database transaction level.
Pipelining in Distributed Databases [10] overlaps query execution stages to improve throughput. Our proof deferral is analogous to pipelining, where proof generation is a distinct stage.
9.3 Agent Coordination Frameworks
FIPA Specifications [11] define abstract interaction protocols for multi-agent systems and do not provide cryptographic verification mechanisms.
Similarly, Ethereum's Account Abstraction [12] enables smart contract-based agents and encounters the same sequential verification bottleneck we address.
In contrast, Autonolas [13] provides infrastructure for autonomous services and relies on reputation rather than cryptographic proofs for correctness guarantees.
Our contribution extends these foundations by combining ZKP-based verification with speculative execution optimized for latency-critical multi-agent workflows.
9.4 Alternative Approaches to the Verification Bottleneck
Several emerging technologies offer complementary or alternative approaches to the proof pipeline latency problem. We analyze each in the context of decentralized agent coordination and compare their trade-offs with speculative execution.
9.4.1 Incrementally Verifiable Computation (IVC) and Folding Schemes
Folding schemes, introduced by Nova [16] and extended by SuperNova, HyperNova [17], and MicroNova [18], enable incrementally verifiable computation where a prover produces a proof of correct multi-step execution with constant overhead per step. Rather than generating independent proofs for each task, the prover "folds" each step's proof into the previous one via a single multi-scalar multiplication, avoiding full recursive SNARK verification at each step.
Advantages over speculative execution:
Eliminates the need for independent per-task proofs entirely
No rollback risk, as the folded proof is valid at every step
MicroNova achieves on-chain verification with O(log N) group elements [18]
The multi-agent trust boundary problem. IVC folding requires a continuous prover, each step's proof is folded into a running accumulator that the prover carries forward. In a multi-agent pipeline where Agent A executes Task 1 and Agent B executes Task 2:
Accumulator handoff requires trust. Agent B needs Agent A's internal accumulator state to fold Task 2's proof into the chain. This accumulator contains Agent A's prover-internal randomness and intermediate state. Agent A must either (a) hand over its prover secrets, a fundamental trust violation in a decentralized protocol , or (b) run all steps itself, which defeats the purpose of multi-agent coordination.
No folding across trust boundaries. The folding operation is not decomposable: one party cannot fold a step without the other party's accumulated state. There is no known construction for "trust-minimized" IVC where independent provers contribute to a shared accumulator without revealing their internal state. Split prover techniques [33] address witness partitioning but not accumulator sharing.
Homogeneous proof system requirement. All agents in a pipeline must use the identical folding-compatible constraint system (R1CS for Nova, CCS for HyperNova). AgenC's design allows agents to use any proving backend that produces a valid RISC Zero Groth16 proof , agents may run different hardware, different prover versions, or future alternative proof systems. Folding forecloses this flexibility.
No production deployment on Solana. No folding scheme has been deployed on Solana. Adapting RISC Zero's STARK-based pipeline to a folding scheme would require fundamental architectural changes to both the guest program and the on-chain verifier.
Where IVC excels. For a single agent running a multi-step pipeline internally , for example, an autonomous agent that claims and executes Tasks 1 through 5 sequentially, IVC is strictly superior to speculative execution. The agent holds the accumulator throughout, faces no trust boundary, and produces a single compact proof. However, this is not the primary use case for a decentralized coordination protocol; the interesting and difficult case is cross-agent pipelines.
Assessment: IVC is theoretically optimal for single-prover sequential computation but fundamentally inapplicable to multi-agent decentralized coordination, which is the core use case AgenC targets. The trust boundary between independent agents , the defining characteristic of decentralized coordination, is precisely where folding schemes break down and speculative execution with economic bonding provides a viable alternative.
9.4.2 Proof Composition via RISC Zero
RISC Zero's zkVM provides native proof composition through the env::verify() guest API [14], allowing one guest program to verify another RISC Zero proof as an "assumption." The recursive proving pipeline resolves these assumptions, compressing a chain of composed proofs into a single Groth16 proof for on-chain verification.
Relevance to AgenC: A "batch verifier" guest could call env::verify() for each individual task completion proof, producing one aggregated proof that verifies N task completions in a single on-chain transaction. This reduces the per-task confirmation overhead from N × T_confirm to a single T_confirm.
Advantages:
Uses AgenC's existing RISC Zero infrastructure, no proof system migration required
Reduces on-chain costs by amortizing verification across multiple tasks
Composable with speculative execution: agents speculate and generate proofs in parallel, then batch-compose proofs for submission
Limitations:
Composition adds prover overhead (each env::verify() call increases the outer proof's circuit size)
Requires all composed proofs to use the RISC Zero zkVM — cannot aggregate heterogeneous proof systems
The batch verifier introduces a coordination point that may add latency for time-critical single-task completions
Assessment: Proof composition is a natural near-term enhancement to AgenC's existing architecture and is complementary to speculative execution. The optimal design combines both: speculative execution for latency reduction during pipeline execution, proof composition for cost reduction during on-chain settlement.
9.4.3 Hybrid Optimistic/ZK Models
The OP Kailua system [19], deployed in production on BOB (the first Hybrid ZK Rollup), implements a model where transactions execute optimistically by default, with ZK proofs generated only when disputes arise or when users explicitly request fast finality.
Brevis coChain [20] extends this pattern to coprocessing: results are submitted as economic claims backed by restaked assets, with ZK fraud proofs serving as the dispute resolution mechanism. The overwhelming majority of operations never incur proof generation costs.
Comparison with speculative execution:
Assessment: Hybrid models achieve superior latency and cost by deferring proof generation entirely in the common case. However, they weaken the security model from universal validity to economic security with cryptographic fallback. For AgenC's use case, where task outputs may involve financial transactions, sensitive data processing, or high-stakes coordination, universal validity proofs provide stronger guarantees. A graduated approach is promising: use speculative execution for high-value tasks requiring cryptographic finality, and hybrid optimistic/ZK for lower-value tasks where economic security suffices.
9.4.4 Proof Markets and Delegated Proving
Decentralized proof markets, Boundless [21] (RISC Zero), Succinct Prover Network [22] (SP1), Brevis ProverNet [23], and ZkCloud [24], enable agents to outsource proof generation to specialized GPU operators who compete for proving work.
Impact on the latency calculus:
Boundless processes 542+ trillion compute cycles with 98-100% order fulfillment
SP1 Hypercube proves 99.7% of Ethereum blocks in under 12 seconds on 16 GPUs [22]
Brevis Pico Prism achieves 6.9-second average Ethereum block proving [23]
RISC Zero's R0VM 2.0 reduced Ethereum block proving from 35 minutes to 44 seconds [25]
For AgenC's relatively simple task completion proofs (192-byte journal, 260-byte seal), delegated proving to a market like Boundless could reduce T_proof from 2-10 seconds to sub-second, fundamentally changing the latency equation. When T_proof ≈ 0, speculative execution's benefit diminishes — the sequential model approaches n × (T_exec + T_confirm), which may be acceptable for many workloads.
Assessment: Proof markets are complementary to speculative execution, not alternatives. They reduce T_proof, which reduces the absolute latency but preserves the relative speedup ratio of speculative execution. The combination of speculative execution (for structural latency reduction) and proof markets (for absolute latency reduction) yields the best overall performance. However, Boundless does not yet support Solana settlement directly [21], limiting near-term applicability for AgenC.
9.4.5 Proof Aggregation
Universal proof aggregation systems, NEBRA UPA [26] on Ethereum, Aligned Layer [27] on EigenLayer, batch multiple proofs from heterogeneous sources into a single on-chain verification, reducing per-proof gas costs by 75-90%.
Relevance to AgenC: If AgenC expands to EVM chains, proof aggregation could batch multiple task completions into a single verification, amortizing cost. On Solana, the lower base verification cost (~200K compute units for Groth16) makes aggregation less critical, but it becomes valuable at scale (hundreds of concurrent task completions per block).
9.4.6 Hardware Acceleration
Custom hardware for ZK proving is advancing rapidly:
Fabric VPU [28], ASIC-class verifiable processing unit, partnered with both Polygon and RISC Zero, claims 900% more big-integer operations than GPU
UniZK [29], Unified hardware accelerator achieving 97× over CPU, 46× over GPU for end-to-end proof generation (ASPLOS 2025)
BatchZK [30], Fully pipelined GPU system achieving 259.5× throughput improvement with sub-second batch proving (ASPLOS 2025)
As hardware acceleration matures, T_proof could approach milliseconds for simple circuits, potentially eliminating the verification bottleneck entirely for many workloads. Speculative execution would remain valuable for complex proofs (ML inference verification, large dataset processing) where proving time remains significant even with acceleration.
9.4.7 Comparative Summary
Table 5. Approach comparison for multi-task proof pipelines
Our position: The verification bottleneck in multi-agent coordination is fundamentally different from the single-prover case. IVC/folding, the theoretically optimal solution for sequential computation, cannot cross the trust boundary between independent agents, which is the defining characteristic of decentralized coordination. Speculative execution addresses precisely this gap: it preserves universal validity guarantees while enabling parallel execution across trust boundaries with economic bonding as the interim security mechanism.
Speculative execution is the right approach for AgenC because it (1) works across mutually distrusting agents without requiring shared prover state, (2) uses existing RISC Zero infrastructure on Solana, (3) preserves universal validity guarantees, and (4) composes well with proof composition (for batch settlement), proof markets (for reduced T_proof), and hardware acceleration as they mature.
9.5 Speculative Execution in Consensus Protocols
Recent work has applied speculative execution to blockchain consensus itself. Proof-of-Execution [31] (ACM TODS 2025) executes transactions before consensus is reached, achieving 86% throughput improvement over standard BFT protocols. HotStuff-1 [32] introduces one-phase speculation where replicas speculatively execute and update local ledgers upon receiving a prepare-certificate.
These systems validate the core thesis of this paper, that speculative execution, with appropriate rollback mechanisms, provides significant performance benefits in blockchain settings, though they operate at the consensus layer rather than the application layer.
10. Future Work
10.1 Cross-Agent Speculation
The current system restricts speculation to single-parent dependency chains (implemented via parentTaskId), not necessarily single-agent pipelines. Cross-agent speculation-where Agent B speculates on Agent A's uncommitted output-introduces trust requirements:
Agent B must trust Agent A's commitment (or post additional bond)
Slashing distribution across agent boundaries requires careful design
Reputation systems could modulate cross-agent speculation willingness
Research directions include:
Cryptographic commitment schemes enabling cross-agent verification
Game-theoretic models for optimal cross-agent speculation policies
Trust network propagation for speculation eligibility
10.2 Adaptive Speculation Policies
Current speculation policies are static (fixed depth limits, stake ratios). Adaptive policies could:
Adjust depth limits based on observed rollback rates
Modify stake requirements based on task type risk profiles
Learn agent-specific reliability for personalized bounds
Machine learning approaches for speculation decision optimization represent a promising direction. (standard predictive modeling applied to a scheduling problem).
10.3 Proof Composition for Batch Settlement
RISC Zero's native proof composition (Section 9.4.2) enables a near-term optimization: rather than submitting n individual complete_task_private transactions, a batch verifier guest program could compose n task proofs into a single Groth16 proof, reducing on-chain verification from n × ~200K CU to a single ~200K CU transaction. This requires:
A new complete_tasks_private_batch on-chain instruction
A batch verifier guest program that calls env::verify() for each inner proof
SDK wrappers for batch proof submission
This is complementary to speculative execution: agents speculate and prove in parallel, then batch-compose completed proofs for amortized on-chain settlement.
10.4 Proof Market Integration
Integration with decentralized proof markets particularly, Boundless [21] once Solana settlement is available would, allow agents to delegate proof generation to specialized GPU operators. This could reduce T_proof from seconds to sub-second for AgenC's relatively simple task completion proofs, dramatically improving both sequential and speculative pipeline latency. Research questions include optimal delegation strategies, prover selection, and latency vs. cost trade-offs.
10.5 Competitive Task Speculation
The current analysis assumes cooperative pipelines where tasks have unique executors. In competitive task scenarios where, multiple agents race to complete the same task speculative, execution introduces additional waste: losing agents have generated proofs for outputs that will never be accepted. Future work should analyze the expected waste under competitive speculation and develop mechanisms (e.g., conditional speculation limited to one competitor per task, or pre-commitment auctions) to bound this cost.
10.6 Hardware Acceleration
Proof generation latency is rapidly decreasing through hardware acceleration:
GPU-based proving: SP1 Hypercube achieves real-time Ethereum block proving on 16 GPUs [22]; RISC Zero R0VM 2.0 reduced Ethereum block proving from 35 minutes to 44 seconds [25]
Custom ASICs: Fabric's Verifiable Processing Unit (VPU) [28] demonstrates 900% more big-integer operations than GPU, with direct RISC Zero partnership
FPGA acceleration: Succinct targets 20× speedup via FPGAs in 2026
Academic advances: UniZK [29] achieves 97× over CPU, 46× over GPU; BatchZK [30] achieves 259× throughput improvement
As T_proof approaches milliseconds, the verification bottleneck may be eliminated for simple circuits, reducing the value proposition of speculative execution for those workloads. However, complex proofs (ML inference verification, multi-step data processing) will continue to benefit from speculative parallelization.
10.7 Formal Verification
While we provide proof sketches for key invariants, full formal verification using tools like Coq or Isabelle would strengthen confidence in system correctness. Priority areas include:
Proof ordering invariant (Theorem 5.1)
Rollback completeness (Theorem 5.2)
Economic security properties under adaptive adversaries
Cascade-aware slashing fairness guarantees
11. Conclusion
This paper presented Speculative Execution with Optimistic Proof Deferral, a novel approach to reducing latency in proof-based decentralized agent coordination. By allowing downstream tasks to execute before ancestor proofs achieve finality, while maintaining strict proof ordering invariants, our system achieves 2.65-4.5× latency reduction for proof-dominant multi-task pipelines.
The key contributions include:
Formal Model: A rigorous definition of speculative commitments in task dependency graphs, with precise semantics for execution, proof deferral, and rollback. The tight latency bound (Section 7.1.2) corrects earlier simplified analyses and demonstrates stronger speedup than previously reported.
Architecture: A modular system design with five core components (DependencyGraph, CommitmentLedger, ProofDeferralManager, RollbackController, SpeculativeTaskScheduler) that can be integrated into existing agent protocols. The runtime implementation is complete and tested (~200+ dedicated tests).
Safety Guarantees: Safety Guarantees: Proof sketches for critical invariants (Appendix B) establishing that on-chain state always reflects valid dependency ordering despite out-of-order off-chain execution. Full mechanized verification in Coq or Isabelle is identified as a priority future work item (Section 10.7).
Economic Model: Exponential stake bonding with cascade-aware slashing that aligns incentives, bounds systemic risk, and provides layered attack resistance (economic + reputational) while maintaining capital efficiency for shallow speculation.
Comparative Analysis: Systematic evaluation against alternative approaches including IVC/folding schemes, proof composition, hybrid optimistic/ZK models, proof markets, and hardware acceleration (Section 9.4), establishing speculative execution as the appropriate technique for heterogeneous multi-agent coordination on Solana.
Implementation: Concrete specifications for Solana/Anchor on-chain programs and TypeScript runtime components, with the off-chain engine fully implemented and the on-chain integration path clearly defined.
The work establishes that speculative execution, long successful in hardware architectures and distributed databases, can be adapted for decentralized agent coordination while preserving the security guarantees that make such systems valuable.
As autonomous agents become increasingly prevalent in digital economies, the ability to coordinate complex multi-step workflows with minimal latency becomes essential. Speculative execution with optimistic proof deferral provides a principled approach to achieving this goal without sacrificing the trust guarantees that cryptographic verification provides.
References
[1] Tetsuo Corporation. "AgenC: A Protocol for Decentralized Agent Coordination." White Paper, 2025.
[2] J. Groth. "On the Size of Pairing-based Non-interactive Arguments." EUROCRYPT 2016, pp. 305-326.
[3] NIST. "Secure Hash Standard (SHS)." FIPS Publication 180-4, 2015. AgenC uses SHA-256 via Solana's hashv syscall for commitment hashing.
[4] R. M. Tomasulo. "An Efficient Algorithm for Exploiting Multiple Arithmetic Units." IBM Journal of Research and Development, 11(1):25-33, 1967.
[5] M. Lipp et al. "Meltdown: Reading Kernel Memory from User Space." USENIX Security 2018.
[6] P. Kocher et al. "Spectre Attacks: Exploiting Speculative Execution." IEEE S&P 2019.
[7] Offchain Labs. "Arbitrum: Scalable, Private Smart Contracts." Technical White Paper, 2020.
[8] Optimism Foundation. "Optimistic Rollups." https://optimism.io, 2021.
[9] H. T. Kung and J. T. Robinson. "On Optimistic Methods for Concurrency Control." ACM TODS, 6(2):213-226, 1981.
[10] S. Harizopoulos, V. Liang, D. J. Abadi, and S. Madden. "Performance Tradeoffs in Read-Optimized Databases." VLDB 2006.
[11] Foundation for Intelligent Physical Agents. "FIPA Agent Communication Language Specifications." https://web.archive.org/web/2023/http://www.fipa.org, 2002.
[12] Ethereum Foundation. "EIP-4337: Account Abstraction Using Alt Mempool." Ethereum Improvement Proposal, 2021.
[13] Valory AG. "Autonolas: Unified framework for off-chain services." White Paper, 2023.
[14] RISC Zero, Inc. "RISC Zero zkVM: General Purpose Zero-Knowledge Virtual Machine." https://dev.risczero.com, 2025. See also: Proof Composition documentation, https://dev.risczero.com/api/zkvm/composition.
[15] Boundless (formerly RISC Zero). "risc0-solana: Solana Verifier Router for RISC Zero Groth16 Proofs." https://github.com/boundless-xyz/risc0-solana, v3.0.0, October 2025.
[16] A. Kothapalli, S. Setty, and I. Tzialla. "Nova: Recursive Zero-Knowledge Arguments from Folding Schemes." CRYPTO 2022, pp. 359-388.
[17] A. Kothapalli and S. Setty. "HyperNova: Recursive Arguments for Customizable Constraint Systems." CRYPTO 2024.
[18] W. Zhao, S. Setty, W. Cui, and G. Zaverucha. "MicroNova: Folding-based Arguments with Efficient (On-chain) Verification." IEEE S&P 2025. ePrint 2024/2099.
[19] RISC Zero, Inc. "OP Kailua: Hybrid ZK Rollup on the OP Stack." https://risczero.com/blog/kailua-how-it-works, 2025.
[20] Brevis Network. "Brevis coChain AVS: Crypto-Economic Security with ZK Fraud Proofs on EigenLayer." https://blog.brevis.network, April 2024.
[21] RISC Zero, Inc. "Boundless: Open Proof Market." Mainnet on Base, September 2025. https://boundless.xyz.
[22] Succinct Labs. "SP1 Hypercube: Real-Time Proving with 16 GPUs." https://blog.succinct.xyz/real-time-proving-16-gpus/, 2025.
[23] Brevis Network. "Brevis ProverNet: Open Marketplace for Zero-Knowledge Proofs." https://blog.brevis.network, 2025.
[24] ZkCloud (formerly Gevulot). "Decentralized Proving Infrastructure." https://zkcloud.com, 2025.
[25] RISC Zero, Inc. "Introducing R0VM 2.0." https://risczero.com/blog/introducing-R0VM-2.0, April 2025.
[26] NEBRA. "Universal Proof Aggregation on Ethereum." https://docs.nebra.one, October 2024. Live on Ethereum mainnet and World Chain.
[27] Aligned Foundation. "Aligned Layer: Proof Verification on EigenLayer." https://whitepaper.alignedlayer.com/, 2024.
[28] Fabric Cryptography. "Verifiable Processing Unit (VPU)." https://www.fabriccryptography.com, 2025. Partnerships with Polygon Labs and RISC Zero.
[29] Y. Zhang et al. "UniZK: Accelerating Zero-Knowledge Proof." ASPLOS 2025. 97× over CPU, 46× over GPU for end-to-end proof generation.
[30] T. Lu, J. Chen et al. "BatchZK: A Fully Pipelined GPU-Accelerated System for Batched Generation of Zero-Knowledge Proofs." ASPLOS 2025. ePrint 2024/1862.
[31] S. Gupta, J. Hellings et al. "Proof-of-Execution: Low-Latency Consensus via Speculative Execution." ACM Transactions on Database Systems, 2025.
[32] D. Kang, S. Gupta, D. Malkhi, and M. Sadoghi. "HotStuff-1: Linear Consensus with One-Phase Speculation." Proc. ACM Manag. Data (SIGMOD), 2025.
[33] S. Garg, A. Goel, D. Kolonelos, S. Shiehian, and R. Sinha. "Split Prover Zero-Knowledge SNARKs." PKC 2025. ePrint 2025/373. Enables distributed proof generation by splitting the prover across parties.
[34] ePrint 2024/940. "Scalable Collaborative zk-SNARK and Its Application to Fully Distributed Proof Delegation." 128 servers achieve 30× speedup for joint proof generation.
[35] D. Boneh and B. Chen. "LatticeFold: A Lattice-based Folding Scheme and its Applications to Succinct Proof Systems." ASIACRYPT 2025. ePrint 2024/257. First post-quantum folding protocol.
Appendix A: Formal Definitions
A.1 Task Dependency Graph
Definition A.1 (Task Dependency Graph). A task dependency graph is a 6-tuple G = (V, E, σ, τ, δ, β) where:
V is a finite set of task vertices
E ⊆ V × V is a set of directed dependency edges
σ: V → Status maps vertices to execution status
τ: V → ℕ maps vertices to creation timestamps
δ: V → ℕ₀ maps vertices to speculation depth
β: V → ℕ₀ maps vertices to bonded stake (in lamports)
where Status = {PENDING, SPECULATIVE, FINALIZED, FAILED}.
A.2 Speculative Commitment
Definition A.2 (Speculative Commitment). A speculative commitment is a 7-tuple C = (v, h, r, d, b, t_create, t_expire) where:
v ∈ V is the committed task
h ∈ {0,1}^256 is the output commitment hash
r ∈ ℤ_p is the commitment salt
d ∈ ℕ₀ is the speculation depth
b ∈ ℕ₀ is the bonded stake
t_create ∈ ℕ is the creation timestamp
t_expire ∈ ℕ is the expiration timestamp
A.3 System State
Definition A.3 (System State). The system state is a tuple S = (G, L, Q, P) where:
G is the current task dependency graph
L is the commitment ledger (mapping V → C ∪ {⊥})
Q is the proof deferral queue (ordered list of (proof, ancestors))
P is the active rollback plan (or ⊥)
A.4 State Transitions
Definition A.4 (Valid State Transition). A state transition S → S' is valid iff:
No cycles are introduced in G'
All new commitments satisfy depth bounds
Proof ordering invariant is maintained
Stake constraints are satisfied
Appendix B: Proof Sketch
B.1 Proof of Theorem 5.1 (No Premature Submission)
Theorem 5.1. Under the speculative execution protocol, no proof for task v is submitted to the blockchain while any ancestor of v remains unfinalized.
Proof. We prove by examining the proof submission pathway.
Claim 1: A proof for task v enters the submission path only through ProofDeferralManager.processReadyQueue().
Evidence: By code inspection, submitProof() is only called from processReadyQueue(), which only processes proofs with status READY.
Claim 2: A proof achieves status READY only when pendingAncestors is empty.
Evidence: The state transition WAITING → READY in onAncestorConfirmed() is guarded by:
Claim 3: pendingAncestors is initialized to all unfinalized ancestors and only decremented upon ancestor finalization.
Evidence: At proof enqueue:
Removal occurs only in onAncestorConfirmed():
Conclusion: By Claims 1-3, submission occurs only when all ancestors have been finalized. Since finality events are triggered by on-chain finality, all ancestors have on-chain finality before any descendant proof is submitted. □
B.2 Proof of Theorem 5.2 (Rollback Completeness)
Theorem 5.2. If task u fails, all descendants of u are eventually rolled back.
Proof. We prove that rollbackCascade(u) reaches all descendants.
Claim 1: computeAffectedSet(u) returns all descendants of u.
Evidence: The function performs BFS starting from u's children:
By BFS completeness, all reachable nodes via child edges are visited. By definition, descendants are exactly the reachable nodes.
Claim 2: Every task in affected is rolled back.
Evidence: The algorithm iterates over all elements:
Claim 3: validateNoOrphans(affected) confirms completeness.
Evidence: Post-rollback validation:
Any missed descendant would fail this assertion.
Conclusion: By Claims 1-3, all descendants are identified and rolled back, with post-hoc validation confirming completeness. □
Appendix C: Configuration Parameters
C.1 Core Configuration
C.2 Stake Configuration
C.3 Proof Configuration
C.4 Resource Limits
C.5 Preset Configurations
Conservative:
Balanced (Default):
Aggressive:
© 2026 Tetsuo Corporation. All rights reserved.
