# Ditto Consensus

## **1. Overview**

Ditto relies on Othentic’s consensus to securely validate operations before execution.

<figure><img src="/files/NIpvlnlTxGBpdHN05fjX" alt=""><figcaption></figcaption></figure>

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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.dittonetwork.io/overview/protocol-overview/ditto-consensus.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.