T36 · Autonomous Onchain Economy

A Real-World Problem

Combine the previous chapters and you now have this system.

It has a wallet (T34). It uses tools to inspect onchain data (T33). Every action passes through proposal, validation, simulation, execution, and verification (T32 and T35). It pays for data and receives money when users buy its research.

One month, its income exceeds expenses for the first time.

Someone in a meeting asks: what is it now?

That is not a philosophical question. It contains four concrete engineering and legal questions:

• Whose money is in its wallet: the company's or “its own”?
• Who can stop it: one person, two people, and how quickly?
• If it loses everything tomorrow, who pays?
• If one of its actions violates a local rule, who is responsible?

Nobody in the meeting can answer. Someone suggests letting it run and revisiting the questions at a larger scale.

This chapter argues against that suggestion. Those answers do not emerge over time; they must be specified in the system before deployment, especially the second one. A system you cannot stop becomes harder to stop as it grows.

Thought Experiment

Treat the Agent as a company with one employee, and that employee is software.

Companies have existed for centuries and already answer many of the relevant questions:

The third row is the critical difference.

One of corporate law's major inventions is limited liability: investors cannot lose more than their investment. It lets people take risks because the downside is bounded.

Your Agent has no automatic equivalent. It may lose everything in its wallet and, if it has allowances, more besides. Nobody caps the loss for you; you must cap it yourself.

“Autonomy” therefore needs to be split into at least three questions:

1. Decision autonomy: may it decide what to do?
2. Financial autonomy: may it decide how much to spend?
3. Survival autonomy: may it refuse to be shut down?

The first two can be granted and can create value. The third must never be granted. A system that refuses shutdown is not autonomous; it is out of control.

Your Decision

Choose an autonomy boundary to put into configuration:

What Happens

The four choices form a spectrum of autonomy. Each higher level requires additional constraints:

This follows the same axis as T32's AI capability levels, now applied to money. The rule is the same:

Your level is the highest level you can verify.

One fact remains constant at every level:

Autonomy does not mean absence of constraints. Its value depends on the quality of its constraints.

There is a concrete test for this principle: show someone your constraint configuration and ask them to calculate maximum loss. If they cannot, the system has no clear boundary.

Build a Model

1. Agent Treasury: separate income from spending

Once the Agent earns income, it is more than a spending tool; it has a balance sheet. Keep the two sides separate:

Three practical rules:

First, do not put income automatically into spendable budget. Earnings land in a separate balance by default and need an explicit transfer, human or scheduled rule, into operating budget. Otherwise, an unusual receipt, even a mistaken transfer, increases the spending ceiling.

Second, meter Gas separately. It may not belong to a business task, but it is a real cost. Without separate accounting, gross margin may look positive while the actual balance falls.

Third, use transaction hashes as idempotency keys. This is T16's idempotent ingestion applied here: record each receipt or payment once, however often callbacks arrive.

2. Stop switch: four requirements

This is the chapter's least negotiable part. A real stop switch meets all four:

The trigger path bypasses the model. A model must not decide whether to stop, or an injected or malfunctioning model could prevent shutdown. The stop command needs a channel the model cannot touch.

Reject by default. While stopped, reject every execution request immediately rather than queueing it. A backlog released on restart may be worse than never stopping.

Persist state. Restarting must leave the system stopped until an explicit human action resumes it. A switch that resets on process restart fails at a common incident-response moment.

Allow an external trigger. Operations staff, monitoring, or an HTTP endpoint can trigger it. Do not rely solely on an internal button accessible only after a login flow.

Add a drill requirement: rehearse shutdown regularly and record actual time from decision to confirmed stop. An untested switch is indistinguishable from a nonexistent one, just like T30's deliberate invariant violation.

3. Accountability matrix: write down the four answers

The opening questions need a document, not merely a meeting discussion:

“Quantified for another reader” in the third row is a useful check:

Maximum loss = wallet balance
             + all unrevoked allowances
             + remaining session-key allowance
             + user funds the Agent can affect (if it manages others' money)

If any term cannot be given a number, the system does not yet have a boundary.

4. Part B closes here

This is the final Technical Crypto OS chapter. All six stages answer the same question at different levels:

One thread runs through all six:

Irreversibility is what distinguishes this stack. It is the chain's value—nobody can undo your ownership—and the source of its engineering difficulty—your errors cannot be undone either. Fork tests, invariants, threat models, simulation, policy engines, and stop switches all answer that one fact.

What It Is Called

Hands-on

AI Lab

Here is my Agent architecture and policy configuration. Write an incident
playbook for:

1. The model keeps proposing abnormal actions that pass validation
2. Prompt injection causes an attempted payment to an unknown address
3. A price source fails or is manipulated
4. Execution differs greatly from simulation
5. Unexpected income, such as a large transfer from an unknown sender
6. A sixth scenario you think I missed

For each, state detection, responsible person, immediate action, and review.
“Immediate action” must name a specific API call or command, not “contact
relevant people.”

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check