> For the complete documentation index, see [llms.txt](https://docs.fairway.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fairway.global/developers/core-concepts/cloud-agents-as-a-witness.md).

# Cloud agents as a Witness

### Concept Overview

The **Fairway Cloud Agent** is the component that bridges **decentralized identity data** (stored off-chain) and **on-chain verifiable proofs**.

It **does not act as a cryptographic witness** itself; instead, it **constructs witness data** that the **Midnight Compact circuit** consumes when generating ZK-proofs.

This preserves privacy while allowing deterministic proof generation and replay verification.

***

### Roles & Responsibilities

| Function              | Description                                                                                                                                | Data Handling                                      |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------- |
| **Data Access**       | Authenticates and fetches user KYC/AML data from decentralized vaults (e.g., S3-like encrypted storage or DID-linked repositories).        | Scoped, ephemeral access; no persistence.          |
| **Proof Preparation** | Transforms KYC results into **witness inputs** (e.g., hashes of name, DOB, nationality, accreditation, `kyc_verified_at`).                 | All inputs are pre-hashed before circuit entry.    |
| **Proof Generation**  | Calls the **Midnight Compact circuit** with witness inputs to produce a ZK-proof of compliance.                                            | No raw PII in memory post-proof.                   |
| **Proof Publication** | Posts resulting proof to **Midnight’s public ledger** as a `proof UTXO`, with metadata (`midnight_ref`, `sanctions_epoch`, `fairway_sig`). | On-chain: only references and commitments.         |
| **Cross-Chain Sync**  | Updates Cardano Merkle UTXO or EVM attestation with reference to the proof (`midnight_ref`) and validity metadata.                         | Generates verifiable off-chain ↔ on-chain linkage. |

***

### Workflow

<figure><img src="/files/4AiFJQhCwkkXW6f8diTh" alt=""><figcaption></figcaption></figure>

***

### Witness Data Structure (Conceptual)

```json
{
  "address": "0xUserWallet",
  "kyc_verified_at": "2025-03-15T10:00:00Z",
  "claims": ["KYC2_OK", "EU_RESIDENT"],
  "sanctions_epoch": 452,
  "risk_profile_score": 17,
  "vault_commitments": {
    "id_doc_hash": "0xaaa...",
    "selfie_hash": "0xbbbb...",
    "aml_check_hash": "0xcccc..."
  }
}

```

* The **Cloud Agent** prepares this object locally and hashes each field before passing it to the circuit.
* The **Compact circuit** then verifies that these hashes satisfy compliance rules (e.g., “EU resident”, “KYC ≥ level 2”).
* The resulting proof binds to the wallet address and timestamp, producing a **proof UTXO on Midnight**.

***

### Output Artifacts

After proof generation, the Agent publishes:

| Field             | Description                                       |
| ----------------- | ------------------------------------------------- |
| `midnight_ref`    | Reference to proof UTXO on Midnight (for audits). |
| `fairway_sig`     | Signature binding root, timestamp, and epoch.     |
| `kyc_verified_at` | Timestamp of KYC completion.                      |
| `sanctions_epoch` | Sanctions freshness indicator.                    |
| `commitment_root` | Merkle commitment of the proof data.              |

These values are propagated to:

* **Cardano** → Compliance UTXO (Merkle root + sig + metadata).
* **EVM** → EAS attestation (same fields encoded).

***

### Security & Privacy Notes

* No raw PII leaves the Vault.
* The Cloud Agent operates under **zero-trust assumptions**: verifiers on-chain confirm only cryptographic commitments and Fairway signatures.
* Proofs are immutable once written to Midnight, ensuring auditability without exposing user data.

***

### Integration with Other Components

| Layer                  | Interaction                                                  |
| ---------------------- | ------------------------------------------------------------ |
| **Vault**              | Provides raw KYC/AML data under ephemeral session.           |
| **Midnight Circuit**   | Accepts hashed witness data for ZK-proof.                    |
| **Midnight Ledger**    | Stores immutable proof record.                               |
| **Cardano/EVM Chains** | Consume `midnight_ref` + metadata for compliance validation. |
| **Trust Registry**     | (Future) manages Fairway key rotations and proof versioning. |

***

### Next Steps

* Read Midnight ZK Proofs to see how proofs are generated and referenced cross-chain.
* See Decentralized Vaults for storage structure and API behavior.
* Explore Build on Cardano and Build on EVM to see how proofs are verified on-chain.
* Review Revocation Epochs & Freshness to understand how `kyc_verified_at` and `sanctions_epoch` work together.