# Contract & Execution Flow

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXe5fXg96hmqxmmZsk8O8Cqx6s7g1Wam9LZFb6Gl5_-5nxhrDZnAvli18pM4qXrqE1DYdGGEo1NofH7YEwgnFjmzwmmGGO0fatzLSRgjGC2yZD_qnoAafAn2DJ3ZCZQMsHAfA6YKRw?key=S_AVxe4Pa4t7GMdXHRa1L20C" alt=""><figcaption></figcaption></figure>

### Core Smart Contract Modules

LazAI’s Verified Computing system consists of the following core contract modules:

<table data-header-hidden><thead><tr><th width="181.2421875"></th><th></th></tr></thead><tbody><tr><td><strong>Contract</strong></td><td><strong>Responsibility</strong></td></tr><tr><td>Verifier Contract</td><td>Core validator that receives proofs from the VSC and verifies TEE signatures, ZK proofs, or OP-based fraud evidence on-chain.</td></tr><tr><td>VSC Coordinator</td><td>Middleware that aggregates proofs from TEE nodes, including optional ZK/OP proofs, and submits them to the Verifier contract.</td></tr><tr><td>Challenger Registry</td><td>Maintains a list of Quorum-elected challenger nodes and tracks their activity, reputation, and rewards.</td></tr><tr><td>ExecutionRecord</td><td>Stores metadata of each computation task, including result hash and verification status.</td></tr><tr><td>Settlement Contract</td><td>Handles reward allocation and slashing based on verification results, impacting DAT ownership and value.</td></tr></tbody></table>

### Verifier Contract Interface&#x20;

`interface IVerifier {`

&#x20;   `function submitTEEProof(`

&#x20;       `bytes calldata taskId,`

&#x20;       `bytes calldata resultHash,`

&#x20;       `bytes calldata teeSignature,`

&#x20;       `bytes calldata attestationReport`

&#x20;   `) external;`

&#x20;   `function submitZKProof(`

&#x20;       `bytes calldata taskId,`

&#x20;       `bytes calldata zkProof,`

&#x20;       `bytes calldata publicSignals`

&#x20;   `) external;`

&#x20;  `function submitFraudProof(`

&#x20;       `bytes calldata taskId,`

&#x20;       `bytes calldata evidence,`

&#x20;       `address challenger`

&#x20;   `) external;`

&#x20;   `function verifyResult(bytes calldata taskId) external view returns (bool valid);`

`}`

### Task Lifecycle Flow Diagram

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXee5cn_vbidoYVGKIrZDSuItUIOV8FbgPvETAAwsQeN1la19oVxnnpDGuY40oigD2pRfx63bkuaMKdoN4YMUKnfL46uCwpaPUEB7pVO9rVzuxR618SQ7Tn7e2wz-237DdHFzO5SMw?key=S_AVxe4Pa4t7GMdXHRa1L20C" alt=""><figcaption></figcaption></figure>

### Full Execution Lifecycle

This section outlines the step-by-step process for verifiable execution under each supported mode: TEE, TEE+ZK, and OP. Each flow ensures secure and auditable AI computation within the LazAI framework.

#### Step 1: Task Submission by iDAO

The iDAO initiates a computation task via an off-chain UI or dApp, sending it to the VSC for orchestration.

**Submitted Fields:**

* **taskId:** Unique hash for the task;
* **dataRef:** Dataset reference (e.g., IPFS, Arweave hash);
* **modelId:** The model or Agent identifier to execute;
* **params:** Inference or training parameters;
* **verifyMode:** Enum specifying TEE, TEE+ZK, or OP.

The VSC stores this metadata and assigns the task to eligible TEE nodes.

#### Step 2: Secure Execution Inside TEE

The assigned TEE Worker Node performs the task inside an isolated enclave:

**In-Enclave Process:**

1. Initialize environment using the specified dataset and model;
2. Run computation (e.g., forward pass, token prediction, classification);
3. Generate resultHash from the output;
4. Sign the result using TEE’s private key;
5. Attach remote attestation report.

**Depending on verifyMode, the node additionally:**

* Generates a ZK-SNARK proving the correctness of the computation without revealing input/output (for TEE+ZK mode);
* Prepares a Fraud-Proof-ready execution trace, hashed and stored off-chain (for OP mode).

**Security Guarantees:**

* Execution is isolated and tamper-resistant;
* Signed results are cryptographically bound to the specific TEE environment.

#### Step 3: VSC Aggregation and Proof Packaging

Once execution is complete, the VSC (Verifiable Service Coordinator) aggregates the following:

<table data-header-hidden><thead><tr><th width="199.859375"></th><th width="175.33984375"></th><th></th></tr></thead><tbody><tr><td><strong>Data</strong></td><td><strong>Included When</strong></td><td><strong>Purpose</strong></td></tr><tr><td>TEE Signature</td><td>Always</td><td>Confirms execution occurred inside TEE</td></tr><tr><td>ZK Proof</td><td>TEE+ZK only</td><td>Proves result validity without exposing data</td></tr><tr><td>OP Trace Hash</td><td>OP only</td><td>Enables later challenge by a third party</td></tr><tr><td>Execution Metadata</td><td>Always</td><td>Includes modelId, dataRoot, execution timestamp, etc.</td></tr></tbody></table>

The VSC then formats this package and submits it as a transaction to the Verifier Contract on LazChain.

#### Step 4: On-Chain Verification by Verifier Contract

The Verifier Contract receives the task package and performs the following steps:

**TEE Mode**

* Verifies the **TEE signature** using trusted attestation keys;
* Validates that resultHash and attestation correspond to the original request;
* Marks task as **verified** and stores the output hash on-chain.

**TEE + ZK Mode**

* Verifies the **TEE signature** as above;
* Executes on-chain ZK verifier to validate the **ZK-SNARK proof**;
* Records both resultHash and proofResult in ExecutionRecord.

**OP Mode**

* Stores the result and OP Trace Hash;
* Opens a **challenge window (**&#x65;.g., 12–24 blocks) for registered challengers to submit fraud claims;
* If no valid fraud proof is submitted within the window, the result is finalized as valid.

#### Step 5: Post-Verification Hooks

**Once verification is complete:**

* The **ExecutionRecord** module stores taskId, verification status, resultHash, and timestamp;
* The **Settlement Contract**:
  * Increases or adjusts DAT value for contributing iDAOs;
  * Releases access credits or rewards based on usage;
  * Optionally triggers stake updates or slashing (in case of OP fraud).

All results are publicly queryable and indexed on LazChain for audit, traceability, and downstream data monetization.

### Module-to-Module Interaction Summary

<table data-header-hidden><thead><tr><th width="125.94140625"></th><th width="112.37890625"></th><th width="285.65234375"></th><th></th></tr></thead><tbody><tr><td><strong>Source</strong></td><td><strong>Target</strong></td><td><strong>Data Transmitted</strong></td><td><strong>Purpose</strong></td></tr><tr><td>iDAO</td><td>VSC</td><td>taskId, modelId, dataId, verifyMode</td><td>Task configuration</td></tr><tr><td>TEE Node</td><td>VSC</td><td>resultHash, signature, attestation</td><td>Secure result</td></tr><tr><td>VSC</td><td>Verifier</td><td>Proofs and metadata</td><td>On-chain validation</td></tr><tr><td>Verifier</td><td>ExecutionRecord</td><td>Status and result hash</td><td>Task tracking</td></tr><tr><td>Verifier</td><td>Settlement</td><td>valid status, DAT info</td><td>Reward or slashing</td></tr></tbody></table>

### Proving Dataset and Model Ownership

To establish clear and verifiable ownership of datasets and models within LazAI, the following protocol is implemented between iDAO users, Quorum nodes, and the LazChain infrastructure:

1. **Initial Anchoring with TEE Attestation**\
   When a user (or iDAO member) first uploads a dataset or model to a Quorum, the selected TEE Worker Node performs a cryptographic attestation by:

   1. Computing the data hash (e.g., SHA256 of the dataset or model);
   2. Binding it to the uploader’s public key or LazChain address;
   3. Signing this tuple using the TEE’s private attestation key.

2. **Ownership Registration via LazChain**\
   The Verifiable Service Coordinator (VSC) packages this attestation into a LazChain transaction, which includes:

   1. The data or model hash;
   2. The uploader’s public address;
   3. The TEE signature and timestamp.

   The Ownership Registry Contract stores this mapping, establishing an on-chain link between data hash and rightful owner.

3. **Consensus-Based Verification and Transfer**\
   All future operations involving the dataset - whether validation, licensing, delegation, or ownership transfer - must be registered as consensus-approved transactions on LazChain. This ensures tamper-proof traceability and cryptographic auditability.

4. **Ownership Query and Privacy-Preserving Claims**\
   To prove ownership, a user simply queries the on-chain registry for the binding between their address and the data hash.\
   In cases where the user must prove specific dataset properties (e.g., contains 10,000 labeled entries, complies with regulatory filters) without revealing the raw data, a Quorum node may generate a Zero-Knowledge Proof (ZKP) certifying the claim, which can then be verified on-chain.&#x20;

### Computing node

* Users can indirectly query and use encrypted data through computing nodes, including fine-tuning and inference.
* Verify that nodes control accounts that can access the data through contracts.
* Joint data analysis allows users to securely process information across multiple iDAOs.


---

# 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.lazai.network/contract-and-execution-flow.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.