This document provides a comprehensive overview of the Ditto Network architecture, its components, and relationships.

​
Core Components

Ditto Network is a decentralized network designed to execute custom automations with high availability and scalability.
Core Components
Shared-security protocols that create a set of validators to ensure data security and integrity. They synchronize the list of validators from the L1 (Ethereum) network.Currently, we use Symbiotic and Eigenlayer

​
System Relations

​
Committee Formation

Committee
Committee Formation Process:
1

Commit Phase

Every validator commits a random hash of private key.
2

Reveal Phase

Validators reveal their private keys and submit their votes.
3

Committee Creation

As a result, we get a seed that is used for random selection of the TESS leader. The leader will act as an aggregator of signatures from other committee members. The leader receives more rewards, as they perform more work. More about rewards will be covered in the Rewards section.
Participation RulesIf a validator who participated in the commit phase refuses to participate in the reveal phase, they will not be included in the committee.
Committee Responsibilities:
  • Execution of automations
  • Updating the validator set
  • Updating information about the next committee in Execution Chains
  • Updating information about automation execution statuses

​
Restaking Integration

Ditto Network uses a shared-security model with integration of multiple restaking networks to provide maximum protection.

Symbiotic

A shared-security network using a set of validators to ensure data security and integrity.

Eigenlayer

A restaking platform that enhances Ditto Network security through distributed validation.
In order to synchronize the list of validators from the L1 network, we developed a Restaking module on our network and abandoned the use of native Staking. This could have been avoided, but this path was chosen to simplify the architecture and reduce the number of components in the network.
Restaking integration

​
Validator Types

Default Validators

Default validators without additional conditions

Emergency Validators

Validators with enhanced conditions for emergency situations
Emergency protocol In case there are not enough validators to form a committee or insufficient votes, validators from the Emergency protocol are escalated. Such validators typically have the lowest voting power so as not to interfere with other validators, but can be used in emergency situations.
Escalation Conditions
  • Insufficient number of validators to form a committee
  • Insufficient votes to form a committee
  • Non-fulfillment of obligations by the previous committee

​
Validator Update Mechanism

Report flow
1

Report Formation

TESS participants (Active committee) form a multisig Report by quorum which contains messages for Kepler. One such message may contain information about validator updates. This approach resembles the multicall mechanism in EVM together with multisig.
2

Processing

When the message reaches Kepler, it goes to the x/committee module, which accepts reports. Within this module, a check for quorum and legitimacy of participants is performed.
3

Routing

If all checks are passed, the committee module sends messages through MessageRouter to the appropriate modules.
4

Validator Updates

Using the example of a validator update message, when it reaches the MessageRouter, it is sent to the x/restaking module, which takes a list of operators as input and updates the set of validators in the network.
Only the committee can update the validator set.

​
Full flow from Operator to Validator

1

L1 Restaking Protocol Registration

The operator first registers on one of the supported L1 restaking protocols (Symbiotic or Eigenlayer). This involves staking tokens and completing the protocol’s registration process.
2

Kepler Node Setup

The operator sets up a Kepler node by:
  • Installing and configuring the Kepler node software
  • Setting up the necessary infrastructure (server, networking, etc.)
  • Syncing with the Kepler network
3

TESS Bridge Update

The TESS network detects the new operator registration. This information is then propagated to the Kepler chain through the committee.
4

BondValidator Transaction

Once the node is operational, the operator creates and submits a BondValidator transaction to Kepler. This transaction:
  • Links the L1 operator address with the Kepler validator address
  • Initiates the process of becoming a validator
5

Validator Activation

After the BondValidator transaction is processed:
  • The operator is added to the validator set
  • They can participate in committee formation
  • They become eligible for rewards and penalties
Important Requirements
  • The operator must maintain sufficient stake in the L1 restaking protocol
  • The Kepler node must meet minimum hardware and network requirements
  • The operator must maintain high uptime and proper node operation