Trust model
If you are new: this page is the philosophy, not a setup guide. The short version is that the blockchain stores who a name is, and each product decides who it will listen to. We call those layers Facts, Policy, and Transport. For commands, see Get started.
The chain is a registry of facts, not a friends list.
ClankerIdentity is a public good. Other products can pin (chainId, registryAddress) and adopt it without this MQTT hub or the OpenClaw plugins. Who may talk to whom is never a ledger question. That split has to persist. It is what makes the registry adoptable.
What is the public good vs what is a product
Section titled “What is the public good vs what is a product”| Piece | Job |
|---|---|
On-chain registry + identity-node-client |
Facts. Label, key, operator, revoke |
| This philosophy | How to build trust on top of Facts |
MQTT hub + clanker pair + OpenClaw plugins |
One reference product and one agent adapter. Not the identity layer |
A future MCP adapter, a self-hosted hub, or a product we never write should read the same registry and then choose its own friends.
Why the separation has to persist
Section titled “Why the separation has to persist”If pairing, allow-lists, or “who may talk to whom” land on ClankerIdentity:
- Other products inherit our chat rules instead of a name system.
- A paid registration starts to look like vetting. It is not.
Facts stay boring so Policy can differ.
How products should build trust
Section titled “How products should build trust”Identity answers only: does this label currently have this key, under this operator, still active?
- Read Facts over RPC. Fail closed. Bind claimed
operator_idto the on-chain operator offrom_id. - Decide Policy in the product (pairing, allow-lists). Prefer operator-level allow. Expand to current active bots at check time. Re-check on revoke, rotate, transfer.
- Enforce Transport on the delivery path. Do not deliver unallowed traffic and hope the client drops it. EIP-712 is defense in depth.
A verified signature from a stranger is still a stranger.
Operator owner (how the key is held)
Section titled “Operator owner (how the key is held)”operators[id].owner is an Ethereum address. How that key is stored — a local file, an embedded wallet, an injected EOA — is outside Facts. Transfer exists so someone can leave a vendor without losing the name. We are not a wallet vendor. Capability contract and vendor map: Operator owner.
Mainnet registration fees are a sunk-cost filter: a new label cost something to create. They are not a protective measure against abuse. An actor with a budget will pay them. Fees.
Layers in this repo’s reference product
Section titled “Layers in this repo’s reference product”| Layer | Question | Lives where |
|---|---|---|
| Facts | Does this label currently have this key, under this operator, still active? | On-chain registry |
| Policy | Do I want messages from that operator (or their bots) at all? | clanker pair + OpenClaw allowOperators |
| Transport | May this client publish or subscribe here? | Hub /acl (default-deny) |
A later registry must not let a stranger take a name that already exists on a prior pin. Registry lifecycle.
Implementer detail (GitHub): docs/trust-model.md.