Governed spending for agents on Tether WDK: the record, the verdict, the verifiers
Governed economic agency for FlashyOS agents on Tether WDK: the AAO WalletCapability, a FlashyOS authorizer client, an MCP elicitation handler, and a WDK policy rule that defers to the authorization plane.
An agent that can hold money needs a description of a spend that the agent, the authorization plane and the signer all agree on, and a way to ask for a verdict before anything moves. This package is that description — the OperationRecord and the extractors that derive it from a real call — plus the client that asks the plane, and the verifiers a stranger runs offline against our receipts and our exports.
A spend is an `OperationRecord`: kind (transfer, swap, bridge), chain as `<family>:<id>`, exact asset or `native`, amount as an integer string in base units, exact destination. The extractors derive one from what an agent is actually about to do — an EVM or TRON transaction, a swap or bridge protocol call, an EIP-3009 typed-data transfer — and a call they cannot read is refused, not passed through. What each pack vouches for is published as a manifest and drift-checked by test.
`FlashyOSAuthorizer` sends the record to the plane and gets one of three verdicts: `ALLOW` with an Ed25519-signed `SpendAuthorization` the signer will later check the real call against; `ESCALATE` with the id of a decision a human resolves; `DENY` with a code such as `PER_TX_CAP` or `DESTINATION_NOT_PERMITTED`. The same verdict can be registered as a rule in WDK’s own policy engine, so the account is governed twice.
The verifiers close the loop for someone who trusts none of this. `verifyReceipt` and `verifyInvoice` check the signed documents two organizations exchange; `verifyPlaneDocument` resolves the key from a plane’s published identity; `verifyExport` recomputes an organization’s hash-chained export and its signed Merkle root, and `metricsFromExport` re-derives the weekly numbers from the bytes. All of it runs offline with a public key.
The JSON Schemas under docs/wallet/schema are generated from the validators this package and the API share, and a test fails when the two drift. The signer verifies a fixture authorization the API signed, so the two sides of the boundary cannot disagree silently. The three wallet packages publish together, in dependency order, from one workflow that fires on a version bump to any of them.
Apache-2.0, read from the package’s own manifest. Embed it in anything, including closed software — that is what makes a spec adoptable and a verifier worth running. FlashyOS’s server side is AGPL-3.0-only instead, and a test in the monorepo asserts the direction between them: AGPL code may consume this, this may never consume AGPL code.