# Consensus and Trust Model ### Decentralized Nodes KRC-20 nodes operate in a **permissionless** manner. Anyone can independently parse KRC-20 OP data by syncing Kaspa Layer-1 blocks and transactions, and deterministically replay KRC-20 execution locally to reproduce the KRC-20 state and the Checkpoint chain. Nodes rely on Layer-1 for data availability and ordering as their sole input source, without depending on centralized services or trusted third parties. When a Layer-1 reorganization occurs, nodes roll back to the common ancestor and re-execute under the new ordering to ensure that the computed KRC-20 state and Checkpoints are fully consistent, verifiable, and reproducible. ### State Commitments and Checkpoints To ensure consistency and verifiability of state, KRC-20 introduces two cryptographic anchoring mechanisms: state commitments and Checkpoints. State commitments are constructed using **MuHash**, committing to the entire KRC-20 state dataset while supporting transaction-level incremental updates. After deterministically executing each valid KRC-20 transaction, nodes cumulatively apply the corresponding state changes to derive a new state commitment. Given identical inputs, different nodes should produce the same state commitment, providing a unified, verifiable digest of the KRC-20 state. Checkpoints are generated using **BLAKE2b**, with a distinct Checkpoint produced for each valid KRC-20 transaction at transaction granularity. Each Checkpoint is computed from **the previous Checkpoint**, **the Layer-1 reference data** used to anchor the OP, and **the corresponding KRC-20 state commitment**, forming a chained, traceable, and tamper-evident commitment sequence. Any node can reproduce this sequence from public Layer-1 data and deterministic execution rules and verify its consistency. State commitments are also used for the KRC-20 fast bootstrap mechanism **ISD (Initial State Download)**. A new node can download the latest state from other KRC-20 nodes, compute the MuHash commitment for that state, recompute the expected latest Checkpoint, and compare it against the Checkpoint recorded on Layer-1. If they match, the initial state is considered valid; otherwise, the state is rejected and the node falls back to full resynchronization. ### Rollup Mechanism KRC-20’s Rollup mechanism is built on Kaspa Layer-1’s data availability and transaction ordering. KRC-20 nodes treat their selected Layer-1 view as the only input source, parse KRC-20 OPs according to the protocol rules, and replay transactions in a deterministic execution environment, producing a consistent KRC-20 state, MuHash state commitments, and a transaction-level Checkpoint sequence. Because ordering and finality are inherited from Layer-1, KRC-20 can reach globally consistent and reproducible execution results across nodes **without additional voting or committee-based consensus**. Under Layer-1’s **RTD (Real-Time Decentralization)** mechanism, miner-submitted Rollup data is verifiable. KRC-20 nodes can reproduce the execution results from public Layer-1 data and compare them with the Rollup data (Checkpoints) recorded on the Layer-1. If consistent, the data is accepted as valid and can be used for rapid node alignment and reward settlement. When Layer-1 reorganizes, KRC-20 nodes roll back to the common ancestor and re-execute in the new order; the corresponding state commitments and Checkpoints are updated accordingly, ensuring the KRC-20 state always remains consistent with the Layer-1 view. From a trust-model perspective, KRC-20 Rollup submission and verification follow an open-participation “**1-of-N**” assumption: given N potential submitters/observers/validator nodes, as long as **any one** honest participant can write the correct Rollup commitment data to Layer-1 and have it verified by other nodes, the system maintains public verifiability and continued progress of KRC-20 state. Errors or malicious behavior by any single submitter will not be “forced” into acceptance by the protocol; validity is ultimately determined by reproducible verification across all nodes. ### How to Verify For commitment consistency, a verifier can independently compute (or obtain from a local node) the latest transaction-level Checkpoint and compare it with the Checkpoint recorded on Layer-1. For ISD, a newly deployed node computes the MuHash commitment of the downloaded latest state, derives the expected latest Checkpoint from it, and compares the result against the Checkpoint recorded on Layer-1. --- # 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-kasplex.gitbook.io/krc20/technical-overview/consensus-and-trust-model.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.