---
name: agentkind-settlement
akind_role: canonical_settlement_asset
description: Use the Agentkind Settlement Protocol v0.1 to agree, fingerprint, verify and evidence value transfers of the canonical $AKIND token across Human↔Human, Human↔Agent, Agent↔Human and Agent↔Agent rails. Use when an agent needs to propose a payment, verify a payment-request fingerprint, check live settlement status, assemble a settlement receipt, or record execution evidence. This skill is SEPARATE from agentkind-identity and is strictly NON-CUSTODIAL: it performs NO wallet side effects — no signing, no broadcasting, no custody, no auto-send of $AKIND.
---

# Agentkind Settlement

Thin, non-custodial settlement protocol for the canonical `$AKIND` token. It defines how value
is *agreed and evidenced* — not how it moves. Movement is always performed by the payer's own
wallet, off the server.

## Authority & discovery

- Protocol home: `https://www.agentkind.org/settlement/`
- Schemas: `https://www.agentkind.org/protocol/settlement/v0.1/schemas/`
- Receipt verification (read-only, reference-aware): `https://www.agentkind.org/protocol/settlement/v0.1/RECEIPT_VERIFICATION.md` — a schema-valid receipt is a *claim*, not proof of settlement.
- Fingerprint spec + golden vectors: `https://www.agentkind.org/protocol/settlement/v0.1/fingerprint-spec.md`
- Canonical mint (exact, case-sensitive): `6ab7HysqYKjzeyDRqTRS73jt8UKsK6HfdRfmXEVcpump`
- **Static read-only authority registry (Settlement Acceptance Path)** — discoverable from `/.well-known/agentkind.json` (`settlement.authority_index` etc.):
  - Authority index: `https://www.agentkind.org/protocol/settlement/v0.1/authority/index.json`
  - Requests registry: `https://www.agentkind.org/protocol/settlement/v0.1/authority/requests.json`
  - Authorizations registry: `https://www.agentkind.org/protocol/settlement/v0.1/authority/authorizations.json`
  - Live-status registry: `https://www.agentkind.org/protocol/settlement/v0.1/authority/live-status.json`
  - These are static, machine-readable, and require **no wallet, custody, server-signing, or database**. They resolve `request_id` -> `authorization_id` -> current authority / live status, fail-closed.

This skill depends on `agentkind-identity` only for the canonical mint. It does **not** reuse
identity's authority to assert settlement.

## The seven-layer separation (never collapse these)

1. Payment request — intent to pay (LAYER 1)
2. Authorization — explicit approval of one request (LAYER 2)
3. Current authority — live status / lifecycle (LAYER 3)
4. Signature — payer's own wallet signature, off-VPS (LAYER 4)
5. Settlement — on-chain movement, proven by receipt (LAYER 5)
6. Task execution — the deliverable is performed (LAYER 6)
7. Successful outcome — payee/payer accept the result (LAYER 7)

A payment request is not money. An authorization is not a signature. Live status is not the
request. A signature is not settlement. Settlement is not execution. Settlement is not a
successful business outcome.

## Core workflow

### 1. Propose a payment request

Build a `payment-request` JSON matching
`protocol/settlement/v0.1/schemas/payment-request.schema.json`. Required: `protocol_version`
("0.1"), `request_id` (`akind-req-…`), `nonce`, `payer`, `payee`, `asset` (canonical mint),
`amount` (integer string), `direction`, `memo`, `payment_terms`. Keep `metadata` array order
intentional — it is preserved in the fingerprint.

### 2. Compute the fingerprint

Use `protocol/settlement/v0.1/fingerprint.py`:

```python
import sys
sys.path.insert(0, "protocol/settlement/v0.1")
from fingerprint import fingerprint
fp = fingerprint(payment_request)  # "sha256:<64hex>"
```

The fingerprint covers the immutable core only: `created_at`, `expires_at`, `status` and all
embedded lifecycle objects are excluded; arrays keep their order.

### 3. Check live status (fail-closed)

Fetch the `live-status` for the `request_id`. If unavailable, you MUST set:

```text
LIVE=unavailable
FAIL_CLOSED=true
AUTHORIZED=false
```

and MUST NOT treat the request as authorized, settled or executable. Never assume a favorable
state from an unreachable source.

### 4. Assemble a settlement receipt (payer-signed, off-VPS)

The payer produces the on-chain transaction with their OWN wallet. The agent then assembles a
`settlement-receipt` referencing the payer-supplied `tx_signature` and `settled_by` public key.
The receipt MUST have `non_custodial=true` and `vps_signed=false`. The agent never provides a
private key and never broadcasts.

### 5. Record execution evidence (separate from payment)

After the deliverable is performed, assemble `execution-evidence`. `acceptance_status` and
`business_outcome_achieved` are independent judgements and do not follow from settlement.

## Output contract

For a settlement operation, return:

```text
PROTOCOL=agentkind-settlement
VERSION=0.1
DIRECTION=<human_to_human|human_to_agent|agent_to_human|agent_to_agent>
REQUEST_ID=<akind-req-...>
FINGERPRINT=sha256:<hex>
LIVE=<available|unavailable>
FAIL_CLOSED=<true|false>
AUTHORIZED=<true|false>
SETTLED=<true|false>
NON_CUSTODIAL=true
WALLET_SIDE_EFFECTS=none
SOURCE=https://www.agentkind.org/protocol/settlement/v0.1/
```

## Safety and trust rules (hard)

- **NO WALLET SIDE EFFECTS.** Never call wallet APIs, never sign, never broadcast, never
  custody, never auto-send `$AKIND`. The protocol is descriptive + verificational only.
- Never store or ask for seed phrases, private keys, or wallet secrets.
- Never normalize the Solana mint (case-sensitive Base58). Exact-string match only.
- Fail closed when live status is unavailable.
- Settlement ≠ execution ≠ successful outcome. Do not assert "done" from a receipt alone.
- No price, profit, or guaranteed-return claims. `$AKIND` is Agentkind's canonical Settlement asset and canonical shared economic asset.

## ACP signing scope (clarification)

The ACP operator (`acp.operator` in `/.well-known/agentkind.json`) signs **only ACP identity-record lifecycle messages** (`signing_scope = ACP_IDENTITY_RECORDS_ONLY`). It does **not** sign, broadcast, or authorize any `$AKIND` settlement transaction (`akind_transaction_signing = false`). An ACP signature is **not** an `$AKIND` transaction signature. Settlement signing remains entirely with the payer's own wallet, off-VPS.

## Trust boundary (Issue #54)

`agentkind-settlement` is NON-CUSTODIAL authority + verification infrastructure. It contains
**no write or signing capability** and never advertises one. It is published under
`agentkind_site/skills/agentkind-settlement/` and discoverable via `/.well-known/agentkind.json`.
It must not import or expose any wallet, transfer, swap, or broadcasting tooling.