> For the complete documentation index, see [llms.txt](https://docs.dittonetwork.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dittonetwork.io/overview/protocol-overview/ditto-consensus.md). # Ditto Consensus ## **1. Overview** Ditto relies on Othentic’s consensus to securely validate operations before execution.
Workflow: 1. **Simulation** Simulators monitor active workflows and execute scheduled tasks. Each workflow points to a registry contract that references the corresponding TypeScript code. The code runs in a restricted environment: * Whitelisted packages only * RPC calls to supported networks * Strict execution time limits If the code returns calldata, the Performer proposes a task result (in Ditto: approval of a UserOperation) and produces a proofOfTask. 2. **Attestation** Attesters independently validate the result against local policy. They BLS-sign an approval or rejection, weighted by their restaked voting power. 3. **Aggregation** An Aggregator collects signatures, monitors quorum thresholds, and aggregates them into a single BLS signature. 4. **On-chain Verification** The AttestationCenter contract verifies the aggregated signature on-chain using OBLS (Optimized BLS verification). 5. **Authorization** Ditto consumes this consensus output inside the DittoValidatorModule, authorizing the UserOperation if consensus confirms validity. Consensus thresholds: * Approval → >66% of total voting power signs approval * Rejection → ≥33% of total voting power signs rejection * Unresolved → No quorum, task remains pending ## **2. Roles in Consensus** * Performer * Finds workflows that need execution * Simulates workflow execution * Creates a tasks and submits them for attester validation * Attesters * Validate the task and its proofs according to Ditto session policies * Approve or reject by signing with BLS * Voting power is proportional to the restaked balance * Aggregator * Collects BLS signatures from attesters * Verifies quorum thresholds * Aggregates signatures and submits the final proof to the Attestation Center * Attestation Center * Receives the aggregated proof * Submits the task execution result to the target chain * Executes workflow logic via a task submission hook ## **3. Keys and Security Model** Operators use a dual-key design: * Controller key (ECDSA, Safe) * On-chain actions: registration, submissions, rewards * Financially exposed * Consensus key (BLS) * Off-chain attestations and P2P auth * Cannot move funds ## **4. Networking** * libp2p + Gossipsub pub/sub network * Message flow: Performer → gossip proofOfTask → Attesters → signed votes → Aggregator → on-chain submission Network types: * Permissionless: any restaker with stake * Whitelisted: governance-approved operators only ## **5. On-chain Contracts** Ethereum (L1): * Governance & operator staking * Cross-layer messaging for registrations, slashing, rewards Task Chain (L2, e.g., Base): * AttestationCenter * Verifies aggregated BLS sigs with OBLS * Applies quorum rules, enforces slashing/rewards * OBLS (Optimized BLS) * Efficient verification of aggregates * Tracks operator sets and voting power * InternalTaskHandler * Syncs voting power from L1 * Maintains OBLS registry consistency ## **6. Voting Power** * Proportional to restaked assets * Synced from L1 → L2 dynamically * Governance can define per-task quorum rules ## **7. Ditto Task Definition** Ditto defines UserOpValidation tasks. These tasks request validation of proposed UserOperations against Ditto session policies. Configurable parameters: * Minimum voting power per attester * Max attesters per task (latency/gas cap) ## **8. Attested Message Format** Operators sign a standardized EIP-712 digest: * userOpHash — canonical ERC-4337 hash * smartAccount — Ditto account submitting the op * sessionKey — authorized session key * sessionNonce — replay protection * validAfter / validUntil — optional time bounds * targetChainId — cross-chain replay protection ## **9. End-to-End Flow** 1. Trigger → UserOperation constructed 2. Performer → produces proofOfTask 3. Attesters → validate + sign votes 4. Aggregator → collects sigs, aggregates on quorum 5. On-chain → AttestationCenter + OBLS verify → AC hook → EntryPoint → Ditto Validator Module → executes transaction ## **10. Slashing & Challenges** * Performer slashing → if consensus rejects * Attester slashing → if votes contradict finalized consensus * Challenge system → third parties can prove misbehaviour, claim part of slashed stake ## **11. Ditto Signing Model** * Attesters sign UserOpConsent (EIP-712 structured) * Aggregated BLS signature + attester IDs submitted * DittoValidatorModule verifies signature * EntryPoint executes authorized transaction ## **12. Failure Modes** * No quorum → UserOp unauthorized * Byzantine attesters → slashed if provably malicious * Operator churn → voting power synced to reflect reality ## **13. Coming soon: Stateless Workflow for Vault Curators** This model guarantees that vault automations are transparent, reproducible, and consensus-driven, while removing reliance on mutable off-chain infrastructure. 1. **Policy Updates** If the curator changes the policy, it must be done publicly through the registry. All Ditto operators automatically discover and enforce the updated code, ensuring consistent execution across the network. 2. **Session Creation** A session is created pointing to the curator’s specified policy. This policy defines the rules under which automations are authorized. 3. **Vault Integration** The vault installs the ERC-7579 DittoValidatorModule, enabling automated validation and execution of UserOperations against the published workflow. 4. **Workflow Publication** Curators publish compiled workflow code into the Ditto Automation Registry. This code must adhere to Ditto’s enforced runtime restrictions (whitelisted packages, RPC-only access, execution time limits). This model guarantees that vault automations are transparent, reproducible, and consensus-driven, while removing reliance on mutable off-chain infrastructure.