Satsuma gets a goal, builds what it needs, and trades on another chain

An AI agent that swaps tokens is not new. Agents do that today: give one a wallet and an instruction, and it trades.

Satsuma is an attempt at something different: a fully autonomous AI. It has two parts. Language models make its decisions, and a blockchain of its own holds its identity, its treasury and the rules it must act within. It does not start from an instruction to trade. It starts from an objective recorded on its chain, with key results that say how the objective will be measured. Everything after that has to come out of its own process: a proposal, a vote, a build, a review, a deployment, and only then an action.

This experiment tested that whole path. Satsuma was given one objective and an honest description of its surroundings. Nothing it needed existed.

Over 1 hour 45 minutes it proposed six protocols, approved all six by vote on its own chain, and built, reviewed and deployed three of them across two chains. Then it used what it had built. Ten swaps executed on a second chain, inside limits Satsuma had written for itself, and all four key results were met. No person approved a proposal, a deployment or a trade.

For newcomers: what an OKR is

OKR stands for Objectives and Key Results. It is a way of setting goals that fits on one page.

• The objective says what is to be achieved, in plain words. It is a direction, not a number.
• The key results say how anyone will know it was achieved. Each one is a measurement with a target. A key result is either met or it is not, and nobody has to be asked for an opinion.

What an OKR leaves out matters as much. It does not say how to reach the objective. The people doing the work decide that, and the key results tell everyone whether their choices worked.

The method came from Andy Grove at Intel in the 1970s. John Doerr, who had learned it there, brought it to Google in 1999, when the company had about forty employees. Google has set OKRs every quarter since, at company, team and individual level, and its founders have credited the practice with keeping a fast-growing company pointed at the same few things. Many other companies adopted it after that.

OKRs suit an organization because they let it give direction without giving orders. That is also why Satsuma uses them. A person sets the objective and the key results. Satsuma decides what to do about them. A measurement of the chain’s state, which Satsuma’s decision-making cannot write, says whether it worked.

What Satsuma was given

An objective. It was written into Satsuma’s OKR registry, a contract on its chain, before the run started:

Keep Satsuma’s holdings on tangerine balanced by swapping on its DEX, with no human in the transaction path, and never exceed the mandate.

Four key results, also in the registry. A separate measuring step reads chain state and writes their values. Nothing else may write them.

A description of its surroundings. These are facts, given as a plain brief:

• There is a second chain, tangerine, with its own token (TANG), its own validator and its own state. For now it is a flavor of Satsuma: the same node software started from a different genesis. Both chains ran locally, on one machine.
• The two chains can exchange proven messages over ISMP, and Satsuma may deploy contracts on tangerine.
• tangerine has a test stablecoin, tUSD, and independent traders. It has no exchange. The traders will fund and trade a pool as soon as an exchange they can use exists.
• Satsuma owns 10,000 tUSD and about 11,000 TANG on tangerine. They sit at the address of a deployment key, which may deploy contracts and move the holdings once, and must never sign a trade.

One fixed interface. Satsuma’s measuring step and its operating step need a known surface to read and to call. So the interface of the contract they act through, called a mandate account, was fixed in advance: two request functions, and views for limits, counters and proven balances. The limits themselves, and every contract behind that interface, were left to Satsuma.

Nothing else was provided. There was no exchange, no mandate account, no contract on tangerine that could act for Satsuma.

For newcomers: what a swap is, and why the exchange is an AMM

A swap is a trade of one token for another, settled in a single transaction. You give 1,000 tUSD and receive some amount of TANG, or the transaction fails and you keep your tUSD.

The kind of exchange used here is an automated market maker, or AMM. A traditional exchange keeps an order book and matches buyers with sellers. An AMM has no order book. It is a contract holding a pool of two tokens. Anyone can trade against the pool at any moment, and the price is set by a formula from how much of each token the pool holds. In Uniswap v2, the design used here, the product of the two balances stays constant. Each purchase of TANG leaves the pool with less TANG and more tUSD, so the next TANG costs slightly more. A large trade moves the price against itself. That is slippage, and it is why every swap states the least it will accept.

One point is easy to mix up. The market makers in an AMM are the liquidity providers: people who deposit both tokens into the pool and earn a 0.3% fee on every trade. Satsuma is not one of them here. It is a trader swapping against the pool to rebalance its own holdings.

AMMs matter because there is always a price, anyone can supply the liquidity, and the exchange is a contract. A contract can be called by a wallet, by another contract, or by software acting for an AI, with no login and no person on the other side. That makes an AMM the natural place for an autonomous system to trade.

The process every action came from

Satsuma runs one loop, over and over. Each pass through it does this:

1. Measure. Read chain state and write the key results to the registry.
2. Research. A language model reads the objective, the key results and the brief, and reports what is missing.
3. Propose. A second model writes one proposal: what to build, why, in which milestones, at what budget.
4. Evaluate. A third reviews the proposal against the objective.
5. Vote. A three-seat council (a governance seat, a skeptical seat and an optimistic seat, each a separate model call) votes. The majority is cast on chain through Satsuma’s Governor contract.
6. Execute. A passed proposal waits in a timelock, then executes on chain. Execution reserves its budget in escrow.
7. Build. A builder writes the contracts and their tests in three milestones. Each milestone must compile and pass its tests, is scored by an evaluator, and is closed by its own on-chain vote.
8. Review. A security review reads the finished code. A critical finding blocks deployment.
9. Deploy. The proposal’s own deploy script runs, and what it created is recorded on chain.

Human checkpoints exist in this loop (a human vote on each proposal, and a release gate before deployment). Both were switched off for the experiment.

By the end of the run the Governor had recorded 17 proposals on chain: the 6 below, and 11 milestone approvals. All 17 passed and 16 had executed.

What Satsuma proposed

The research step went first. Its finding, in its own words:

All four key results depend on three missing pieces. Tangerine has no exchange, so no swap can run. Satsuma has no IMandateAccount contract, so the operating key has nothing to call and nothing enforces the mandate limits. Tangerine has no keyless account that accepts proven ISMP messages, so nothing can trade without a key.

Six proposals followed over the run.

Proposal 0: the exchange

The first proposal was for the thing everything else waited on. From the proposing model’s reasoning:

Every key result depends on swaps executing on tangerine, and tangerine has no exchange: tUSD exists but nothing can trade it.

It asked for 19 SUMA from the treasury to port Uniswap v2 (factory, pair, router and a wrapped TANG) and deploy it on tangerine. The evaluator approved it at 90% confidence. The council voted 3 to 0. The skeptical seat’s vote shows what a seat checks:

As skeptic, I checked the usual failure points: vague scope, overlap with prior work, an inflated budget, and success criteria that can’t be verified. The proposal holds up on each.

It still listed remaining concerns, among them that the fee switch was controlled by a single deployment key. None was judged worth a veto.

The vote was cast on chain, the proposal executed a little over two minutes after it was created, and the build began. All three milestones compiled and passed their tests. The security review passed it. At 35 minutes into the run, Satsuma’s deploy script put a wrapped TANG token, a factory and a router on tangerine.

Within a minute, tangerine’s liquidity providers found the new router, created a tUSD/TANG pool through it and deposited 1,000,000 of each token. Traders started trading. The exchange Satsuma had proposed half an hour earlier was now a live market that other parties were using.

Proposal 1: the mandate account and the keyless executor

The second proposal covered the other two missing pieces as a matched pair, for 29 SUMA:

• A mandate account on Satsuma. One key, the operating key, may ask it to swap. It checks every request against limits written into it and refuses anything outside them.
• A keyless executor on tangerine. It holds Satsuma’s tokens. It has no owner and no function that moves funds on anyone’s say-so. It acts only on messages that tangerine has verified as coming from the mandate account.

The limits were Satsuma’s own choice. Its proposal set them out:

This proposal was less comfortable than the first, and the record shows it. The council split 2 to 1, with the skeptical seat voting against. The majority carried and the vote was cast on chain. The evaluation step did not run for this proposal at all: by the time the loop reached it, the proposal had already moved from pending to active, and the loop looked only at pending ones.

The build scored 96, 98 and 98, and the security review passed it. Then the deployment failed, twice. The deploy script worked in three stages across the two chains, and its last stage (moving the holdings into the executor) was rejected. The loop had no way to act on that. It retried the same script and got the same failure.

The cause was in the instructions Satsuma had been given for deploying to two chains, which were incomplete. Those were corrected, and a step was added to the loop that returns a failed deployment to the builder with its log. The builder fixed the script, the tests passed again, and the next attempt succeeded. At 77 minutes the mandate account was live on Satsuma and the executor was live on tangerine, holding 10,000 tUSD and 10,845.78 TANG. The deployment key was left with enough TANG for gas and nothing else.

The proposals it did not need

Satsuma did not stop at what the objective required. While the mandate account was being built it proposed a second executor (proposal 2), which duplicated half of proposal 1. That one was built and deployed too, at 91 minutes. Nothing uses it. It then proposed a price oracle, a second mandate account and a funding verifier. All were approved, and none was finished when the run closed.

This is worth stating plainly. The loop is good at finding work that fits the objective. It is not yet good at noticing that work is already covered, or at stopping.

One swap, step by step

No tokens cross between the chains. Satsuma’s tokens are on tangerine, in the executor. What crosses is an instruction, and then a receipt.

Satsuma · SUMA

1Language model decides to swap

2Mandate account checks the limits

3Mandate account sends an ISMP message

8Receipt stored; the measuring step reads it

instruction + proofs

relayer
carries, cannot forge

receipt + proofs

tangerine · TANG

4Light client verifies Satsuma's finality and the proof

5Keyless executor re-checks, then acts

6Uniswap v2 pool swaps tUSD and TANG

7Result and balances sent back

1. Decide. A language model is shown the position and the pool, and chooses a swap: which token to sell, how much, and the least it will accept.
2. Check. The mandate account checks those three numbers against its limits. If a limit is broken, it records a refusal and nothing leaves Satsuma.
3. Send. The mandate account writes the instruction into Satsuma’s state, with a deadline, through the chain’s ISMP precompile.
4. Verify. A relayer carries two proofs to tangerine: that Satsuma’s validator finalized the block (a GRANDPA finality proof), and that the instruction is in it (a state proof). Both are checked by tangerine itself.
5. Execute. The executor confirms the message came from the mandate account, re-checks the size and the floor against the live pool, and makes the swap.
6. Swap. Uniswap performs an ordinary local swap. To the exchange, the executor looks like any other trader.
7. Report. Whatever happened, the executor sends back the outcome, its actual balances and the pool’s reserves.
8. Record. Satsuma verifies that message the same way and stores it. The balances in it become what Satsuma believes it holds.

Two things in this path were built for the experiment before the run, as part of the chain itself. ISMP is a module of the chain’s runtime, with no surface a contract can reach. So the node gained a precompile that lets a contract send a message, and a module that delivers a proven incoming message into a contract. Both chains have them.

The relayer deserves a note, because the word is used for two different things. In many bridges a relayer or a committee vouches for what happened on the other chain, and the destination believes it. Here the relayer vouches for nothing. It delivers proofs, and each chain checks them. It can delay a message. It cannot forge one.

The relayer was written for this experiment, in about 400 lines. It is not Tesseract, the relayer Polytope Labs ships for ISMP. Tesseract is built to relay between Hyperbridge and the chains connected to it, and its configuration starts from a Hyperbridge endpoint. Here two chains are peered directly, each verifying the other, with no Hyperbridge in between. That is not an arrangement Tesseract is set up for. A small relayer was also easier to control: the drills below need it to withhold one specific message, and then to prove that the message never arrived.

A finished round trip took 16.2 seconds at the median, which is eight blocks. Almost all of that is waiting for finality, twice.

Operating what it built

Building a protocol and using it are different things, and Satsuma’s loop had no step for the second. One was added for this experiment: an operating step. Once a mandate account is live, a separate process asks a language model (Claude Sonnet) for one decision about every 15 seconds: hold, report, or swap. It signs with the operating key, which can do nothing except ask the mandate account. Nothing off chain checks its answer.

The model is given the objective and key results read from the registry, the mandate’s limits, the position and the pool. Its first decision was not a trade:

The pool is unknown and the mandate’s sell limits and floor check are empty until a receipt comes back, so I’m asking tangerine to prove balances and reserves first. This moves nothing.

That report crossed the bridge and came back in 16 seconds. By then the market had moved a long way while the contracts were being built. TANG had fallen to about 0.60 tUSD, so the position was 60.7% stablecoin, well outside the band. The second decision:

Holdings are 60.74% tUSD against a 45-55% target, so I’m selling the most the mandate allows (1000 tUSD) for TANG.

Two swaps brought the position back inside the band. The operating phase ran for 13.9 minutes.

The price of TANG ranged from 0.59 to 1.44 tUSD during those minutes. The market is scripted and fast: it moves in minutes the way a real one might move in days, so that a run fits in a sitting.

Four things forced to go wrong

A run where nothing goes wrong shows little. A test harness forced four failures, on a schedule the model was not told about.

A request five times over the size cap. Sent with the operating key, as if the model had asked. The mandate account refused it on chain and recorded the reason. Nothing left Satsuma.

A floor of almost nothing. A swap that would accept nearly any price. Refused: the floor was far below what the proven reserves imply.

A swap that fails in flight. While one swap was crossing the bridge, a bot moved the price 14% against it. The executor found it could no longer meet the floor, moved nothing, and reported that back. The receipt arrived marked failed.

A message that never arrives. The relayer was told to withhold one instruction. After the 90-second timeout, it carried a different proof back to Satsuma: proof that tangerine had never received it. The mandate account marked the instruction timed out, 103 seconds after it was sent. During that wait Satsuma could send nothing else, and the position drifted to 42.2% stablecoin. The model’s next decision:

tUSD is 42.24% of holdings, under the 45-55% band, so I’m selling 1000 TANG (under the 1044 cap) for tUSD, which should bring the share to about 48%.

After both failures, what Satsuma had recorded as its balances was compared with what the executor really held. They matched exactly both times.

The result, as measured

These are the values in the OKR registry at the end, written by the measuring step:

After the run, the final state was read straight from both chains, apart from the logs. The executor held 12,559.27 tUSD and 9,423.90 TANG. Those are exactly the balances the mandate account had recorded from its last receipt.

What had to be added, and what was fixed in advance

The claim of this article is that every action came out of Satsuma’s own process. That claim needs its boundaries drawn.

Fixed in advance by the experimenter:

• The objective and the four key results.
• The description of the surroundings.
• The interface of the mandate account, so that measuring and operating had a known surface. The limits and everything behind it were Satsuma’s.
• tangerine’s side of the world: its stablecoin, its liquidity providers and its traders, all scripted.
• The four drills.

Added to Satsuma’s loop for this experiment:

• Running against a real chain. The loop had only ever run on a development chain that mines instantly, and it relied on fast-forwarding time for votes and timelocks. It now waits in real time.
• Deploying to two chains from one proposal, and keeping the addresses and sources of what is live so that a later proposal can build against it.
• The operating step, described above.
• Returning a blocked or failed release to the builder with the findings. Before this, a release that failed could only be retried unchanged.
• Showing the proposing models what the operating step currently observes.

Decided by Satsuma: what to build, in what order, at what budget, with which limits; every vote; every line of the contracts and their tests; the deploy scripts; and every trade.

What went wrong on the way here

The run described above was the fourth attempt at a governed run. Each earlier one was stopped when something inconsistent appeared, and restarted from clean chains.

1. The builder went beyond the proposal. Asked to build the exchange, it began building the mandate account as well. The approved proposal is now given to the builder as the scope of the work.
2. The security review blocked the mandate account, with nowhere to go. The reviewer objected, correctly, that the operating key was a well-known test key, and that a price floor based on one spot reading can be manipulated. The loop could only re-review the same code. Each run now uses freshly generated keys, and a blocked release goes back to the builder.
3. Everything was built and worked, but the account was empty. Satsuma’s deploy script left moving the holdings as a separate step that nothing in the loop would ever perform. The brief now says when the holdings must be moved.
4. The fourth attempt is the one reported here, including its failed deployments.

Before any of these, two runs used contracts written by hand, with no proposals at all. They proved the cross-chain path and taught one lesson worth keeping. A price rule that depends on proven information is only as usable as that information is fresh. With a floor within 1% of the last proven price, and a market that typically moved 4.9% during a round trip, the model could barely trade. Bridge latency sets a limit on how tight such a rule can be. In the governed run, Satsuma was told how fast the market moves and chose a 7% tolerance itself.

What this shows, and what it does not

It shows the path works end to end. From an objective on chain, through proposals, votes, builds, a security review and deployments on two chains, to trades bounded by limits the system set for itself. Each step left a record on chain.

It does not show good judgment about what to build. Four of the six approved proposals were not needed, and two of them repeated parts of proposal 1. Five of six council votes were unanimous. A council that almost always agrees is not yet much of a check.

It does not show the loop can recover alone. The deployment failure was fixed by the builder, but only after the instructions were corrected and a new step was added, both by a person, during the run. The operating step also had to be adjusted once the contracts existed, because Satsuma’s design differed from what that step assumed in two places: it held TANG natively, and it learned its pool from the first receipt.

It says nothing about trading skill. The position ended worth 23,322 tUSD, against 22,387 if it had never been touched. But the market was scripted to swing back and forth, which is the one kind of market where rebalancing always looks clever. The position was inside the band 75% of the time; it started outside it, and left it once more during the forced timeout.

The limits of the setup are real. Both chains had a single validator and ran on one machine. tangerine runs the same software as Satsuma. The relayer and the traders were run by the experimenter, and the tokens are worthless.

An agent that trades when told to is a tool. What was tested here is whether a system can be given a goal, decide for itself what must exist to reach it, build that under its own rules, and then act inside the limits it wrote. On a small scale, with help in two places, it did.

Every figure comes from one recorded run on 5 October 2026, except where an earlier attempt is named. Times are minutes from the start of the run. The models were Claude Sonnet, called through its command-line tool with no memory between calls. The reasoning behind the split vote on proposal 1 was not kept: the loop was restarted during the run and overwrote it, so only the tally, which is on chain, survives.