# Getting Started with the Fairway

Welcome to **Fairway Developer Documentation**.

Fairway provides a decentralized compliance infrastructure that bridges **institutions** and **DeFi protocols** through **identity proofs**, **zero-knowledge verification**, and **standards-based integrations** across **Cardano, Midnight, and EVM**.

***

### Who Should Read This?

* **Smart Contract Developers** → integrate compliance gates into your dApp.
* **Protocol Architects** → design yield, RWA, and liquidity strategies that satisfy institutional requirements.
* **Compliance Teams** → understand how Fairway workflows meet KYC/AML standards without exposing PII.

***

### Where to Start (coming soon)

***

### Next Steps

1. What is Fairway? → [Learn the core architecture.](https://docs.fairway.global/~/revisions/rnSjZBEQmp5ZhwBkzR4G/developers/readme/what-is-fairway)
2. Concepts → [Deep dive into identity proofs, vaults, and trust registries.](https://docs.fairway.global/~/revisions/rnSjZBEQmp5ZhwBkzR4G/developers/core-concepts)
3. APIs & SDKs → [Start coding with Fairway’s endpoints and SDK.](https://docs.fairway.global/~/revisions/rnSjZBEQmp5ZhwBkzR4G/developers/apis-and-sdks)

***

### Security & Compliance Notes

{% hint style="danger" %}
Never store raw PII on-chain. Use proofs, salted commitments, or proof references.
{% endhint %}

{% hint style="info" %}
Fairway’s workflows align with **GDPR**, **eIDAS 2.0**, and evolving **AML directives**.

Our principle: **compliance without surveillance**.
{% endhint %}


# What is Fairway?

Fairway is a **decentralized compliance infrastructure** for making **KYC/AML checks programmable** across **Cardano, Midnight, and EVM,** without putting PII on-chain.

We store KYC data in **decentralized off-chain storage** (the “Vault”), use a **Fairway Cloud Agent** via API with a **Witness** to generate a **Midnight ZK-proof** *bound to a specific wallet address*, and record that proof on **Midnight’s public ledger**.

A reference to that Midnight proof (the **proof UTXO**) is then **embedded in Merkle trees** on Cardano and/or EVM, alongside Fairway’s signature and the user’s eligibility flags. dApps verify **Merkle membership + Fairway signature + epoch freshness**, and can later **audit** the referenced Midnight UTXO.

***

### Why It Matters

* **For Developers** → add a single eligibility check (Merkle inclusion + signature verify) to your validator/contract.
* **For Institutions** → get auditability (via Midnight proof references) without handling raw PII on-chain.
* **For Users** → prove once, reuse across chains; no document leakage.

***

### How It Works

<figure><img src="https://3812774301-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlfDULdwa6BuKx0DZyvBO%2Fuploads%2FLy6idR6LvTNEvLT4gDGr%2Fimage.png?alt=media&amp;token=d975356b-6c64-40fa-972e-8e45bd16aa76" alt=""><figcaption></figcaption></figure>

**Core components**

* **Vault (decentralized storage)** — holds KYC documents/PII **off-chain**.
* **Cloud Agent** — verifies inputs, runs Witness logic, and **generates ZK-proofs on Midnight** bound to the user’s wallet.
* **Midnight proof UTXO** — immutable record of the ZK result on Midnight’s public ledger.
* **Merkle Trees (Cardano & EVM)** — compact allowlists of **wallet → claims/flags + midnight\_ref**, signed by Fairway.
* **Policy Engine** — dApp-side rule evaluation (YES/NO) based on Merkle membership + epoch freshness.

***

### Merkle Leaf (Cardano/EVM) — canonical fields

```json
{
  "address": "addr1... | 0x...",
  "claims": ["KYC1_OK", "EU_RESIDENT"],
  "midnight_ref": "0x<txid>#<index>",
  "epoch": 391,
  "fairway_sig": "sig(fairway_key, hash(root || epoch || midnight_ref))"
}

```

**Verifier MUST:**

1. Verify **Merkle membership** of `address` with the on-chain root.
2. Verify **Fairway signature** over `(root, epoch, midnight_ref)` using the chain-appropriate key.
3. Enforce **epoch freshness** (revocation).
4. (Optional, for audits) Resolve `midnight_ref` on Midnight to validate provenance.

> EVM note: you can integrate via (A) Merkle allowlist guard or (B) ERC-3643 adapter that internally checks Fairway eligibility. Both carry the midnight\_ref for auditability.

***

### Key Principles

* **No PII on-chain** — only commitments, signatures, and references.
* **Auditability by reference** — every Merkle leaf links to a **Midnight proof UTXO**.
* **Composable** — same proof powers Cardano and EVM integrations.

***


# Quickstart (Cardano, EVM)


# Sandbox & Test Credentials


# 🔍 Core Concepts

### Overview

Core concepts explain the building blocks of Fairway’s decentralized compliance infrastructure.

They are chain-agnostic in design, but tailored to **Cardano, Midnight, and EVM** in implementation.

Concepts:

* [Identity proofs (Cardano)](https://docs.fairway.global/~/revisions/65lkfXxYSTHA07mfx5hu/developers/core-concepts/identity-proofs-cardano)
* [Identity proofs (EVM)](https://docs.fairway.global/~/revisions/65lkfXxYSTHA07mfx5hu/developers/core-concepts/identity-proofs-evm)
* [Zero-Knowledge Proofs (Midnight)](https://fairway.gitbook.io/docs/~/revisions/T7QbPummS3rtxio8EvUm/getting-started/core-concepts/zero-knowledge-proofs-midnight)
* [Decentralized vaults](https://docs.fairway.global/~/revisions/65lkfXxYSTHA07mfx5hu/developers/core-concepts/decentralized-vaults)
* [Trust registries](https://docs.fairway.global/~/revisions/65lkfXxYSTHA07mfx5hu/developers/core-concepts/trust-registries)
* [Revocation Epochs & Freshness](https://docs.fairway.global/~/revisions/65lkfXxYSTHA07mfx5hu/developers/core-concepts/revocation-epochs-and-freshness)


# Identity Proofs (Cardano)

Here we explain how Fairway encodes KYC/AML eligibility on Cardano using a single UTXO with a Merkle root, Fairway signature, a verification timestamp, and a reference to a Midnight proof UTXO.

### Background

Instead of minting identity tokens per user (e.g., CIP-113 or NFTs), Fairway maintains a **canonical Compliance UTXO** that contains:

* `merkle_root` → commitment to all compliant addresses + claims.
* `sanctions_epoch` → global counter for sanctions/risk updates.
* `fairway_sig` → Fairway’s signature binding root + epoch + Midnight ref.
* `midnight_ref` → pointer to the ZK-proof UTXO on Midnight (audit trail).

Each **Merkle leaf** represents a user and includes:

* `address` → wallet identifier.
* `claims` → e.g., `KYC2`, `EU_RESIDENT`.
* `kyc_verified_at` → timestamp of last KYC check.

Eligibility is checked by proving **Merkle membership** and verifying both:

* **Fairway signature** over the Compliance UTXO state.
* **Freshness conditions** (timestamp vs. sanctions epoch).

***

### Data Model

#### UTXO Datum

```json
{
  "merkle_root": "0xabc123...",
  "sanctions_epoch": 452,
  "midnight_ref": "0xdeadbeef#0",
  "fairway_sig": "sig(fairway_key, hash(merkle_root || sanctions_epoch || midnight_ref))"
}

```

#### Merkle Leaf

```json
{
  "address": "addr1...",
  "claims": ["KYC2", "EU_RESIDENT"],
  "kyc_verified_at": "2025-03-15T10:00:00Z"
}

```

***

### Flow

```mermaid
sequenceDiagram
  participant Vault as Decentralized Storage (PII)
  participant Agent as Fairway Cloud Agent
  participant Midnight as Midnight Proof UTXO
  participant Cardano as Compliance UTXO
  participant User as Wallet
  participant dApp as Protocol Validator

  Vault->>Agent: Scoped KYC read
  Agent->>Midnight: Generate & post ZK proof (proof UTXO)
  Agent->>Cardano: Update Merkle root + sanctions_epoch + Fairway sig
  User->>dApp: Submit Merkle proof {address, claims, kyc_verified_at}
  dApp->>Cardano: Verify Merkle membership, Fairway sig, sanctions_epoch
  dApp->>User: Access granted if valid

```

***

### Validator Pseudocode (Aiken)

```
validator checkEligibility {
  fn is_valid(ctx: ScriptContext, proof: MerkleProof, leaf: Leaf, max_age: Int) -> Bool {
    let utxo = get_utxo(ctx, FAIRWAY_UTXO_REF)

    // 1. Verify Merkle proof
    let ok_proof = verify_merkle(proof, utxo.datum.merkle_root)

    // 2. Verify Fairway signature
    let payload = hash(utxo.datum.merkle_root || utxo.datum.sanctions_epoch || utxo.datum.midnight_ref)
    let ok_sig = verify_signature(FAIRWAY_PUBKEY, payload, utxo.datum.fairway_sig)

    // 3. Check sanctions epoch freshness
    let ok_epoch = utxo.datum.sanctions_epoch == current_sanctions_epoch()

    // 4. Check KYC recency (dApp-defined)
    let age = ctx.tx.now - leaf.kyc_verified_at
    let ok_kyc = age <= max_age

    ok_proof && ok_sig && ok_epoch && ok_kyc
  }
}

```

* `max_age` is defined by the **protocol/institution** (e.g., 180 days).
* The validator never opens raw PII.
* `midnight_ref` links to a verifiable ZK proof on Midnight for audits.

***

### Benefits

* **Compact** → one UTXO anchors all compliant users.
* **Flexible** → institutions define their own `max_age` for KYC proofs.
* **Auditable** → `midnight_ref` links back to ZK proof.
* **Compliant** → sanctions freshness via epoch, KYC recency via timestamp.
* **Composable** → eligibility checks slot directly into LP/staking validators.

***

### Next Steps

* [Learn Revocation Epochs & Freshness](https://docs.fairway.global/~/revisions/X8Jlv38w66ja0MIFhnqJ/developers/core-concepts/revocation-epochs-and-freshness) → how timestamps + epochs combine.
* [See Build on Cardano](https://docs.fairway.global/~/revisions/X8Jlv38w66ja0MIFhnqJ/developers/build-on-cardano) → full Aiken integration guide.
* [Explore Trust Registries](https://docs.fairway.global/~/revisions/X8Jlv38w66ja0MIFhnqJ/developers/core-concepts/trust-registries) → issuer key governance (roadmap).


# Identity Proofs (EVM)

How we represent KYC/AML eligibility on EVM networks using attestation-led identity proofs with EAS + PolicyEngine, separating long-term KYC verification timestamps from short-term sanctions epochs.

### Background

On EVM chains, Fairway doesn’t mint identity tokens. Instead, compliance status is expressed through **EAS attestations** that encode:

* **When the user last passed KYC** (`kyc_verified_at`).
* **Current sanctions/risk freshness** (`sanctions_epoch`).
* **Optional compliance claims** (jurisdiction, accreditation, risk score).
* **Commitment root** linking to Midnight proofs.

These attestations are:

* **Issued off-chain** by the Fairway Cloud Agent (Witness) after reading KYC data from decentralized storage.
* **Anchored on-chain** in the EAS registry.
* **Referenced** in dApps through the Fairway **PolicyEngine**:

```solidity
(bool ok, uint32 reason) = policyEngine.isEligible(user, ruleBytes);

```

***

### Components

* **EAS (Ethereum Attestation Service)** → canonical registry of typed attestations.
* **Fairway Verifier** → contract that validates attestations, issuer trust, timestamp, and sanctions epoch.
* **PolicyEngine** → single-call YES/NO eligibility check for dApps.
* **IdentityRegistry** → governance-controlled list of trusted issuers and rules.
* **Optional façade tokens** → ERC-5484 / ERC-5192 for UX or whitelist compatibility.

***

### Flow

```mermaid
sequenceDiagram
  participant User as Wallet
  participant Agent as Fairway Cloud Agent (Witness)
  participant EAS as EAS Registry
  participant Verifier as Fairway Verifier
  participant Policy as PolicyEngine
  participant dApp as Protocol

  User->>Agent: Completes off-chain KYC
  Agent->>EAS: Issue EIP-712 attestation {kyc_verified_at, sanctions_epoch, claims}
  dApp->>Policy: isEligible(user, ruleBytes)
  Policy->>Verifier: Verify attestation + signature + epoch freshness
  Verifier->>EAS: Resolve attestation UID
  Verifier->>Policy: Return (ok, reason)
  Policy->>dApp: YES / NO

```

***

### Example Attestation Schema

```json
{
  "name": "FairwayComplianceV2",
  "fields": [
    { "name": "subject", "type": "address" },
    { "name": "policyId", "type": "bytes32" },
    { "name": "kyc_verified_at", "type": "uint64" },     // unix timestamp
    { "name": "sanctions_epoch", "type": "uint64" },     // rolling freshness counter
    { "name": "jurisdictionSet", "type": "uint16" },
    { "name": "accredited", "type": "bool" },
    { "name": "risk_profile_score", "type": "uint16" },
    { "name": "commitmentRoot", "type": "bytes32" }
  ],
  "revocable": true}

```

***

### Rule Encoding

Policies are defined once in the **IdentityRegistry**.

dApps pack rules as `ruleBytes`:

```solidity
bytes32 policyId = keccak256("POOL-A.KYC2.EU-ACCREDITED");

bytes memory ruleBytes = abi.encode(
    policyId,
    userAttestationUID,   // EAS UID
    expectedEpochRoot,    // sanctions freshness
    maxKycAge             // e.g. 180 days
);

```

***

### Validator Checks

1. **Attestation validity** → issuer signature + schema match.
2. **KYC freshness** → `block.timestamp - kyc_verified_at <= maxKycAge`.
3. **Sanctions freshness** → `sanctions_epoch == latestEpochRoot`.
4. **Other claims** → jurisdiction, accreditation, or risk score thresholds.

***

### Benefits

* **PII-free** → no sensitive docs stored on-chain.
* **Separation of duties** → KYC timestamp (long-lived) + sanctions epoch (short-lived).
* **Compliant** → FATF/AMLD rules enforced per jurisdiction by dApp-defined max age.
* **Interoperable** → compatible with ERC-3643 TransferManager, EAS tooling, and SBT façades.
* **Simple DX** → dApps use a single `isEligible()` call.
* **Auditable** → `commitmentRoot` links attestations back to Midnight ZK proofs.

***

### Next Steps

* [Learn about Revocation Epochs & Freshness.](https://docs.fairway.global/~/revisions/X8Jlv38w66ja0MIFhnqJ/developers/core-concepts/revocation-epochs-and-freshness)
* [Explore Build on EVM for full Solidity integration.](https://docs.fairway.global/~/revisions/X8Jlv38w66ja0MIFhnqJ/developers/build-on-evm)
* [See the ERC-3643 Adapter for RWA integration.](https://docs.fairway.global/~/revisions/Dk4tf7CZM5uuRFD9IJ8x/developers/build-on-evm/attestation-led-compliance-eas-erc-1271-erc-3643/adapter-for-erc-3643-transfermanager)&#x20;


# Zero-Knowledge Proofs (Midnight)

This shows how the Fairway Cloud Agent transforms off-chain KYC data into a Midnight ZK-proof, records it on Midnight, and enables cross-chain eligibility checks on Cardano and EVM.

### Flow

<figure><img src="https://3812774301-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlfDULdwa6BuKx0DZyvBO%2Fuploads%2FdabjRtK9Q0tulx8WdhFj%2Fimage.png?alt=media&amp;token=29c2435b-808f-4791-bd94-446b15071760" alt=""><figcaption></figcaption></figure>

***

### What’s Proven in the Circuit

* The user’s **KYC data** satisfies required rules (e.g., `KYC2_OK`, jurisdiction).
* The proof is **bound to a specific wallet address**.
* The proof is linked to a **timestamp of KYC verification** (`kyc_verified_at`).
* The proof is **anchored on Midnight** as an immutable reference (`midnight_ref`).
* Cross-chain (Cardano/EVM) contracts only verify **Merkle membership, Fairway sig, sanctions\_epoch, and KYC recency** — no raw PII.

***

### Verifier Checklist (Cardano/EVM)

* ✅ Verify **Merkle membership** for `address`.
* ✅ Verify **Fairway signature** over `(root, sanctions_epoch, midnight_ref)`.
* ✅ Enforce **KYC recency** → `now - kyc_verified_at ≤ max_age`.
* ✅ Enforce **sanctions freshness** → `sanctions_epoch == latestEpochRoot`.
* ⬜ Optional audit: **resolve `midnight_ref`** on Midnight for regulator review.

***

### Notes on Keys & Curves

* **Fairway signature** uses chain-appropriate keys:
  * secp256k1 for EVM chains.
  * Cardano-compatible key for UTXO scripts.
* Midnight Compact supports Schnorr signatures inside circuits.
* On-chain verifiers don’t recompute the ZK — they only check Fairway’s signature + Merkle inclusion.

***

### Next Steps

* See [Build on Cardano](https://fairway.gitbook.io/docs/~/revisions/2bV85LKrNLQL0C6MEOcr/developers/build-on-cardano) → validator checks for Merkle, timestamp, and sanctions epoch.
* See [Build on EVM](https://fairway.gitbook.io/docs/~/revisions/2bV85LKrNLQL0C6MEOcr/developers/build-on-evm) → attestation schema with `kyc_verified_at` + `sanctions_epoch`.
* Review[ Revocation Epochs & Freshness](https://fairway.gitbook.io/docs/~/revisions/2bV85LKrNLQL0C6MEOcr/developers/core-concepts/revocation-epochs-and-freshness) → how long-term KYC vs short-term sanctions are combined.


# Decentralized Vaults

Fairway Vaults are off-chain, decentralized storage environments for KYC/AML data. They ensure compliance with FATF standards and GDPR/eIDAS while enabling privacy-preserving, proofs of compliance.

### Compliance Context

#### FATF & AML Requirements

* **Customer Due Diligence (CDD)** → Collect and verify customer identity documents.
* **Record Keeping** → Maintain records for 5–10 years, available for regulators on request.
* **Sanctions Screening** → Check against updated lists (UN, OFAC, EU, local).
* **Ongoing Monitoring** → Reassess at regular intervals or when risk events occur.

#### KYC Regulations

* **Document Verification** (passport, national ID, proof of address).
* **Risk-based Approach** → Different levels (KYC1, KYC2, Enhanced Due Diligence).
* **Accreditation/Eligibility** → Investor class checks for RWA access.

#### GDPR / eIDAS

* **Data Minimization** → only necessary data collected.
* **Right to Erasure / Portability** → users can revoke and migrate.
* **Encryption & Scoped Access** → Vault encrypts data at rest and in transit.
* **Separation of Concerns** → Vault handles PII; blockchains only handle proofs & commitments.

***

### Architecture

```mermaid
flowchart TD
  subgraph Off-Chain [Off-Chain Layer]
    U[User submits KYC data] --> V[Fairway Vault encrypted decentralized storage]
    V --> A[Fairway Cloud Agent Witness]
    A -->|ZK proof| M[Midnight Compact Circuit]
  end

  subgraph On-Chain [On-Chain Layer]
    M --> L[Midnight Ledger: Proof UTXO]
    L --> C[Cardano Merkle UTXO]
    L --> E[EVM EAS Attestation]
    C --> D[dApp/Protocol Guard]
    E --> D
  end

```

***

### Data Lifecycle

1. **Collection** → user submits KYC docs to Vault (off-chain, encrypted).
2. **Verification** → Cloud Agent validates docs (document checks, sanctions screening, AML rules).
3. **Proof Generation** → Witness calls Cloud Agent and Compact circuit produces ZK-proof bound to a wallet address.
4. **Recording** → Proof stored as a UTXO on Midnight (immutable audit trail).
5. **Reference** → Merkle roots (Cardano) or EAS attestations (EVM) include `midnight_ref` and Fairway signature.
6. **Usage** → dApps only check eligibility flags; no direct access to PII.

***

### Data Model (Vault Entry)

```json
{
  "user_id": "uuid-v4",
  "wallets": ["addr1...", "0xabc..."],
  "kyc_level": 2,
  "jurisdiction": "EU",
  "accredited": true,
  "sanctions_status": "clear",
  "docs": {
    "passport_hash": "sha256:0x123...",
    "proof_of_address_hash": "sha256:0x456..."
  },
  "created_at": "2025-09-22T10:15:00Z",
  "updated_at": "2025-09-22T11:00:00Z"
}

```

***

### Compliance Properties

* **FATF R.10 / R.11 (Recordkeeping)** → Vault maintains secure audit trail; regulators can request full trace via `midnight_ref`.
* **AML Directives (AMLD5/6, EU)** → sanctions screening + enhanced due diligence supported by Vault Agent workflows.
* **GDPR Articles 5 & 25 (Minimization, Privacy by Design)** → only commitments/flags on-chain, never PII.
* **eIDAS** → cryptographic signatures and proofs meet EU electronic trust service requirements.
* **Auditability** → any `midnight_ref` can be checked against Vault + Issuer records under regulator supervision.

***

### What Vaults Are (and Are Not)

* ✅ **Are** → encrypted, decentralized KYC data stores aligned with FATF/AML/GDPR.
* ❌ **Are Not** → on-chain databases (no PII ever published).
* ❌ **Are Not** → public APIs for dApps (only the Witness Agent reads them).
* ❌ **Are Not** → proof stores (ZK-proofs live on Midnight).

***

### Benefits

* **Privacy-first** → regulators can audit, but protocols see only “YES/NO”.
* **Regulatory alignment** → satisfies FATF, AMLD, KYC, GDPR/eIDAS simultaneously.
* **Future-proof** → Vault workflows adapt to new directives (e.g., FATF Travel Rule, MiCA).
* **Trust-minimized** → Fairway signature + Midnight proofs decouple compliance checks from raw data custody.

***

### Next Steps

* See Witnesses → how Cloud Agents read Vaults and generate proofs. (Not public yet)
* [Learn Zero-Knowledge Proofs (Midnight).](https://docs.fairway.global/~/revisions/ANJ44LbwfWAXIHTM56W0/developers/core-concepts/zero-knowledge-proofs-midnight)
* [Explore Compliance Guides for regulator mapping.](https://docs.fairway.global/~/revisions/LmhbGZ8szY6vRl5kdqPa/learn/compliance-and-risk-management-guides)


# 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

<figure><img src="https://3812774301-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlfDULdwa6BuKx0DZyvBO%2Fuploads%2F78GqUF7I7rfObcCu2FLs%2FScreenshot%202025-10-08%20at%2021.17.08.png?alt=media&amp;token=da79ff01-bad7-4703-bf0a-f18f5e48531f" 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.


# Trust Registries

Trust registries define which issuers and keys are authorized to issue compliance proofs, enabling multi-issuer ecosystems and key rotation.

### Purpose

A **Trust Registry** is a structured list of **who is trusted to issue compliance proofs**.

It provides a governance layer over issuers, roles, schemas, and revocations.

Trust registries answer:

* *Which keys can sign Merkle roots or attestations?*
* *Which issuers are recognized for specific KYC levels or jurisdictions?*
* *How are compromised keys or outdated schemas revoked?*

***

### Why They Matter

* **Multi-Issuer ecosystems** → more than one regulated entity can issue proofs.
* **Key rotation** → issuers can update or revoke signing keys without breaking dApps.
* **Schema governance** → define which compliance schemas are valid at a given epoch.
* **Cross-chain consistency** → same “who do we trust?” logic works for Cardano and EVM.

***

### Current State (MVP)

Fairway MVP runs in **single-issuer mode**:

* **Fairway** is the sole trusted issuer.
* DApps validate proofs by checking **Fairway’s signature** on:
  * Cardano: Merkle UTXO `{root, epoch, midnight_ref}`
  * EVM: EAS attestation under Fairway’s key

**Trust Registry (today)** = just the Fairway pubkey(s), hardcoded or stored in a simple on-chain datum for rotation.

***

### Future Roadmap (Planned Expansion)

Fairway will expand Trust Registries into a **multi-issuer governance primitive**:

1. **Issuer List**
   * Map of issuer addresses/keys → roles (KYC provider, accreditor, sanctions oracle).
2. **Schema & Version Registry**
   * Declare valid schema IDs for different compliance checks.
3. **Revocation Epochs**
   * Registry tracks when an issuer key or schema was revoked, ensuring dApps enforce freshness.
4. **DAO Governance**
   * Institutions stake Fairway token to onboard new issuers.
   * Curated by a governance process, not a single operator.

***

### Example: Future Multi-Issuer Registry

```json
{
  "issuers": [
    {
      "address": "0xIssuerBank",
      "roles": ["KYC_L2", "Accreditor"],
      "schema_versions": [2,3],
      "revoked": false},
    {
      "address": "0xSanctionsOracle",
      "roles": ["SanctionsFeed"],
      "schema_versions": [1],
      "revoked": true,
      "revoked_epoch": 205
    }
  ],
  "last_updated": "2025-09-22T10:00:00Z"
}

```

***

### Diagrams

#### Evolution Path

```mermaid
flowchart LR
  MVP[Single Issuer: Fairway key] --> Phase1[Key rotation support]
  Phase1 --> Phase2[Multi-Issuer: banks, accreditors, oracles]
  Phase2 --> Phase3[DAO-governed Trust Registry with staking + curation]

```

***

### Benefits

* **For Developers** → stable pubkey source for eligibility checks.
* **For Institutions** → ability to recognize multiple issuers under governance.
* **For Regulators** → clear audit trail of “who was trusted when.”

***

### Roadmap Clarification

* **MVP (2025)** → single issuer, Fairway signature only.
* **Mid stage (2026)** → introduce Trust Registry module (multi-issuer).
* **Late stage (2029)** → DAO-governance and full decentralization \*\*\*\*
* **Docs** → early page included so developers and partners understand where Fairway is heading.

***

### Next Steps

* See [Build on Cardano](https://docs.fairway.global/~/revisions/LmhbGZ8szY6vRl5kdqPa/developers/build-on-cardano) for how the current single-issuer signature is enforced.
* See [Build on EVM](https://docs.fairway.global/~/revisions/LmhbGZ8szY6vRl5kdqPa/developers/build-on-evm) for how attestations are verified today.
* Follow [roadmap](https://docs.fairway.global/~/revisions/LmhbGZ8szY6vRl5kdqPa/developers/changelog-and-roadmap) updates for when Trust Registry functionality ships.


# Revocation Epochs & Freshness

Fairway separates long-term KYC from short-term sanctions monitoring. KYC proofs include the time of verification; protocols enforce their own acceptance windows and checking latest sanctions epoch.

### Purpose

Compliance freshness has two layers:

1. **KYC Verification Timestamp** → When was the user last verified?
   * Recorded once in proof metadata.
   * Protocols decide how old is “too old” (jurisdiction-specific).
2. **Sanctions & Risk Epochs** → Rolling counters that track dynamic changes.
   * Incremented whenever sanctions lists or risk profiles update.
   * Only addresses affected by a change are updated.

This layered approach avoids forcing users to re-KYC daily, while ensuring protocols can enforce up-to-date sanctions and AML checks.

***

### Why It Matters

* **KYC validity** → EU vs. US vs. emerging market rules differ (6 months, 1 year, etc.).
* **Sanctions screening** → must be near real-time (lists update daily/weekly).
* **Risk monitoring** → risk scores can change without invalidating full KYC.

Without this separation, you’d either:

* Burden users with unnecessary re-checks, or
* Accept stale compliance states.

***

### How It Works

#### Cardano (Merkle UTXO)

The Compliance UTXO datum includes:

```json
{
  "merkle_root": "0xabc123...",
  "kyc_verified_at": "2025-03-15T10:00:00Z",
  "sanctions_epoch": 452,
  "risk_profile_score": 17,
  "midnight_ref": "0xdeadbeef#0",
  "fairway_sig": "sig(...)"
}

```

* **`kyc_verified_at`** = fixed timestamp of when KYC was performed.
* **`sanctions_epoch`** = current counter (increments on list/risk changes).
* **`risk_profile_score`** = optional numeric risk measure (low=0, high=100).

***

#### EVM (EAS Attestation)

EAS attestations include the same fields:

```json
{
  "subject": "0xUserWallet",
  "policyId": "POOL-A.KYCv2.EU",
  "kyc_verified_at": "2025-03-15T10:00:00Z",
  "sanctions_epoch": 452,
  "risk_profile_score": 17,
  "commitmentRoot": "0xabc123...",
  "epoch": 452
}

```

* Protocols pass `expectedEpochRoot` into the PolicyEngine for freshness.
* Off-chain rules define how old a `kyc_verified_at` can be.

***

#### Midnight (Proof Ledger)

* ZK-proofs generated by the Cloud Agent are posted to Midnight with:
  * **KYC verification timestamp**
  * **Current sanctions epoch**
* Serves as the immutable audit trail for regulators.

***

### Diagram

```mermaid
flowchart TD
    U[User completes KYC once] --> V[Vault stores PII + timestamp]
    V --> A[Fairway Agent generates proof]
    A --> M[Midnight Ledger (proof + kyc_verified_at + sanctions_epoch)]
    M --> C[Cardano Merkle UTXO {root, timestamp, epoch, sig}]
    M --> E[EVM Attestation {policyId, timestamp, epoch}]
    S[Sanctions feed update] --> F[Cloud Agent updates sanctions_epoch and only impacted leaves]
    F --> C
    F --> E

```

***

### Enforcement Logic

1. **Check KYC freshness**
   * Compare `kyc_verified_at` against protocol’s policy.
   * Example: “only accept KYC within last 6 months.”
2. **Check sanctions epoch**
   * Ensure user’s proof includes the **latest sanctions\_epoch**.
   * If out of date → reject.
3. **Check risk score** (optional)
   * Compare against configured thresholds.

***

#### Cardano (Aiken snippet)

```
let ok_kyc = ctx.tx.now - utxo.datum.kyc_verified_at <= rule.max_age
let ok_epoch = utxo.datum.sanctions_epoch == registry.current_epoch

```

#### EVM (Solidity snippet)

```solidity
require(
  block.timestamp - kycVerifiedAt <= maxAge,
  "KYC_DENIED:STALE_KYC"
);

require(
  latestEpochRoot == expectedEpochRoot,
  "KYC_DENIED:STALE_SANCTIONS"
);

```

***

### Benefits

* **Jurisdiction-aware** → protocols choose their own KYC freshness policy.
* **User-friendly** → users don’t re-KYC for every sanctions update.
* **Efficient** → only affected addresses updated when sanctions lists change.
* **Audit-ready** → Midnight provides historical proof trail.

***

### Compliance Alignment

* **FATF Recommendation 10** (ongoing due diligence) → sanctions epoch updates.
* **AML Directives** → periodic KYC refresh enforced per institution.
* **GDPR** → only timestamps & hashed commitments on-chain.
* **Regulatory audits** → auditors can query `kyc_verified_at` + `epoch` state at time of tx.

***

### Next Steps

* See [Build on Cardano](https://docs.fairway.global/~/revisions/xqNJ6bTRIwH1epmr6yrr/developers/build-on-cardano) → validator checks timestamps + epoch.
* See [Build on EVM](https://docs.fairway.global/~/revisions/xqNJ6bTRIwH1epmr6yrr/developers/build-on-evm) → attestation freshness.
* Review [Trust Registries](https://docs.fairway.global/~/revisions/xqNJ6bTRIwH1epmr6yrr/developers/core-concepts/trust-registries) → how issuer keys evolve with epochs.


# Build on Cardano


# Merkle Compliance UTXO

## Introduction

Fairway provides a compliance layer for **Cardano DeFi** using a **Merkle-root UTXO**.

Instead of minting identity tokens, all eligible addresses + claims are committed into a Merkle tree.

The **Compliance UTXO** anchors this state with:

* `merkle_root` → commitment to all compliant users
* `kyc_verified_at` → timestamp of last KYC check
* `sanctions_epoch` → counter for sanctions/risk updates
* `midnight_ref` → link to Midnight proof UTXO
* `fairway_sig` → Fairway’s signature over the state


# Architecture Overview

#### Core Components

* **Compliance UTXO**
  * Holds root, timestamp, epoch, signature, midnight reference.
  * Updated when sanctions/risk lists change, or when new users are onboarded.
* **Merkle Proofs**
  * Submitted by users in transactions.
  * Leaf = `{ address, claims, kyc_verified_at }`.
* **Policy Engine (Aiken)**
  * Verifies membership, signature, timestamp vs. max-age, and sanctions epoch freshness.
* **Trust Registry (future)**
  * Will manage Fairway issuer keys + versioning.

***

#### Mermaid (high level)

```mermaid
flowchart LR
  A[User completes KYC once] --> B[Vault stores PII + kyc_verified_at]
  B --> M[Midnight proof UTXO posted]
  M --> C[Compliance UTXO root, kyc_verified_at, sanctions_epoch, sig]
  C --> D[dApp Validator]
  D -->|Proof verified, timestamp ok, epoch fresh| E[YES → allow]
  D -->|fail| F[NO → deny]

```

<figure><img src="https://3812774301-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlfDULdwa6BuKx0DZyvBO%2Fuploads%2Ft9FwHnqX6yY1b5k2VMW0%2FScreenshot%202025-10-02%20at%2013.15.22.png?alt=media&amp;token=ae85086a-c3d6-468b-9739-5af813223459" alt=""><figcaption></figcaption></figure>


# Integration Workflow

1. **Institution defines requirements**
   * Min KYC level
   * Jurisdiction allow/deny
   * Sanctions epoch freshness (must match latest)
   * Max KYC age (e.g. 6 months, 12 )
2. **User completes KYC off-chain**
   * Vault stores PII.
   * Cloud Agent records `kyc_verified_at`.
   * Proof posted to Midnight.
3. **Fairway updates Compliance UTXO**
   * New Merkle root.
   * `sanctions_epoch` incremented if needed.
   * `kyc_verified_at` attached per-leaf.
   * Signed by Fairway.
4. **User interacts with dApp**
   * Submits Merkle proof with leaf `{addr, claims, kyc_verified_at}`.
   * dApp attaches Compliance UTXO as reference input.
5. **Validator checks**

* [x] Merkle membership
* [x] Signature
* [x] `sanctions_epoch=latest`
* [x] `now - kyc_verified_at ≤ max_age`


# Developer Integration Guide

#### Datum structure (Compliance UTXO)

```json
{
  "merkle_root": "0xabc123...",
  "sanctions_epoch": 452,
  "midnight_ref": "0xdeadbeef#0",
  "fairway_sig": "sig(fairway_key, hash(root || epoch || midnight_ref))"
}

```

***

#### Leaf structure (Merkle tree)

```json
{
  "address": "addr1...",
  "claims": ["KYC2", "EU_RESIDENT"],
  "kyc_verified_at": "2025-03-15T10:00:00Z"
}

```

***

#### Aiken Policy Engine (simplified)

```
validator eligibility {
  fn check(ctx: ScriptContext, proof: MerkleProof, leaf: Leaf, max_age: Int) -> Bool {
    let utxo = get_ref_input(ctx, FAIRWAY_UTXO_REF)

    // 1. Verify Merkle proof
    let ok_proof = verify_merkle(proof, utxo.datum.merkle_root, leaf)

    // 2. Verify Fairway signature
    let payload = hash(utxo.datum.merkle_root || utxo.datum.sanctions_epoch || utxo.datum.midnight_ref)
    let ok_sig = verify_signature(FAIRWAY_PUBKEY, payload, utxo.datum.fairway_sig)

    // 3. Check sanctions epoch freshness
    let ok_epoch = utxo.datum.sanctions_epoch == current_sanctions_epoch()

    // 4. Check KYC timestamp freshness
    let age = ctx.tx.now - leaf.kyc_verified_at
    let ok_kyc = age <= max_age

    ok_proof && ok_sig && ok_epoch && ok_kyc
  }
}

```

***

{% hint style="info" %}
**Protocol-defined max\_age** → institutions decide (3mo/6mo/12mo).

**Fairway just records `kyc_verified_at`** → not prescriptive.
{% endhint %}


# Case Study


# Security & Compliance

* **No PII on-chain** → only commitments, timestamps, epochs.
* **Revocation model**
  * Sanctions → epoch increments.
  * Risk score → leaf updates.
  * KYC → re-run required after expiry window.
* **Auditability** → regulators can resolve `midnight_ref` for historical proof.
* **Trust anchor** → Fairway signature ensures integrity.

{% hint style="danger" %}
Never leak raw jurisdiction names or document types in leaves. Use codes (ISO country, KYC level integers).
{% endhint %}


# Testing & Deployment

#### Local dev with Aiken

* Mock a Compliance UTXO.
* Simulate Merkle membership with a test leaf.
* Write unit tests for:
  * Membership valid/invalid
  * Sanctions epoch stale
  * KYC too old
  * Signature mismatch

#### Deploy flow

1. Deploy Compliance UTXO script.
2. Fairway Agent publishes Merkle root + epoch.
3. Integrate Policy Engine into validators.
4. Test epoch + timestamp logic.
5. Roll to preprod → mainnet.


# Glossary

* **Compliance UTXO** → anchors Merkle root, epoch, sig, midnight ref.
* **KYC Verified At** → timestamp of when user last completed KYC.
* **Sanctions Epoch** → counter incremented when lists/risk change.
* **Leaf** → user-level proof data (address, claims, timestamp).
* **Policy Engine** → Aiken validator library for YES/NO eligibility.


# Aiken Validator Guides


# Policy Engine


# Trust Registry Contracts


# Build on EVM


# ERC-3643 & EAS Overview


# Attestation-Led Compliance (EAS, ERC-1271, ERC-3643)

### Introduction

Fairway enables **institutions** to enforce compliance on-chain in a privacy-preserving way. On EVM chains we use **EAS attestations** with:

* `kyc_verified_at` → when the KYC check was done (long-lived).
* `sanctions_epoch` → current counter for sanctions/risk list freshness.
* `risk_profile_score` → optional AML risk rating.

This lets dApps enforce **jurisdiction-specific freshness policies** without exposing PII.


# High-Level Flow

1. **User completes KYC once** → Vault + Cloud Agent store raw docs.
2. **Fairway issues EAS attestation** with:
   * Subject address (EOA or ERC-1271 smart account).
   * `kyc_verified_at` timestamp.
   * Current `sanctions_epoch`.
   * Risk score if applicable.
3. **Protocol calls PolicyEngine** before sensitive actions.
4. PolicyEngine checks:
   * Attestation validity + signature.
   * `sanctions_epoch` freshness.
   * `now - kyc_verified_at ≤ max_age` (defined by the dApp).
5. Returns YES/NO + reason code.


# Attestation Schema (EAS JSON)

```json
{
  "name": "FairwayComplianceV2",
  "fields": [
    { "name": "subject", "type": "address" },
    { "name": "policyId", "type": "bytes32" },
    { "name": "kyc_verified_at", "type": "uint64" },    // unix timestamp
    { "name": "sanctions_epoch", "type": "uint64" },
    { "name": "risk_profile_score", "type": "uint16" },
    { "name": "commitmentRoot", "type": "bytes32" }
  ],
  "revocable": true}

```


# Policy Engine Interface

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IPolicyEngine {
    function isEligible(address subject, bytes calldata rule)
        external view returns (bool ok, uint32 reason);
}

```

Rule encoding example:

```solidity
abi.encode(
    policyId,
    attestationUID,
    expectedEpochRoot,
    maxKycAge // e.g. 180 days
);

```


# Validator Checks

#### Solidity Example

```solidity
(bytes32 policyId, bytes memory attUID, bytes32 expectedEpochRoot, uint256 maxKycAge) =
    abi.decode(rule, (bytes32, bytes, bytes32, uint256));

(bool ok, uint32 reason) = policyEngine.isEligible(
    msg.sender,
    abi.encode(policyId, attUID, expectedEpochRoot, maxKycAge)
);

require(ok, string(abi.encodePacked("KYC_DENIED:", _toString(reason))));

```

#### Inside PolicyEngine

```solidity
function _checkFreshness(
    uint64 kycVerifiedAt,
    uint64 sanctionsEpoch,
    uint64 latestEpoch,
    uint256 maxAge
) internal view returns (bool ok, uint32 reason) {
    if (block.timestamp - kycVerifiedAt > maxAge) {
        return (false, 2001); // STALE_KYC
    }
    if (sanctionsEpoch < latestEpoch) {
        return (false, 1001); // STALE_SANCTIONS
    }
    return (true, 0);
}

```


# Adapter for ERC-3643 (TransferManager)

```solidity
contract FairwayTo3643Adapter is ITransferManager3643 {
    IPolicyEngine public policy;
    bytes public ruleFrom;
    bytes public ruleTo;

    constructor(address _policy, bytes memory _ruleFrom, bytes memory _ruleTo) {
        policy = IPolicyEngine(_policy);
        ruleFrom = _ruleFrom;
        ruleTo = _ruleTo;
    }

    function canTransfer(address from, address to, uint256)
        external view
        returns (bool ok, uint256 reason)
    {
        (bool okFrom, uint32 rFrom) = policy.isEligible(from, ruleFrom);
        if (!okFrom) return (false, rFrom);
        (bool okTo, uint32 rTo) = policy.isEligible(to, ruleTo);
        if (!okTo) return (false, rTo);
        return (true, 0);
    }
}

```


# Example Integration

**Scenario:** dApp requires:

* KYC ≤ 6 months old.
* Must match latest sanctions epoch.
* EU residents only.

```solidity
bytes32 constant POLICY_EU = keccak256("POOL.KYC2.EU");

bytes memory rule = abi.encode(
    POLICY_EU,
    userEASUID[msg.sender],
    bytes32(0),  // expected epoch root (latest)
    180 days     // max KYC age
);

(bool ok, uint32 reason) = policyEngine.isEligible(msg.sender, rule);
require(ok, _reason(reason));

```


# Reason Codes

* `0` → OK
* `1001` → Stale sanctions epoch
* `1002` → Invalid issuer/signature
* `2001` → KYC too old
* `2002` → Jurisdiction not allowed
* `2003` → Risk score too high


# Security & Compliance Notes

* **No PII on-chain** → only timestamps, epochs, risk flags.
* **Sanctions updates** → epoch increments automatically.
* **KYC timestamp** → dApps enforce jurisdictional freshness rules.
* **Smart wallets** → supported via ERC-1271 signatures.
* **Audit trail** → `commitmentRoot` links back to Midnight proofs.

{% hint style="info" %}
This model aligns with **FATF ongoing due diligence**, **AML directives**, and **GDPR** by separating long-term KYC validity from short-term sanctions updates.
{% endhint %}


# Next Steps

* Try the EVM Quickstart.
* Explore the Revocation Epochs & Freshness page.
* Connect to your preferred EAS deployment (Base, Arbitrum, Polygon).


# Policy Engine & Adapters


# ERC-1271 Verification Flows


# APIs & SDKs

Coming soon...


# Fairway Cloud Agent API

## Fairway Cloud Agent API

> Base URL: `https://api.fairway.global`\
> Version: `v1`\
> Authentication: `Bearer <API_KEY>` in the `Authorization` header.\
> Format: JSON (UTF-8).

***

### Overview

The **Fairway Cloud Agent API** lets you integrate **KYC verification, proof generation, and on-chain eligibility publishing** into your own apps and backends.

You can:

* Trigger user verification sessions.
* Query verification results.
* Request **ZK-proof generation** on Midnight.
* Retrieve **proof metadata** (Merkle root, `midnight_ref`, signature).
* Sync compliance state with Cardano or EVM contracts.

All responses follow this standard envelope:

```json
{
  "success": true,
  "data": { ... },
  "meta": { "timestamp": "2025-10-08T13:12:00Z" }
}
```

***

### Authentication

Every request must include your project API key:

```http
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
```

::: info\
You can generate or rotate keys in the Fairway Developer Console.\
:::

***

### Endpoints

#### 1. Create Verification Session

**POST** `/v1/kyc/session`

Initiate a new user KYC flow.

**Request**

```json
{
  "user_wallet": "addr1qxyz...",
  "callback_url": "https://yourapp.com/webhook/fairway",
  "metadata": {
    "kyc_level": 2,
    "jurisdiction": "EU"
  }
}
```

**Response**

```json
{
  "success": true,
  "data": {
    "session_id": "sess_92f3a1",
    "redirect_url": "https://verify.fairway.global/session/sess_92f3a1"
  }
}
```

**Example (cURL)**

```bash
curl -X POST https://api.fairway.global/v1/kyc/session \
  -H "Authorization: Bearer sk_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{"user_wallet":"addr1qxyz...","callback_url":"https://yourapp.com/webhook"}'
```

***

#### 2. Get Verification Status

**GET** `/v1/kyc/status/{session_id}`

Check the result of a user’s KYC verification.

**Response**

```json
{
  "success": true,
  "data": {
    "session_id": "sess_92f3a1",
    "wallet": "addr1qxyz...",
    "kyc_verified_at": "2025-10-08T11:45:23Z",
    "risk_profile_score": 12,
    "status": "approved"
  }
}
```

Status values:

* `pending` — still in progress.
* `approved` — verified and ready for proof generation.
* `rejected` — failed verification or expired.

***

#### 3. Generate Proof (Midnight)

**POST** `/v1/proof/generate`

Trigger creation of a **Midnight ZK-proof** for a verified user.

**Request**

```json
{
  "wallet": "addr1qxyz...",
  "session_id": "sess_92f3a1",
  "claims": ["KYC2_OK", "EU_RESIDENT"]
}
```

**Response**

```json
{
  "success": true,
  "data": {
    "midnight_ref": "0xdeadbeef#0",
    "kyc_verified_at": "2025-10-08T11:45:23Z",
    "sanctions_epoch": 452,
    "fairway_sig": "sig(fairway_key, ...)",
    "commitment_root": "0xabc123..."
  }
}
```

**Example (TypeScript SDK)**

```ts
const proof = await fairway.proofs.generate({
  wallet: "addr1qxyz...",
  session_id: "sess_92f3a1",
  claims: ["KYC2_OK", "EU_RESIDENT"]
});
console.log(proof.midnight_ref);
```

***

#### 4. Fetch Proof Metadata

**GET** `/v1/proof/{wallet}`

Get latest proof metadata for a wallet.

**Response**

```json
{
  "success": true,
  "data": {
    "wallet": "addr1qxyz...",
    "midnight_ref": "0xdeadbeef#0",
    "sanctions_epoch": 452,
    "kyc_verified_at": "2025-03-15T10:00:00Z",
    "risk_profile_score": 17,
    "status": "active"
  }
}
```

***

#### 5. Webhooks

Your app can receive asynchronous events for:

| Event              | Description                                      |
| ------------------ | ------------------------------------------------ |
| `kyc.completed`    | A user finished KYC verification.                |
| `proof.generated`  | A ZK-proof was generated and posted to Midnight. |
| `sanctions.update` | A sanctions epoch increment affected the wallet. |

Webhook payload example:

```json
{
  "event": "proof.generated",
  "data": {
    "wallet": "addr1qxyz...",
    "midnight_ref": "0xdeadbeef#0",
    "sanctions_epoch": 452,
    "kyc_verified_at": "2025-03-15T10:00:00Z"
  },
  "signature": "sig(fairway_key, ...)"
}
```

Verify webhook authenticity with Fairway’s public key from:\
`GET https://api.fairway.global/v1/public-keys`

***

### Rate Limits

Default: **60 requests/minute per API key**.\
Bursting and enterprise tiers available — contact <support@fairway.global>.

On limit exceeded → HTTP `429 Too Many Requests`.

***

### Errors

| Code  | Meaning        | Typical Cause                 |
| ----- | -------------- | ----------------------------- |
| `400` | Bad Request    | Missing or invalid parameters |
| `401` | Unauthorized   | Missing or invalid API key    |
| `403` | Forbidden      | Insufficient permissions      |
| `404` | Not Found      | Unknown session or wallet     |
| `429` | Rate limited   | Too many requests             |
| `500` | Internal error | Unexpected backend issue      |

Error example:

```json
{
  "success": false,
  "error": {
    "code": 401,
    "message": "Invalid API key"
  }
}
```

***

### Security & Compliance Notes

* All endpoints use **TLS 1.3+**.
* No PII ever leaves your infrastructure — the Agent API works only with hashed and encrypted data.
* `kyc_verified_at` and `sanctions_epoch` values are deterministic and audit-friendly.
* Webhooks are signed for integrity; always verify before processing.

***

### SDKs

* **TypeScript/Node.js SDK** → `npm install @fairway/sdk`
* **Python SDK (beta)** → `pip install fairway-sdk`

Example:

```ts
import { FairwayClient } from "@fairway/sdk";

const fairway = new FairwayClient({ apiKey: process.env.FAIRWAY_KEY });
const session = await fairway.kyc.createSession({
  wallet: "addr1qxyz...",
  callback_url: "https://yourapp.com/webhook"
});
```

***

### Next Steps

* See Decentralized Vaults → how KYC data is stored off-chain.
* Explore Midnight ZK Proofs → how proofs are generated and linked cross-chain.
* Implement Webhook Handlers → to sync proof events.
* Read Build on Cardano or Build on EVM for on-chain integration.

***


# References and standards


# Changelog & Roadmap

***

### 🧩 Q4 2025 — MVP Phase

* [ ] API for KYC-proof checks released
* [ ] Cardano Oracle v1

***

### 🧩 Q1 2026 — Foundation Phase

* [ ] Launch Vaults & Identity Tokens with Merkle trees
* [ ] Biometrics API for Midnight
* [ ] Liveness check API for Midnight

***

### ⚙️ Q2 2026 — Integration Phase

* [ ] SDK v1 for dApp integration&#x20;

***

### 🏦 Q3 2026 — Institutional Phase

* [ ] Policy Engine
* [ ] Trust registry tools
* [ ] EUDI-Integration
* [ ] First National-ID integrations

***

### Q4 2026 - Initial Token Incentivization phase

★ **Token Generation Event(TGE)** ★&#x20;

* [ ] Fairway Token release
* [ ] Governance v1

***

### 🌐 Q4 2026 — Expansion Phase

* [ ] Cross-chain SDK (Cardano + EVM + BTC)
* [ ] Cross-chain RWA pilots with clients tokenization platforms

***

### 🚀 Q1 2027 — Enterprise Phase

* [ ] Enterprise SDK&#x20;
* [ ] Enterprise client dashboard

***

### 🪶 Q2 2027 — Sovereign Trust Phase

* [ ] Fully decentralized KYC/AML without any PII data leaving users device
* [ ] Cross-chain proof verification toolkit

***

### Q4 2030 — DAO Hand-Over

* [ ] Governance Autonomy Achieved
* [ ] Fairway DAO assumes full control of protocol and treasury


# FAQ & Troubleshooting


# Compliance and risk management Guides


# Compliance Bridge: Trust for Institutional DeFi

Trust, not tech, is the barrier. Fairway’s compliance bridge uses KYC vaults, ZK proofs, and identity tokens to unlock safe institutional DeFi.

Every **DeFi founder** knows the appetite is there. **Pension funds, insurers, and sovereign wealth funds** want exposure to **yield, tokenized assets, and new liquidity** venues. But one high-profile failure could close the door for the entire sector.

The real obstacle isn’t technology. It’s **trust**.

#### The Risks

* **AML gaps**: Funds moving through pools without clarity on source of funds.
* **Sanctions evasion**: Blacklisted wallets sneaking in, sanctioned countries or individuals participating
* **Auditability**: Regulators demand clear trails, but DeFi often provides opacity.

#### Why This Matters

Institutions aren’t waiting for “perfect” regulation—they’re waiting for **credible guardrails**. Without them:

* Banks can’t custody assets.
* Funds can’t allocate capital.
* Regulators can shut doors overnight.

#### The Bridge: Verify → Prove → Access

```mermaid
flowchart LR
    A[Institution defines KYC/AML policy] --> B[Users complete KYC with provider]
    B --> C[Vault stores commitments + ZK proof]
    C --> D[Identity Token issued]
    D --> E[dApp checks eligibility]

```

* Define → Institutions define rules and users complete KYC with trusted providers.
* **Prove** → Fairway vaults turn KYC data into ZK-proofs (no raw PII on-chain).
* **Access** → Identity tokens unlock compliance-gated DeFi participation.

#### Tools

* **KYC Vaults** (off-chain storage + ZK commitments).
* **Identity Proofs** (Merkle trees / ERC-3643 style).
* **Policy Engines** (programmable eligibility checks).

**Takeaway Framework: The 3-Steps for users**

{% stepper %}
{% step %}

### Verify once

Users go through traditional KYC process
{% endstep %}

{% step %}

### Prove without revealing

They gain a proof that can be connected to multiple wallets and used to prove eligibility
{% endstep %}

{% step %}

### Access everywhere

Same proofs will be accepted on any DeFI
{% endstep %}
{% endstepper %}


# Risk management as Code - Making Rules Programmable in DeFi

TradFi compliance officers rely on manuals, memos, and human interpretation. DeFi can do better; Turn risk policies into executable code.

#### *In TradFi, compliance lives in binders. In DeFi, it should live in smart contracts.*

#### The Risks

* **Inconsistent KYC**: Different pools, different processes.
* **Manual approvals**: Slows down liquidity flows.
* **Jurisdictional confusion**: “Accredited” means one thing in the U.S., another in the EU.

#### Why This Matters

Institutions need **predictability**. If compliance can’t be automated, scale is impossible.

#### The Policy Engine Model

```mermaid
flowchart TD
    A[Policy Engine] --> B{Rule: Accredited only?}
    B -->|Yes| C[Allow deposit to RWA Pool]
    B -->|No| D[Reject tx]

```

* Codify rules as **on-chain eligibility checks**.
* Example: “Only wallets with Accredited Investor token may deposit in RWA Pool.”
* Rules are transparent, testable, and enforceable.

#### Tools

* **Policy Engine contracts** (eligibility as a function).
* **Trust Registries** (who counts as an issuer of credentials).
* **Identity Adapters** (bridge ERC-5484 SBTs / CIP-113 tokens into policy checks).

**Risk management as Code**

* [ ] Define policy in natural language.
* [ ] Translate into smart contract conditions.
* [ ] Connect to proof/identity tokens.
* [ ] Test rules with edge cases.


# Privacy vs. Regulation, The False Choice

Too often, builders think: either expose all PII for compliance or keep everything private. That’s a false choice.

#### *Most people think privacy and compliance are opposites. They’re not.*

#### The Risks

* **Overexposure of PII**: Data breaches or blockchain leaks.
* **GDPR violations**: Fines and loss of EU market access.
* **User mistrust**: Institutions won’t onboard if data control is weak.

#### Why This Matters

Institutional adoption depends on **privacy-preserving compliance**. No bank will onboard if customer PII leaks to a public ledger.

#### The Solution: ZK + Selective Disclosure

```mermaid
flowchart LR
    A[User KYC docs] --> B[Vault Commitments]
    B --> C[ZK Proof: Is EU Citizen?]
    C --> D[dApp Policy Engine: Yes/No]

```

* **Vault Commitments** → Hash and commit raw KYC data off-chain.
* **ZK-Proofs** → Prove eligibility (e.g. EU citizenship) without revealing passport.
* **Selective Disclosure** → Reveal only what’s required (e.g. “Over 18”).

#### Privacy-by-Design Compliance

1. **Minimize** → Store only proofs, not data.
2. **Control** → Users own their credentials.
3. **Prove** → Share only cryptographic attestations.
4. **Revoke** → Support ongoing compliance without leaks.

{% hint style="info" %}
**Takeaway**: Privacy is not the enemy of compliance. It’s the *foundation* for institutional trust.
{% endhint %}


# Sanctions in Real Time: Why Revocation Matters?

Static KYC is dangerous. If a wallet passes KYC in 2023 but gets sanctioned in 2024, protocols without revocation are exposed.

#### *A KYC done once is a risk forever.*

#### The Risks

* **Outdated KYC**: Users change circumstances.
* **Sanctions evasion**: Bad actors slip in after initial screening.
* **Expired credentials**: Passports expire, licenses lapse.

#### Why This Matters

Institutions require **continuous compliance**. One gap can taint an entire pool.

#### The Solution: Continuous Compliance Lifecycle

```mermaid
flowchart TD
    A[User Credential] --> B[Epoch Revocation Check]
    B -->|Revoked| C[Access blocked]
    B -->|Valid| D[Access granted]

```

* **Epoch-based revocation** → Proofs expire after fixed intervals.
* **Rolling sanctions lists** → Protocols query updated negative attestations.
* **Issuer-managed expiry** → Credentials tied to validity periods.

#### Framework: Continuous Compliance

1. **Issue** → Credential minted.
2. **Monitor** → Periodic re-checks.
3. **Revoke** → Negative attestations if status changes.
4. **Audit** → Proof of compliance lifecycle.

{% hint style="danger" %}
Static KYC is a liability. Real-time revocation is the only safe path forward
{% endhint %}


# The Compliance Moat: Turning Regulation into a Competitive Edge

In Institutional DeFi, compliance is not defense but a moat. With trust registries, ZK identity tokens, and SDKs, protocols turn regulation into an advantage.

#### *DeFi protocols that master compliance don’t just survive; they dominate.*

The winners of Institutional DeFi won’t be those who avoid compliance. They’ll be those who **weaponize it as a moat.**

#### The Risks

* **Losing institutional capital** → Funds can’t participate.
* **Regulatory blacklisting** → Barred from exchanges and custodians.
* **Competitors outpacing** → Those with compliance rails get first-mover advantage.

#### Why This Matters

Compliance is not just defense. It’s offense. It opens doors to:

* **Banks and custodians** (integration).
* **Sovereign wealth funds** (deployment).
* **ETF issuers** (partnerships).

#### The Framework: 4 Levels of Compliance Maturity

| Level                   | Description                        | Outcome                     |
| ----------------------- | ---------------------------------- | --------------------------- |
| **Basic**               | KYC once, store data               | Risk exposure               |
| **Smart**               | On-chain rules, attestations       | Basic institutional trust   |
| **ZK**                  | Privacy-preserving proofs          | EU/GDPR readiness           |
| **Institutional-grade** | Continuous compliance + revocation | Eligible for global capital |

#### Tools

* **Trust Registries** (curate issuers).
* **ZK Identity Tokens** (scalable proofs).
* **Compliance SDK** (plug-and-play for DeFi).

{% hint style="info" %}
**Takeaway**: Compliance isn’t a checkbox, it’s a moat. Build it right, and institutions can’t ignore you.
{% endhint %}


# Counterparty Risk in DeFi: The Invisible Exposure

#### *In TradFi, you know your counterparty. In DeFi, sometimes you don’t even know they exist.*

Institutions entering DeFi aren’t just worried about protocols, they’re worried about **who else is in the pool with them.**

In TradFi, counterparty risk is managed with contracts, audits, and credit checks. In DeFi, liquidity is pooled, pseudonymous, and borderless. That’s both the opportunity and the threat.

***

#### The Risks

* **Anonymous counterparties** → Anyone, anywhere, can join a pool.
* **Regulatory contagion** → One sanctioned address can taint the entire pool.
* **Default risk** → Borrowers in lending pools disappear without recourse.
* **Reputational exposure** → “Guilt by association” headlines can spook LPs and regulators alike.

***

#### Why This Matters

Institutions can’t allocate billions into pools without **knowing who they’re standing next to.**

If one wallet is later linked to illicit activity:

* Custodians may freeze assets.
* Regulators may investigate *all* participants.
* Institutions may face write-downs due to reputational harm.

Counterparty risk is **not about code exploits,** it’s about *who shares the pool*.

***

#### The Solution: Identity-Layered Counterparty Checks

Fairway’s decentralized compliance stack turns opaque pools into **credential-gated venues**:

```mermaid
flowchart TD
    A[Pool Participation] --> B{Identity Token Valid?}
    B -->|No| C[Access Denied]
    B -->|Yes| D[Whitelisted Pool]
    D --> E[Institutions see: 'All participants verified']

```

* **Identity Tokens** → Ensure counterparties have passed accredited KYC/AML.
* **Trust Registries** → Only allow issuers recognized by regulators.
* **Policy Engines** → Filter counterparties by jurisdiction, accreditation, or risk profile.
* **ZK-Proofs** → Prove eligibility without revealing identities.

***

#### Framework: Counterparty Risk Playbook

{% stepper %}
{% step %}
**Define**

What counterparties can your pool accept? (e.g., only accredited investors, only EU-based institutions).
{% endstep %}

{% step %}
**Verify**

KYC counterparties via vaults + ZK proofs.
{% endstep %}

{% step %}
**Tokenize**

Issue compliance tokens to verified participants.
{% endstep %}

{% step %}
**Gate**

Enforce policy at smart contract level.
{% endstep %}

{% step %}
**Monitor**

Continuous revocation if status changes (sanctions, expired docs).
{% endstep %}
{% endstepper %}

***

#### TradFi vs. DeFi Counterparty Risk Management

| TradFi                   | DeFi without Compliance | DeFi with Fairway               |
| ------------------------ | ----------------------- | ------------------------------- |
| Credit checks, contracts | Anonymous addresses     | Credentialed participants       |
| KYC at onboarding        | No onboarding checks    | Ongoing proof of eligibility    |
| Bilateral contracts      | Shared pools            | Policy-gated pools              |
| Regulator oversight      | Grey zone               | Transparent auditability via ZK |

***

{% hint style="info" %}
**Takeaway**: Counterparty risk in DeFi is invisible until it isn’t.

Credential-gated pools transform “unknown counterparties” into “trusted participants” without sacrificing privacy.
{% endhint %}


# Introduction to Digital Identity & Verifiable Credentials

(Setting the foundation for decentralized identity and trustless verification)


# What is Digital Identity?

(How wallets work, use cases, interoperability.)

Digital identity refers to the electronic representation of an individual, organization, or device within an online system. Digital identity can be used for **authentication, verification, and access control** across various platforms.

***Setting the foundation for decentralized identity and trustless verification)***

In a world where online interactions are increasingly becoming the norm, the demand for secure, privacy-preserving, and interoperable identity solutions is more pressing than ever. Traditional identity systems — relying heavily on centralized databases, usernames, passwords, and physical documents — suffer from inherent vulnerabilities like data breaches, identity theft, and the misuse of personal information.

**The Problem with Centralized Identity Systems**

* ❌ **Single points of failure:** Centralized databases are prime targets for hackers, risking mass data breaches.
* ❌ **Lack of user control:** Individuals have limited control over their own personal data.
* ❌ **Siloed verification processes:** Trust is fragmented, with organizations maintaining their own proprietary systems for identity verification.

#### **The Decentralized Alternative: Self-Sovereign Identity (SSI)**

Self-Sovereign Identity (SSI) offers a revolutionary approach where individuals have complete ownership and control over their digital identity. Rather than relying on centralized systems, SSI allows users to manage and share their credentials securely, using blockchain and cryptographic standards.

✅ **User Control:** Individuals fully control their credentials — no third party can alter, revoke, or misuse them.\
✅ **Privacy-Preserving:** Data is shared only when necessary, through **Zero-Knowledge Proofs (ZKPs)** if desired.\
✅ **Interoperable:** Works across different systems, jurisdictions, and technologies.

#### **How SSI Works: The Basics**

SSI is built on three foundational components:

1. **🪪 Issuers:**\
   Organizations or institutions that create and issue credentials.
   * Examples: Governments issuing national IDs (e.g., Fayda ID in Ethiopia), Universities issuing degrees and diplomas.
   * Credentials are signed cryptographically to ensure authenticity and integrity.
2. **👤 Holders:**\
   Individuals who receive, store, and manage their credentials in a digital wallet (e.g., Fairway Wallet).
   * Credentials are stored locally and securely, providing users with complete control.
   * Users decide what information to share, with whom, and for what purpose.
3. **🔍 Verifiers:**\
   Entities that request proof of credentials for verification purposes.
   * Examples: Embassies, employers, universities, banks, or regulatory bodies.
   * Verification is achieved without the need to contact the original issuer, thanks to cryptographic proof mechanisms.

#### **The Role of Verifiable Credentials (VCs)**

At the core of SSI are **Verifiable Credentials (VCs)** — digitally signed statements issued by trusted parties (issuers) to prove various aspects of an individual’s identity or qualifications.

* VCs are tamper-proof, cryptographically signed, and instantly verifiable without requiring a central database.
* Built on global standards like **W3C DID (Decentralized Identifiers)** and **VC frameworks** compatible with **eIDAS 2.0, EUDI, MOSIP, and OpenID**.

#### **Why SSI Matters for Governments & Organizations**

SSI enables reliable, privacy-respecting, and instant verification of credentials for various purposes:

* 🌍 **Immigration & Work Visas:** Governments can verify educational credentials and identity documents without manual checking.
* 💼 **Employment & Recruitment:** Employers can access authentic, verified credentials instantly, reducing fraud and speeding up the hiring process.
* 🏛️ **Universities & Certification Bodies:** Credentials can be issued in a secure, tamper-proof format, enhancing credibility and global interoperability.

#### **Fairway’s Role in the SSI Ecosystem**

Fairway offers a robust SSI-based system designed to integrate seamlessly with national ID systems (like Fayda in Ethiopia), universities, and businesses to provide verified credentials that are easily shareable and instantly verifiable.

* **For Governments:** Enable trusted, verifiable digital IDs for workforce mobility and immigration.
* **For Universities:** Provide graduates with secure, blockchain-backed diplomas and certificates that are universally trusted.
* **For Employers:** Receive credentials that are instantly verifiable and resistant to fraud.

Fairway leverages **Verifiable Credentials (VCs)** to ensure that credentials can be trusted globally — whether they are issued by a national ID system, a university, or a private certifier. By integrating these credentials into a seamless system, Fairway enables real-time, cross-border verification for a wide range of use cases.

#### **Traditional Identity Models vs. Decentralized Identity**

| **Traditional Identity Models**                                              | **Decentralized Identity (SSI)**                                       |
| ---------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| Identity controlled by centralized institutions (governments, corporations). | Identity is user-controlled and stored in self-sovereign wallets.      |
| Relies on third-party databases for verification.                            | Uses cryptographic proof and Verifiable Credentials.                   |
| Prone to data breaches and identity theft.                                   | Privacy-first with selective disclosure.                               |
| Requires repetitive identity verification across different services.         | One-time issuance of credentials, reusable for multiple verifications. |
| Limited interoperability between systems.                                    | Open standards (DIDs, VCs) ensure seamless interoperability.           |

Decentralized identity solutions aim to **eliminate the reliance on intermediaries**, ensuring that individuals and organizations retain full control over their credentials while enhancing **trust, privacy, and security**.

Fairway’s SSI approach offers security, privacy, and interoperability. As governments and institutions around the world continue to adopt decentralized identity standards, Fairway provides the necessary infrastructure to ensure seamless, trusted interactions across borders.

🔗 **Sources:**

* Sovrin Foundation - Self-Sovereign Identity: <https://sovrin.org/>
* W3C DID Core Specification: <https://www.w3.org/TR/did-core/>


# Verifiable Credentials

(How VCs work, W3C standards, global trust frameworks.)

**📜 Verifiable Credentials – Trust That Travels With You**

Verifiable Credentials (VCs) are digitally signed statements issued by trusted entities that allow individuals and organizations to **prove claims about their identity, skills, or qualifications** without revealing unnecessary personal information. VCs provide a **tamper-proof, cryptographically secure** method of verifying information across different platforms and jurisdictions.

<figure><img src="https://3812774301-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlfDULdwa6BuKx0DZyvBO%2Fuploads%2FCcmWtIOTf3UCa10Y5UTK%2FHow%20it%20works%202%20-%20verifiable%20credentials.png?alt=media&amp;token=024c3983-ce62-45ee-af8f-fa9ba0ff3df0" alt=""><figcaption><p>Fairway Professional Credentials</p></figcaption></figure>

#### **How Verifiable Credentials Work**

1. **Issuance** – A trusted entity (Issuer) digitally signs and issues a credential to a user’s digital wallet.
2. **Storage** – The user (Holder) securely stores the credential in their self-sovereign identity (SSI) wallet.
3. **Verification** – A verifier (Employer, Bank, Government) requests proof of specific information, and the user shares only the required details.

#### **Key Features of VCs:**

* **Privacy-Preserving** – Users can share minimal data through **Selective Disclosure**.
* **Interoperable** – Adheres to **W3C Verifiable Credentials Standard**, ensuring compatibility across platforms.
* **Tamper-Proof** – Cryptographic signatures prevent credential forgery or alteration.
* **Cross-Border Trust** – Supported by frameworks like **EUDI, eIDAS 2.0, and EBSI**.

🔗 **Sources:**

* W3C Verifiable Credentials Data Model: <https://www.w3.org/TR/vc-data-model/>
* European Blockchain Services Infrastructure (EBSI): <https://ec.europa.eu/digital-building-blocks/wikis/display/EBSI>


# The Trust Triangle

🔗 The Trust Triangle: Issuer, Holder, Verifier

The **Trust Triangle** is the foundation of Verifiable Credentials and Decentralized Identity. It ensures that **identity verification is decentralized, secure, and user-controlled**.

<figure><img src="https://3812774301-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlfDULdwa6BuKx0DZyvBO%2Fuploads%2F8euZHOUA7WBkEsx87AlV%2FHow%20it%20works%207%20-%20trust%20triangle%20white.png?alt=media&amp;token=d8d5a0c8-37fc-4b08-9b3e-d1a7a5f89c92" alt=""><figcaption></figcaption></figure>

#### **1️⃣ Issuer**

A **trusted authority** (government, university, employer, financial institution) **creates and digitally signs Verifiable Credentials (VCs)**. These credentials confirm facts such as **educational qualifications, work experience, or identity documents**.

#### **2️⃣ Holder**

The **individual or organization** that receives, stores, and manages credentials in their **digital identity wallet**. Holders can **selectively disclose** parts of their credentials when needed.

#### **3️⃣ Verifier**

An **entity (business, government agency, online service)** that requests and verifies specific identity attributes from a user’s credentials without accessing excessive personal data.

#### **How the Trust Triangle Works**

1. **Issuer** (e.g., a university) signs and issues a diploma as a **Verifiable Credential (VC)**.
2. **Holder** (graduate) stores the diploma in their **self-sovereign identity wallet**.
3. **Verifier** (potential employer) requests proof of degree completion. The graduate shares the credential via cryptographic proof without revealing unnecessary personal details.

🔗 **Sources:**

* W3C Verifiable Credentials Trust Model: <https://www.w3.org/TR/vc-data-model/>
* European Digital Identity Framework (EUDI): <https://ec.europa.eu/digital-building-blocks/wikis/display/EUDI>


# Decentralized Identifiers (DIDs) and SSI

(W3C DID standard, interoperability, privacy control.)

**Decentralized Identifiers (DIDs) and Their Role in SSI**

#### **What Are Decentralized Identifiers (DIDs)?**

DIDs are **unique, self-controlled identifiers** that allow individuals and organizations to **authenticate and verify themselves across digital platforms** without relying on centralized identity providers (such as Facebook, Google, or government agencies). Unlike traditional email-based or username-password authentication, **DIDs are cryptographically secure and interoperable across different identity systems**.

#### **How DIDs Work in Self-Sovereign Identity (SSI)**

* A **user generates a DID** through their digital wallet.
* The DID is **linked to a cryptographic key pair**.
* Users can **sign identity proofs** using their **private key** and share them with verifiers without revealing their private data.
* DIDs can be resolved and verified on **decentralized networks**, such as **Hyperledger, Ethereum, Cardano, and EBSI**.

#### **Privacy Control & Interoperability**

* **DIDs support Zero-Knowledge Proofs (ZKPs)** for privacy-preserving verification.
* **They enable user-controlled, self-sovereign identity solutions**.
* **Interoperable across blockchain networks and digital identity ecosystems.**

🔗 **Sources:**

* W3C Decentralized Identifiers Standard: <https://www.w3.org/TR/did-core/>
* Hyperledger Identity Solutions: <https://www.hyperledger.org/>

***

###


# Global Standards & Frameworks in Digital Identity

(Covering major SSI and digital identity frameworks globally)

<figure><img src="https://3812774301-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlfDULdwa6BuKx0DZyvBO%2Fuploads%2F5bmtEgv1maPsQa9S2Wy9%2FHow%20it%20works%203%20-%20cross%20border%20identity.jpg?alt=media&amp;token=18814b68-3a2d-46e5-bace-98ca19bbd841" alt=""><figcaption></figcaption></figure>


# W3C Standards

W3C Standards and Related Technologies

### Introduction

The World Wide Web Consortium (W3C) is an international community that develops open standards to ensure the long-term growth of the Web. W3C standards aim to provide interoperability, accessibility, and usability across the internet. These standards encompass various protocols, guidelines, and specifications for web technologies.

### W3C Standards

W3C standards cover multiple areas of the web, including:

* **HTML (Hypertext Markup Language):** The standard markup language for creating web pages.
* **CSS (Cascading Style Sheets):** A style sheet language used for describing the presentation of a document written in HTML or XML.
* **XML (Extensible Markup Language):** A flexible way to create structured documents and transmit data over the internet.
* **WebRTC:** Protocols enabling real-time communication over peer-to-peer connections.
* **WebAuthn:** A web standard for passwordless authentication based on public-key cryptography.
* **Decentralized Identifiers (DIDs):** A key component of the W3C’s efforts towards a decentralized web.
* **Verifiable Credentials:** A standard for expressing, transmitting, and verifying cryptographically secure, privacy-respecting digital credentials.

### W3C DID Standards and Related Technologies

The W3C Decentralized Identifiers (DIDs) standard is a foundational component of the decentralized web. It is designed to allow individuals, organizations, and machines to have identifiers that are:

* **Self-sovereign:** Not controlled by a central authority.
* **Cryptographically secure:** Using public-key cryptography to prove ownership and control.
* **Interoperable:** Designed to work across various platforms and technologies.

#### Decentralized Identifiers (DIDs)

The DID specification provides a standard mechanism for creating, resolving, updating, and deactivating decentralized identifiers. Key aspects include:

* **DID Documents:** JSON-LD documents that describe the cryptographic material and associated metadata needed to interact with the DID.
* **DID Methods:** Various approaches for creating and managing DIDs across different decentralized networks (e.g., blockchains, distributed ledgers).
* **DID Resolution:** The process of retrieving the associated DID Document using a DID.
* **DID Controllers:** Entities that have the capability to make updates to a DID Document.
* **Authentication:** Mechanisms for proving control over a DID using cryptographic methods.

#### Verifiable Credentials (VCs)

Verifiable Credentials are closely tied to DIDs and provide a standard way to express statements about an entity in a secure, privacy-preserving manner. Key aspects include:

* **Issuer:** The entity that creates and signs a credential.
* **Holder:** The entity that owns or possesses the credential.
* **Verifier:** The entity that checks the authenticity of a credential.
* **Presentation:** A collection of verifiable credentials provided by the holder to the verifier.
* **Proof Mechanisms:** Typically achieved using digital signatures linked to DIDs.

#### W3C DID Standards in Context

The DID standard is particularly relevant to:

* **Self-Sovereign Identity (SSI):** Providing a user-centric, decentralized approach to identity management.
* **Blockchain Technology:** Serving as a base layer for decentralized identifiers and credentials.
* **eIDAS and EUDI:** Integrating decentralized identities with European digital identity frameworks.
* **MOSIP:** Utilizing DIDs for foundational identity systems to enhance interoperability and privacy.

### Conclusion

W3C standards, particularly those related to DIDs and Verifiable Credentials, are essential for building a decentralized, interoperable, and secure digital ecosystem. As these technologies continue to evolve, W3C’s contributions remain pivotal for fostering innovation and ensuring compatibility across various platforms.

### Sources

* [W3C Official Website](https://www.w3.org/)
* [Decentralized Identifiers (DIDs) – W3C](https://www.w3.org/TR/did-core/)
* [Verifiable Credentials – W3C](https://www.w3.org/TR/vc-data-model/)
* [SSI Frameworks and Protocols](https://www.ssicoop.eu/)
* [eIDAS Regulation](https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation)
* [EUDI Wallet Initiative](https://digital-strategy.ec.europa.eu/en/library/european-digital-identity)
* [MOSIP Official Site](https://www.mosip.io/)


# 🇪🇺eIDAS & eIDAS 2.0: The European Digital Identity Framework

As the digital landscape evolves, the European Union has recognized the need for a more robust and user-centric digital identity framework. This recognition has led to the development of eIDAS 2.0, an updated regulation designed to enhance electronic identification and trust services across EU member states. Understanding eIDAS 2.0 is crucial for entities such as governments, universities, and regulated businesses, as it directly impacts how digital identities are managed and authenticated within the EU.

### Evolution from eIDAS to eIDAS 2.0

The original eIDAS regulation, established in 2014, provided a unified framework for electronic identification and trust services, aiming to facilitate secure cross-border transactions within the EU. While it laid the groundwork for digital interactions, rapid technological advancements and increased digitalization necessitated an update. In April 2024, Regulation (EU) 2024/1183 was published, introducing eIDAS 2.0, which came into force on May 20, 2024.

### Key Features of eIDAS 2.0

#### European Digital Identity Wallet

A cornerstone of eIDAS 2.0 is the introduction of the European Digital Identity Wallet. This digital wallet allows EU citizens, residents, and businesses to store and manage their identity data and official documents electronically. Users can securely access various services across member states, such as e-government platforms, banking, and healthcare, using this wallet. The wallet emphasizes user control, enabling individuals to decide which data to share and with whom, thereby enhancing privacy and security.

#### Reusable Digital Identities

eIDAS 2.0 promotes the concept of reusable digital identities, allowing individuals and entities to create a single digital identity that can be used across multiple services and platforms. This approach reduces the need for repetitive verification processes, streamlining interactions and enhancing user experience. For businesses, this means simplified customer onboarding and reduced administrative overhead.&#x20;

#### Enhanced Trust Services

The regulation expands the scope of trust services, which are essential for secure digital transactions. These services now include electronic signatures, seals, time stamps, and website authentication certificates. By standardizing these services across the EU, eIDAS 2.0 ensures that digital transactions are reliable and legally recognized, fostering trust among users and service providers.

### Implications for Governments, Universities, and Regulated Businesses

#### Governments

For governmental bodies, eIDAS 2.0 facilitates the provision of secure and efficient e-government services. Citizens can access public services using their digital identity wallets, simplifying processes such as tax filings, license applications, and social service access. This not only enhances user experience but also streamlines administrative operations.

#### Universities

Academic institutions can leverage eIDAS 2.0 to issue and verify digital academic credentials, such as diplomas and certificates. This ensures the authenticity of qualifications and simplifies the verification process for employers and other educational institutions. Additionally, universities can facilitate cross-border student mobility by recognizing digital identities from other member states, aligning with initiatives like the European Student Card. ​

#### Regulated Businesses

Businesses operating in regulated sectors, such as finance and healthcare, benefit from standardized and secure digital identification processes. eIDAS 2.0 enables seamless customer onboarding, reduces fraud risk, and ensures compliance with regulatory requirements. By adopting the European Digital Identity Wallet, businesses can offer customers a secure and user-friendly authentication method, enhancing trust and satisfaction. ​

### Implementation Timeline and Compliance

Member states are required to offer at least one European Digital Identity Wallet to all citizens, residents, and businesses by 2026. The European Commission has outlined specific deadlines for establishing standards and specifications, with a notable milestone on November 21, 2024, for setting reference criteria and verification procedures for the digital ID wallet. ​

Entities must assess their current digital identity systems and plan for integration with the new framework. This includes ensuring interoperability with the European Digital Identity Wallet and compliance with the enhanced trust service standards. Early adoption and proactive planning will be key to leveraging the benefits of eIDAS 2.0 and maintaining a competitive edge in the evolving digital landscape.​

### Conclusion

eIDAS 2.0 represents a significant advancement in the EU's approach to digital identity and trust services. By introducing the European Digital Identity Wallet, promoting reusable digital identities, and enhancing trust services, the regulation aims to create a secure, user-centric, and interoperable digital environment. Governments, universities, and regulated businesses must understand and adapt to these changes to harness the full potential of eIDAS 2.0 and continue to provide secure and efficient services in the digital age.

#### Sources

* European Commission: [eIDAS Regulation Overview](https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation)
* EUR-Lex: [Regulation (EU) 2024/1183 on eIDAS 2.0](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1183)
* European Digital Identity Wallet Pilot Projects: [Official Portal](https://digital-strategy.ec.europa.eu/en/policies/european-digital-identity)
* European Commission FAQs on the EUDI Wallet: [ec.europa.eu](https://ec.europa.eu/commission/presscorner/detail/en/qanda_21_2663)
* ENISA: [Trust Services and eID in the EU](https://www.enisa.europa.eu/topics/trust-services)
* OpenID Foundation: OpenID4VC Specifications
* Dock.io blog (for context): [Dock on eIDAS 2.0](https://www.dock.io/post/eidas-2)


# 🇪🇺EUDI Wallet: Europe’s Digital Identity Initiative

The European Union is introducing the European Digital Identity (EUDI) Wallet, a secure digital platform designed to enable citizens, residents, and businesses to authenticate their identity and access services across member states. This initiative aims to streamline digital interactions while enhancing security and user control over personal data.

**Key Features of the EUDI Wallet:**

* **Secure Identification:** Users can verify their identity online and offline, facilitating access to services such as banking, healthcare, and education. ​
* **Document Storage and Sharing:** The wallet allows storage and selective sharing of digital documents like ID cards, diplomas, and medical prescriptions, simplifying various administrative processes.
* **Legally Binding Digital Signatures:** Users can create legally binding electronic signatures, streamlining transactions and document approvals.

**Implications for Stakeholders:**

* **Governments:** The EUDI Wallet enhances the delivery of public services by providing a standardized digital identity framework, reducing fraud, and improving administrative efficiency.
* **Universities:** Academic institutions can issue and verify digital credentials, facilitating student mobility and simplifying enrollment and verification processes. ​
* **Regulated Businesses:** Sectors like finance and healthcare benefit from streamlined customer onboarding, improved compliance with Know Your Customer (KYC) regulations, and reduced identity fraud.

By 2026, EU member states are expected to provide the EUDI Wallet to citizens and businesses, marking a significant step toward a unified and secure digital identity framework across Europe.\ <br>

**Sources**:

1. **European Commission – EUDI Wallet Overview**

   <https://ec.europa.eu/digital-building-blocks/sites/display/EUDIGITALIDENTITYWALLET/What+is+the+Wallet>
2. **European Commission – Digital Identity Policy**

   <https://digital-strategy.ec.europa.eu/en/policies/european-digital-identity>
3. **CRIIPTO Blog – EUDI Wallet Explained**

   <https://www.criipto.com/blog/eudi-wallet>
4. **Daon – Impact of EUDI Wallet on Business**

   <https://www.daon.com/resource/how-will-eudi-wallets-affect-your-business>
5. **European Commission – Press Corner (Q\&A on EUDI Wallet)**

   <https://ec.europa.eu/commission/presscorner/detail/en/qanda_21_2663>
6. **EU Digital Identity Architecture and Reference Framework**

   <https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/1.4.0/arf>


# 🇪🇺EBSI: Blockchain-Powered Trust in the EU

The **European Blockchain Services Infrastructure (EBSI)** is a pioneering initiative launched by the European Commission in collaboration with the **European Blockchain Partnership (EBP)**, which includes all EU Member States, Norway, and Liechtenstein. Established in 2018, EBSI aims to leverage blockchain technology to enhance the efficiency, security, and transparency of cross-border public services across Europe.

EBSI operates as a peer-to-peer network of interconnected nodes distributed throughout Europe. Each participating country manages at least one node, collectively forming a decentralized infrastructure that supports various applications focused on selected use cases. This design ensures resilience, promotes interoperability, and upholds European values and regulations.

**Key Use Cases of EBSI:**

* **Digital Diplomas:** EBSI enables the issuance and verification of educational credentials, allowing citizens to share their qualifications across borders easily.
* **Self-Sovereign Identity (SSI):** The infrastructure supports the development of decentralized identity frameworks, empowering individuals with control over their personal data. ​
* **Trusted Data Sharing:** EBSI facilitates secure and verifiable data exchange between governments, businesses, and citizens, enhancing trust in digital interactions. ​
* **Document Traceability:** The platform provides mechanisms for notarization and traceability of documents, reducing fraud and ensuring authenticity. ​

By integrating blockchain technology into public services, EBSI aims to streamline administrative processes, reduce fraud, and foster trust among EU citizens and institutions. Its commitment to open standards and interoperability positions EBSI as a foundational component in Europe's digital transformation journey.​

**Sources**:

1. **European Commission – EBSI Policy Overview**

   <https://digital-strategy.ec.europa.eu/en/policies/european-blockchain-services-infrastructure>
2. **European Blockchain Services Infrastructure – Official EBSI Portal**

   <https://ec.europa.eu/digital-building-blocks/sites/display/EBSI>
3. **European Blockchain Partnership (EBP)**

   <https://digital-strategy.ec.europa.eu/en/policies/european-blockchain-partnership>
4. **European Commission – EBSI Use Cases and Technical Docs**

   <https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/EBSI+Use+Cases>
5. **North Sea Region Report – EBSI Explained by Daniel Du Seuil**

   <https://northsearegion.eu/media/16680/ebsi-explained-by-daniel-du-seuil.pdf>
6. **EQAR – European Qualifications and EBSI**

   <https://www.eqar.eu/qa-results/synergies/european-blockchain-service-infrastructure-ebsi>


# MOSIP: Open-Source Identity for Governments

In an era where digital transformation is pivotal, establishing secure and adaptable digital identity systems is essential for effective governance and service delivery. The Modular Open Source Identity Platform (MOSIP) emerges as a transformative solution, offering governments, universities, and regulated businesses a robust framework to develop and manage digital identities.​

### Understanding MOSIP

MOSIP is an open-source platform designed to assist nations in creating foundational digital identity systems. Incubated at the International Institute of Information Technology, Bangalore (IIIT-B) in 2018, MOSIP provides a modular and scalable architecture that enables countries to tailor identity solutions to their unique requirements. By emphasizing principles such as modularity, security, and inclusivity, MOSIP empowers nations to build systems that are transparent, customizable, and free from vendor lock-in.&#x20;

### Key Features of MOSIP

#### Modularity

MOSIP's modular design allows for flexible integration of various components, enabling governments to customize their identity systems according to specific needs. This flexibility ensures that as technological landscapes evolve, the identity system can adapt without necessitating a complete overhaul.&#x20;

#### Open-Source Framework

As an open-source platform, MOSIP promotes transparency and collaboration. Governments have access to the source code, allowing for customization and fostering innovation through contributions from a global community of developers. This approach not only reduces costs but also mitigates the risks associated with proprietary systems.&#x20;

#### Security and Privacy

Prioritizing the protection of personal information, MOSIP incorporates robust security measures, including cryptographic encryption and zero-knowledge architecture. These features ensure that data remains secure both in transit and at rest, with individuals retaining control over their information. Data sharing occurs only with the individual's consent, reinforcing trust in the system.

#### Scalability

Designed to accommodate large populations, MOSIP's architecture supports scalability, making it suitable for countries with diverse and expansive demographics. This ensures that the system remains efficient and responsive as the number of users grows.

#### Vendor Neutrality

MOSIP's vendor-neutral approach allows governments to integrate with a wide range of compliant technology partners. Through the MOSIP Partner Programme and Marketplace, countries can select and update their technology solutions freely, avoiding dependency on a single vendor and fostering a competitive ecosystem.

### Implications for Governments, Universities, and Regulated Businesses

#### Governments

For governmental bodies, MOSIP offers a pathway to develop and implement national digital identity systems that are secure, inclusive, and cost-effective. By adopting MOSIP, governments can enhance public service delivery, streamline administrative processes, and ensure that citizens have reliable access to services such as healthcare, education, and social welfare. The platform's emphasis on data security and privacy aligns with the need to protect citizen information, thereby fostering trust in digital initiatives.

#### Universities

Academic institutions can leverage MOSIP to issue and manage digital credentials securely. By integrating MOSIP, universities can provide students with verifiable digital identities, facilitating seamless access to educational resources, online platforms, and cross-institutional collaborations. This not only enhances the student experience but also streamlines administrative tasks related to enrollment, record-keeping, and certification.​

#### Regulated Businesses

For businesses operating in regulated sectors such as finance and healthcare, MOSIP provides a framework to implement secure and compliant digital identity verification processes. This enables efficient customer onboarding, reduces fraud, and ensures adherence to regulatory standards. By adopting MOSIP, businesses can enhance operational efficiency and build customer trust through robust identity management practices.​

### Implementation and Global Adoption

Since its inception, MOSIP has seen adoption and interest from various countries aiming to establish or upgrade their digital identity systems. Nations such as Ethiopia, Morocco, and the Philippines have engaged with MOSIP to pilot and implement national ID programs, demonstrating the platform's versatility across different contexts. These implementations highlight MOSIP's potential to bridge the identity gap affecting millions worldwide, providing individuals with legal and verifiable IDs essential for accessing various services.

### Conclusion

MOSIP stands as a significant advancement in the realm of digital identity management, offering a flexible, secure, and inclusive platform for governments, universities, and regulated businesses. By embracing MOSIP, stakeholders can develop tailored identity solutions that enhance service delivery, ensure data protection, and foster trust in digital interactions. As digital transformation continues to shape societies, platforms like MOSIP play a crucial role in building foundational infrastructures that are resilient, adaptable, and centered around the needs of individuals.

**Sources**:

1. **MOSIP Official Website – Overview and Architecture**\
   <https://www.mosip.io>
2. **MOSIP Documentation – Technical Guides and Modules**\
   <https://docs.mosip.io>
3. **MOSIP Use Cases and Implementing Countries**\
   <https://www.mosip.io/models\\_phases>
4. **MOSIP Partner Program & Marketplace**\
   <https://partners.mosip.io>
5. **MOSIP Blog and Media – Country Implementations**\
   <https://www.mosip.io/newsroom>
6. **World Bank – ID4D Initiative (Referenced Contextually)**\
   <https://id4d.worldbank.org>


# 🇪🇹Ethiopian Fayda National ID

Ethiopia's digital transformation has taken a significant leap forward with the introduction of the Fayda National ID, a unique 12-digit identification number issued to residents. This initiative, spearheaded by the National ID Program (NIDP) under the Office of the Prime Minister, aims to provide a secure and verifiable identity for all Ethiopians, facilitating seamless access to both public and private sector services.&#x20;

### Integration with MOSIP

The Fayda ID system is built upon the Modular Open Source Identity Platform (MOSIP), an open-source framework designed to assist countries in developing robust digital identity systems. By adopting MOSIP, Ethiopia benefits from a modular and scalable architecture that allows for customization to meet the nation's specific needs. This integration enables the Fayda ID to incorporate advanced biometric technologies, ensuring the uniqueness and security of each individual's identity.

### Key Features of the Fayda ID

* **Unique Identification Number**: Each resident is assigned a unique 12-digit Fayda number, serving as a foundational identifier across various services.
* **Biometric Data Integration**: The system captures biometric information, including fingerprints, facial photos, and iris scans, to prevent duplication and enhance security.
* **Digital and Physical Formats**: Residents receive their Fayda number via SMS and can request a printed card with a 2D barcode for offline authentication, accommodating areas with limited internet connectivity.

### Implications for Stakeholders

#### Governments

For governmental agencies, the Fayda ID streamlines the delivery of public services by providing a reliable means of identifying residents. It reduces fraud, enhances administrative efficiency, and supports initiatives such as social welfare distribution and tax collection. The centralized system also aids in policy formulation and implementation by offering accurate demographic data.​

#### Universities

Academic institutions can leverage the Fayda ID to verify student identities, simplifying enrollment processes and ensuring the integrity of academic records. It facilitates secure access to educational resources and can be integrated into campus management systems for attendance tracking and examination authentication.​

#### Regulated Businesses

In the financial sector, the National Bank of Ethiopia has mandated the use of the Fayda ID for opening new bank accounts, enhancing the Know Your Customer (KYC) processes and reducing identity fraud. This requirement underscores the ID's role in promoting financial inclusion and securing transactions. ​

### Implementation and Adoption

The NIDP has set ambitious targets, aiming to register 90 million residents by 2023. As of 2024, over 9 million residents have been enrolled. The program has successfully imported pre-existing records of 550,000 students, demonstrating the system's capability to integrate with existing databases and streamline the registration process.

### Conclusion

The Fayda National ID represents a transformative step in Ethiopia's digital journey, offering a secure, inclusive, and efficient means of identification. By building upon the MOSIP framework, Ethiopia has developed a system that not only addresses current identification challenges but also lays a foundation for future digital innovations. For governments, universities, and regulated businesses, the Fayda ID serves as a critical tool in enhancing service delivery, ensuring compliance, and fostering trust in digital interactions.

**Sources**:

1. **National ID Program of Ethiopia – Official Website**

   <https://www.id.gov.et>
2. **Wikipedia – Fayda ID**

   <https://en.wikipedia.org/wiki/Fayda_ID>
3. **Wikipedia – National ID Program (NIDP)**

   <https://en.wikipedia.org/wiki/National_ID_Program>
4. **MOSIP – Country Implementations (Ethiopia)**

   <https://www.mosip.io/models_phases>
5. **Aratek – National ID in Ethiopia**

   <https://www.aratek.co/news/national-id-ethiopia-a-gateway-to-digital-id-empowerment>
6. **ID Tech Wire – Ethiopia Mandates Fayda ID for Bank Accounts**

   <https://idtechwire.com/ethiopia-mandates-faida-digital-id-system-for-new-bank-accounts-in-addis-ababa>


# OpenID for Verifiable Credentials

**OpenID: Powering Secure and Seamless Digital Identity**

**OpenID** is an open standard and decentralized authentication protocol that allows users to log into multiple websites with a single set of credentials, improving both convenience and security. Instead of creating new usernames and passwords for every site, users can authenticate through a trusted identity provider (IdP), such as Google, Microsoft, or a government digital ID system.

#### Key Benefits of OpenID

* **User Convenience**: One login across services means fewer passwords to remember and manage.
* **Stronger Security**: OpenID reduces the risk of password reuse and phishing attacks by delegating authentication to secure, trusted identity providers.
* **Federated Identity**: Enables organizations to accept identities issued by other trusted sources—useful for governments, universities, and regulated businesses seeking cross-platform interoperability.
* **Open Standards**: As an open protocol, OpenID is supported by a global community and continually evolves to meet modern identity and privacy needs.

#### OpenID Connect

The most widely adopted version today is **OpenID Connect**, which layers identity on top of the OAuth 2.0 protocol. It provides identity tokens (ID tokens) in JSON Web Token (JWT) format, making it easy to integrate into modern web and mobile applications.

#### Relevance to Digital Identity Ecosystems

OpenID Connect is now foundational to many national and international digital identity frameworks, including:

* **EUDI Wallet** (EU Digital Identity): Uses OpenID for Verifiable Credentials (OpenID4VC) to enable secure sharing of digital credentials.
* **MOSIP**: Integrates OpenID for authentication between relying parties and identity providers in decentralized identity architectures.

#### Conclusion

OpenID is a critical building block for secure, user-centric digital identity systems. Its widespread adoption and compatibility with privacy-first approaches make it essential for governments, academic institutions, and businesses navigating digital transformation.

**Sources**:

1. **OpenID Foundation – Official Website**

   <https://openid.net>
2. **OpenID Connect Specification**

   <https://openid.net/connect>
3. **OpenID for Verifiable Credentials (OpenID4VC)**

   <https://openid.net/wg/abcd/>

   *(Working group for OpenID4VCI and OpenID4VP protocols)*
4. **European Commission – Digital Identity and EUDI Wallet (for OpenID4VC use)**

   <https://ec.europa.eu/digital-building-blocks>
5. **MOSIP Documentation – OpenID Bridge Developer Guide**

   <https://docs.mosip.io/1.2.0/modules/commons/openid-bridge-developer-guide>
6. **OpenID Foundation – Introduction to OpenID Connect**

   <https://openid.net/developers/how-connect-works/>


# Decentralized Identity Foundation (DIF) (Interoperability efforts across Web2 & Web3.)

The **Decentralized Identity Foundation (DIF)** is a collaborative, engineering-driven organization dedicated to developing the foundational components necessary for an open, standards-based, decentralized identity ecosystem. Established to ensure interoperability among all participants, DIF focuses on creating tools and protocols that empower individuals, organizations, applications, and devices to manage digital identities securely and privately.&#x20;

**Mission and Objectives:**

DIF's primary mission is to establish a decentralized identity framework that reduces reliance on centralized authorities, thereby enhancing user control over personal data. By fostering the development of open-source protocols and standards, DIF aims to create a robust ecosystem where digital identities are universally recognized and trusted. ​

**Key Initiatives and Contributions:**

* **Open Standards Development:** DIF actively contributes to the creation and promotion of open standards for decentralized identity, collaborating with global entities to ensure broad adoption and interoperability.
* **Open-Source Projects:** The foundation supports various open-source projects, including the Universal Resolver, which facilitates the resolution of decentralized identifiers (DIDs) across different methods, promoting a unified approach to digital identity.
* **Community Collaboration:** DIF serves as a hub for developers, organizations, and policymakers to collaborate on advancing decentralized identity technologies, hosting working groups and forums to address emerging challenges and opportunities. ​

**Impact and Industry Recognition:**

DIF's efforts have garnered support from various industry leaders and organizations. For instance, Block (formerly known as Square) has contributed digital identity components developed under its Web5 initiative to DIF, highlighting the foundation's role in shaping the future of digital identity. ​

**Conclusion:**

In an era where digital interactions are ubiquitous, the Decentralized Identity Foundation plays a crucial role in redefining how identities are managed online. By championing open standards and fostering collaboration, DIF contributes to building a more secure, private, and user-centric digital identity landscape.

**Sources**:

1. **DIF – Official Website**

   <https://identity.foundation>
2. **DIF GitHub – Open Source Projects and Working Groups**

   <https://github.com/decentralized-identity>
3. **DIF Working Groups Overview**

   <https://identity.foundation/working-groups.html>
4. **Block Inc. Contribution to DIF – Web5 Components**

   <https://block.xyz/inside/block-contributes-digital-identity-components-to-the-decentralized-identity-foundation>
5. **W3C – Decentralized Identifiers (DIDs) & Verifiable Credentials**

   <https://www.w3.org/TR/did-core/>

   <https://www.w3.org/TR/vc-data-model/>


# Digital Wallets

Your Identity, Owned by You (Exploring digital wallets, their standards, and use cases)


# What Are Digital Identity Wallets?

(How wallets work, use cases, interoperability.)

A **digital identity wallet** is a secure, cryptographic application that enables individuals and organizations to store, manage, and share **verifiable credentials (VCs)** linked to their identity. These wallets function as **trust anchors** in the digital world, allowing users to prove their identity and credentials in a privacy-preserving manner.

Unlike traditional identity systems that rely on centralized databases or intermediaries, digital identity wallets operate on principles of **self-sovereign identity (SSI)** and **decentralized identity**. This means that users have full control over their personal data and can selectively disclose only the necessary information without revealing unnecessary details.

#### **Key Features and Capabilities:**

* **Storage and Management of Multiple Credentials:** Digital wallets can securely hold various types of identity-related credentials, including:
  * **Government-issued IDs** (Passports, National IDs, eIDs, Personal Identity Documents - PID)
  * **Work and education records** (Degrees, certifications, employment history)
  * **Financial credentials** (Banking access, KYC compliance, credit history, cryptocurrency keys)
  * **Healthcare records** (Insurance details, vaccination certificates, medical prescriptions)
  * **Memberships and access rights** (Club memberships, digital keys, event passes)
* **Cryptographic Security:** These wallets leverage **public-key cryptography** and **decentralized identifiers (DIDs)** to ensure secure interactions. Private keys remain under user control, preventing unauthorized access and mitigating the risks of identity theft and fraud.
* **Selective Disclosure & Zero-Knowledge Proofs (ZKPs):** Users can **selectively share** only the necessary details from their credentials (e.g., proving age without disclosing birthdate). Some wallets incorporate **ZKPs** to allow verification without revealing underlying data.
* **Interoperability Across Platforms & Networks:** Many digital identity wallets are designed to work across various identity ecosystems, including **government services, financial institutions, healthcare providers, and online platforms**. Compliance with global standards like **W3C Verifiable Credentials (VC), ISO/IEC 18013-5 (mobile driver’s licenses), and eIDAS 2.0** ensures broad adoption.
* **Offline and Online Usability:** While most digital wallets function over the internet, some offer **offline verification capabilities**, making them useful in areas with limited connectivity.

#### **Use Cases and Benefits:**

* **Frictionless Digital Onboarding:** Enables faster and more secure registration processes for banks, employers, and online services without repetitive KYC checks.
* **Enhanced Privacy & Data Control:** Users decide what data to share, reducing the risk of data breaches and surveillance.
* **Secure Access & Authentication:** Functions as a digital alternative to passwords, enhancing security with biometric or cryptographic authentication.
* **Cross-Border Identity Verification:** Facilitates seamless international travel and remote work by providing globally recognized digital credentials.

#### **Emerging Standards and Regulations:**

Governments and regulatory bodies worldwide are increasingly recognizing the value of digital identity wallets. Notable initiatives include:

* **The European Digital Identity Wallet (EUDI)** – A standardized digital ID framework under **eIDAS 2.0**, allowing EU citizens to access government and private services securely.
* **Sovrin Foundation & Self-Sovereign Identity (SSI) Framework** – Advocates decentralized identity principles for global interoperability.
* **The World Economic Forum’s (WEF) Identity on the Blockchain Initiative** – Exploring blockchain-based identity verification models.

🔗 **Sources & Further Reading:**

* **Sovrin Foundation - Self-Sovereign Identity Principles:** <https://sovrin.org/self-sovereign-identity/>
* **European Digital Identity Wallet (EUDI):** <https://digital-strategy.ec.europa.eu/en/policies/electronic-identification>
* **W3C Verifiable Credentials Standard:** <https://www.w3.org/TR/vc-data-model/>
* **eIDAS 2.0 Digital Identity Regulation:** <https://digital-strategy.ec.europa.eu/en/library/eidas-2-proposal-european-digital-identity-framework>


# DIDs & VCs in Digital Wallets

(How wallets store and manage credentials.)

#### **Decentralized Identifiers (DIDs)**

DIDs are **globally unique identifiers** that allow individuals to control their identity without relying on a central issuing authority. Unlike traditional identifiers such as usernames or government-issued ID numbers, **DIDs are decentralized and can be resolved across various blockchain and identity networks**.

#### **How DIDs Work in Digital Wallets**

* A user generates a DID and **stores it in their digital wallet**.
* The DID is **linked to a cryptographic key pair**.
* The user can prove ownership of their DID using **cryptographic signatures**, enabling secure, private interactions online and offline.

#### **Verifiable Credentials (VCs)**

VCs are **digitally signed identity proofs** issued by trusted entities like governments, universities, or businesses. They allow users to prove claims about their identity, qualifications, or access rights without exposing excessive personal data.

#### **How VCs Work in Digital Wallets**

* An **issuer (e.g., a university)** signs a VC attesting to a claim (e.g., a diploma).
* The **credential is stored in the user's digital wallet**.
* When verification is needed, the user can **selectively disclose** the necessary information without revealing their entire identity.

#### **Benefits of DIDs & VCs in Digital Wallets**

* **User control & privacy** – No central authority can revoke or alter credentials.
* **Interoperability** – VCs can be used across **different identity networks, services, and borders**.
* **Fraud prevention** – Cryptographic signatures ensure **credentials are tamper-proof**.

🔗 **Sources:**

* W3C DID Standard: <https://www.w3.org/TR/did-core/>
* W3C Verifiable Credentials Data Model: <https://www.w3.org/TR/vc-data-model/>


# Cross-Border Identity Wallets: EUDI, MOSIP, OpenID

(Interoperability with major frameworks.)

#### **The Need for Cross-Border Digital Identity Wallets**

In today’s globalized world, identity verification should be **instant, trusted, and accessible across borders**. Traditional verification systems, which rely on **centralized databases, paper-based records, and national silos**, have created inefficiencies that hinder global mobility, workforce integration, and regulatory compliance.

**Cross-border identity wallets solve these challenges** by providing **a secure, digital-first solution** that allows individuals to carry their **verifiable identity credentials** across countries, industries, and online ecosystems. These wallets ensure that identity remains **portable, interoperable, and under user control** while adhering to regulatory requirements.

#### **European Digital Identity Wallet (EUDI)**

The **EUDI Wallet** is part of the European Union’s **eIDAS 2.0 initiative**, designed to create a **pan-European, interoperable digital identity system**. The EUDI Wallet enables EU citizens to **store, manage, and share** their official identity credentials securely while ensuring compliance with EU regulations.

#### **MOSIP – Open-Source Digital Identity for Governments**

MOSIP (**Modular Open Source Identity Platform**) is an open-source, government-backed framework for implementing **national digital identity systems**. It provides the infrastructure for **biometric and non-biometric identity verification**, particularly in **emerging economies**.

#### **OpenID – Bridging Traditional and Decentralized Identity**

OpenID is a widely used identity authentication protocol that allows users to **log in securely to websites and applications without creating multiple accounts**. The OpenID Foundation has expanded its efforts into **verifiable credentials** and **decentralized identity solutions**, bridging the gap between **Web2 authentication models and Web3 self-sovereign identity (SSI)**.


# Fairway Wallet: A Next-Generation Identity Solution

(Fairway’s approach to digital wallets and workforce mobility)

{% embed url="<https://www.youtube.com/watch?list=PLphtpkqE2Do3vgj_8L1GeMgXo_6yYYbQ3&v=Rr_NPcw8C78>" %}

### Meeting the Demand for Digital Identity Solutions in a Mobile Workforce

As the world rapidly shifts toward digital transformation, the need for secure, portable, and user-controlled digital identity solutions has never been more pressing. Millions of people worldwide face challenges related to proving their identity across borders, industries, and platforms. Whether it's verifying credentials for employment, accessing financial services, or complying with regulatory requirements, the traditional methods of identity verification are increasingly inadequate in the face of a mobile and global workforce.

According to the World Bank, nearly **one billion people** globally lack a legally recognized identity, creating barriers to economic participation. Additionally, **McKinsey reports** that companies lose billions annually due to inefficiencies in identity verification and fraud prevention. This growing demand for a decentralized, user-centric identity system has led to the rise of **Self-Sovereign Identity (SSI)**—a revolutionary model where individuals retain full control over their credentials without relying on centralized authorities.

Enter **Fairway Wallet**, a cutting-edge digital wallet designed to harness the power of **SSI and Verifiable Credentials (VCs)** to offer a seamless, secure, and compliant identity solution. Built on **Hyperledger Identus** and leveraging the power of **Cardano**, Fairway Wallet is taking digital identity to the next level with **unparalleled security, decentralization, scalability, and enterprise adoption potential**.

***

### How Fairway Uses SSI and Verifiable Credentials

Fairway Wallet leverages **Self-Sovereign Identity (SSI)** to empower users with complete control over their identity and credentials. Unlike traditional identity systems that require constant reliance on centralized databases or intermediaries, Fairway enables users to securely store, manage, and share their credentials **directly from their digital wallet**.

At the heart of Fairway’s innovation is its use of **Verifiable Credentials (VCs)**—tamper-proof, cryptographically signed digital credentials issued by trusted entities (e.g., employers, universities, government agencies). These credentials can be instantly verified by third parties without requiring continuous access to the issuing institution.

#### Key Benefits of Fairway Wallet:

* 🌍 **Global Accessibility:** Users can prove their identity and credentials across borders, industries, and platforms.
* 🔐 **Privacy-Preserving Verification:** Through the use of Zero-Knowledge Proofs (ZKPs), users can share only what’s necessary, safeguarding their privacy.
* 📱 **User-Friendly Experience:** An intuitive interface designed to enhance usability while ensuring high-level security.
* 💸 **Cost-Effective:** Eliminates costly intermediaries, providing a streamlined, efficient credentialing process.
* 🔑 **Full Ownership:** Users have complete control over their credentials, avoiding reliance on centralized databases.
* 🚀 **Seamless Integration:** Compatible with various identity systems including EUDI, eIDAS 2.0, OpenID, and MOSIP.
* 🛡️ **Built on Cardano and Hyperledger Identus:** Leveraging the robustness of Cardano's blockchain with the enterprise-grade identity management of Hyperledger Identus.

***

### Powered by Hyperledger Identus and Cardano

Fairway Wallet is **built on Hyperledger Identus**, a robust and enterprise-ready SSI framework designed for security, privacy, and interoperability. Hyperledger, a trusted name in decentralized identity solutions, provides a strong foundation for Fairway’s infrastructure, ensuring that identity verification is **trustless, transparent, and future-proof**.

**Hyperledger Identus**, formerly known as **Atala PRISM**, is developed by **Input Output Global (IOG)** and integrated into the **Hyperledger Foundation’s ecosystem**. Its architecture is designed to leverage **Decentralized Identifiers (DIDs)** and **Verifiable Credentials (VCs)** for creating secure, user-centric identity systems. Identus provides a layered approach to identity management involving:

* **Identity Creation and Registration:** Anchoring DIDs on the **Cardano blockchain**, ensuring immutability and authenticity.
* **Credential Issuance:** Providing tamper-proof credentials through trusted institutions.
* **Verification:** Using privacy-preserving mechanisms such as **Zero-Knowledge Proofs (ZKPs)**.
* **Revocation and Updating:** Allowing credentials to be updated or revoked with transparency.

The adoption of Hyperledger Identus ensures the future compatibility with standards like **GDPR** (already)**, eIDAS 2.0, and W3C Verifiable Credentials** (already). Its strong foundation within the **Hyperledger Foundation** also provides extensive developer resources and enterprise-grade governance.

Additionally, **Fairway is integrated with the Cardano blockchain**, widely recognized as the most **robust, scalable, and secure** blockchain for enterprise and governmental adoption. Cardano’s **proof-of-stake architecture** provides Fairway with unmatched sustainability, low transaction costs, and high resilience against security threats, making it the ideal backbone for digital identity solutions.

#### Enhanced Features in Fairway Wallet

* 🏢 **Enterprise-Level Trust:** Backed by Hyperledger Identus and Cardano, providing a secure, compliant, and scalable infrastructure.
* 🎓 **Credentialing for Education & Employment:** Issue, verify, and share educational degrees, employment certificates, and licenses.
* 💼 **Business Integration:** Works seamlessly with corporate KYC requirements, government frameworks, and financial institutions.
* 🌐 **Cross-Border Compatibility:** Designed to integrate with EUDI, eIDAS 2.0, MOSIP, and other global identity frameworks.
* 📈 **Continuous Upgrades:** Leveraging Hyperledger Identus for regular updates and improvements, ensuring compliance and interoperability.

***

### The Future of Digital Identity with Fairway Wallet

The world is moving towards **decentralized identity solutions**, and Fairway Wallet is leading the charge. By leveraging **Hyperledger Identus** and **Cardano**, Fairway is setting new standards for security, decentralization, and scalability in digital identity.

Fairway is **proud to be built on these cutting-edge technologies**—Hyperledger’s industry-leading identity framework ensures enterprise-grade trust, while Cardano provides an unmatched blockchain backbone for **global adoption**. With these technologies, Fairway Wallet is more than just a digital ID—it’s a **revolution in how identity is owned, verified, and shared**.

With **millions of users** seeking secure and frictionless ways to prove their identity, **Fairway Wallet is more than just a digital ID—it’s a passport to the future**. Whether it’s for work, travel, or online transactions, Fairway ensures that identity verification is seamless, trusted, and truly in the hands of the user.

***

### Sources

1. [World Bank – Identification for Development (ID4D)](https://id4d.worldbank.org/global-dataset)
2. [McKinsey & Company – The Value of Digital Identity](https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/digital-identification-a-key-to-inclusive-growth)
3. [World Economic Forum – A Blueprint for Digital Identity](https://www.weforum.org/reports/a-blueprint-for-digital-identity)
4. [Decentralized Identity Foundation (DIF)](https://identity.foundation/)
5. [W3C – Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/)
6. [Evernym – Self-Sovereign Identity Explained](https://www.evernym.com/blog/what-is-self-sovereign-identity/)
7. [Hyperledger Identus – Enterprise-Grade Self-Sovereign Identity](https://www.hyperledger.org/use/hyperledger-identus)
8. [Cardano Enterprise Adoption – Official Cardano Page](https://cardano.org/enterprise/)
9. [Cardano Foundation – Blockchain for Identity Verification](https://www.cardanofoundation.org/en/)
10. [GDPR Compliance & Digital Identity](https://gdpr.eu/what-is-gdpr/)
11. [eIDAS Regulation – European Commission](https://ec.europa.eu/digital-building-blocks/wikis/display/EIDAS/About+eIDAS)
12. [ISO 27001 – Information Security Management](https://www.iso.org/iso-27001-information-security.html)
13. [Hyperledger Indy – Decentralized Identity Blockchain](https://www.hyperledger.org/use/hyperledger-indy)
14. [MIT Digital Currency Initiative – Identity on the Blockchain](https://dci.mit.edu/)


# Blockchain & Digital Identity

(How blockchain enhances identity verification and compliance)

### **How Blockchain Enhances Identity Verification and Compliance**

Blockchain technology is revolutionizing digital identity by providing **a decentralized, tamper-proof infrastructure** for storing, managing, and verifying identity data. Unlike traditional systems that rely on centralized databases, blockchain acts as a **trust layer**, ensuring that identity credentials are **verifiable, secure, and resistant to fraud**.

By combining **self-sovereign identity (SSI)** principles with **public ledgers**, blockchain enables **trustless, user-controlled identity verification**. This section explores how blockchain strengthens digital identity systems, including **leading protocols, government experiments, zero-knowledge proofs, oracles, and identity-enabled decentralized applications (dApps).**


# Blockchain as a Trust Layer for Identity (How public ledgers enable verifiable identity.)

Public blockchains serve as **immutable ledgers** where **verifiable credentials (VCs)** and **decentralized identifiers (DIDs)** can be registered, anchored, or referenced. This allows verifiers to validate identity data **without depending on a single issuing authority**.

#### Key Benefits:

* **Decentralized Trust** – Eliminates reliance on centralized databases.
* **Auditability & Transparency** – Credential issuance and verification events can be tracked publicly.
* **Tamper-Proof Storage** – Records are immutable and cryptographically secured.

Public blockchains like **Cardano, Ethereum, and Polygon** are increasingly used to register DIDs, anchor VCs, or interact with smart contracts for identity verification.

🔗 Sources:

* World Economic Forum – Blockchain Identity: <https://www.weforum.org/>
* W3C DID Specification: <https://www.w3.org/TR/did-core/>


# Blockchain-Based Identity Systems: A Comparative Analysis

(Cardano, Ethereum, Polygon, KILT, Identus)

#### **Cardano**

* Focus on **regulatory compliance** and **identity-layer privacy**.
* Partners with **Identus** and **Midnight** for DID and ZK identity management.

#### **Ethereum**

* Used by **projects like uPort and SpruceID**.
* Flexible smart contract system supports **Verifiable Credential issuance and verification**.

#### **Polygon**

* Scalable Ethereum-compatible chain with **Verite and Polygon ID**.
* Enables **private proof generation and credential verification**.

#### **KILT Protocol**

* Built on Polkadot for **Web3 credentials** and reputation systems.
* Allows issuance of **claim-based identities**.

#### **Identus (Cardano-based)**

* Built for **SSI-compliant credential issuance** with strong W3C alignment.
* Integrates into **Fairway Wallet** and other regulated ID solutions.

#### **Cheqd**

* Focused on **decentralized credential monetization**.
* Offers DID & VC support with **incentive layers** and **trust registries**.

🔗 **Sources**:

* Cardano Atala PRISM: <https://www.atalaprism.io/>
* Polygon ID: <https://polygon.technology/polygon-id>
* KILT Protocol: <https://www.kilt.io/>
* Cheqd: <https://cheqd.io/>
* Identus: <https://www.identus.org/>


# EBSI & Public Blockchains: How Governments Are Experimenting

The **European Blockchain Services Infrastructure (EBSI)** is a **government-led initiative** exploring blockchain use for **identity, diplomas, and cross-border services**. Though initially launched on **permissioned ledgers**, the EU is actively testing **public blockchain integrations** for **Verifiable Credentials and trust registries**.

Countries like **Italy, Belgium, and Spain** have participated in pilot programs focused on **digital diplomas, self-sovereign identity, and credential verification**.

🔗 Sources:

* EBSI Use Cases: <https://ec.europa.eu/digital-building-blocks/>


# 🔐 Zero-Knowledge Proofs – Privacy Without Compromise

(How ZKPs provide trustless verification.)

## **Zero-Knowledge Proofs & Midnight Network: Privacy and Compliance in Digital Identity**

### **Introduction**

As digital identity and verification systems evolve, **privacy and security remain critical challenges**. Traditional verification methods often require users to expose sensitive information, leading to **privacy risks, identity theft, and data misuse**. **Zero-Knowledge Proofs (ZKPs)** are changing this by allowing individuals to **prove something is true without revealing any underlying data**.

Blockchain technology is driving ZKP adoption, enabling **privacy-first identity solutions** that ensure **trust, compliance, and selective disclosure**. With frameworks like **Midnight (Cardano’s privacy-focused network)**, ZKPs are becoming more accessible for real-world applications, including **regulatory frameworks like eIDAS 2.0**.

***

### **What Are Zero-Knowledge Proofs?**

Zero-Knowledge Proofs are cryptographic methods that allow one party (the prover) to prove a statement’s validity to another party (the verifier) **without revealing any additional information**. This ensures **data security and privacy** while enabling trust in various verification processes.

#### **Types of ZKPs**

* **zk-SNARKs (Succinct Non-Interactive Arguments of Knowledge)** – Used for fast, lightweight private transactions and identity proofs.
* **zk-STARKs (Scalable Transparent Arguments of Knowledge)** – Offer scalability and transparency, removing the need for trusted setups.

ZKPs have broad applications in **finance, identity, compliance, and data security**, ensuring that only necessary information is shared while maintaining full cryptographic trust.

***

### **Midnight: A Blockchain for Private & Compliant Identity**

Midnight is a **privacy-first blockchain built on Cardano**, integrating **ZKPs for verifiable but private data sharing**. Unlike traditional blockchains that expose transaction details, Midnight ensures **confidentiality and selective disclosure**, making it a powerful tool for **identity verification, business compliance, and regulated financial transactions**.

#### **How Midnight Enhances Digital Identity**

* **Regulatory Compliance** – Supports frameworks like **eIDAS 2.0 and GDPR**, enabling decentralized yet compliant identity solutions.
* **Selective Disclosure** – Users can prove identity attributes (e.g., age, employment status) without exposing full personal details.
* **Decentralized Identity Proofs** – Ensures trust in identity verification **without central authorities controlling user data**.

***

### **ZKPs and the Future of Digital Identity**

With eIDAS 2.0 introducing **secure digital identities across Europe**, ZKPs provide a **bridge between centralized regulation and decentralized privacy**. By enabling **trusted, tamper-proof identity verification**, ZKPs are **reshaping financial services, borderless hiring, and compliance-driven industries**.

Midnight and other privacy-focused blockchains demonstrate how **blockchain and ZKPs can work together to create a future where identity verification is both private and trusted**—without sacrificing **security or regulatory requirements**.

**Sources:**

* Vitalik Buterin: zk-SNARKs and Identity – <https://vitalik.ca/general/2022/06/15/using\\_snarks.html>
* Polygon ID – <https://polygon.technology/polygon-id>
* Midnight Official Website – <https://www.midnight.io/>
* IOG Blog: Midnight and Data Protection – <https://iohk.io/en/blog/posts/2022/11/18/midnight-and-dust-a-new-era-of-data-protection/>


# 📦 Importing Trust Registries to Cardano with Oracles

#### Overview

**Trust registries** are curated databases of verified **credential issuers** (e.g., universities, licensing bodies, regulated businesses). They serve as the foundation for **trust decisions** in any system that verifies identities or credentials.

By using **blockchain oracles**, these registries can be made accessible to smart contracts on Cardano, enabling secure, on-chain validation of issuers and their credentials.

***

#### 🧠 What is a Trust Registry?

A **trust registry** is an authoritative list of credential issuers that are considered valid for a specific purpose.

Examples:

* 🇪🇺 EU Register of Higher Education Institutions
* 🇸🇪 Swedish Companies Registration Office
* 🇺🇸 US National Provider Identifier (NPI) Registry for healthcare
* 🌍 Sector-based accreditation lists (e.g., ISO-certified auditors)

These registries include:

* **Issuer ID** (e.g., a DID or legal registration number)
* **Issuer type** (university, company, government agency)
* **Registry scope** (jurisdiction, sector)
* **Timestamped inclusion or expiration**

***

#### 🛠️ How Oracle Integration Works

1. **Source Registry Data**
   * Trusted entities (government portals, public APIs, CSV/JSON dumps) are used as sources.
2. **Standardize & Encode**
   * Each entry is formatted with required metadata (e.g., `issuer_id`, `type`, `valid_until`) in a canonical JSON format.
3. **Oracle Publishing**
   * The data is signed by the Oracle and uploaded to Cardano as a transaction or oracle feed (can be native asset or datum-based).
4. **Smart Contract Query**
   * Contracts query the oracle by submitting an issuer ID and receive back a `true/false` or proof of inclusion.
5. **Decision Logic**
   * Based on this check, smart contracts allow or deny the action (e.g., credential acceptance, access, reward, or payment).

***

#### 🔍 Example Workflow

> Use Case: A Cardano-based job board verifies that only accredited universities can issue degree credentials.

<table><thead><tr><th width="72.60546875">Step</th><th>Action</th></tr></thead><tbody><tr><td>1️⃣</td><td>Credential contains <code>issuer_id: did:example:university123</code></td></tr><tr><td>2️⃣</td><td>Smart contract queries the Oracle with this ID</td></tr><tr><td>3️⃣</td><td>Oracle confirms issuer is in <code>education_registry_v2</code></td></tr><tr><td>4️⃣</td><td>Contract proceeds to accept the credential as valid</td></tr></tbody></table>

***

### 📈 Tokenomics-Based Validation of Issuers

Trust registries can also be enhanced by **on-chain consensus and staking mechanisms**. This introduces decentralized governance to the issuer validation process.

#### 🔐 Token-Curated Trust Registries

Instead of only relying on a central authority, a **community of stakers** can participate in validating issuers.

Key mechanics:

<table><thead><tr><th width="234.40234375">Mechanism</th><th>Description</th></tr></thead><tbody><tr><td>🗳️ <strong>Staked Curators</strong></td><td>Individuals or orgs stake tokens to validate a new issuer into the registry</td></tr><tr><td>✅ <strong>Onboarding Vote</strong></td><td>A DID issuer is proposed and voted into the registry by stakers</td></tr><tr><td>📉 <strong>Slashing for Misconduct</strong></td><td>If an issuer is later proven to issue fraudulent credentials, the curator’s stake can be slashed</td></tr><tr><td>🎯 <strong>Reputation Scoring</strong></td><td>Issuers earn trust scores based on usage &#x26; verification history</td></tr><tr><td>🎁 <strong>Reward System</strong></td><td>Verified issuers and curators are rewarded per successful credential verification</td></tr></tbody></table>

***

#### 🔁 Sample Flow

<table><thead><tr><th width="73.2421875">Step</th><th>Action</th></tr></thead><tbody><tr><td>1️⃣</td><td>Curator stakes 10,000 $FWT to vouch for a new university</td></tr><tr><td>2️⃣</td><td>Smart contract records the new issuer + curator</td></tr><tr><td>3️⃣</td><td>Employer verifies a credential issued by this university</td></tr><tr><td>4️⃣</td><td>The transaction confirms the issuer’s status via oracle</td></tr><tr><td>5️⃣</td><td>Curator receives a small portion of the verification fee</td></tr><tr><td>❗</td><td>If fraud is reported, the stake is slashed and issuer removed</td></tr></tbody></table>

***

### ✅ Benefits

<table><thead><tr><th width="152.15234375">Category</th><th>Benefit</th></tr></thead><tbody><tr><td>🔒 Security</td><td>Oracles validate issuer lists based on trusted sources</td></tr><tr><td>🧠 Composability</td><td>Smart contracts make dynamic trust decisions without off-chain logic</td></tr><tr><td>🌍 Openness</td><td>Any type of registry (gov, sector, community-curated) can be plugged in</td></tr><tr><td>🔁 Incentives</td><td>Staking and rewards drive high-quality participation in registry governance</td></tr><tr><td>🚀 Scalability</td><td>Registries can be updated and expanded without forking or manual upgrades</td></tr></tbody></table>

***

### 🔄 Registry Types That Can Be Oracle-Enabled

* **National ID Issuers** (Gov-backed identity schemes)
* **Accredited Universities** (Higher education regulators)
* **Business Registries** (Chambers of Commerce, Company Registration Offices)
* **Healthcare Providers** (NPI registries or regional health boards)
* **Tax Authorities** (Valid employer/employee databases)
* **Fintech KYC Providers** (Trusted e-KYC firms)


# 📈 Tokenomics-Based Validation of Issuers

Trust registries can also be enhanced by **on-chain consensus and staking mechanisms**. This introduces decentralized governance to the issuer validation process.

#### 🔐 Token-Curated Trust Registries

Instead of only relying on a central authority, a **community of stakers** can participate in validating issuers.

Key mechanics:

<table><thead><tr><th width="190.140625">Mechanism</th><th>Description</th></tr></thead><tbody><tr><td>🗳️ <strong>Staked Curators</strong></td><td>Individuals or orgs stake tokens to validate a new issuer into the registry</td></tr><tr><td>✅ <strong>Onboarding Vote</strong></td><td>A DID issuer is proposed and voted into the registry by stakers</td></tr><tr><td>📉 <strong>Slashing for Misconduct</strong></td><td>If an issuer is later proven to issue fraudulent credentials, the curator’s stake can be slashed</td></tr><tr><td>🎯 <strong>Reputation Scoring</strong></td><td>Issuers earn trust scores based on usage &#x26; verification history</td></tr><tr><td>🎁 <strong>Reward System</strong></td><td>Verified issuers and curators are rewarded per successful credential verification</td></tr></tbody></table>

***

#### 🔁 Sample Flow

<table><thead><tr><th width="73.2421875">Step</th><th>Action</th></tr></thead><tbody><tr><td>1️⃣</td><td>Curator stakes 10,000 $FWT to vouch for a new university</td></tr><tr><td>2️⃣</td><td>Smart contract records the new issuer + curator</td></tr><tr><td>3️⃣</td><td>Employer verifies a credential issued by this university</td></tr><tr><td>4️⃣</td><td>The transaction confirms the issuer’s status via oracle</td></tr><tr><td>5️⃣</td><td>Curator receives a small portion of the verification fee</td></tr><tr><td>❗</td><td>If fraud is reported, the stake is slashed and issuer removed</td></tr></tbody></table>

***

### ✅ Benefits

<table><thead><tr><th width="152.15234375">Category</th><th>Benefit</th></tr></thead><tbody><tr><td>🔒 Security</td><td>Oracles validate issuer lists based on trusted sources</td></tr><tr><td>🧠 Composability</td><td>Smart contracts make dynamic trust decisions without off-chain logic</td></tr><tr><td>🌍 Openness</td><td>Any type of registry (gov, sector, community-curated) can be plugged in</td></tr><tr><td>🔁 Incentives</td><td>Staking and rewards drive high-quality participation in registry governance</td></tr><tr><td>🚀 Scalability</td><td>Registries can be updated and expanded without forking or manual upgrades</td></tr></tbody></table>

***

### 🔄 Registry Types That Can Be Oracle-Enabled

* **National ID Issuers** (Gov-backed identity schemes)
* **Accredited Universities** (Higher education regulators)
* **Business Registries** (Chambers of Commerce, Company Registration Offices)
* **Healthcare Providers** (NPI registries or regional health boards)
* **Tax Authorities** (Valid employer/employee databases)
* **Fintech KYC Providers** (Trusted e-KYC firms)

### 🌐 Fairway’s Role: Building the Tokenized Trust Layer

Fairway is not just integrating trust registries — we’re building the **token-powered trust economy** that makes these registries sustainable, decentralized, and scalable.

While most digital credential platforms rely on centralized registries or manual approvals, Fairway introduces a **self-sustaining token economy** to drive curation, validation, and rewards for trust registries.

#### 🏗️ What Fairway Is Building

Fairway is developing:

| Component                        | Description                                                                                             |
| -------------------------------- | ------------------------------------------------------------------------------------------------------- |
| 🔗 **On-Chain Trust Registries** | Smart contracts that store and verify lists of trusted DID issuers across identity domains              |
| 💰 **Staking-Based Governance**  | Curators stake $FWT (Fairway Token) to validate issuers, putting real skin in the game                  |
| 🧾 **Reputation Tracking**       | Issuers earn trust dynamically through usage, verification success, and lack of disputes                |
| ⚖️ **Slashing Mechanisms**       | Misconduct or fraud from an issuer leads to slashing of the curator’s stake, protecting trust integrity |
| 🎁 **Incentivized Verification** | Recruiters, platforms, and apps pay for verifications → rewards are distributed to issuers & curators   |

***

#### 🤝 Why This Matters

Most SSI (Self-Sovereign Identity) ecosystems face the **cold start problem** — there's no incentive for issuers to participate, and no economic model to support validation.

**Fairway solves this by rewarding the full trust stack:**

* **Issuers** are paid when their credentials are verified
* **Curators** earn recurring fees for maintaining quality registries
* **Verifiers** (e.g. employers, apps) pay in fiat → converted into $FWT on-chain, creating constant demand
* **Fraud is penalized**, ensuring trust doesn't require central gatekeepers

***

#### 🌍 Real-World Use Case: Workforce Mobility

Fairway’s first target vertical is **international hiring**, where credential fraud, verification delays, and cross-border complexity make recruitment inefficient.

Our solution:

* Plug trusted university & government registries into Cardano
* Use Fairway tokenomics to build a **network of verified issuers**
* Reward verifications tied to **real jobs, real payments, real identity checks**

This creates a **positive flywheel**:\
More demand → more issuers → more verifications → stronger trust → growing network.

***

#### 🚀 Designed for Expansion

Once proven in workforce identity, Fairway’s trust tokenomics can power:

* KYC validation in **DeFi**
* Regulated **on-chain remittance**
* Verified credentials for **DAO contributors**
* Identity-gated access to **tokenized financial instruments**

Wherever verifiable identity is needed — Fairway’s protocol will offer the infrastructure.


# 🧠 On-Chain dApps That Can Verify SSI (Midnight ZK Enabled)

### **Introduction**

As the world embraces decentralized identity systems, a new frontier is emerging: **on-chain applications (dApps) that can verify Self-Sovereign Identity (SSI) credentials** directly on blockchain. With the support of **zero-knowledge proofs (ZKPs)** and **confidential smart contracts**, Cardano’s **Midnight Partnerschain** offers a powerful foundation for building dApps that respect privacy, ensure compliance, and enable trustless interactions.

### **Why On-Chain Verification Matters**

Traditional SSI systems rely on off-chain verification, where a verifier checks credentials through centralized or semi-centralized middleware. On-chain verification brings several advantages:

* ✅ **Transparency & Auditability** – Credential verifications and rules are visible and traceable on-chain.
* ✅ **Trustless Architecture** – Eliminates the need for intermediaries in verifying credentials.
* ✅ **Programmable Logic** – dApps can enforce logic such as access control, compliance checks, and rewards based on verifiable identity attributes.

### **How Midnight Enables On-Chain SSI**

Midnight is a **confidential computation sidechain** to Cardano that supports smart contracts enhanced with **zk-SNARKs**, enabling **verifiable, privacy-preserving identity proofs**. Its shielded architecture supports sensitive use cases like identity without compromising regulatory compliance.

#### Key Features:

* **ZK Identity Proofs** – Credentials issued off-chain can be transformed into ZK proofs and verified on-chain.
* **Selective Disclosure** – Only required attributes are revealed, aligned with eIDAS 2.0.
* **Smart Contract Enforcement** – dApps can conditionally approve or reject transactions based on credential validity.

🔗 Source: <https://midnight.io>

### **Use Cases of On-Chain SSI-Enabled dApps**

#### 🔐 **Regulatory-Compliant DeFi**

DeFi platforms can allow users to prove:

* Age or nationality (for AML/CFT compliance)
* Employment status or income (for lending protocols)
* Residency or citizenship (for regional regulatory compliance)

All without revealing the full underlying data.

#### 🗳️ **DAO Governance with Identity-Based Voting**

DAOs can implement on-chain voting mechanisms where:

* 1 credential = 1 vote
* Voting rights are linked to verified employment, university affiliation, or regulatory licenses

ZKPs ensure the **validity of credentials** while **preserving voter anonymity**.

#### 🧾 **KYC & Access-Controlled dApps**

dApps requiring KYC or real-world identity (e.g. insurance, property, legal tech) can:

* Verify KYC credentials issued by regulated institutions
* Validate them with ZKPs via Midnight
* Allow access only when the proof is valid

#### 💼 **Credential-Driven Work & Education Platforms**

Platforms can:

* Match users with jobs based on on-chain verified skills
* Gate access to opportunities based on educational credentials
* Reward verified contributors with tokens or NFT-based proof of work

### **How It Works: SSI + ZK + Midnight + dApps**

1. **Credential Issuance** – User receives a VC from a trusted issuer (university, employer, government).
2. **Proof Generation** – User transforms this credential into a ZK proof via the Fairway Wallet or similar.
3. **Smart Contract Verification** – dApp running on Midnight smart contract checks the proof.
4. **Access Granted or Transaction Executed** – Based on the result of the ZK proof, the contract executes.

### **Why This Matters**

This unlocks a **new class of decentralized applications** where identity and trust are core features—not bolted-on additions. It brings **Web2-grade compliance and personalization** into **Web3-native environments**.

It also enables broader visions like:

* Cross-chain identity compliance (e.g. Bitcoin, Ethereum)
* RWA tokenization tied to verified identities
* Secure credential-backed reputation in open finance

### **Related Projects & Ecosystems**

* **Polygon ID** – Uses ZKPs for identity-based smart contracts
* **Worldcoin** – Provides identity verification via iris scans and ZKPs
* **KILT Protocol** – On-chain reputation and claims system on Polkadot
* **Fairway** – Enabling workforce identity, credential issuance, and privacy-preserving identity proofs on Cardano + Midnight

### **Conclusion**

With the rise of confidential smart contracts, ZKPs, and self-sovereign identity, **the next wave of dApps will be privacy-first, compliance-ready, and user-controlled.** Midnight positions Cardano as a powerful foundation for building these dApps—opening new doors for **digital identity innovation at scale**.


# Verified Identity In Blockchain Based Finance (DeFi)

(Exploring identity-integrated finance and regulatory compliance)

SSI-Enabled DeFi & Blockchain-Based Financial Solutions


# 💱 What is SSI-Enabled DeFi?

(SSI, ZKPs, and credential validation for finance.)

### **Introduction**

Decentralized Finance (DeFi) is revolutionizing financial systems by enabling **peer-to-peer transactions without intermediaries**. However, its growth has introduced **regulatory, privacy, and compliance challenges**. That’s where **Self-Sovereign Identity (SSI)** comes in. **SSI-enabled DeFi** blends the best of both worlds—**decentralized identity** and **decentralized finance**—to create a new class of **secure, compliant, and trustless financial applications**.

### **What is SSI? (Quick Recap)**

**Self-Sovereign Identity (SSI)** is a framework that allows individuals and organizations to **own, control, and share their identity data** without relying on central authorities. With SSI, credentials like government IDs, diplomas, or proof of income are issued as **verifiable credentials (VCs)** and stored in **digital wallets**.

🔐 These credentials can be **shared selectively**, using **Zero-Knowledge Proofs (ZKPs)** to prove claims without revealing the underlying data.

Learn more: [Verifiable Credentials & SSI Overview](https://www.w3.org/TR/vc-data-model/)

***

### **Why DeFi Needs Identity**

Traditional DeFi is **anonymous by design**, but as the space matures, many real-world use cases—like lending, insurance, or regulated asset trading—**require identity verification** for legal compliance and risk management.

#### Pain Points in Traditional DeFi:

* ❌ Lack of KYC/AML compliance blocks institutional adoption
* ❌ Inability to issue credit without identity or proof of income
* ❌ Risk of fraud or Sybil attacks in a pseudonymous system

### **What is SSI-Enabled DeFi?**

**SSI-enabled DeFi** integrates identity standards like **DIDs (Decentralized Identifiers)** and **VCs** into DeFi protocols. These systems allow users to **prove eligibility or regulatory compliance** without compromising privacy.

This is achieved by:

1. **Receiving credentials** from trusted issuers (governments, employers, banks)
2. **Storing them in a digital wallet** (e.g. Fairway Wallet, Polygon ID)
3. **Generating ZKPs** to prove facts like age, nationality, or income
4. **Submitting proofs on-chain** to dApps that validate credentials with smart contracts

✅ The result: a **user-centric DeFi experience that’s privacy-preserving, secure, and compliant**.

***

### **Use Cases of SSI-Enabled DeFi**

#### 💳 Identity-Backed Lending

* Prove employment or income via VC
* Borrow against identity-linked credit score
* Enable unbanked users to access microloans with verified credentials

#### 🌍 Cross-Border Stablecoin Transfers

* Regulate access by verifying nationality or residency
* Ensure compliance with international remittance laws

#### 🛡️ Regulated Asset Access

* Use age, location, or professional status to access certain tokenized assets
* Comply with securities laws via privacy-preserving KYC

#### 🗳️ Governance with Reputation

* Use VCs to weight DAO votes by verified expertise, stakeholder status, or institutional role

***

### **How Does It Work? (Technical Flow)**

1. **Credential Issued**: A university issues a VC for graduation.
2. **User Stores Credential**: In a secure, decentralized wallet (e.g., Fairway Wallet).
3. **Proof Generated**: Wallet converts the credential into a ZK proof.
4. **dApp Verification**: A lending platform smart contract on **Cardano Midnight** verifies the proof.
5. **Action Taken**: Loan is approved without exposing the original diploma.

🔗 Related tech: zk-SNARKs, zk-STARKs, Midnight, Identus, Polygon ID, Cheqd, KILT

***

### **Benefits of SSI-Enabled DeFi**

* 🔐 **Privacy** – Users reveal only what’s necessary
* 🌐 **Compliance** – Align with GDPR, eIDAS, and other regulations
* 🚀 **Inclusion** – Provide access to credit and financial tools for underbanked users
* 🧠 **Reputation-Based Finance** – Build financial credibility based on verifiable work, education, and income credentials

***

### **Fairway & SSI-Enabled DeFi**

Fairway is building the infrastructure to **bring verifiable identity into DeFi**:

* 🌍 **Workforce Credentials** verified on-chain
* 💼 **Tamper-proof job offers** as digital credentials
* 🔐 **ZK Proofs via Midnight** to power regulatory compliance
* 📱 **Cardano-enabled smart contracts** to tie verified credentials to actions in DeFi

***

### **Further Reading & Sources**

* W3C Verifiable Credentials: <https://www.w3.org/TR/vc-data-model/>
* Polygon ID: <https://polygon.technology/polygon-id>
* Midnight: <https://midnight.io>
* EBSI Identity Model: <https://ec.europa.eu/digital-building-blocks/>
* zk-SNARKs Explained: <https://vitalik.ca/general/2022/06/15/using\\_snarks.html>


# 🏦 Regulated DeFi & Blockchain-Based Finance with Fairway

s decentralized finance (DeFi) continues to evolve, there is growing demand for **identity-aware and regulation-compliant solutions**. While DeFi’s original ethos emphasized anonymity, the future of blockchain-based finance is moving toward **selective disclosure, legal interoperability, and regulatory alignment**—without compromising decentralization.

Technologies like **Self-Sovereign Identity (SSI)**, **Zero-Knowledge Proofs (ZKPs)**, and **smart contract-based compliance frameworks** enable this next generation of financial applications. Fairway is building infrastructure to support **identity-tied, privacy-preserving DeFi** across **Cardano, Bitcoin, and hybrid systems**.

***

### **🔄 Cardano-Based Regulated Stablecoins Through Fairway ID**

Stablecoins are the lifeblood of DeFi, but regulation is tightening. **MiCA (EU)** and **global AML directives** now require issuers and users to demonstrate traceability and compliance.

Fairway enables stablecoin issuers and platforms to:

* ✅ Link user wallets to **ZK-verified credentials** (e.g., age, nationality, compliance status)
* ✅ Use **Midnight** to verify credentials without revealing personal data
* ✅ Ensure **GDPR and eIDAS compliance** via selective disclosure of Verifiable Credentials (VCs)

#### Use Case:

An EU-regulated stablecoin requires all users to verify their residency and AML status. Users generate ZK proofs of government-issued credentials and submit them on-chain to access regulated stablecoin contracts.

The result: **legal compliance + privacy protection + DeFi liquidity**.

***

### **⚡ Bitcoin Transactions Through Fairway ID: Identity-Tied Bitcoin Compliance**

Bitcoin’s base layer does not natively support identity or smart contracts, but through **Cardano-based bridges**, Fairway introduces **identity-linked Bitcoin usage**:

#### How It Works:

1. **User Identity** – Verified via VC and turned into a ZK proof using Fairway Wallet
2. **Proof Vault** – The proof is stored on Cardano using a smart contract
3. **Bridged BTC** – Bitcoin is locked on Bitcoin, minted as wrapped BTC on Cardano
4. **BTC Transfer** – Smart contracts enable BTC transactions only if linked to valid identity proofs

#### Why It Matters:

This system enables:

* Regulatory-friendly **Bitcoin payments and savings**
* Identity-verified **cross-border remittances**
* On-chain auditability **without exposing user identity**

Fairway acts as the glue across:

* ✅ Identity issuance (SSI + VCs)
* ✅ Proof generation (ZKPs via Midnight)
* ✅ Blockchain enforcement (Cardano smart contracts)

This model lays the foundation for **regulatory-compliant Bitcoin DeFi** and **real-world finance interoperability**.

***

### **📜 Using Smart Contracts on Cardano (Midgard/Sundial) to Attach Identity to Bitcoin**

Cardano’s smart contract frameworks—**Midgard** and **Sundial Protocol**—offer advanced tooling to bridge Bitcoin and Cardano through identity.

#### Key Innovations:

* **Midgard** – A Cardano-based optimistic rollup designed for scalable and composable DeFi
* **Sundial** – Protocol for unlocking and locking Bitcoin in sync with Cardano smart contract conditions

#### Identity Integration:

* **Attach identity proofs** to Cardano addresses and UTxOs
* **ZK-enabled rules** verify credentials without disclosing raw data
* Smart contracts on **Sundial** release or deny Bitcoin actions based on identity conditions

#### Sample Use Cases:

* 🔐 Releasing wrapped BTC for users with verified KYC credentials
* 🛡️ Enabling institutional investors to transact in BTC through whitelisted smart contracts
* 🌍 Supporting remittances from verified wallets to avoid blacklisted regions or identities

***

### **Conclusion**

As DeFi matures, identity-aware systems will become critical for **bridging decentralized innovation with real-world compliance**. Fairway’s infrastructure—with smart contracts, ZKPs, and decentralized identity—creates a future where **Bitcoin and stablecoins can be used compliantly, globally, and securely.**


# ⚙️ Scaling Cardano-Based DeFi: Midgard & Hydra

### **Introduction**

Cardano is rapidly evolving as a home for scalable, secure, and regulated decentralized finance (DeFi). However, like any Layer 1 blockchain, **scalability is critical** for supporting real-world financial applications—especially those requiring fast settlement, identity integration, and regulatory compliance.

Cardano’s scaling strategy includes two complementary solutions: **Hydra**, a Layer 2 protocol for off-chain scalability, and **Midgard**, an optimistic rollup framework designed for high-throughput smart contract execution. Together, they lay the foundation for **DeFi infrastructure that supports identity, privacy, and compliance at scale**.

***

### **Hydra: Layer 2 for Instant Settlement**

Hydra is Cardano’s official Layer 2 scaling solution that allows:

* ⚡ **Near-instant transaction finality**
* 🔗 **Low-fee microtransactions**
* 🔐 **Off-chain execution with on-chain security**

#### How It Works:

Hydra allows participants to open **state channels** where most transactions occur off-chain. Final states are later committed to the Cardano mainnet. This ensures:

* High scalability for dApps (especially payments and marketplaces)
* Efficient, parallel execution for low-latency use cases

#### Use Cases:

* Micro-payments
* NFT auctions
* Real-time gaming or DeFi interactions

🔗 Learn more: <https://hydra.family/>

***

### **Midgard: Optimistic Rollups for Smart Contracts**

Midgard is an emerging **optimistic rollup framework for Cardano**, under development by IOG. It enables:

* 🚀 **High-throughput smart contract execution**
* 🧾 **Fraud-proof mechanisms for state verification**
* 🤝 **Compatibility with tools like Plutus, CIP-68, and Cardano-native tokens**

#### Identity + Compliance Layer:

Midgard is being developed with **ZK-proof compatibility**, enabling identity-based actions on-chain using:

* Verifiable Credentials (VCs)
* Zero-Knowledge Proofs (zk-SNARKs)
* Credential-verified smart contracts

This makes it an ideal execution layer for:

* ✅ Identity-based DeFi
* ✅ Regulated stablecoin issuers
* ✅ Credential-backed asset issuance (RWA)

🔗 Learn more: <https://iohk.io/en/blog/posts/2023/10/05/a-scalable-rollup-design-for-cardano/>

***

### **Hydra + Midgard: A Multi-Layered Scaling Stack**

Cardano’s strength lies in combining:

* **Hydra** – For lightweight, rapid-fire, off-chain transactions
* **Midgard** – For complex, high-throughput smart contract workflows

Together, they enable:

* ⚙️ Scalable DeFi apps that interact with identity systems (Fairway, Atala PRISM)
* 🔐 Regulated dApps that use privacy-preserving smart contracts (Midnight)
* 🌍 Global remittance and stablecoin platforms with identity enforcement

***

### **Fairway’s Role in Scaling SSI-Enabled DeFi**

Fairway is building key SSI infrastructure that works across **Hydra, Midgard, and Midnight**, including:

* ✅ Off-chain identity wallets that generate ZKPs
* ✅ Credential issuance flows compatible with Hydra/Midgard layers
* ✅ Smart contracts that validate proofs and unlock DeFi functionality

This multi-layer integration will allow Fairway to:

* Support **real-time hiring + payment workflows**
* Enable **regulatory-compliant Bitcoin DeFi** through Cardano bridges
* Build **programmable compliance** into stablecoin flows

***

### **Conclusion**

Scaling Cardano’s DeFi ecosystem isn’t just about speed—it’s about enabling **real-world adoption with identity, compliance, and security** at the core. With **Hydra** and **Midgard**, Cardano is positioned to support **next-gen DeFi** that is **scalable, decentralized, and regulation-ready**.


# Scaling Bitcoin DeFi with Sundial Protocol

Bitcoin is the most secure and valuable digital asset in existence—but it wasn’t built for **speed**, **DeFi**, or **compliance**. Its base layer lacks smart contracts, programmability, and native identity features.

**Sundial Protocol** changes that.

By leveraging **Cardano’s scalable smart contract ecosystem** and bridging Bitcoin into this high-performance environment, **Sundial enables Bitcoin to scale**—bringing **low-fee transactions**, **faster settlement**, and access to **full DeFi capabilities** like lending, DEX trading, and automated payments.

***

#### **🔗 Sundial Protocol: Scaling & Securing Bitcoin for DeFi**

[**Sundial Protocol**](https://www.sundialprotocol.com/) is a purpose-built **Bitcoin-to-Cardano bridge** that transforms Bitcoin into a **scalable, programmable, and compliant asset**.

By leveraging **Cardano’s high-performance smart contract infrastructure** and integrating with **Midgard Protocol**, Sundial enables:

* ⚡ **Faster Bitcoin settlements** — seconds, not hours
* 📉 **Extremely low transaction fees** — powered by Cardano
* 📈 **High throughput** — hundreds to thousands of TPS
* 💹 **Full DeFi capabilities**, including:
  * Bitcoin lending and borrowing
  * Swapping BTC on Cardano-based DEXes
  * Yield farming and liquidity provision

Sundial also supports **compliance and identity-based logic**, making it ideal for:

* 🌉 Bridging BTC into wrapped formats on Cardano
* 🔐 Enforcing smart contract logic with identity proofs
* 💸 Enabling regulated remittances, institutional BTC flows, and DeFi use cases

Together, **Sundial + Midgard** unlock a future where **Bitcoin is fast, low-cost, programmable, and regulatory-ready**—without compromising its core values of decentralization.

***

#### **🧠 Powered by Midgard**

\[Sundial] works seamlessly with [Midgard Protocol](https://midgardprotocol.com/), a **smart contract rollup layer** on Cardano optimized for:

* High-throughput DeFi and programmable finance
* Identity-aware and compliance-checked logic
* ZK-friendly infrastructure for verifying proofs from decentralized ID systems

Together, **Sundial + Midgard** make Bitcoin programmable, scalable, and compliance-ready.

***

#### **🔁 Sample Workflow 1**

1. BTC is bridged into a wrapped format on Cardano using Sundial
2. The user interacts with a DeFi protocol (DEX, lending, etc.)
3. Smart contract conditions are checked and executed via Midgard
4. BTC is routed or released depending on the outcome

#### **🔁 Sample Workflow 2**

1. A user wants to send Bitcoin in a compliant way
2. BTC is wrapped on Cardano using Sundial
3. A Cardano smart contract determines whether the transaction meets regulatory conditions
4. If conditions are met, the BTC is released or routed accordingly

***

#### 🏆 **Why Sundial Is Different**

Traditional Bitcoin scaling solutions focus solely on speeding up transactions. **Sundial Protocol** goes much further—bringing **smart contracts**, **DeFi programmability**, and **identity integration** directly to Bitcoin, without compromising decentralization.

This transforms Bitcoin from a passive store of value into a **high-speed, low-cost, identity-ready financial rail**—fully compatible with today’s DeFi and regulatory needs.

***

#### 🔥 **What You Can Do with Sundial**

* 🌍 **Low-fee international BTC payments**
* 🧾 **Regulated Bitcoin lending and borrowing**
* 📊 **KYC-based token swaps and compliant DeFi products**
* 🏦 **Institutional DeFi access with identity-verified logic**
* 💼 **BTC payroll, invoicing, and remittance with legal clarity**

***

#### ✅ **Benefits of Scaling Bitcoin Through Cardano**

* **Regulatory compliance** (MiCA, KYC, AML)
* **Composable smart contracts** across DeFi dApps
* **Privacy-preserving zk-proof logic** via Fairway + Midnight
* **Institutional-grade workflows** powered by Cardano and Midgard
* **Ultra-fast and low-cost Bitcoin transactions**
* **Access to lending, trading, and automated finance using BTC**

***

#### 🔚 **Conclusion**

**Sundial Protocol**, backed by **Cardano smart contracts** and the **Midgard rollup**, unlocks a new chapter in Bitcoin’s evolution:

→ Scalable\
→ Compliant\
→ Programmable

This is **Bitcoin finance at Web3 speed**—built for users, institutions, and the next generation of global DeFi.


# Unlocking Bitcoin DeFi with Fairway

Bitcoin was never designed for identity, compliance, or smart contracts—but that’s exactly what modern finance demands.

**Fairway** introduces a new paradigm: it enables **identity-powered Bitcoin DeFi** by layering **verifiable credentials, zk-proofs, and smart contract logic** on top of the Bitcoin ecosystem.

The result? **Compliant, programmable Bitcoin finance** that preserves privacy, increases accessibility, and scales to real-world institutional and DeFi use cases.

***

#### **🧱 Fairway as the Identity Layer for Bitcoin Finance**

At the core of this transformation is **Fairway Wallet**, which lets users store and selectively share **verifiable credentials** such as:

* Nationality
* Employment status
* Income or tax ID
* Proof of education
* AML/KYC compliance status

These credentials are verified and **converted into Zero-Knowledge Proofs** using **Midnight**, Cardano’s ZK privacy layer. Smart contracts on **Cardano (via Midgard)** then verify these proofs without revealing private data.

This infrastructure allows **Bitcoin to become programmable based on identity**—a critical missing piece in unlocking global DeFi adoption.

***

#### **💡 What Fairway Enables for Bitcoin**

When layered with **Sundial Protocol** and **Midgard**, Fairway enables:

* ✅ **Regulated Bitcoin access** (e.g., only verified users can move or receive BTC)
* 🧾 **Compliance logic** directly embedded into smart contracts
* 🧑‍💼 **Whitelisted DeFi** participation based on verifiable identity
* 🌐 **Cross-border BTC remittances** tied to employment credentials
* 💼 **BTC payroll and invoicing** based on real-time credential checks
* 📉 **Private, low-fee, high-speed BTC finance** using zk-proofs

Fairway doesn't change Bitcoin—it **extends what Bitcoin can do** in the modern financial world.

***

#### **🔁 Connecting the Stack: Fairway + Midgard + Sundial + Bitcoin**

Here’s how the full infrastructure comes together:

1. **User verifies identity credentials** using Fairway Wallet
2. **Midnight** converts those credentials into **zk-proofs**
3. **Cardano smart contracts (via Midgard)** evaluate the proofs
4. If conditions are met, **Sundial** bridges or routes BTC accordingly
5. The user interacts with BTC-based DeFi products, payroll flows, or remittances—with **legal-grade trust and privacy intact**

***

#### **🔚 Conclusion**

**Fairway makes Bitcoin DeFi real.**

By introducing **verified identity** and **privacy-preserving compliance checks**, Fairway enables Bitcoin to serve as:

* A **regulated DeFi asset**
* A **compliant payment rail**
* A **programmable, identity-aware financial layer**

This is how Bitcoin grows up—and Fairway is the missing identity layer that ties it all together.


# The Role of Identity in Real-World Asset (RWA) Tokenization

Tokenizing real-world assets—such as real estate, land, business shares, employment contracts, or even income—creates enormous potential for **liquidity, transparency, and global access to capital**. However, without **identity and regulatory compliance**, tokenized assets can face legal, financial, and ethical barriers.

**Self-Sovereign Identity (SSI)** and **Verifiable Credentials (VCs)** enable compliant, privacy-preserving tokenization. Through **Fairway’s infrastructure**, issuers can link tokenized RWAs to:

* Verified ownership credentials (e.g., land title, company registry entry)
* Proof of employment/income for income-backed tokens
* Regulatory-compliant eligibility for investors (e.g., jurisdiction, risk score)

This ensures that assets are:

* ✅ Issued only to qualified owners
* ✅ Tradable under legal frameworks
* ✅ Securely verifiable and auditable

ZKPs via **Midnight** allow selective disclosure of user credentials—ensuring that **only the necessary identity data is shared** when engaging with financial instruments.


# Regulated Stablecoins: Linking Identity to Financial Stability

Stablecoins are vital tools in emerging market economies and decentralized finance—but without identity, they pose AML, taxation, and risk challenges.

Fairway enables regulated stablecoins to:

* ✅ Bind wallet usage to identity-based ZK proofs (e.g., KYC, residency)
* ✅ Comply with MiCA, FATF, and jurisdictional laws without data overexposure
* ✅ Prevent illicit use while ensuring privacy and inclusion

Combined with Cardano smart contracts and bridges like Sundial, identity-aware stablecoins become:

* 🔒 Legally compliant
* 🌍 Globally interoperable
* 🧾 Ready for real-world remittances, payrolls, and public services


# Regulated DeFi Applications: The Future of Identity-Backed Finance

The financial systems of tomorrow will depend on **programmable identity**. Fairway’s infrastructure supports the development of:

* 📈 RWA-backed loans (land, income, digital work credentials)
* 🏦 Government-approved tokenized savings and pension systems
* 💳 Blockchain-based payroll systems linked to verifiable employment records
* 💼 SME tokenization for inclusive venture financing

Through SSI, Midnight ZKPs, and platforms like **Midgard**, these regulated applications ensure:

* Identity-based access control
* Proof-based compliance enforcement
* Full data sovereignty for users

***

### **Conclusion**

Tokenizing real-world assets unlocks enormous financial inclusion—but only when tied to **trust, compliance, and identity**. Fairway’s modular stack enables **ZK-backed, SSI-powered tokenization** that brings credibility and utility to the next wave of decentralized finance.


# A Paradigm Shift for the Global Finance and banking

## 🚧 **The Infrastructure is Ready: Regulated Digital Finance Is No Longer Theoretical**

The convergence of **Self-Sovereign Identity (SSI)**, **Zero-Knowledge Proofs**, **blockchain interoperability**, and **regulatory frameworks** has made it **technically possible**—and now **inevitable**—to build a globally regulated, privacy-preserving, decentralized financial system.

This is not a whitepaper vision.

This is not speculative.

The protocols exist. The standards are ratified. The infrastructure is being deployed.

**Regulated, compliant, programmable finance is now executable at scale.**

And **Fairway**, along with a growing ecosystem of public and private contributors, is actively deploying it.

***

### 🧱 The Components Are Here—And Interoperable

#### ✅ **Identity: Legal Trust Meets User Control**

The past two decades of digital identity development—MOSIP, EUDI, EBSI, W3C VCs, and DIDs—have coalesced into globally accepted standards. These identity frameworks are now:

* **Legally recognized** by governments (e.g. EU Digital ID Wallets)
* **Open-source and interoperable** (e.g. MOSIP for national ID)
* **Integrated with smart contract platforms** (EBSI–Cardano pilot programs)

Fairway Wallet fully supports:

* W3C Verifiable Credentials (VCs)
* DIDComm & OpenID Connect
* EUDI/EBSI alignment
* MOSIP-integrated ID flows for partner governments
* ZK-enabled credential sharing via Midnight zk-SNARKs `GITREFERENCE`

#### 🔒 **Privacy: Zero-Knowledge Compliance Is Working**

**Midnight**, Cardano’s zero-knowledge data protection layer, now enables credentialed users to **prove compliance without revealing personal data**.

Combined with **zk-logic** inside Cardano’s smart contract platforms like **Midgard**, credentials can be checked for:

* ✅ Nationality
* ✅ Residency
* ✅ Income/employment
* ✅ Sanctions & blacklist status
* ✅ Accredited investor status
* ✅ Age & legal capacity

…without exposing raw data or compromising sovereignty.

These proofs are **verifiable**, **auditable**, and **private by design**. `GITREFERENCE`

#### 🔗 **Settlement: Bitcoin, Stablecoins & RWAs Are Ready for Logic-Based Movement**

On-chain settlement of **Bitcoin** and **real-world assets (RWAs)** tied to verified credentials is no longer experimental:

* **Sundial Protocol** allows BTC to move based on Cardano smart contract logic
* **Maesttro**, **Anastasia Labs**, and **Fluid Tokens** enable lending, escrow, and tokenization logic around BTC, NFTs, invoices, and off-chain collateral
* **Cardano wallets** like Eternl, Nami, Flint, Typhon, and GeroWallet now support integrations for identity-aware dApps and asset flows
* **Stablecoins** such as USDA and iUSD are deploying KYC integrations for fiat–crypto bridging

The ecosystem is live and composable. Verified identity now governs:

* 🏦 Tokenized finance
* 📄 Legal contracts & escrow
* 🧾 Invoice-based lending
* 🪙 Fiat ramps & regulated stablecoin flows
* 💰 Bitcoin smart contract execution
* 🌍 Compliant remittance & payroll

***

### 💡 Regulated DeFi Is No Longer an Oxymoron

We’ve crossed the threshold. For the first time in digital finance, we can have:

* **Decentralized control**
* **Selective, verifiable compliance**
* **ZK-powered privacy**
* **Legal validity and interoperability with state systems**
* **Composability across BTC, stablecoins, RWAs, and dApps**

DeFi protocols can now build for:

* 🌍 Global user onboarding through legal ID
* 💸 KYC/AML-compliant stablecoin swaps and loans
* 🧾 RWAs that meet securities requirements
* 🛡️ Institutionally compliant token gating
* 🔐 Decentralized wallets with government-grade credential handling

This is not just a new market opportunity—it’s a **new financial operating system**.

***

### 🚀 Fairway’s Role in the New Stack

Fairway is not just a product. It’s an infrastructure participant in the **deployment of the global identity-finance stack**.

Our contributions include:

* ✅ Building the Fairway ID Wallet—EUDI- and EBSI-aligned, MOSIP-ready, ZK-integrated
* ✅ Supporting issuance and verification of credentials for education, employment, and national identity
* ✅ Developing credential flows compatible with Sundial Protocol and Cardano smart contracts
* ✅ Participating in DID registry work with Cardano-based identity registrars
* ✅ Collaborating with DeFi protocols for identity-gated financial products
* ✅ Contributing to open standards across the SSI and blockchain ecosystems `GITREFERENCE`

We’re proud to be building alongside:

* **Midnight Network** — privacy-preserving zk infrastructure
* **Cardano Developer Community** — L2, rollups, identity tooling
* **Sundial Protocol** — BTC settlement via Cardano smart contracts
* **Maesttro, FluidTokens, Anastasia Labs** — RWA and Bitcoin DeFi protocol builders
* **Wallet teams** like Eternl, Flint, Typhon, Nami — enabling real adoption
* **SSI infrastructure orgs** and regulators advancing digital ID interoperability globally

Together, we’re not just imagining this future—we’re implementing it.

***

### 🌐 The Path Forward

We now have:

✅ Legal identity

✅ Privacy-preserving proofs

✅ Smart contract enforceability

✅ Settlement with BTC, stablecoins, and tokenized RWAs

✅ Institutional UX via modern wallets and APIs

✅ Interoperability with national and supranational identity systems

The tools are built.

The standards are converging.

The builders are aligned.

***

### 🧭 This Is the Global Financial Stack of the 2030s

It’s open. It’s private. It’s compliant.

And it works.

**Fairway is proud to be laying its foundation—identity first.**

We invite developers, governments, institutions, and protocol teams to join us in deploying this future.

***

### 📚 Sources & References

* [EUDI Wallet Architecture](https://ec.europa.eu/digital-building-blocks/wikis/display/EUDIGITALID/)
* [EBSI Technical Framework](https://ec.europa.eu/digital-building-blocks/wikis/display/EBSI/)
* [MOSIP Open Identity Platform](https://www.mosip.io/)
* Midnight: Cardano’s ZK Layer
* [Midgard Protocol](https://midgardprotocol.com/)
* [Sundial Protocol](https://twitter.com/ada_sundial)
* Cardano Wallet Ecosystem Overview
* [Maesttro Protocol](https://twitter.com/maesttrofi)
* [Fluid Tokens](https://fluidtokens.com/)
* [Anastasia Labs](https://twitter.com/anastasialabs)
* `GITREFERENCE` — Link to Fairway tech docs, whitepapers, use case workflows, ecosystem maps, and demo videos