AgenC Speculative Execution: Architecture Design Document
Speculative Execution is a performance optimization layer for the AgenC coordination protocol that enables agents to begin work on dependent tasks **before** th
AgenC Speculative Execution: Architecture Design Document
1. Executive Summary
Overview
Speculative Execution is a performance optimization layer for the AgenC coordination protocol that enables agents to begin work on dependent tasks before their prerequisite proofs have been fully verified on-chain. By allowing controlled, stake-backed speculation, we can dramatically reduce end-to-end latency for complex multi-task workflows while maintaining the protocol's cryptographic integrity guarantees.
Key Benefits
| Benefit | Impact |
|---|---|
| Reduced Latency | Up to 85% reduction in multi-task completion time |
| Improved Throughput | 3-5x increase in tasks processed per unit time |
| Economic Efficiency | Lower per-task gas costs through batched settlements |
| Maintained Security | Stake-based guarantees prevent abuse without sacrificing performance |
Design Principles
- Optimistic by Default, Secure by Design — Assume success, prepare for failure
- Economic Alignment — Make honest behavior profitable, dishonest behavior expensive
- Graceful Degradation — Fall back to sequential execution when speculation is unsafe
- Observability First — Comprehensive metrics for debugging and optimization
- Privacy Preservation — Speculative state never compromises ZK proof integrity
2. Problem Statement
The Latency Challenge
In the current AgenC architecture, multi-task workflows execute sequentially. Each task must:
- Be claimed by an agent
- Be executed off-chain
- Have its proof generated (ZK proof for private tasks)
- Submit proof to chain and wait for confirmation (~400ms on Solana)
- Have the proof verified on-chain
- Only then can dependent tasks begin
For complex workflows with deep dependency chains, this creates substantial latency.
Latency Analysis: Sequential vs. Speculative
Consider a typical 5-task dependency chain:
Sequential Execution Timing
| Phase | Time per Task | Tasks | Total |
|---|---|---|---|
| Claim Transaction | 400ms | 5 | 2,000ms |
| Off-chain Execution | 500ms | 5 | 2,500ms |
| ZK Proof Generation | 2,000ms | 5 | 10,000ms |
| Submit & Confirm | 400ms | 5 | 2,000ms |
| On-chain Verification | 50ms | 5 | 250ms |
| Total Sequential | 16,750ms |
Speculative Execution Timing
With speculation, tasks execute in parallel where the dependency graph allows:
| Phase | Description | Time |
|---|---|---|
| Claim T1 | Initial task | 400ms |
| Execute T1 + Start Speculative T2-T5 | Parallel execution | 500ms |
| Proof Generation (all tasks) | Parallel proofs | 2,000ms |
| Batch Submit & Confirm | Single batch | 400ms |
| Batch Verification | Amortized | 100ms |
| Total Speculative | 3,400ms |
Latency Improvement: 79.7% reduction (16,750ms → 3,400ms)
Deeper Chain Analysis
| Chain Length | Sequential (ms) | Speculative (ms) | Improvement |
|---|---|---|---|
| 1 | 3,350 | 3,350 | 0% |
| 3 | 10,050 | 4,000 | 60.2% |
| 5 | 16,750 | 4,200 | 74.9% |
| 10 | 33,500 | 4,450 | 86.7% |
The Economic Challenge
Without proper incentives, speculative execution introduces risks:
Our design addresses these through stake-based commitments and economic bonding.
3. Goals and Non-Goals
Goals
| ID | Goal | Priority | Success Metric |
|---|---|---|---|
| G1 | Reduce multi-task latency by >70% for chains of 5+ tasks | P0 | Measured via benchmark suite |
| G2 | Maintain protocol security guarantees | P0 | No new attack vectors introduced |
| G3 | Preserve privacy model integrity | P0 | ZK proofs remain unforgeable |
| G4 | Enable graceful fallback to sequential execution | P0 | 100% fallback success rate |
| G5 | Provide configurable risk tolerance | P1 | Per-agent and per-task configuration |
| G6 | Support partial speculation (some tasks speculative, some not) | P1 | Mixed-mode workflows function correctly |
| G7 | Minimize on-chain footprint | P2 | <10% additional CU cost per speculative task |
| G8 | Enable monitoring and debugging | P2 | Full observability via events |
Non-Goals
| ID | Non-Goal | Rationale |
|---|---|---|
| NG1 | Cross-program speculation | Out of scope; focus on AgenC-internal workflows |
| NG2 | Speculation across multiple chains | Future enhancement; single-chain focus for v1 |
| NG3 | Automatic agent trust scoring | Complex ML problem; deferred to v2 |
| NG4 | Speculation for disputed tasks | Too risky; disputes require verified state |
| NG5 | Zero-stake speculation | Economic alignment requires skin in the game |
| NG6 | Real-time speculation adjustment | Async batch model is sufficient for v1 |
Constraints
- Backward Compatibility — Existing tasks must work without modification
- Anchor 0.32+ Compatibility — Must use stable Anchor features
- Solana CU Limits — Operations must fit within 200k CU budget
- Privacy Cash Integration — Must work with existing privacy pool
- ZK Circuit Compatibility — No changes to existing Circom circuits
4. System Context
Where Speculation Fits
Speculative execution operates as a middleware layer between task discovery and proof submission. It does not modify the core protocol—it optimizes the execution path.
Integration Points
| Component | Integration Type | Data Flow |
|---|---|---|
| Coordination Program | Bidirectional | Task state, proof submission, claims |
| Privacy Cash | Outbound | Payment authorization after confirmation |
| Agent SDK | Bidirectional | Speculation decisions, execution results |
| Circom Circuits | Outbound | Batch proof requests |
| Event System | Outbound | Observability events |
Interaction with Existing Components
5. High-Level Architecture
Component Overview
Component Responsibilities
| Component | Responsibility | Key Interfaces |
|---|---|---|
| DependencyGraph | Build and maintain task dependency DAG | addTask(), getDependents(), getCriticalPath() |
| SpeculativeTaskScheduler | Decide which tasks to speculate on | scheduleSpeculative(), getExecutionPlan() |
| ProofDeferralManager | Queue proofs for batch generation | deferProof(), flushBatch(), getProofStatus() |
| CommitmentLedger | Track speculative commitments | recordCommitment(), confirmCommitment(), rollbackCommitment() |
| RollbackController | Coordinate failure recovery | initiateRollback(), propagateRollback(), completeRollback() |
State Transitions
6. Component Descriptions
6.1 DependencyGraph
Purpose: Builds and maintains a directed acyclic graph (DAG) of task dependencies, enabling efficient traversal and critical path analysis.
Reference: Issue #261
Key Algorithms:
- Topological Sort — Kahn's algorithm for DAG traversal
- Critical Path Method (CPM) — Identify longest dependency chain
- Parallelization Analysis — Group independent tasks for concurrent execution
Example:
typescript
const graph = new DependencyGraph();
// Add tasks with dependencies
graph.addTask(taskA);
graph.addTask(taskB);
graph.addTask(taskC);
graph.addDependency(taskA.id, taskB.id); // B depends on A
graph.addDependency(taskA.id, taskC.id); // C depends on A
// Analyze
const criticalPath = graph.getCriticalPath();
// [taskA, taskB] or [taskA, taskC] depending on durations
const parallel = graph.getParallelizableGroups();
// [[taskA], [taskB, taskC]] // B and C can run in parallel6.2 ProofDeferralManager
Purpose: Manages the deferral and batching of ZK proof generation, optimizing for throughput while maintaining proof integrity.
Reference: Issue #264
Batching Strategies:
| Strategy | Trigger | Use Case |
|---|---|---|
| Size-based | N proofs accumulated | High-throughput scenarios |
| Time-based | T milliseconds elapsed | Latency-sensitive workflows |
| Dependency-based | All deps confirmed | Complex DAG execution |
| Manual | Explicit flush call | Testing, debugging |
Proof Lifecycle:
6.3 CommitmentLedger
Purpose: Maintains an ordered, immutable record of speculative commitments, enabling audit trails and coordinated rollbacks.
Reference: Issue #266
Commitment Structure:
| Field | Example Value |
|---|---|
commitmentId | "comm_abc123..." |
taskId | "task_xyz789..." |
agentId | "agent_def456..." |
speculativeOutputHash | 0x1234... |
stakedAmount | 100_000_000 lamports (0.1 SOL) |
createdSlot | 250_000_000 |
expirySlot | 250_000_500 (~3.3 min @ 400ms/slot) |
status | PENDING |
dependsOn | ["comm_prev1...", "comm_prev2..."] |
signature | <agent_signature> |
6.4 RollbackController
Purpose: Coordinates the recovery process when speculative execution fails, ensuring consistent state across all components.
Reference: Issue #269
Rollback Propagation:
Cascade Rollback Example:
text
Initial State:
C1 (Task A) ← C2 (Task B) ← C3 (Task C)
↖ C4 (Task D)
If C2 fails verification:
1. C2 marked ROLLED_BACK
2. Find dependents: C3, C4
3. C3 marked ROLLED_BACK (depends on C2)
4. C4 marked ROLLED_BACK (depends on C2)
5. C1 remains CONFIRMED (independent)
Stake impact:
- Agent of C2: slashed (proof failed)
- Agents of C3, C4: stakes returned (cascade victims)6.5 SpeculativeTaskScheduler
Purpose: Makes intelligent decisions about which tasks to execute speculatively, balancing risk against performance gains.
Reference: Issue #271
Speculation Decision Factors:
| Factor | Weight | Description |
|---|---|---|
| Dependency Depth | 0.25 | Deeper chains benefit more from speculation |
| Historical Success | 0.20 | Agent's past speculation success rate |
| Stake Ratio | 0.20 | Stake relative to task reward |
| Task Complexity | 0.15 | Estimated proof generation time |
| Chain Confidence | 0.10 | Confidence in predecessor proofs |
| Network Conditions | 0.10 | Current Solana congestion |
Decision Tree:
7. On-Chain Components
7.1 Account Structures
Reference: Issue #273
SpeculativeCommitment Account
rust
/// On-chain record of a speculative commitment
/// PDA seeds: ["speculative_commitment", task_id, agent_pubkey]
#[account]
pub struct SpeculativeCommitment {
/// The task this commitment relates to
pub task_id: [u8; 32],
/// The agent making the commitment
pub agent: Pubkey,
/// Hash of the speculative output (commitment, not revealed)
pub output_commitment: [u8; 32],
/// Amount of stake bonded for this commitment
pub bonded_stake: u64,
/// Slot when commitment was created
pub created_slot: u64,
/// Slot after which commitment expires if not confirmed
pub expiry_slot: u64,
/// Commitments this depends on (max 4 for CU efficiency)
pub dependencies: [[u8; 32]; 4],
/// Number of active dependencies (0-4)
pub dependency_count: u8,
/// Current status
pub status: SpeculativeCommitmentStatus,
/// PDA bump seed
pub bump: u8,
/// Reserved for future use
pub _reserved: [u8; 32],
}
impl SpeculativeCommitment {
pub const SIZE: usize = 8 + // discriminator
32 + // task_id
32 + // agent
32 + // output_commitment
8 + // bonded_stake
8 + // created_slot
8 + // expiry_slot
128 + // dependencies (4 * 32)
1 + // dependency_count
1 + // status
1 + // bump
32; // _reserved
// Total: 291 bytes
}
#[derive(AnchorSerialize, AnchorDeserialize, Clone, Copy, PartialEq, Eq)]
#[repr(u8)]
pub enum SpeculativeCommitmentStatus {
Pending = 0, // Awaiting proof verification
Confirmed = 1, // Proof verified, commitment honored
RolledBack = 2, // Commitment invalidated
Expired = 3, // TTL exceeded without confirmation
Slashed = 4, // Agent stake slashed due to failure
}StakeBond Account
rust
/// Tracks stake bonded across multiple speculative commitments
/// PDA seeds: ["stake_bond", agent_pubkey]
#[account]
pub struct StakeBond {
/// The agent whose stake this tracks
pub agent: Pubkey,
/// Total stake currently bonded across all commitments
pub total_bonded: u64,
/// Maximum allowed bonded stake (set by agent)
pub max_exposure: u64,
/// Number of active commitments
pub active_commitment_count: u32,
/// Cumulative amount slashed historically
pub total_slashed: u64,
/// Cumulative successful confirmations
pub successful_confirmations: u64,
/// Last slot stake was modified
pub last_modified_slot: u64,
/// PDA bump seed
pub bump: u8,
/// Reserved for future use
pub _reserved: [u8; 31],
}
impl StakeBond {
pub const SIZE: usize = 8 + // discriminator
32 + // agent
8 + // total_bonded
8 + // max_exposure
4 + // active_commitment_count
8 + // total_slashed
8 + // successful_confirmations
8 + // last_modified_slot
1 + // bump
31; // _reserved
// Total: 116 bytes
}SpeculationConfig Account
rust
/// Protocol-level configuration for speculative execution
/// PDA seeds: ["speculation_config"]
#[account]
pub struct SpeculationConfig {
/// Authority that can update config
pub authority: Pubkey,
/// Minimum stake required per speculative commitment (lamports)
pub min_commitment_stake: u64,
/// Maximum speculation depth (dependency chain length)
pub max_speculation_depth: u8,
/// Default TTL for commitments (slots)
pub default_commitment_ttl: u64,
/// Slash percentage for failed proofs (basis points, 0-10000)
pub slash_rate_bps: u16,
/// Whether speculation is globally enabled
pub speculation_enabled: bool,
/// Minimum agent reputation score to speculate (0-100)
pub min_reputation_score: u8,
/// Protocol fee on speculative rewards (basis points)
pub speculation_fee_bps: u16,
/// PDA bump seed
pub bump: u8,
/// Reserved for future use
pub _reserved: [u8; 32],
}
impl SpeculationConfig {
pub const SIZE: usize = 8 + // discriminator
32 + // authority
8 + // min_commitment_stake
1 + // max_speculation_depth
8 + // default_commitment_ttl
2 + // slash_rate_bps
1 + // speculation_enabled
1 + // min_reputation_score
2 + // speculation_fee_bps
1 + // bump
32; // _reserved
// Total: 96 bytes
}7.2 Instructions
| Instruction | Description | CU Estimate |
|---|---|---|
create_commitment | Create a new speculative commitment | ~25,000 |
confirm_commitment | Confirm commitment after proof verification | ~15,000 |
rollback_commitment | Rollback a failed commitment | ~20,000 |
expire_commitments | Batch expire stale commitments (cranked) | ~50,000 |
initialize_stake_bond | Initialize stake tracking for agent | ~10,000 |
bond_stake | Bond additional stake | ~8,000 |
unbond_stake | Unbond stake (with delay) | ~8,000 |
slash_stake | Slash stake on failure | ~12,000 |
initialize_speculation_config | One-time config setup | ~15,000 |
update_speculation_config | Modify config parameters | ~10,000 |
7.3 Stake Bonding Model
Stake Bonding Rules:
- Minimum Stake: Each commitment requires
min_commitment_stake(configurable, default 0.1 SOL) - Exposure Limit: Agent cannot bond more than their
max_exposuresetting - Proportional Stake: Higher reward tasks require proportionally higher stake
- Slash Rate: Failed proofs result in
slash_rate_bps / 10000of bonded stake being burned - Unbonding Delay: Stake cannot be withdrawn for
unbonding_periodslots after last commitment
8. Data Flow
8.1 End-to-End Flow
8.2 Detailed Phase Breakdown
Phase 1: Task Discovery → Speculation Decision
Phase 2: Execution → Proof
Phase 3: Confirmation / Rollback
9. Security Considerations
Reference: Issue #275
9.1 Threat Model
| Threat | Attack Vector | Mitigation |
|---|---|---|
| Free Option Attack | Agent speculates, abandons if unfavorable | Stake bonding with slash on abandonment |
| Cascade Amplification | Intentionally fail to cause max cascade | Cascade victims not slashed, only trigger agent |
| Stake Drain | Repeatedly speculate to drain competitors | Rate limiting, minimum stake proportional to reward |
| Front-running | MEV bot front-runs proof submission | Commit-reveal scheme with output commitment |
| Proof Replay | Reuse old proof for new commitment | Task ID and slot binding in proof |
| State Manipulation | Manipulate dependency graph | On-chain verification of all dependencies |
| Griefing | Create many commitments to waste resources | Minimum stake requirement, cleanup fees |
9.2 Economic Security
Economic Invariants:
stake_required >= reward * risk_factor— Stake must exceed potential gain from cheatingslash_amount > gas_cost— Slashing must hurt more than attack costscascade_slash = 0for victims — Only trigger agent paysmin_stake > dust_threshold— Prevent spam attacks
9.3 Privacy Preservation
Speculative execution must NOT leak:
Privacy Audit Checklist:
9.4 Smart Contract Security
Anchor Security Patterns Applied:
- Signer checks — All mutations require authorized signer
- PDA validation — Seeds verified on every access
- Overflow protection — All arithmetic uses checked operations
- Reentrancy guards — State updated before external calls
- Access control — Role-based permissions for admin functions
Critical Invariants:
rust
// Commitment can only be confirmed with valid proof
require!(
verify_groth16_proof(&commitment.output_commitment, &proof),
SpeculationError::InvalidProof
);
// Slashing cannot exceed bonded amount
require!(
slash_amount <= stake_bond.total_bonded,
SpeculationError::InsufficientStake
);
// Commitment cannot be modified after confirmation
require!(
commitment.status == SpeculativeCommitmentStatus::Pending,
SpeculationError::CommitmentFinalized
);10. Performance Considerations
Reference: Issue #278
10.1 Latency Budget
| Operation | Target | Max | Notes |
|---|---|---|---|
| Dependency graph construction | <10ms | 50ms | In-memory, no I/O |
| Speculation decision | <5ms | 20ms | Cached risk profiles |
| Commitment creation TX | 400ms | 2000ms | Solana finality |
| Batch proof generation | 2000ms | 10000ms | Parallelized |
| Commitment confirmation TX | 400ms | 2000ms | Solana finality |
10.2 Throughput Targets
| Metric | Target | Sustained | Notes |
|---|---|---|---|
| Commitments per second | 50 | 30 | Per agent |
| Concurrent speculative tasks | 100 | 50 | Per agent |
| Batch size | 20 proofs | 50 proofs | Per batch |
| Rollback propagation | <100ms | <500ms | For 10-deep cascade |
10.3 Resource Utilization
Compute Units:
| Operation | CU Cost | Limit | Utilization |
|---|---|---|---|
create_commitment | 25,000 | 200,000 | 12.5% |
confirm_commitment | 15,000 | 200,000 | 7.5% |
rollback_commitment | 20,000 | 200,000 | 10% |
| Batch of 10 | 150,000 | 200,000 | 75% |
Memory:
| Component | Memory | Notes |
|---|---|---|
| DependencyGraph (1000 tasks) | ~2 MB | Adjacency list |
| CommitmentLedger (1000 entries) | ~500 KB | Indexed maps |
| ProofDeferralManager queue | ~1 MB | Bounded queue |
10.4 Optimization Strategies
- Batch Transactions — Group multiple commitment operations into single TX
- Lazy Proof Generation — Defer proof gen until batch threshold
- Parallel Proof Generation — Generate multiple proofs concurrently
- Commitment Pruning — Remove confirmed commitments after grace period
- Hot Path Optimization — Keep critical path tasks in memory cache
11. Failure Modes and Recovery
11.1 Failure Classification
| Category | Severity | Recovery | Example |
|---|---|---|---|
| Transient | Low | Auto-retry | Network timeout, rate limit |
| Recoverable | Medium | Rollback + retry | Proof verification fail |
| Permanent | High | Rollback + alert | Invalid task state |
| Critical | Critical | Circuit breaker | Chain reorg, contract bug |
11.2 Failure Scenarios
Scenario 1: Proof Verification Failure
Scenario 2: Commitment Timeout
Scenario 3: Cascade Rollback
11.3 Recovery Procedures
Automatic Recovery:
| Trigger | Action | Timeout |
|---|---|---|
| TX timeout | Retry with higher priority fee | 3 attempts |
| Rate limit | Exponential backoff | 30s max |
| Proof gen failure | Retry with fresh witness | 2 attempts |
Manual Recovery:
| Trigger | Action | Escalation |
|---|---|---|
| Contract error | Pause speculation, investigate | Page on-call |
| Repeated failures | Circuit breaker activation | Page on-call |
| Stake discrepancy | Freeze affected accounts | Security team |
11.4 Circuit Breaker
Circuit Breaker Thresholds:
| Metric | Threshold | Window |
|---|---|---|
| Consecutive failures | 5 | N/A |
| Failure rate | >20% | 5 minutes |
| Cascade depth | >10 | Single cascade |
| Slash amount | >10 SOL | 1 hour |
12. Configuration Options
Reference: Issue #285
12.1 Protocol-Level Configuration
Stored in SpeculationConfig PDA, modifiable by protocol authority:
| Parameter | Type | Default | Range | Description |
|---|---|---|---|---|
speculation_enabled | bool | true | - | Global speculation toggle |
min_commitment_stake | u64 | 100_000_000 | 1M - 10B | Min stake per commitment (lamports) |
max_speculation_depth | u8 | 5 | 1-10 | Max dependency chain depth |
default_commitment_ttl | u64 | 500 | 100-2000 | Commitment TTL (slots) |
slash_rate_bps | u16 | 1000 | 0-5000 | Slash rate (10% default) |
min_reputation_score | u8 | 50 | 0-100 | Min reputation to speculate |
speculation_fee_bps | u16 | 50 | 0-500 | Protocol fee on speculative rewards |
12.2 Agent-Level Configuration
Stored in StakeBond PDA, modifiable by agent:
| Parameter | Type | Default | Range | Description |
|---|---|---|---|---|
max_exposure | u64 | 1_000_000_000 | 0 - agent stake | Max total bonded stake |
auto_speculate | bool | false | - | Auto-accept speculation opportunities |
risk_tolerance | u8 | 50 | 0-100 | Risk appetite (affects decisions) |
min_reward_threshold | u64 | 10_000_000 | 0 - ∞ | Min reward to consider speculation |
12.3 Task-Level Configuration
Specified at task creation:
| Parameter | Type | Default | Description |
|---|---|---|---|
speculation_allowed | bool | true | Whether task can be speculatively executed |
max_speculation_depth | u8 | 3 | Max depth this task can participate in |
speculation_bonus_bps | u16 | 0 | Extra reward for successful speculation |
12.4 SDK Configuration
typescript
interface SpeculationConfig {
// Scheduling
batchSize: number; // Default: 10
batchTimeoutMs: number; // Default: 5000
maxConcurrentSpeculations: number; // Default: 20
// Risk
defaultRiskTolerance: number; // Default: 0.5 (0-1)
maxChainDepth: number; // Default: 5
// Proof generation
proofGenerationTimeoutMs: number; // Default: 30000
parallelProofWorkers: number; // Default: 4
// Recovery
maxRetries: number; // Default: 3
retryBackoffMs: number; // Default: 1000
circuitBreakerThreshold: number; // Default: 5
// Observability
metricsEnabled: boolean; // Default: true
traceEnabled: boolean; // Default: false
}12.5 Environment Variables
bash
# Core settings
AGENC_SPECULATION_ENABLED=true
AGENC_MAX_SPECULATION_DEPTH=5
AGENC_DEFAULT_RISK_TOLERANCE=50
# Performance tuning
AGENC_BATCH_SIZE=10
AGENC_BATCH_TIMEOUT_MS=5000
AGENC_PROOF_WORKERS=4
# Recovery
AGENC_CIRCUIT_BREAKER_ENABLED=true
AGENC_CIRCUIT_BREAKER_THRESHOLD=5
AGENC_MAX_RETRIES=3
# Observability
AGENC_METRICS_ENDPOINT=http://localhost:9090
AGENC_TRACE_ENDPOINT=http://localhost:431713. Future Enhancements
13.1 Short-Term (v1.1)
| Enhancement | Priority | Description |
|---|---|---|
| Adaptive batch sizing | P1 | Dynamically adjust batch size based on network conditions |
| Reputation scoring | P1 | Track agent speculation success rate |
| Speculation insurance | P2 | Optional insurance pool for cascade victims |
| Multi-proof batching | P2 | Combine proofs from multiple agents in single TX |
13.2 Medium-Term (v2.0)
| Enhancement | Priority | Description |
|---|---|---|
| Cross-agent speculation | P1 | Multiple agents collaborating on speculative chain |
| Partial speculation | P1 | Speculate on subset of task outputs |
| Speculation markets | P2 | Prediction market for speculation outcomes |
| ML-based risk profiling | P2 | Machine learning for risk assessment |
13.3 Long-Term (v3.0)
| Enhancement | Priority | Description |
|---|---|---|
| Cross-chain speculation | P2 | Speculation across multiple blockchains |
| Hardware attestation | P3 | TEE-based execution for trusted speculation |
| Recursive speculation | P3 | Speculate on speculation outcomes |
13.4 Research Areas
14. Glossary
| Term | Definition |
|---|---|
| Commitment | A cryptographic binding to a speculative task output, backed by stake |
| Confirmation | On-chain verification that a speculative commitment's proof is valid |
| Critical Path | The longest dependency chain in a task workflow |
| Cascade Rollback | When one failed commitment causes dependent commitments to also fail |
| Dependency Graph | A DAG representing task dependencies |
| Free Option Problem | The risk that agents speculate without commitment to completion |
| Output Commitment | A hash of the speculative task output (commitment scheme) |
| Proof Deferral | Delaying ZK proof generation to enable batching |
| Rollback | The process of invalidating a failed speculative commitment |
| Slash | Burning a portion of an agent's stake as penalty |
| Speculation Depth | The number of unconfirmed commitments in a dependency chain |
| Speculative Execution | Executing dependent tasks before prerequisites are confirmed |
| Stake Bond | Collateral locked by an agent to back speculative commitments |
| TTL (Time-To-Live) | Maximum time a commitment can remain pending before expiration |
| Witness | Private inputs to a ZK circuit |
Appendix A: Related Documents
Appendix B: Change Log
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0.0 | 2025-01-28 | AgenC Core Team | Initial architecture document |
Appendix C: Reviewers
This document is the authoritative reference for AgenC Speculative Execution architecture. All implementation must conform to the specifications herein.