10. State Model & Accounts
10.1 Account-Based State
Quantos uses an account model (quantos/src/types/account.rs, state/manager.rs) rather than Bitcoin-style UTXOs, which simplifies smart-contract state and stake accounting. Each Account carries:
| Field | Meaning |
|---|---|
address | 32-byte account identifier |
balance | Spendable token balance |
nonce | Monotonic counter for replay protection and ordering |
code_hash | Hash of contract bytecode (None for externally-owned accounts) |
storage_root | Merkle root of the account's contract storage |
stake | Amount staked for validation |
is_validator | Whether the account is an active validator |
Addresses are 32 bytes (versus Ethereum's 20), reflecting the larger key material of post-quantum schemes and providing ample collision resistance.
10.2 Deterministic Account Hashing
Account state is committed via a deterministic serialization rather than a general-purpose codec. The Account::hash routine explicitly concatenates fields in fixed order with fixed-endian encoding (little-endian) before hashing with SHA3-256. This is a deliberate safety choice: non-deterministic serialization (e.g. map iteration order) is a classic source of consensus forks, so Quantos hashes a canonical byte layout that is identical on every node and architecture.
10.3 Transaction Types
A Transaction (types/transaction.rs) declares its intent through a typed TransactionType, so the state machine validates and routes each transaction precisely:
Transfer— move balance between accounts.Stake/Unstake— adjust staked balance.ValidatorRegister/ValidatorExit— join or leave the validator set.ContractDeploy/ContractCall— deploy or invoke smart contracts.
Each transaction also carries max_compute_units (its STACC CU budget), an optional boost (priority lock — tokens are locked, never burned), a vm_kind selector (Qvm native WASM or Evm), shard_id, nonce, chain_id, timestamp, and the post-quantum signature + public_key.
10.4 Replay and Drift Protection
Several fields exist specifically to defeat replay and manipulation:
nonceensures each transaction is applied at most once and in order per sender.chain_idbinds a transaction to Quantos, preventing cross-chain replay.- Timestamp drift bound:
MAX_TIMESTAMP_DRIFT = 30 seconds— a transaction whose timestamp deviates too far from network time is rejected, narrowing the window for timestamp-based manipulation (reduced from an earlier 5-minute bound). - Batch-verified signatures: transaction signatures use the repository's ML-DSA-65 batch-verification path under the transaction domain tag, with exact batching behavior determined by the active implementation.
10.5 State Management and Execution
The state manager (state/manager.rs) is the authority on account state, validation, and the validator set; the executor (state/executor.rs) applies ordered transactions to produce the next state. Parallel execution within a shard is mediated by software-transactional-memory and MVCC layers (state/stm.rs, and the VM's MVCC), so independent transactions commit concurrently while conflicting ones are serialised — the execution-side counterpart to the DAG's ordering guarantees.
10.6 State Growth Management
Unbounded state growth is an important design concern. The repository contains a configurable state-rent collector, archival-pruning and snapshot helpers, flat storage, compression and sync components. Their activation, deletion/restoration semantics, retention guarantees and interaction with committed state must be validated in the active node path; the presence of a helper is not proof that automatic archival is live on every network.