Nonce

Origin: composes, decades-old cryptographic vocabulary, applied to accounts the way Ethereum popularized it. Solidus status: shipped, enforced on every transaction on the live testnet.

A nonce is a number a sender includes in a transaction, and a blockchain uses it to make sure that transaction can never be processed twice. Without one, an attacker who observes a valid, signed transaction on the network could simply rebroadcast it: the signature is still valid, so a naive system would happily execute it again, moving the sender's funds a second time. In account-based blockchains, the fix is to give every account its own counter, starting at zero, and require each new transaction to carry the counter's current value plus one. Once a transaction with nonce N executes, the account's stored nonce becomes N, and the exact same signed transaction can never execute again, its nonce no longer matches.

This is different from "nonce" as used in proof-of-work mining (a throwaway value miners vary to find a hash below a target), same word, unrelated purpose. The transaction nonce described here is about replay protection and ordering, not mining.

Where it comes from

The word itself, a number used once, comes from general cryptographic practice: challenge–response authentication and many symmetric-cipher modes have relied on single-use values for decades to prevent an attacker from replaying an old, valid message. The specific pattern Solidus uses, one monotonically increasing counter per account, checked for an exact match before execution, is the account-based model Ethereum formalized in its 2014 Yellow Paper. Solidus did not design either the general idea or this specific accounting scheme; it implements the same pattern other account-based chains use.

How Solidus enforces it

Every Solidus transaction (a token transfer, a DID operation, a credential issuance, a stake) carries a nonce: u64 field. At execution time, solidus-state's executor checks sender.nonce != tx.nonce and rejects the transaction outright on any mismatch, with an explicit invalid nonce: expected {X}, got {Y} error. This is stricter than some mempool designs: Solidus does not queue a transaction with a nonce further ahead than the account's current value and wait for the gap to fill, it must arrive in exact order or it's rejected on the spot. On success, the account's stored nonce increments by exactly one.

Check it yourself

solidus_getNonce is a live, public JSON-RPC method on rpc.solidus.network, send it any address and read back its current nonce directly, no account or API key needed. The rejection logic itself is visible in source in the public solidusnetwork/protocol repository's solidus-state crate.

Related terms: Transaction Pool · State Root · Genesis Block · Ed25519/EdDSA