One-way state

Sometimes one transaction has to happen before another, or the state becomes wrong. On Solana there is no sender nonce, so two transactions sent at the same time can land in either order, and either of them can land twice. Restoring the order on Solana is an antipattern.

Suppose an oracle pays a device its daily reward: 5 tokens today, 7 tokens tomorrow. Each reward is a signed message, and the program adds the amount to what the device may claim.

Now suppose two messages are in flight at once. If one of them is resent, the device is paid twice, and if one is lost, it is lost. When the second lands before the first, the state is wrong until the first arrives. The program cannot tell a late message from a duplicate, because a message says what to add, not where the result should end up.

EVM contracts solve this with the transaction nonce and with message ids. Every message has a number, and the contract accepts the next number only. We could copy this to Solana: an extra account for the number, and rent for it. But it is still not enough. A number proves that a message is new. It does not make A then B equal B then A.

The one-way design flips the problem. Instead of restoring the order, we shape the state so that the order stops mattering.

The message carries the destination, not the step. The oracle signs the total a device has earned so far, not today's reward. A total applied twice is just the total, and a total that arrives late is below the current state and does nothing. A step cannot do this, even one that only moves forward, because +5 applied twice is not +5 applied once.

With one-way state, the program accepts only moves in one direction. A counter can go up, never down. A set of rights can shrink, never grow. The program never compares two messages with each other. It compares the message with the current state and checks only whether this has already been taken into account. When you are moving in one direction, you cannot find yourself at 80 after you have passed 100.

Helium pays rewards to about a million devices, and its oracle does not sign daily rewards. It signs the total a device has earned since the beginning.

The device's account stores how much was already paid. A claim pays the difference and moves the paid amount up to the signed total. Send the same claim twice, and the second pays zero, because the paid amount already equals the total. Bring an older signature with a smaller total, and it pays nothing, because the paid amount is already above it. The counter never goes down, so nobody can take back what was paid, and no claim can land in a wrong order.

Squads is a multisig. When its signers or its threshold change, every proposal approved by the old signers has to become invalid.

Squads does not look at when the proposals were created or approved relative to the change. It moves one index, the stale transaction index, up to the latest proposal. Every proposal with a number at or below that index is stale. A stale proposal can be cancelled, but it cannot be approved or executed, in whatever order the transactions arrive. An approval that was in flight when the signers changed lands after the index moved, and the state rejects it. No timestamp is compared.

Drift's markets with an expiry go into reduce-only mode before they expire. A trader can close a position but cannot open a new one or grow an existing one. The set of allowed actions only narrows as the market approaches settlement. So a late order to open does not depend on whether it was signed before or after the switch. It is rejected because the state says the market is reduce-only.

One-way state survives one test: take any two transactions, swap their order, and the final state is the same. A duplicate is a transaction swapped with itself, and it changes nothing. The program never asks which message came first. It only asks whether the state has already passed this point.