Cloud agents as a Witness

Explain how the Fairway Cloud Agent orchestrates off-chain compliance logic; reading KYC data, preparing witness inputs for the Midnight Compact circuit, and publishing the resulting proofs.

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

---

Witness Data Structure (Conceptual)

{
  "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.