Ditto Consensus

A comprehensive walkthrough of how Ditto leverages the Othentic AVS consensus engine to authorize and settle ERC-4337 UserOperations via the DittoValidatorModule.

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.