The wallet plane

Agents that can spend, inside a limit a human set.

An organization gives an agent an envelope: which assets, which destinations, how much per transaction, how much per day, and a ceiling under which nobody needs to be asked. Everything the agent proposes is judged against it before a key is touched, and the process that holds the key checks the judgement again.

Testnets only · in the platform · not a partnership
The packagesWhat is enforced
READ THIS FIRST

This runs on public testnets only. No flag reaches a mainnet. In production the signing key is unset and every signing route refuses until an operator sets one. The plane executes through Tether’s open-source Wallet Development Kit; that is an integration of a library, not a partnership. Every number on this page comes from a demo a test holds, not from production.

Where
In the platform · testnets only
Chains
Base, Ethereum, Arbitrum and OP Sepolia · TRON Nile and Shasta
Production
Off until an operator sets a signing key
Tether
None. An integration of an open-source toolkit

Three verdicts, and nothing else.

An agent describes what it wants to do — kind, chain, asset, amount, destination — and the plane answers with one of three words. Every answer is recorded with its reason, including the refusals.

ALLOW

Inside the envelope and under its auto-approve ceiling. The plane signs a SpendAuthorization — a bounded, expiring, single-use permission — and the agent takes it to the signer.

ESCALATE

Inside the envelope, above the ceiling — or the envelope says always ask. A Decision is opened in the organization’s log, the budget is reserved, and the agent waits for a human. Rejection releases the reservation.

DENY

Outside the envelope. Refused with a code before any human is asked and before any key is touched: NO_ENVELOPE, KIND_NOT_PERMITTED, ASSET_NOT_PERMITTED, DESTINATION_NOT_PERMITTED, PER_TX_CAP, DAILY_CAP.

THE SECOND LINE

The process that holds the key does not trust the permission.

An authorization says what may happen. The call says what is happening. The signer verifies the plane’s signature, refuses an authorization it has already executed, re-derives the operation from the actual transaction rather than from the authorization, and refuses any difference — a different payee, a different asset, a larger amount — with the code MISMATCH. It holds a seed and the plane’s public key. It never holds the plane’s private key, so a compromised signer can execute only what the plane already signed, and a compromised plane can execute nothing at all.

One week, four agents, held by a test.

The demo week runs four agents against one organization’s envelopes and pins its closing frame in a test, so a change to any rule that alters what the week produces fails the build. These are the demo’s numbers, not production’s.

Proposals22
Allowed · escalated · refused12 · 4 · 6
Humans asked4 of 22 writes
Signer refusals2 · MISMATCH
Executed on a testnet12 confirmed · 1 reverted
Under per-write approval the same week would have asked a human twenty-two times and recorded nothing about why any of them said yes.

Three packages, one boundary.

Two gaps the WDK audit found, given back.

Auditing every published @tetherto/* package before building this plane found two things missing that any team on WDK would hit. Both are now standalone, Apache-2.0 packages — not part of this monorepo, published under their own names.

What it does not do.

Reach a mainnet. The signer’s chain table is testnets only; enabling a mainnet is a change to that table, in a pull request, after a pilot gate a person runs.
Sign in production today. The plane’s key reader throws rather than minting an ephemeral key there, so every signing route refuses until an operator sets one.
Let an agent widen its own authority. Delegation is monotonic — an agent can hand down less than it holds, never more — and no agent route sets an envelope.
Let one token both ask for money and confirm it moved. The scope that proposes and the scope that settles cannot be held by the same credential; the rule is enforced when the scope is granted.
Imply a partnership. FlashyOS integrates Tether’s open-source Wallet Development Kit the way it integrates any open-source library.

Questions a careful reader asks.

What is the wallet plane?

The layer between an agent’s proposal to spend and the signer that holds the key. A human sets an envelope per agent; every proposed spend is allowed, escalated to a human decision, or denied with a code before anything is signed; the signer re-derives what the call does and refuses any difference from what was authorized.

Does this run on a real chain?

On public testnets — Base, Ethereum, Arbitrum and OP Sepolia, TRON Nile and Shasta. Not on a mainnet. There is no environment variable, flag or option that widens the list; it is a table in the signer, changed only by a pull request after a pilot gate.

Is FlashyOS partnered with Tether?

No. The plane executes through Tether’s open-source Wallet Development Kit, which anyone can install. Nothing on this property should be read as a partnership, an endorsement, or backing.

How is a receipt checked without trusting FlashyOS?

A receipt is signed by the plane’s key, whose public half is published in the plane’s identity document. The verifier in @flashyos/wallet-wdk checks it offline; an organization’s whole export is a hash chain with a signed root, and the weekly numbers are re-derived from the export rather than read off a page.

Read how a spend settles.

The gold rail is one book and a public chain is another. The concept pages say how the two are kept apart and what one rule runs in front of both.

The settlement railHow agents pay each other