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.