> For the complete documentation index, see [llms.txt](https://docs.palliora.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.palliora.org/learn/architecture/how-the-compute-contract-works.md).

# How the Compute Contract Works

## Overview

A Compute Contract combines:

* On-chain economic agreement
* Guardian-based threshold decryption
* Off-chain computation
* Verifiable result publication
* Automatic fund settlement

It ensures that computation happens only after economic terms are agreed upon, and payment is released only after execution is completed.

## Architecture Components

<figure><picture><source srcset="/files/tMwc7iPDuP1qCZZupHEm" media="(prefers-color-scheme: dark)"><img src="/files/R76YTRn0r6ro2sG680fG" alt=""></picture><figcaption></figcaption></figure>

####

**User**\
Initiates the request through a dApp.

**dApp**\
Creates the agreement and a compute request transaction.

**RPC Node**\
Gateway between the dApp and the Palliora network.

**Guardian Nodes**\
Selected nodes that:

* Agree to the computation terms
* Perform threshold decryption
* Coordinate secure execution

**Guardian Service**\
Service layer responsible for:

* Threshold decryption
* Forwarding decrypted payloads to the Compute Node

**Compute Node**\
Executes the requested computation (AI model, logic, etc.).

**Data Availability Layer**\
Stores published results with recoverability and proof guarantees.

**Consensus Layer**\
Finalizes transactions, locks funds, and triggers settlement.

## Step-by-Step Flow

***

### 1. Agreement Creation

The flow begins when the User interacts with the dApp.

The dApp creates a Compute Contract Agreement Request, which defines:

* Compute the cost the user is willing to pay
* Threshold decryption fees
* List of selected Guardians
* Execution parameters

This formalizes the economic and trust assumptions before any computation begins.

***

### 2. Agreement Submission

The dApp sends the Agreement Request to an RPC Node.

The transaction:

1. Enters the transaction mempool
2. Funds are locked
3. Is broadcast to the selected Guardians

Each Guardian reviews the request and submits an Agreement confirmation. When all required Guardians agree:

* The agreement is included in a block
* A unique Agreement ID is generated

At this stage, the Compute Contract is officially established on-chain.

***

### 3. Compute Request Submission

After the Agreement is finalized:

* The dApp submits the Compute Request
* The request references the Agreement ID
* The compute payload is submitted encrypted

The encryption ensures that no single Guardian can access the payload alone, and decryption requires the agreed threshold

***

### 4. Threshold Decryption

Once the Compute Request is confirmed on-chain:

* The Guardian Service initiates threshold decryption
* A minimum number of Guardians must participate
* The payload is decrypted collectively

This guarantees privacy, shared trust, and resistance to single-node compromise

***

### 5. Execution by Compute Node

After decryption:

* The request is forwarded to the Compute Node( Trusted or Confidential)
* The computation is executed

The Compute Node only processes the decrypted payload, and does not control private keys, nor can it alter economic terms

***

### 6. Result Publication

When computation completes:

* The result is published to the Data Availability Layer

The Data Availability Layer ensures Proof of existence, Data recoverability and Verifiability

***

### 7. Consensus & Fund Release

Once the result is published:

* The Consensus Layer finalizes it
* Settlement logic is triggered
* Funds are released according to the Agreement

Payments are distributed to the Compute provider and Guardians  who participated in threshold decryption

***

### 8. Result Retrieval

While execution happens off-chain:

* The dApp polls for the result
* When available, it retrieves it from the Data Availability Layer
* The result is presented to the User

<br>