Trust Infrastructure

Trust infrastructure
for AI.

Provenance, AI decisions, authority, regulatory attributes. For each, a cryptographic proof.

Every time AI uses data, the questions follow: where did it come from, what did it look at to decide, on whose behalf did it act, and does it meet the regulations? Lemma trust infrastructure answers all four across four axes.

Trust, across every phase.

Your AI workflow stays as-is. Add the Lemma trust layer once, and proofs ride along every phase — from input through delegated execution.

PHASE 01 · INPUT

Input

P1 · VERIFIABLE ORIGIN

Verifiable Origin

Explore P1 →

PHASE 02 · INFERENCE

Inference

P2 · VERIFIABLE AI

Verifiable AI

Explore P2 →

PHASE 03 · DECISION

Decision

P4 · REGULATORY

Regulatory Attribute Proof

Explore P4 →

PHASE 04 · DELEGATION

Delegation

P3 · AGENT AUTHORITY

Agent Authority Proof

Explore P3 →

Proprietary cryptography,
three cores.

Three core technologies make the trust infrastructure work — establishing "it's the same thing," "disclose only this," and "no one can rewrite it," all without touching the original data.

Zero-Knowledge
Proof

Zero-Knowledge Proof

Turn business rules like "18 or older" or "revenue over threshold" into machine-verifiable cryptographic facts. Prove a statement's truth without touching the original.

Lemma's edge

Each proof is recorded permanently with its circuit (Circom) and generator, so a third party can reproduce it later.

Read the technical docs

core of delegate without sharing

Selective
Disclosure

Selective Disclosure

Keeping the binding to the original issuer signature, the holder reveals only the attributes a model needs. Minimize what AI receives as input.

Lemma's edge

From one issued credential, vary the disclosure per counterparty and use. Hide / Reveal stays controllable after issuance.

Read the technical docs

core of disclose selectively

On-chain
Provenance

On-chain Provenance

Anchor the document commitment, schema, issuer, and ZK verification result on-chain. Fix it as provenance that can be neither rewritten nor erased.

Lemma's edge

Only the docHash and CID are public; the body stays AES-GCM encrypted. Keep provenance without exposing the contents.

Read the technical docs

core of prove after the fact

Data stays in place.
Only proofs travel.

The source mints a proof, only the necessary parts are selectively disclosed, and a verifier checks them with a public key. Through all three phases, raw data never moves.

Phase 01 · Issue

Mint the proof at the source

Embed the Lemma SDK at the source. Issue attribute proofs for data, models, and authority. Raw data never leaves.

BBS+ Signature

Poseidon Hash

DID / VC (W3C)

Phase 02 · Prove

Reveal just enough

Selectively disclose only the facts a verifier needs — authority, attribute, integrity. Raw data is never touched.

Groth16 / BN254

Circom 2.x Circuit

Selective Disclosure

Phase 03 · Verify

Anyone can confirm

Anyone, anytime, verifies authenticity with a public key. Optionally anchor as tamper-evident audit attestations.

Public verify (no trust)

EIP-712 attestation

audit anchor (optional)

ZK Groth16 / BN254

Signing BBS+ / EdDSA

Hash Poseidon / Keccak

Identifier W3C DID/VC

Audit anchor EIP-712 / x402

Read the technical spec →

Four axes,
your schema.

Trust infrastructure has four axes — verifiable origin, verifiable AI, agent authority proof, regulatory attribute proof. Schemas aren't dictated by Lemma; define them to fit your domain and issue/verify them via the SDK. The examples below are framed as your.*.v1.

{
  "schema": "your.provenance.v1",
  "subject": "did:lemma:utility-meter-001",
  "issuer": "did:lemma:org-acme-utility",
  "sourceHash": "0x9f3a...c4e8",
  "lineageChain": ["sensor", "scada", "oracle"],
  "recordedAt": "2026-06-02T14:30:00Z",
  "integrity": "poseidon-merkle",
  "proof": {
    "type": "BBS+Signature2020",
    "value": "0x4a2b...e1d3"
  }
}

P1 · Verifiable Origin

Provenance schema

Record the multi-tier provenance of data as it propagates sensor → SCADA → Oracle, in tamper-evident form. The body never leaks; a hash chain + BBS+ signature proves "this is the same thing."

Capability: Prove data source and tamper-evidence without disclosing content

Use cases: RAG source trust / training data clearance / IoT sensor provenance

SigningBBS+

HashPoseidon-Merkle

IdentifierW3C DID

{
  "schema": "your.model.v1",
  "agent": "did:lemma:agent-fin-bot-007",
  "modelId": "claude-3.7-sonnet",
  "policyHash": "0x71c5...8b9a",
  "inputCommitment": "0xb4e2...3f10",
  "outputCommitment": "0xc8f1...a2d5",
  "satisfiesPolicy": true,
  "proof": {
    "type": "Groth16",
    "circuit": "lemma/model-attest@1.0",
    "value": "0x9d7e...c4f2"
  }
}

P2 · Verifiable AI

Model schema

Record the model ID, applied-policy hash, and commitments over inputs and outputs. The actual I/O is never revealed; only policy satisfaction is proven via Groth16. Closes the LLM audit blind spot.

Capability: Independently verify AI input/output integrity

Use cases: AI audit logs / compliance reporting / accountability

ProofGroth16 / BN254

CircuitCircom 2.x

CommitPedersen / Poseidon

BridgesMCP / Anthropic

{
  "schema": "your.agent.v1",
  "agent": "did:lemma:agent-treasury-042",
  "delegatedBy": "did:lemma:org-acme-fin",
  "role": "treasury_agent",
  "spendLimitUSDC": 500,
  "scope": "x402://api.partner.jp/*",
  "validUntil": "2026-06-30T23:59:59Z",
  "proof": {
    "type": "Groth16+EIP3009",
    "x402PaymentId": "0xa1f3...7d8e",
    "value": "0x6b2c...e4a9"
  }
}

P3 · Agent Authority

Agent schema

delegatedBy says who delegated; role / spendLimit / scope say what and how far. Attached per x402 payment via Trust402, proving an autonomous agent's actions with authority bound.

Capability: Run autonomous agents in production—full speed in scope, stop out of scope

Use cases: Agent payments / expense approval / API metering / cross-agent

ProofGroth16 + EIP-3009

PaymentUSDC / x402

DelegationDID-based VC

ProductTrust402

{
  "schema": "your.attribute.v1",
  "holder": "did:lemma:org-fsa-licensed",
  "issuer": "did:lemma:authority-jp-fsa",
  "jurisdiction": "JP-FSA",
  "licenseType": "type-1-financial",
  "disclosed": ["isLicensed", "validUntilYear"],
  "hidden": ["licenseNo", "address", "executives"],
  "proof": {
    "type": "BBS+SelectiveDisclosure",
    "value": "0x3c8d...f7a2"
  }
}

P4 · Regulatory Attribute

Attribute schema

Attribute credentials issued by authorities. disclosed / hidden control what is shown and what stays hidden, via BBS+ selective disclosure. Eliminates the need to centralize KYC / license raw data.

Capability: Prove regulatory attributes selectively without sharing originals

Use cases: KYC / AML / CBAM / EUDR / AI Act / public procurement

ProofBBS+ Selective

IdentifierW3C DID / VC

StandardeIDAS / DID-Auth

ProductLemma Compliance

From here, it opens up