Limits and assumptions

Understanding the rules also means understanding what they depend on. This page separates features not yet available on Live from risks that remain even when the software follows its rules.

Feature availability

The source includes features that are not enabled on Live. Check these before building an integration around a protocol operation:

These features are disabled in the default build and on Live. They are enabled only on Dev/Test networks built with experimental-testnet:

• Certified verifier selection and activation.
• Governance operations that require certified activation, and full governance content.
• Ledger-backed governance-key delegation.
• Appeals of challenge outcomes.

The experimental flag permits these paths; accounts must still meet each operation's eligibility and state requirements. Bootstrap verification has separate rules.

The switches are in verification and the node release policy. Physical removal of historical block bodies also remains disabled by its release gate; see node storage.

Protocol assumptions

Correct accounting does not by itself establish economic usefulness or honest human judgments. These risks remain relevant even when software follows its rules.

Verification can be wrong in either direction. A false identity that passes can gain extra income and voting weight. A real person wrongly judged fraudulent can lose rights, and honest recipients can lose affected payments. Restoration can correct the accounting but cannot undo an intervening loss of goods or opportunity. Appeals are currently disabled on Live.

Equal account weights do not guarantee widely distributed control. People can delegate them to a small number of representatives. If too much required weight goes offline, agreement can stop; each disconnected part of the network cannot safely redefine the voting group around the nodes it can reach. If enough voters collude, their signatures can authorize a harmful decision. Signatures establish who agreed, not whether the decision was good.

A functioning ledger does not guarantee purchasing power. Merchants may refuse TRST, and a payment may buy goods before its fraudulent origin is discovered. Revocation cannot retrieve those goods or insure the recipient.

The ledger is also public. Linking payment history to real people can reveal financial relationships. Losing the secrets that control an account presents a different risk: the wallet cannot recreate an unknown key. Its local guardian records do not provide a general social-recovery service.

Tests and benchmarks can establish specific behavior under recorded conditions. They do not prove a safe fraudulent-account percentage, incentive equilibrium, unlimited capacity or correctness under every failure mode. Public claims must match the evidence's scope.

Read verification, privacy, wallet recovery and performance for the mechanisms and their practical boundaries.