Finite state machines (FSMs) are a model of computation in which a system occupies exactly one of a finite set of states at a time and moves between them only through defined transitions. The NIST Dictionary of Algorithms and Data Structures defines one as a set of states, a start state, an input alphabet and a transition function that maps an input symbol and the current state to a next state. Variants attach outputs to transitions (a Mealy machine) or to states (a Moore machine), and a nondeterministic machine allows more than one transition for a given symbol and state.
The property that makes the model useful where failure is expensive is that the reachable states can be enumerated in advance. Behaviour that is not a defined transition cannot occur, so questions about what a system might do become questions about a finite table rather than about arbitrary code. This is why the model is standard in embedded and safety-critical control software, and it is the reason it is worth asking, of any ledger, which parts of it are a state machine and which parts only look like one.
Overview
An FSM processes inputs and transitions between states according to a fixed set of rules. Each state represents one condition or phase of the system, and the machine is in exactly one of them at any moment. The constraint is the point: by refusing to represent anything outside the declared states, the model trades expressive power for the ability to reason exhaustively about outcomes.
Contract state versus machine state
A conventional smart contract platform does not present a finite state machine to the people using it. An Ethereum contract keeps its own internal variables and exposes methods that may change them, so an ERC-20 balance is a number in a mapping inside the token contract rather than a state of the system, and the contract’s own code decides who may change it and when. A transaction touching several contracts produces a sequence of internal changes in each of them, and the set of end states the interaction can reach is whatever that code permits rather than an enumerated list. This is a deliberate trade in service of Ethereum’s general-computation model, and it is the trade that makes the reachable-state question hard to answer for a composed system.
Finite state machines in Radix
Radix’s documentation does not describe the Radix Engine as a finite state machine and this page does not claim that it is one. What the documentation does define, in a small enumerated set with transitions enforced on-ledger, is the lifecycle of a transaction intent.
A user transaction is built around a core transaction intent, identified by its intent hash. Once a payload is submitted, the documented outcomes are permanent rejection, temporary rejection, committed success or committed failure. A payload is permanently rejected when it is never possible for it to be committed, for example because it is statically invalid or its epoch window has passed; it is temporarily rejected when commitment may still be possible. Committed failure pays fees up to the failure point and discards every other event and state change; committed success commits all changes and pays fees. Only committed transactions appear in the transaction stream, so a rejected one never enters the ledger’s history. The documentation advises waiting or resubmitting on a temporary rejection, which makes it the lifecycle’s only non-final state.
The uniqueness of the transition is enforced by a component on the ledger rather than by convention. The Transaction Tracker is a native component that stores the success or failure of each recently executed transaction keyed by its intent hash, which lets the executor validate a newly submitted intent hash before executing it and reject a duplicate with IntentHashPreviouslyCommitted. The engine therefore guarantees that a given intent is committed no more than once even though a notary may notarise and submit several different payloads for the same intent. The tracker already carries a cancelled status and the executor is ready to interpret it as IntentHashPreviouslyCancelled, but no public API for cancelling a transaction exists yet.
The tracker keeps that state finite by expiring it. A transaction is valid only within its configured epoch range and that range is hard-capped, so records are only needed for transactions whose range ends after the current epoch. They are held in a ring buffer over partitions 65 to 255, each partition covering 100 epochs, giving 19,100 epochs of capacity against a maximum transaction epoch range of 8,640; the over-allocation means more than half the buffer is empty at any moment by design.
The asset model is the second place the analogy holds. On Radix a token is a resource held in a vault, and moving it means moving it between vaults rather than rewriting a balance variable that a contract owns. Where a resource sits is the state, and no code path can leave it in two places or in neither. That is enforced by the engine for every application on the network, which is the difference between a state machine a developer chooses to implement and one the platform imposes. See asset-oriented programming and native assets versus token approvals.
References
- National Institute of Standards and Technology. finite state machine. Dictionary of Algorithms and Data Structures. Read 11 September 2026.
- RDX Works. Transactions. Radix Technical Documentation. Read 11 September 2026.
- RDX Works. Transaction Tracker. Radix Technical Documentation. Read 11 September 2026.
- RDX Works. Transaction Overview. Radix Technical Documentation. Read 11 September 2026.
- Ethereum. EIP-20: Token Standard. Ethereum Improvement Proposals.