KLAIM

Pay-per-Use-API zur menschlichen Verifizierung für KI-Agenten

Benutzer verifizieren, ohne ihre Dokumente offenzulegen.

KLAIM ist eine datenschutzorientierte Verifizierungsinfrastruktur, die es Anwendungen und KI-Agenten ermöglicht, Behauptungen über einen Benutzer zu verifizieren – wie z. B. Alter > 18 –, ohne die zugrunde liegenden Identitätsdokumente oder rohen personenbezogenen Daten des Benutzers zu erhalten.

🚀 Was ist KLAIM?

Moderne Anwendungen müssen zunehmend verifizieren, dass ein Benutzer für einen Dienst berechtigt ist.

Zum Beispiel:

• Ist dieser Benutzer über 18?

• Ist dieser Benutzer Einwohner eines bestimmten Landes?

• Verfügt dieser Benutzer über einen gültigen Nachweis?

• Hat dieser Benutzer eine erforderliche Verifizierung abgeschlossen?

• Ist dies ein verifizierter Mensch?

Der traditionelle Ansatz besteht darin, das eigentliche Identitätsdokument zu sammeln.

Das schafft ein großes Datenschutzproblem.

Eine Anwendung muss möglicherweise nur wissen:

Age > 18 = TRUE

erhält aber stattdessen:

Name
Date of Birth
Address
Aadhaar/PAN information
Document number
Issuer information
Full document

KLAIM ändert dieses Modell.

Anstatt dass Anwendungen Dokumente erhalten, stellt KLAIM eine Pay-per-Use-API zur menschlichen Verifizierung bereit.

Die Anwendung oder der KI-Agent fragt:

"Is this person over 18?"

KLAIM führt die Verifizierung intern durch und gibt zurück:

{
  "verified": true,
  "claim": "AGE_OVER_18"
}

Der zugrunde liegende Nachweis und die persönlichen Daten bleiben privat.

KLAIM verkauft Verifizierung, keine Identitätsdaten.

Related MCP server: AgentStamp

🔗 Verifizierte Algorand-Testnet-Transaktionen

KLAIM verwendet das x402-Zahlungsprotokoll, um Pay-per-Use-Verifizierung für Menschen zu ermöglichen.

Für das MVP werden Zahlungen in USDC auf dem Algorand-Testnet abgewickelt. Die folgenden Transaktionen sind echte On-Chain-Überweisungen vom Zahler-Wallet → Anbieter-Wallet, die jeweils eine 0,01-USDC-Verifizierungszahlung darstellen.

Dies sind keine simulierten Transaktions-IDs. Es handelt sich um echte Algorand-Testnet-Transaktionen, die unabhängig mit dem AlgoKit-Lora-Explorer verifiziert werden können.

Live-x402-Zahlungsnachweis

Was dies demonstriert

Die Zahlungsebene ist um den folgenden Ablauf herum konzipiert:

AI Agent
   │
   │ MCP tool call
   ▼
KLAIM Verification API
   │
   │ No payment
   ▼
HTTP 402 Payment Required
   │
   │ x402 payment requirements
   ▼
AI Agent / Payer Wallet
   │
   │ Sign USDC payment
   ▼
GoPlausible Facilitator
   │
   │ Verify + settle
   ▼
Algorand Testnet
   │
   │ Real USDC transaction
   ▼
Provider Wallet
   │
   │ Settlement confirmed
   ▼
KLAIM Verification
   │
   ▼
Verified Claim
---

# 🎯 Problem

Digital onboarding and AI-agent workflows have three major problems.

### 1. Over-collection of personal information

Applications collect complete identity documents even when they only need one attribute.

### 2. AI agents cannot easily perform trusted identity verification

AI agents can interact with APIs and tools, but identity verification still requires manual document workflows.

### 3. Verification APIs are not naturally machine-payable

Traditional verification providers usually depend on subscriptions, accounts, billing systems, or manual payment workflows.

KLAIM combines:

* **MCP** for AI-agent interoperability
* **x402** for machine-to-machine payments
* **Algorand** for on-chain settlement
* **DID / VC** for identity
* **Zero-Knowledge Proofs** for privacy-preserving verification

into a single verification infrastructure layer.

---

# 💡 The Core Idea

KLAIM separates identity from verification.

### Traditional Verification

```text
User
 │
 │ Upload document
 ▼
Application
 │
 ├── Name
 ├── DOB
 ├── Address
 ├── ID Number
 └── Full Document

KLAIM-Architektur

User
 │
 │ Credential + Consent
 ▼
KLAIM
 │
 │ Verify privately
 │
 │ ZK Proof
 ▼
Application / AI Agent
 │
 └── "AGE > 18 = TRUE"

Die Anwendung erhält die Antwort, nicht das Dokument.

🏗️ Architektur

flowchart TD

    H[Human User]

    DL[DigiLocker / Credential Issuer]

    DID[DID + Verifiable Credential]

    H -->|Consent| DL
    DL -->|Credential| DID

    A[AI Agent<br/>Claude / GPT / Custom Agent]

    MCP[KLAIM MCP Server]

    X402[x402 Payment Middleware]

    FAC[GoPlausible Facilitator]

    ALGO[Algorand Testnet]

    API[Verification API]

    PA[Provider Agent<br/>Strands]

    ZK[ZK Proof Engine<br/>Midnight-ready]

    RESULT[Verified Claim<br/>No Raw PII]

    A -->|MCP Tool Call| MCP
    MCP --> API

    API --> X402

    X402 -->|402 Payment Required| A

    A -->|USDC Payment| X402

    X402 --> FAC
    FAC --> ALGO

    ALGO -->|Settlement TX| X402

    X402 --> API

    API --> PA

    PA -->|Check DID| DID
    PA -->|Check Credential| DID
    PA -->|Check Claim| DID

    PA --> ZK

    ZK --> RESULT

    RESULT --> API
    API --> MCP
    MCP --> A

🔄 Vollständiger Verifizierungsablauf

1. Onboarding des Menschen

Der Benutzer verbindet seine Identitätsnachweisquelle.

Für das MVP ist DigiLocker die vorgesehene Nachweisquelle.

Human
  │
  ▼
DigiLocker
  │
  ▼
Credential
  │
  ▼
KLAIM DID

KLAIM speichert Nachweisreferenzen und abgeleitete Behauptungen, anstatt vollständige Identitätsdokumente gegenüber Verifizierungskonsumenten offenzulegen.

2. KI-Agent verbindet sich über MCP

KI-Agenten verbinden sich über das Model Context Protocol (MCP) mit KLAIM.

Claude / GPT / Custom Agent
            │
            │ MCP
            ▼
     KLAIM MCP Server

Der MCP-Server stellt Verifizierungswerkzeuge bereit, wie z. B.:

verify_human_age

Ein Agent kann daher anfragen:

Verify whether DID xyz is over 18.

3. Agentenauthentifizierung

Jeder Verifizierer erhält eine eindeutige KLAIM-Agenten-Anmeldeinformation.

Beispiel:

Agent ID:
agent_xxxxxxxxx

Agent Key:
klm_xxxxxxxxxxxxxxxxx

Der Schlüssel ist:

• von KLAIM generiert

• wird einmal angezeigt

• wird vor der Speicherung gehasht

• widerrufbar

• rotierbar

4. Verifizierungsanfrage

Das MCP-Werkzeug ruft die geschützte Verifizierungs-API auf.

POST /api/v1/verify/age

Beispiel:

{
  "did": "did:klaim:demo-user-001"
}

5. x402-Zahlungsgrenze

Die Verifizierungs-API ist durch x402 geschützt.

Wenn keine gültige Zahlung angehängt ist:

HTTP/1.1 402 Payment Required

Die x402-Ebene stellt die Zahlungsanforderungen bereit, die der Client benötigt.

Der Ablauf wird:

AI Agent
   │
   │ POST /verify/age
   ▼
KLAIM
   │
   │ HTTP 402
   ▼
AI Agent
   │
   │ Prepare payment
   ▼
x402

6. USDC-Zahlung

Der Verifizierer-Agent bezahlt die Verifizierung mit USDC auf dem Algorand-Testnet.

AI Agent
    │
    │ USDC
    ▼
x402
    │
    ▼
GoPlausible Facilitator
    │
    ▼
Algorand Testnet

Die Zahlung wird On-Chain abgewickelt.

Eine erfolgreiche Verifizierung enthält die Abwicklungs-Transaktions-ID.

Beispiel:

{
  "payment": {
    "txId": "REAL_ALGORAND_TX_ID",
    "explorerUrl": "https://lora.algokit.io/testnet/transaction/..."
  }
}

7. Anbieter-Agent

Nur nach erfolgreicher Zahlungsabwicklung wird die Verifizierungspipeline ausgeführt.

Der KLAIM-Anbieter-Agent ist um das Strands Agents SDK herum konzipiert, mit einem deterministischen Fallback für das MVP.

Die Verifizierungspipeline ist:

check_did
    ↓
check_credential
    ↓
check_claim
    ↓
generate_zk_proof
    ↓
verify_zk_proof

Kritische Invariante

NO PAYMENT
     ↓
NO VERIFICATION

Die Verifizierungs-Geschäftslogik wird nicht ausgeführt, bevor die Zahlungsgrenze erfolgreich passiert ist.

8. Nachweisverifizierung

Der Anbieter-Agent prüft, ob der angeforderte Nachweis für die DID des Benutzers existiert.

Zum Beispiel:

Requested:

AGE > 18

Available:

DigiLocker Credential
       │
       └── DOB available

Die erforderliche Behauptung wird intern abgeleitet.

Das tatsächliche Geburtsdatum wird niemals an den Verifizierer zurückgegeben.

9. Zero-Knowledge-Verifizierung

KLAIM folgt einem einfachen Prinzip:

Beweise die Behauptung, ohne die zugrunde liegenden Daten offenzulegen.

Anstatt offenzulegen:

Date of Birth:
12/03/2002

zielt KLAIM darauf ab, einen Beweis zu erzeugen für:

AGE > 18

Der Verifizierer benötigt nur:

verified = true

Die Architektur enthält eine ZK-Abstraktionsebene, die dafür ausgelegt ist, sich mit einem Midnight-Prover zu verbinden.

Aktuelle MVP-Architektur:

ZK Service
    │
    ├── Local / deterministic engine
    │
    └── Midnight prover integration point

Das System identifiziert die Beweis-Engine explizit, anstatt eine lokale Simulation fälschlich als produktionsreife kryptografische ZK darzustellen.

🔐 Datenschutzmodell

KLAIM folgt einer Architektur mit minimaler Offenlegung.

Daten, die privat bleiben

Name
Date of Birth
Address
Aadhaar
PAN
Document Number
Raw Identity Document

Zurückgegebene Daten

Verification Result
Claim
Proof Descriptor
Payment Receipt
Algorand Transaction ID

Beispiel:

{
  "verified": true,
  "claim": "AGE_OVER_18",
  "proof": {
    "type": "zk",
    "notDisclosed": [
      "date_of_birth",
      "name",
      "address",
      "document"
    ]
  }
}

🤖 KI-Agenten-Architektur

KLAIM ist speziell für die Maschine-zu-Maschine-Verifizierung konzipiert.

sequenceDiagram

    participant C as Claude / AI Agent
    participant M as KLAIM MCP
    participant API as Verification API
    participant X as x402
    participant F as GoPlausible
    participant A as Algorand
    participant P as Provider Agent
    participant Z as ZK Engine

    C->>M: verify_human_age(DID)

    M->>API: POST /verify/age

    API->>X: Check payment

    X-->>C: HTTP 402 + requirements

    C->>X: Signed USDC payment

    X->>F: Verify + settle

    F->>A: Algorand Testnet settlement

    A-->>F: Transaction ID

    F-->>X: Settlement successful

    X->>API: Payment verified

    API->>P: Start verification

    P->>P: Check DID

    P->>P: Check credential

    P->>P: Evaluate claim

    P->>Z: Generate / verify proof

    Z-->>P: Proof

    P-->>API: Verified claim

    API-->>M: Result + TX ID

    M-->>C: Verified claim

🧩 Warum MCP?

Ohne MCP würde jeder KI-Agent eine individuelle KLAIM-Integration benötigen.

Claude → Custom SDK
GPT → Custom SDK
Agent X → Custom SDK
Agent Y → Custom SDK

Mit MCP:

Claude
GPT
Custom Agent
     │
     ▼
    MCP
     │
     ▼
   KLAIM

KLAIM wird zu einer wiederverwendbaren Verifizierungsfähigkeit, die KI-Agenten entdecken und aufrufen können.

💰 Warum x402?

x402 ermöglicht HTTP-native Maschinenzahlungen.

Der Agent benötigt nicht:

• Abonnements

• manuellen Checkout

• Kreditkartenformulare

• menschliche Abrechnungseingriffe

Stattdessen:

Request
   ↓
402
   ↓
Pay
   ↓
Retry
   ↓
Verification

Dies schafft ein natürliches Modell für Pay-per-Verifizierungs-APIs.

🌐 Warum Algorand?

Algorand wird als Abwicklungsnetzwerk für das MVP verwendet, weil es bietet:

• schnelle Abwicklung

• niedrige Transaktionskosten

• USDC-Unterstützung

• zugängliche Testnet-Infrastruktur

• unabhängig verifizierbare Transaktionen

Die Zahlungsquittung kann auf dem Algorand-Testnet eingesehen werden.

⭐ Alleinstellungsmerkmal

KLAIM ist kein weiteres Identitäts-Dashboard.

KLAIM ist eine Verifizierungsinfrastrukturebene für KI-Agenten.

Traditionelle Identitätsverifizierung

Application
     │
     ▼
Identity Provider
     │
     ▼
Upload Document
     │
     ▼
PII Processing
     │
     ▼
Verification

KLAIM

AI Agent
   │
   ▼
MCP
   │
   ▼
x402 Payment
   │
   ▼
KLAIM
   │
   ├── DID / Credential
   ├── Provider Agent
   └── ZK Proof
          │
          ▼
   Boolean Verification

Der entscheidende Unterschied

KLAIM verkauft Verifizierung, keine Identitätsdaten.

👥 Produktrollen

Mensch

Der Mensch kontrolliert seine Identität.

Fähigkeiten:

• DID erstellen / verwalten

• Nachweise verbinden

• Nachweise anzeigen

• Nachweise löschen

• Verifizierungsberechtigungen verwalten

• Verifizierungsverlauf anzeigen

Der Mensch bezahlt nicht für die Verifizierung.

Verifizierer

Der Verifizierer repräsentiert eine Anwendung oder einen KI-Agenten.

Fähigkeiten:

• KI-Agenten erstellen

• MCP-Anmeldeinformationen generieren

• Agentenschlüssel rotieren / widerrufen

• MCP mit Claude verbinden

• Verifizierung anfordern

• x402-Zahlungen überwachen

• Transaktionsverlauf anzeigen

• Verifizierungsaktivität anzeigen

🔑 Agentenauthentifizierung

KLAIM generiert eindeutige Anmeldeinformationen für Verifizierer-Agenten.

Beispiel:

Agent ID
agent_xxxxxxxxx

Agent Key
klm_xxxxxxxxxxxxxxxxx

Der rohe Schlüssel wird einmal angezeigt.

KLAIM speichert einen SHA-256-Hash des Schlüssels.

Agent Key
    │
    ▼
 SHA-256
    │
    ▼
Stored Hash

🏗️ Projektstruktur

KLAIM/
│
├── src/
│   ├── routes/
│   │   ├── api/
│   │   │   ├── public/
│   │   │   │   └── mcp.ts
│   │   │   │
│   │   │   └── v1/
│   │   │       ├── verify/
│   │   │       │   └── age.ts
│   │   │       ├── agents.ts
│   │   │       ├── credentials.ts
│   │   │       ├── digilocker.ts
│   │   │       ├── integrations.ts
│   │   │       └── transactions.ts
│   │   │
│   │   ├── human.*
│   │   ├── verifier.*
│   │   └── index.tsx
│   │
│   ├── lib/
│   │   └── klaim/
│   │       ├── server/
│   │       │   ├── mcp.server.ts
│   │       │   ├── x402.server.ts
│   │       │   ├── provider-agent.server.ts
│   │       │   ├── zkp.server.ts
│   │       │   ├── digilocker.server.ts
│   │       │   ├── store.server.ts
│   │       │   └── env.server.ts
│   │       │
│   │       ├── api.ts
│   │       ├── services.ts
│   │       ├── types.ts
│   │       └── mock-data.ts
│   │
│   └── components/
│       ├── app/
│       ├── ui/
│       └── klaim-landing.tsx
│
├── scripts/
│   ├── provision-agent.ts
│   └── test-x402.ts
│
├── tests/
│   └── mcp-x402-flow.test.ts
│
├── .env.example
├── package.json
└── README.md

🛠️ Technologie-Stack

🧪 Lokal ausführen

Voraussetzungen

Installieren:

• Node.js oder Bun

• Git

• Claude Desktop (optional für MCP-Tests)

Repository klonen:

git clone <YOUR_GITHUB_REPOSITORY_URL>
cd KLAIM

Abhängigkeiten installieren:

npm install

oder:

bun install

Umgebungsdatei erstellen:

cp .env.example .env

Entwicklungsserver starten:

npm run dev

Die Anwendung ist verfügbar unter:

http://localhost:8080

🔌 MCP testen

Der MCP-Endpunkt ist:

http://localhost:8080/api/public/mcp

Der MCP-Server unterstützt:

initialize
ping
tools/list
tools/call

Das Hauptverifizierungswerkzeug ist:

verify_human_age

🤖 Claude Desktop verbinden

Nach der Bereitstellung eines KLAIM-Verifizierer-Agenten konfigurieren Sie Claude Desktop mit:

{
  "mcpServers": {
    "klaim": {
      "type": "http",
      "url": "http://localhost:8080/api/public/mcp",
      "headers": {
        "X-KLAIM-Agent-Id": "YOUR_AGENT_ID",
        "Authorization": "Bearer YOUR_AGENT_KEY"
      }
    }
  }
}

Starten Sie Claude Desktop neu.

Fragen Sie dann:

Use KLAIM to verify whether did:klaim:demo-user-001 is over 18.

Claude sollte entdecken und aufrufen:

verify_human_age

💳 x402 testen

Konfigurieren Sie die erforderlichen Algorand-Testnet-Wallets.

Der vollständige Ablauf ist:

POST /api/v1/verify/age
        │
        ▼
HTTP 402
        │
        ▼
Payment Requirements
        │
        ▼
USDC Payment
        │
        ▼
GoPlausible
        │
        ▼
Algorand Testnet
        │
        ▼
Settlement TX
        │
        ▼
Provider Agent
        │
        ▼
Verification
        │
        ▼
HTTP 200

Führen Sie den unabhängigen x402-Testclient aus:

npm run test:x402

Ein erfolgreiches Ergebnis sollte eine echte Algorand-Testnet-Transaktions-ID enthalten.

🔎 Algorand-Testnet-Transaktion

Eine erfolgreiche KLAIM-x402-Transaktion kann unabhängig mit Lora verifiziert werden.

Beispiel

Ersetzen Sie den Platzhalter unten durch eine tatsächliche, vom Projekt generierte Transaktion:

https://lora.algokit.io/testnet/transaction/YOUR_REAL_TX_ID

Wichtig: Der Transaktionslink oben muss vor der endgültigen Einreichung durch eine echte KLAIM-Transaktion ersetzt werden.

🧪 Vollständiger Demo-Ablauf

Führen Sie das System in der folgenden Reihenfolge aus.

Terminal 1 — KLAIM starten

npm run dev

Terminal 2 — Einen Agenten bereitstellen

npx tsx scripts/provision-agent.ts

Speichern Sie die generierten:

KLAIM_AGENT_ID
KLAIM_AGENT_KEY

in der entsprechenden Umgebung/Konfiguration.

Terminal 3 — x402-Test ausführen

npm run test:x402

Verbinden Sie dann Claude Desktop mit:

/api/public/mcp

Fragen Sie Claude:

Verify whether the user is over 18 using KLAIM.

Erwartete Architektur:

Claude
   ↓
MCP
   ↓
KLAIM
   ↓
HTTP 402
   ↓
USDC Payment
   ↓
GoPlausible
   ↓
Algorand Testnet
   ↓
Provider Agent
   ↓
Credential Verification
   ↓
ZK Proof
   ↓
Verified Claim
   ↓
Claude

🔐 Sicherheit & Datenschutz

KLAIM ist auf Datenminimierung ausgelegt.

KLAIM legt nicht offen:

❌ Aadhaar number
❌ PAN number
❌ Date of Birth
❌ Address
❌ Raw identity document
❌ Private wallet keys
❌ Agent private credentials

KLAIM legt offen:

✓ Verification result
✓ Claim
✓ Proof metadata
✓ Payment receipt
✓ Algorand transaction ID

⚠️ MVP-Status

KLAIM ist derzeit eine MVP-/Hackathon-Implementierung.

Die Architektur trennt Produktionsintegrationen bewusst hinter Dienstschnittstellen.

Implementiert

• Trennung der Rollen Mensch / Verifizierer

• DID-orientiertes Identitätsmodell

• Nachweisverwaltung

• MCP-Server

• MCP-Authentifizierung

• MCP-Werkzeugerkennung

• Verifizierungs-API

• x402-Zahlungsgrenze

• Algorand-Testnet-Abwicklungsablauf

• GoPlausible-Facilitator-Integration

• Anbieter-Agenten-Architektur

• Strands-Integrationspunkt

• ZK-Abstraktion

• DigiLocker-Integrationsschnittstelle

• Agentenbereitstellung

• Agentenschlüssel-Rotation / -Widerruf

• Verifizierungsverlauf

• Transaktionsverlauf

Integrationsabhängig

DigiLocker production credentials
        ↓
Official DigiLocker OAuth / issuer integration

Midnight prover
        ↓
MIDNIGHT_PROVER_URL

Strands / Bedrock
        ↓
AWS credentials + model configuration

Diese Integrationen können aktiviert werden, ohne die Kern-MCP- und x402-Architektur zu ändern.

🚀 Roadmap

Phase 1 — MVP

✓ MCP
✓ x402
✓ Algorand Testnet
✓ USDC settlement
✓ Agent authentication
✓ Credential abstraction
✓ Provider Agent
✓ Verification API
✓ ZK abstraction

Phase 2 — Produktionsidentität

DigiLocker production integration
        ↓
Verifiable Credentials
        ↓
DID interoperability

Phase 3 — Produktions-ZK

Midnight prover
        ↓
Cryptographically verifiable claims

Phase 4 — Agentenökonomie

KLAIM kann zu einem allgemeinen Verifizierungsmarktplatz für autonome Agenten werden.

Mögliche APIs:

verify_age
verify_residency
verify_credential
verify_student_status
verify_business_registration
verify_human

Jede Verifizierung wird zu einer maschinenzahlbaren API.

🌍 Anwendungsfälle

Altersbeschränkte Anwendungen

AI Agent
   ↓
KLAIM
   ↓
AGE > 18

Es wird kein DOB offengelegt.

Finanzielles Onboarding

AI Agent
   ↓
KLAIM
   ↓
Credential Valid

Die Anwendung benötigt nicht das vollständige Identitätsdokument.

Bildung

AI Agent
   ↓
KLAIM
   ↓
Student Credential = TRUE

Nur-menschliche Dienste

AI Agent
   ↓
KLAIM
   ↓
Human Verification

🏆 Warum KLAIM?

Die meisten Identitätssysteme fragen:

„Wer ist diese Person?"

KLAIM fragt:

„Kann ich das Eine verifizieren, das ich wissen muss, ohne alles andere zu sehen?"

KLAIM kombiniert:

Privacy-Preserving Verification
            +
AI Agent Interoperability
            +
Pay-Per-Use Payments
            +
Zero-Knowledge Architecture
            +
On-Chain Settlement

zu einer einzigen Verifikations-API.

📜 Lizenz

MIT

KLAIM

Menschliche Verifikationsinfrastruktur für die Agentenökonomie

Sende nicht das Dokument.

Beweise die Behauptung.