# Core Concepts Fast is a distributed protocol built around a few key ideas that enable parallel, consistent claim settlement without traditional consensus. These concepts such as validators, node state, claim ordering, and [weak independence](/fast-archived/core-concepts/weak-independence.md), define how the system achieves scalability and determinism. ### Validators and their role Fast runs on a network of independent validators. Each validator receives claims from clients, verifies their validity, and updates its local copy of the global state. Unlike blockchains, there is no leader or voting phase. Validators make progress independently and in parallel, provided claims from the same account are processed in the order they were issued. This independence eliminates the need for global synchronization, greatly improving throughput. ### Node state and replication Every validator maintains a complete replica of the system state, from balances, to client data, and protocol-wide records. While processing claims, validators’ states may diverge temporarily but always converge once they have processed the same set of valid claims. This “eventual agreement without coordination” is a key strength of Fast. ### Ordering and concurrency Fast does not impose a global order on all claims. Instead, it follows two simple rules. First, claims that originate from the same account must be applied in the order they were created. This prevents an account from issuing two conflicting claims at the same time, such as trying to spend the same balance twice. Second, claims that come from different accounts can be processed in any order. The order may vary from one validator to another, depending on how those claims arrive, but this does not cause any conflict. This relaxation of global ordering is what makes Fast different. Two validators may apply the same set of claims in different sequences, and even interleave them. For example, one validator might see claims arrive in the order A1, B1, A2, B2, while another might see B1, A1, B2, A2. Instead of forcing them into the same sequence, Fast allows them to proceed in parallel. You can understand more about this [here](/fast-archived/core-concepts/weak-independence.md#total-ordering). ### Convergence without coordination Weak independence guarantees that this parallelism does not break the system. If all the claims involved are weakly independent, then the final state after applying all of them will be the same, no matter which order was used. This means validators can operate without constant coordination, yet still converge on a single shared outcome once they have processed the same claims. What results from this model is a system that supports massive throughput without sacrificing determinism. Validators avoid the bottleneck of block production and the overhead of global consensus protocols, but they do not lose correctness. ### Why these concepts matter The combination of independent validators, local state replication, minimal ordering rules, and weak independence, is what makes Fast capable of handling the volume and speed of modern decentralized applications. These core concepts remove the trade-off between consistency and performance that has defined blockchain-based systems for over a decade. In Fast, consistency emerges naturally from the way claims are structured and processed. In the next section, you will see how these concepts come together in detail, with formal definitions and examples of weak independence. That section shows why this property is powerful enough to ensure that, no matter how validators interleave claims, the network ends up in a single consistent state. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.fast.xyz/fast-archived/core-concepts.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.