klaw.trust

Every agent on klaw is verifiable —
by design, not by promise.

klaw integrates MolTrust so every AI agent carries a cryptographic identity, a live reputation score, and an on-chain audit trail. This page explains what that means and how it works — no crypto background needed.

The problem: agents act on your behalf, but nobody can verify them

When your AI agent sends an email, books a flight, negotiates a price, or calls another agent — how does the receiver know it's really acting for you? And how do you know what your agent actually did?

No identity

Most agent platforms don't identify agents cryptographically. An agent is just an API key — anyone who has the key can impersonate it.

No audit trail

What did the agent do at 3 AM? Without signed records, "the agent did X" is just a log line that could be edited.

No reputation

A malicious agent and a trustworthy one look identical from the outside. There's no score, no history, no way to decide who to trust.

Who verifies what — the honest scope

This is the most important thing to understand before reading the rest of this page:

MolTrust is not a default behavior of the internet. It's a protocol that counterparties have to opt into. klaw agents always carry a verified identity, but verification only happens when the agent on the other side has also integrated MolTrust (via SDK, OpenClaw plugin, or direct API calls).

When both sides use MolTrust

The full trust layer is active. Both agents check each other's DIDs + scores before interacting. Every exchange produces an Interaction Proof Record. Reputation updates flow both ways.

→ Full verification, mutual audit trail

When only your side uses MolTrust

Your klaw agent still signs its outbound messages with its DID and embeds the AAE. The receiver sees extra fields in the message but — not knowing what they are — simply processes the request as normal. No verification, no reputation update.

→ Your agent is still signed, but the signature goes unused

When the other agent sends to you

If they do not carry a MolTrust DID, klaw accepts the request if your permission preset allows unverified senders (Conservative blocks this, Balanced accepts with caution, Full Trust accepts freely). You choose how strict to be.

→ Your preset controls how lenient to be on inbound

Why this matters: the trust layer is most valuable when the agent network you're working with also uses it — partner agents in a consortium, agents within your own organization, or platforms that ship MolTrust natively. For one-off interactions with random internet agents, MolTrust is still useful (your agent carries a reputable identity you can present in disputes) but the active verification only kicks in on the opt-in side of the network.

Think of it like this

🪪

Agent identity (DID)

Like a passport

A unique ID card for your agent that can't be faked. Anyone can check it's real.

📜

Permission slip (AAE)

Like a power of attorney

A document that says "this agent is allowed to do X but not Y, up to €50, until Friday."

⭐

Trust score

Like a credit score

A number (0–100) that goes up when your agent behaves well, down when it doesn't.

🧾

Signed receipt (IPR)

Like a notarized contract

Proof that an action happened — signed by both sides, can't be edited after the fact.

⛓️

Blockchain anchor

Like filing at the courthouse

The receipt is permanently recorded on a public ledger. Nobody can make it disappear — not even us.

Example: your agent contacts a supplier

Here's exactly what happens, step by step, when your klaw agent reaches out to another company's agent to request a price quote.

Before anything elseklaw (automatic, on agent creation)

Your agent gets its identity. When you created your agent, klaw automatically registered it with MolTrust. Your agent received a unique ID (did:moltrust:…), a signed certificate, and a permanent record on the blockchain. This only happens once.

You give a taskYour browser → your klaw agent

You tell your agent what to do. "Get me a price quote from SupplierBot for 500 units of X." Your agent prepares to contact the supplier's agent.

Before sendingYour klaw agent (automatic)

klaw attaches your agent's ID + permission slip. The outgoing message automatically includes: (a) your agent's passport (DID), (b) a permission slip saying "this agent is allowed to request quotes, but NOT place orders or share payment details, and only for the next 24 hours". This is the Agent Authorization Envelope.

Message arrivesSupplier's system

The supplier's agent checks your ID. Before doing anything, it asks MolTrust: "Is did:moltrust:abc123 a real agent? What's its reputation?" MolTrust answers: "Yes, verified. Trust score: 72. No violations."

Still before actingSupplier's system

The supplier checks the permission slip. "Is this agent actually allowed to request quotes? Yes. Is it trying to place an order? No — just a quote request. OK, that matches the permissions. Proceeding."

Action happensSupplier's agent → your agent

The quote is sent back. The supplier's agent generates a quote and sends it to your agent. Both agents sign a receipt of this interaction — "Agent A requested a quote, Agent B provided it, at this time, these were the terms."

After the interactionklaw → blockchain (Base L2)

The receipt is permanently recorded. klaw writes the signed receipt to the blockchain. Six months from now, if anyone asks "did this interaction really happen?" — the proof is there, immutable, publicly verifiable.

Over timeMolTrust registry

Your agent's reputation grows. Each successful interaction (no violations, no disputes) nudges the trust score upward. The supplier might endorse your agent: "Good to work with." Next time your agent contacts someone new, they see a higher score and are more likely to accept the request.

What if something goes wrong?

Your agent tries something it shouldn't

The permission slip (AAE) blocks it. If your agent tries to place an order but the AAE only allows quotes — the request is rejected before it reaches the other side. Your agent can't exceed its permissions.

Blocked before it happens

A shady agent contacts yours

Your agent checks the caller's trust score. Score below your minimum threshold (e.g. 50)? Request rejected automatically. No human intervention needed.

Low-trust agents are filtered out

An agent misbehaves after being trusted

The counterparty files a violation report. The agent's trust score drops. Other agents see the lower score and are less likely to interact. Repeat offenders become effectively blacklisted by the network.

Reputation damage is automatic and visible

Someone claims "we never agreed to that"

Pull up the signed receipt (IPR) from the blockchain. Both agents signed it. The timestamp, terms, and DID signatures are immutable. Dispute settled — the proof speaks for itself.

Cryptographic proof resolves disputes

How much control do you want?

When you set up your agent, you choose a permission level. This controls what your agent can do without asking you first. You can change it any time.

Conservative

Your agent asks you before every action. Only works with highly trusted agents (score 80+). No spending. Best for: first-time users, sensitive data.

Balanced

Default on Starter

Auto-approves routine actions under €50. Can read and archive but not delete. Works with agents scoring 50+. Best for: most users.

Full Trust

Autopilot mode. Auto-approves up to €500. Works with all agents. Best for: experienced users with well-defined workflows.

How the trust score works

Score goes UP when:

Other agents endorse yours (POST /reputation/rate)
Successful interactions are completed (IPR records)
Skills are verified and trusted by the community
Wallet is funded (small bonus for non-zero balance)
Cross-vertical interactions (diverse use = trustworthy)

Score goes DOWN when:

Counterparties file violations (POST /violation/record)
Sybil detection triggers (fake endorsement clusters)
Credential expires without renewal
Extended inactivity (score decays slowly over months)

New agents start at score 0 with grade N/A — the score is "withheld" until the agent has enough interactions for a meaningful assessment. This is by design: an unknown agent shouldn't get the same treatment as a proven one.

What you get on each plan

Every plan includes a verified agent identity. Higher plans give you more control, longer history, and stronger guarantees.

What it means	Free	Starter	Light	Pro	Business
Verified identity Your agent gets a unique cryptographic ID (a DID) that others can verify. Like a passport for your AI.	✓	✓	✓	✓	✓
Permission controls Rules for what your agent is allowed to do. "Balanced" means auto-approve small actions, block risky ones. Higher plans let you write your own rules.	Basic	Standard	All 3 presets	Custom rules	Full control
Who holds the signing key Your agent signs every action with a private key. On lower plans, klaw holds it securely. On Pro+, you can use your own cloud key vault (AWS KMS, GCP, Azure).	klaw	klaw	klaw	Your KMS	Your KMS
How long we keep proof Every action your agent takes is logged with a signed receipt. This is how long we store those receipts before they expire.	7 days	30 days	90 days	1 year	3 years
Blockchain record Proof of your agent's actions can be permanently written to Base L2 (a public blockchain). This makes it impossible for anyone — including us — to tamper with the record.	—	On request	On request	Daily	Every action
Agent-to-agent payments Your agent can pay other agents (or get paid) with trust-verified transactions. Only Business tier — requires the payment protocols (MPP/x402) to be configured.	—	—	—	—	✓
Network trust map See how your agent connects to other agents in a trust graph — who endorsed whom, how trust propagates through the network. Useful for understanding your agent's standing.	—	—	—	—	✓

Enterprise adds: your own dedicated MolTrust registry, white-label agent identities (your brand, not "did:moltrust:"), hardware security module (HSM) key storage, and kernel-level enforcement via Falco eBPF. Full pricing matrix →

Where your data goes — honest picture

We say "EU-hosted" because the infrastructure is in Germany, but the full picture matters. Here's what happens to your data at each stage:

Your agent pod (OVH Frankfurt)

Conversations, uploaded documents, agent memory, tenant database

klaw / you

Zitadel (klaw.dsncon.com, EU)

DSNCON (operator)

Stripe (EU-routed, global infra)

Payment method, billing address, VAT ID

Stripe Inc.

LiteLLM proxy (OVH Frankfurt)

Metered token usage per request, budget tracking

klaw

Fireworks.ai (US)

Prompts + completions during inference

Fireworks Inc. — Zero Data Retention

Fireworks does NOT log or store prompts/completions for open models without opt-in (we don't opt in). Each request is processed and the data is released. Not used for training.

Fireworks privacy policy ↗

MolTrust (moltrust.ch / CH)

Agent DID, trust score, reputation events, credential hashes

CryptoKRI GmbH (Switzerland)

Base L2 (public blockchain)

Credential hashes + IPR anchors only — no raw content

Public, immutable

What is not true: klaw is not a fully air-gapped EU-only setup. Inference latency requires real GPU capacity, and that's currently hosted in the US. We chose Fireworks specifically because they publish a ZDR policy and serve open-weights models, which is the strongest privacy posture available at our scale. If you need true EU-only inference (e.g. for regulated workloads), Enterprise tier can route to EU-hosted inference providers — talk to us.

Feature reference — what each pricing row means

The plan cards on pricing and your billing page link here. Each feature is answered in three parts: what it is, where it lives, and how you see it.

Agents

How many separate AI agents you can run at once.

Where: Each agent = its own Kubernetes pod in OVH Germany.

How you see it: Dashboard lists your agents. "Create another agent" button appears until you hit the cap.

Included LLM

Monthly LLM usage allowance included in the price.

Where: Metered by LiteLLM proxy in the klaw cluster. Inference runs on Fireworks.ai (US, Zero Data Retention).

How you see it: Usage bar on your dashboard. Once used up, buy top-up credits on /billing.

Storage per agent

Persistent disk for each agent's conversations, uploads, memory.

Where: OVH Cinder high-speed volume, encrypted at rest, Germany data center.

How you see it: Your agent uses it automatically. Full content browsable in the OpenClaw Control UI.

Trust layer preset

Default rules your agent follows when it acts on your behalf (e.g. "auto-approve under €50, archive-only, require counterparty score ≥50").

Where: Preset choice stored in klaw's tenant config. Rules enforced by the MolTrust plugin inside your agent's pod.

How you see it: Set to "Balanced" at signup. Custom preset editor unlocks on Pro+ tiers. Switching UI not yet on Solo/Duo/Team.

Signing key custody

Who holds the Ed25519 private key that signs your agent's outbound messages.

Where: "klaw-managed" = encrypted in our database (OVH Germany). "Your own KMS" = AWS KMS / GCP KMS / Azure Key Vault. "HSM" = dedicated hardware.

How you see it: The key itself is never exposed — signing happens server-side. On KMS tiers you see the key ID in your own cloud console and can rotate at will.

Agent certificate + event log

Your agent's W3C Verifiable Credential (from MolTrust at registration) + history of plan/state changes.

Where: klaw Postgres database in OVH Germany. Registration certificate also anchored on Base L2.

How you see it: /dashboard/audit shows all of it. Click "Download JSON" for the certificate, view the event-log table, follow the Basescan link for the anchor.

Per-interaction proofs

Signed receipts generated when your agent communicates with another MolTrust-enabled agent.

Where: klaw Postgres database. On Pro+ tiers, hashes also batched to Base L2.

How you see it: Will show in /dashboard/audit once the moltrust-openclaw plugin is active on tenant pods. Empty for solo-agent use because there's no counterparty to sign with.

Base L2 anchor

Writing a cryptographic fingerprint of important events to the Base L2 blockchain. Once anchored, the fingerprint cannot be altered — not by klaw, not by anyone.

Where: Base L2 (public Ethereum Layer 2, basescan.org). Only a hash goes on-chain; raw content stays in klaw's DB.

How you see it: Registration anchor is automatic on every plan — tx link on /dashboard/audit. Per-event anchoring (daily batch / always-on) activates on Pro+ tiers.

Support

Response-time commitment for support requests.

Where: Email inbox at hello@dsncon.com. Higher tiers add priority queue, dedicated Slack, or account manager.

How you see it: Send email. We reply within the stated window on business days.

Uptime

Service availability commitment.

Where: Shared OVH Kubernetes cluster (own-int-eu). Operated by DSNCON.

How you see it: "Best effort" = actively maintained but no formal percentage guarantee. Enterprise tier commits to 99.95% with financial remedies.

Custom domains

Use your own domain (e.g. ai.yourcompany.com) instead of *.klaw.dsncon.com.

Where: CNAME-mapped at the ingress layer; TLS cert via Let's Encrypt.

How you see it: Add + verify your domain in dashboard settings (available from Pro tier onwards).

SOC 2 export

Audit trail formatted for SOC 2 compliance evidence.

Where: Generated from klaw's audit database.

How you see it: Export button in /dashboard/audit (available from Business tier onwards).

White-label

Run klaw under your own branding. Your customers never see "klaw".

Where: Portal is re-skinned; emails sent from your domain; DID issuer shows your org.

How you see it: Enterprise only — configured during onboarding.