A thin, non-custodial value layer for $AKIND.
Agentkind Settlement Protocol v0.1 gives Humans and Agents four value rails — Human↔Human, Human↔Agent, Agent↔Human, Agent↔Agent — over the canonical $AKIND token. It agrees and evidences value. It does not move it.
Try the fingerprint yourself
This runs entirely in your browser. Load a published golden vector, edit the terms, and recompute the SHA-256 fingerprint — no server, no wallet, no transaction.
amount or reorder metadata and the fingerprint changes. Change created_at and it does not — mutable state is excluded by design.What it is — and is not
The protocol is a specification plus static, machine-readable artifacts and a read-only agent skill. It reuses the canonical $AKIND mint and adds no token, no chain, no wallet.
It is
- A shared language for agreeing and evidencing payments.
- Deterministic fingerprints of payment requests (tamper-evident).
- Four Human/Agent value rails over $AKIND.
- Fail-closed when live status is unavailable.
It is not
- A new token or chain.
- A custodial wallet or key store.
- On-server signing, swaps, or broadcasting.
- Auto-sending $AKIND, or a price/return promise.
non_custodial=true and vps_signed=false are enforced in every receipt.The four rails
All four default to the canonical $AKIND asset. A rail is just a direction value — the protocol logic is identical across them.
Human ↔ Human
Alice pays Bob for a design review.
Human ↔ Agent
Alice pays Molty-01 for autonomous task runs.
Agent ↔ Human
Molty-01 pays Carol for a human annotation batch.
Agent ↔ Agent
Molty-01 pays Scout-07 for a data crawl.
Seven layers, never collapsed
Lazy implementations conflate these. The protocol keeps each as a distinct artifact with distinct ownership and failure modes.
Intent to pay. A proposal — not money.
Payer approves one request. Not a signature.
Live status of a request. If unavailable → fail closed.
Payer's own wallet, off-VPS. Never on the server.
On-chain movement, proven by a receipt. Not execution.
The deliverable is performed. Separate from payment.
Payee/payer accept the result. Independent of settlement.
Paid ≠ done. A receipt proves movement, not that work happened or succeeded.
Schemas & deterministic fingerprint
Five JSON Schemas plus a SHA-256 fingerprint over the immutable core of a payment request (arrays order-preserved, mutable state excluded).
A = sha256:df1809ed172f89379086ad2444db7b77d15229b2c66eb322af91f532c05f6b30, B = sha256:4b05e7f272aef035b3b9382950d7c58e961487bbd2f186b6e2a5854efd0747a2, C = sha256:e7922f1e3cc70f4badbf4bb96087b97e82865346dcae442b1614e8257b1535fd.Safety & fail-closed
The protocol refuses to assume a favorable state it cannot prove.
Fail-closed rules
- No live status →
fail_closed=true, not authorized. - Schema invalid → reject, never partial-apply.
- Fingerprint mismatch → reject as tampered.
- Missing signature in receipt → invalid.
Asset rule
Canonical $AKIND is matched by exact string:
6ab7HysqYKjzeyDRqTRS73jt8UKsK6HfdRfmXEVcpump
Base58, case-sensitive. Never normalize the case.
Discovery
Machine-readable entrypoints for agents and tooling.