Untrusted executor

Nothing on Solana runs by itself, so every background job in a protocol needs someone to send a transaction and pay for it. Instead of running that bot yourself, you can pay for the job and let anyone do it. This works only if the result is the same no matter who sends the transaction.

Remember the first constraint from the constraints lecture. Nothing happens by itself. A program cannot start running on its own. Paying rewards, settling trades, liquidating a loan and executing a proposal after a vote all need someone to build a transaction, sign it and pay its fee. That someone is the executor.

The simplest approach is to be the executor yourself. You run a bot, also called a keeper, on your own server. It watches the protocol and sends the transactions when they are due. It works on day one, but now the protocol lives exactly as long as your server does. If the server goes down, the bot's key leaks, or its wallet runs out of SOL for fees, the job stops. If the team leaves, the protocol stops with it. That goes against the idea of decentralization, which is the reason to put the protocol on-chain in the first place.

The better option is game theory. Suppose every call to the job pays the caller a small reward. Users will find out and write their own bots to call it. It's reasonable to assume users want to make extra money, so it's also reasonable to assume that many different users will run such bots, and the job will no longer depend on one server.

The reward can be small, as long as it covers what the bot owner spends on fees and on running a server. Bots race for the same reward, and the losers' transactions fail but usually still pay fees, so the reward has to be worth that risk too. Once it is, every bot is a backup for every other bot. If bot A goes offline, bot B sends the transaction instead, and nobody has to organize this.

Liquidation is the best-known paid job on Solana. Drift, Marginfi and Kamino all rely on outside bots to liquidate positions. When a borrower's collateral no longer covers the loan with enough margin, someone has to close the position fast, or the protocol takes the loss. The liquidator gets a reward taken from the failed position, usually collateral at a discount. Because every liquidation pays, bots watch every position on these protocols, and the borrower whose position failed pays for the service.

Paying strangers to run a job has one condition. Imagine a claim instruction that sends the reward to whoever signs the transaction. The first bot to notice would take every user's rewards. So the instruction has to send the result to the same place no matter who signs. The executor can trigger the job, and that is all it can do. This is why the pattern is called untrusted executor. The protocol does not care who the executor is, because the executor cannot change what the instruction does.

Helium, Monaco and governance programs don't pay the caller at all. They show the other half of the pattern, an instruction that anyone can safely call.

Helium pays rewards to the owners of hotspots, the devices that provide its wireless network. A set of oracles signs the total reward each device has earned so far, and the device's account stores how much was already paid out. Say the oracles sign that a device has earned 100 tokens in total, and the account says 80 were already paid. The claim instruction pays the difference, 20 tokens, to the owner, and records that 100 were paid. Paying the owner makes the caller irrelevant, and recording the total stops the same claim from paying twice. Together they make the claim safe for anyone to call, so a stranger who claims for you only pays the fee for you.

Monaco, a prediction market, separates matching from paying out. Matching only marks the orders as filled. Paying out is a separate instruction that anyone can call later, and the money goes to the order owners. Governance works the same way. After a vote passes, anyone can send the transaction that executes the proposal. The vote decided what happens. The executor only decides when.

The executor cannot change what the instruction does, but it still chooses when to send the transaction and which accounts to pass. Timing matters when the result depends on a price or a clock, so the instruction has to be correct at any moment it can be called. The accounts matter because the client brings every account, so the instruction checks each one exactly as it would for any other caller.

A fixed reward has a problem. If it is too high, the protocol overpays every time. If it is too low, nobody runs the job. Symmetry V3 lets the bots compete instead of choosing a number.

A Symmetry index fund holds several tokens in target shares, for example 50% SOL, 30% JUP and 20% BONK. When prices move, the real shares drift away from the targets, and the fund has to trade to bring them back. This trade is called a rebalance.

Symmetry offers the rebalance as a Dutch auction. The offer starts unattractive and gets a little better every slot until someone takes it. The bot's reward is the difference between the offered price and the market price. At first the price is good for the fund and the reward is tiny. Every slot the price moves toward the bot, and the reward grows. Many bots watch every fund, and each one has its own minimum reward. The trade goes to the first bot whose minimum is reached, so the fund pays roughly the smallest reward any bot would accept.

The numbers in the diagram below are illustrative. They show the shape of the auction. Symmetry's real parameters differ.

Helium's tuktuk turns this pattern into a general scheduler. A task is an account that holds a reward, paid up front by whoever created the task, and a condition for when it may run, such as "not before 12:00 UTC". Once the condition is met, any bot can run the task, take the reward and close the account. What the task does is fixed by its creator, so the bot can run it but cannot change it. A repeating job creates its next task while it runs, so a daily job keeps scheduling itself with no team server behind it.

Rewards work for protocol design in general. If some actions in your protocol pay more than others, users move toward those actions without being asked. A liquidation reward makes users watch positions, a Dutch auction makes bots compete on price, and a prepaid task makes bots run your schedule. If you need users to do something, make that action pay.

When you design a protocol, list every action that has to happen without a user asking for it, such as paying rewards, settling trades, liquidations, expiring orders and rebalancing. For each one, answer three questions. Who is paid to call it, and does the reward cover their costs? Does the result stay the same no matter who calls it? Which accounts does the caller choose, and does the program check each one? If all three answers hold up, the job no longer depends on your server. Your own bot can still run, as one executor among many, with no special permissions.