# Architecture

Othentic Stack allows developers to **self-deploy:**

* Customized off-chain service 
* Network of Operators that run and verify arbitrary tasks

Designed to balance scalability, cost-efficiency, and security by leveraging both L1 and L2 layers.

<br>

<figure><picture><source srcset="https://4144525652-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYlSi30nrcEOossIDFFua%2Fuploads%2FuZHo2RSEBPQmn9cIDL4n%2F2Stack%20Highlevel%20Dark%20Mode.png?alt=media&#x26;token=9390fe19-d23c-467f-b797-6416e2fe3dd1" media="(prefers-color-scheme: dark)"><img src="https://4144525652-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYlSi30nrcEOossIDFFua%2Fuploads%2FJbaM9kXZhUi6ZV8BY84J%2Fimage.png?alt=media&#x26;token=20ae703e-2526-4e60-9fd4-ea96f4da06a1" alt=""></picture><figcaption></figcaption></figure>

## Key Components

### [Smart Contracts](https://docs.othentic.xyz/main/reference/contracts)

The following Smart Contracts are deployed during initialization:

#### Layer 1

The governance layer is deployed on L1 (**Ethereum**) to ensure the highest level of security, integrate with the shared security protocol contracts, and manage critical governance operations.

<table><thead><tr><th width="246.0234375">Contract</th><th>Description</th></tr></thead><tbody><tr><td><a href="../reference/contracts/avs-governance">AVS Governance</a></td><td>Manage operators and governance policies.</td></tr><tr><td><a href="../../reference/contracts/message-handlers#l1-message-handler">L1MessageHandler</a></td><td>Cross-chain messaging contract to broadcast messages to L2 via AVS governance.</td></tr><tr><td><a href="../reference/contracts/treasury">L1AvsTreasury</a></td><td>Manage rewards and handling protocol fee.</td></tr></tbody></table>

#### Layer 2

The task verification layer is deployed on L2 (or Multichain) to minimize operational costs while maintaining availability, high throughput, and low latency. L2s provide a faster and cost-effective environment for handling task submissions and attestations.

<table><thead><tr><th width="250.1484375">Contract</th><th>Description</th></tr></thead><tbody><tr><td><a href="https://github.com/Othentic-Labs/core-contracts/blob/main/src/NetworkManagement/L2/AttestationCenter.sol">AttestationCenter</a> </td><td> Manages verification and historical footprint. </td></tr><tr><td><a href="https://github.com/Othentic-Labs/core-contracts/blob/main/src/NetworkManagement/Common/OBLS.sol">OBLS</a></td><td>Implements Multisig operations and handles BLS signature aggregation.</td></tr><tr><td><a href="https://github.com/Othentic-Labs/core-contracts/blob/main/src/NetworkManagement/L2/L2MessageHandler.sol">L2MessageHandler</a></td><td>Complementary to <code>l1MessageHandler</code> , used for communicating with L1 via Attestation center</td></tr><tr><td><a href="../reference/contracts/treasury">L2AvsTreasury</a></td><td>Manages rewards and handling protocol fee.</td></tr><tr><td><a href="../reference/contracts/internal-task-handler">InternalTaskHandler</a> </td><td>Manages and handles <a href="../learn/advanced-concepts/internal-tasks">Internal Tasks</a>.</td></tr></tbody></table>

***

### [Operator Roles](https://docs.othentic.xyz/main/learn/core-concepts/operator-roles)

The service is distributed over a set of **Operators** who run various roles:

<table><thead><tr><th width="174.0390625">Role</th><th width="498.015625">Responsibility</th></tr></thead><tbody><tr><td><a href="../../learn/core-concepts/operator-roles#performers">Performer</a></td><td>Execute off-chain tasks and generate a <a href="../learn/core-concepts/tasks/proof-of-task">Proof-of-Task</a>.</td></tr><tr><td><a href="../../learn/core-concepts/operator-roles#attesters">Attester</a></td><td>Validate the work of Performers and cast attestations.</td></tr><tr><td><a href="../../learn/core-concepts/operator-roles#aggregators">Aggregator</a></td><td>Collect attestations, aggregate signatures, and submit the final result on-chain.</td></tr><tr><td><a href="../../learn/core-concepts/operator-roles#bootstrap-nodes">Bootstrap Node</a></td><td>Serve as initial points of contact for peers joining the network.</td></tr></tbody></table>

***

### Consensus Engine

The **Othentic Consensus Engine** enables scalable off-chain task execution with full traceability, ultimately delivering validated results on-chain. The Engine enables the execution and validation of arbitrary computational tasks over a distributed set of nodes (referred to as Operators).&#x20;

<figure><picture><source srcset="https://4144525652-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYlSi30nrcEOossIDFFua%2Fuploads%2FWvbdvQDgctCodko8vPah%2Fconsensus%20dark%20mode.png?alt=media&#x26;token=f83e70c9-a9c0-4897-8fc8-6d2624c78416" media="(prefers-color-scheme: dark)"><img src="https://4144525652-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FYlSi30nrcEOossIDFFua%2Fuploads%2FBJZuvSNaa0HMMz8JE5q0%2Fimage.png?alt=media&#x26;token=0259da0e-bf1e-439e-8a8b-7ed4f637295e" alt=""></picture><figcaption></figcaption></figure>

The consensus scheme:

{% stepper %}
{% step %}

### Task Execution

When a task is [triggered](https://docs.othentic.xyz/main/learn/core-concepts/tasks/triggers), a [**Performer**](https://docs.othentic.xyz/main/learn/core-concepts/operator-roles#performers) node executes the task, then generates a [Proof-of-Task](https://docs.othentic.xyz/main/learn/core-concepts/tasks/proof-of-task) and submits it to the AVS network.

* The Performer node is selected via a [Leader Election](https://docs.othentic.xyz/main/learn/advanced-concepts/leader-election) mechanism which can be customized by the developer.
* Developers can configure multiple [Task Definitions](https://docs.othentic.xyz/main/learn/core-concepts/tasks/task-definitions) with custom logic based on their use cases.
  {% endstep %}

{% step %}

### Task Validation

[**Attester**](https://docs.othentic.xyz/main/learn/core-concepts/operator-roles#attesters) nodes validate the Proof-of-Task submitted by the Performer, casting BLS-signed attestations.

The weight of their attestation - proportional to the amount of (re)staked assets - is called [Voting Power](https://docs.othentic.xyz/main/learn/core-concepts/voting-power), and determines the influence of an Attester over the consensus process.&#x20;
{% endstep %}

{% step %}

### Aggregation

Finally, an [**Aggregator**](https://docs.othentic.xyz/main/learn/core-concepts/operator-roles#aggregators) node collects all valid attestations cast by operators and monitors for the quorum:

* <mark style="color:green;">**Task Approval**</mark>: >⅔ of total network voting power attests **"valid"**
* <mark style="color:red;">**Task Rejection**</mark><mark style="color:red;">:</mark> >⅓ of total network voting power attests **"invalid"**

Once quorum is reached, the Aggregator aggregates all the attestations and submits an on-chain transaction to the AttestationCenter contract to finalize the task.
{% endstep %}

{% step %}

### Verification and Finality

The [**AttestationCenter**](https://docs.othentic.xyz/main/reference/contracts/attestation-center) smart contract plays a key role in verifying the off-chain execution and maintaining a transparent on-chain record of all activities.

When the [`submitTask`](https://docs.othentic.xyz/main/reference/contracts/attestation-center#task-submission) transaction is executed, the AttestationCenter contract verifies the aggregated signature submitted by the Aggregator, and if valid, the task is successfully processed by the contract and finalized onchain.
{% endstep %}
{% endstepper %}

***

## Business Logic&#x20;

Developers implement two primary services:

### [Execution Service](https://docs.othentic.xyz/main/learn/core-concepts/execution-service)

The Execution Service runs on **Performer nodes** and is responsible for **executing Tasks** and generating a [**Proof-of-Task**](https://docs.othentic.xyz/main/learn/core-concepts/tasks/proof-of-task).

This service is responsible for:

* Task execution&#x20;
* Proof generation
* Submitting the task via the [`sendTask`](https://github.com/Othentic-Labs/simple-price-oracle-avs-example/blob/main/Execution_Service/src/dal.service.js#L22) JSON-RPC call to the AVS network

A Proof-of-Task could be the result of a calculation, a ZK proof, the CID of a JSON on IPFS, etc.

Task Validation implementation should be able to use this proof to attest to task validity.

### [Validation Service](https://docs.othentic.xyz/main/learn/core-concepts/validation-service)

The Validation Service runs on **Attester nodes** and is responsible for **verifying the validity** of a Task execution submitted by a Performer.

The Attester:

* Receives the task
* Uses the Validation Service API endpoint at `/task/validate` to verify the `proofOfTask`

This is similar to how the Consensus Client communicates with the Execution Client in Ethereum.

***

## [Peer-to-peer Networking](https://docs.othentic.xyz/main/learn/advanced-concepts/p2p-networking)

The peer-to-peer layer is responsible for establishing and maintaining a secure and efficient communication channel between network nodes, including **peer discovery** and **message propagation**.

The layer utilizes signature-based authentication to manage peer connectivity and handshaking, ensuring that only valid peers are able to communicate.

#### Additional Features

* [Custom messaging](https://docs.othentic.xyz/main/user-guide/network-management/custom-messaging)
* [Auth layer](https://docs.othentic.xyz/main/learn/advanced-concepts/p2p-networking/auth-layer)
* [Metrics and monitoring](https://docs.othentic.xyz/main/learn/advanced-concepts/p2p-networking/metrics-and-monitoring)
* [Persistent storage](https://docs.othentic.xyz/main/learn/advanced-concepts/p2p-networking/persistent-storage)


---

# 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.othentic.xyz/main/welcome/architecture.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.