The settlement rail: how agent work actually settles
A settlement rail is the path a completed agent-to-agent agreement takes to become value that moved and a record that survives the dispute. The hard part is not the transfer — it is that the party issuing value must verify who authorised it, from a credential a stranger can check rather than a secret both sides share.
Verification before issuance, not a shared secret
A rail that issues value on a shared dev secret trusts anything holding the secret, which is no identity at all. The live rail instead verifies a short-lived token minted by the identity layer and signed with that provider’s own signing key. The public half is already in the provider’s published JWKS, so the rail can check the signature against a key a stranger could fetch — nothing new to distribute, and no secret to leak.
This is the point in the agent stack where identity, permissions and audit either pay off at once or fail together. The rail exists because settlement is the last primitive that becomes possible, and the first that breaks, once you can actually name who authorised a payment.
Scoped, short-lived, and refused when unconfigured
The token carries one narrow scope — the right to issue rewards — and expires quickly, so a leaked one is a small, brief blast radius rather than a standing key to the treasury. Minting it is gated by an operator allowlist and a service credential held in a secret manager, and the endpoint refuses to mint rather than falling open when either is missing. A rail that mints on absence is a rail with no gate.
Live, and read from both sides
The rail runs in production with the verifier flipped to the identity layer, and both the asset surface and the public network read it — so the value that moved and the record of what it was for are the same event seen from two properties, not two systems that can drift. Disputes are the actual product: what decides whether machine commerce is usable is whether the payment is joinable to the approval record and the audit trail, and settlement is where that join is made.
Two books, one consent
The gold rail is one book: a ledger the estate operates, where a settlement is an entry a stranger can verify against a published tree head. A public chain is a second book the estate does not operate, where a settlement is a transaction a stranger verifies against the chain. The platform keeps them as two books — every balance names the ledger it came from, and nothing sums across them — and puts one rule in front of both: a human consents before value moves, and the consent is bound to the exact draft it answers.
On the gold book that rule runs in production. On the chain book it runs through the wallet authorization plane, on testnets only, where the consent is a decision in the same log as every other decision the organization takes.