Mechanics
Pages grouped by this topic tag.
Consensus, GHOSTDAG, And blockDAGConsensusBuild the bridge from public Kaspa descriptions into GHOSTDAG, virtual state, and source-level consensus review.blockDAG ModelConsensusA blockDAG starts from the simple fact that valid blocks can be found close together, but it does not remove the need for a consistent ordering rule.Blue Score And Blue WorkConsensusBlue score and blue work are progress indicators in the consensus view and need careful explanation before apps use them.Consensus FAQ And Failure ModesConsensusThis question-led page corrects common misreadings: DAG does not mean no ordering, selected parent is not the whole state story, and mempool visibility is not accepted evidence.GHOSTDAG MechanicsConsensusThis page explains selected parent, mergesets, blue/red classification, blue score, and blue work as connected mechanics.PHANTOM And GHOSTDAGConsensusPHANTOM and GHOSTDAG belong in the research-to-implementation bridge: the paper motivates the model, and Rusty Kaspa closes current behavior.Selected Parent And MergesetsConsensusSelected parent and mergesets are the first place where DAG intuition becomes source-level mechanics.Virtual State And Accepted TransactionsConsensusVirtual state is where ordered consensus consequences become transaction and UTXO evidence for tools and applications.CovenantsToccataExplain covenant state, lineage, introspection, covenant IDs, and output constraints with clear implementation and proposal boundaries.Auth Groups Vs Covenant GroupsToccataAuth groups and covenant groups answer different questions and must not be collapsed.Counter Covenant StarterToccataA counter covenant starter is a teaching pattern to verify, not an upstream-endorsed production recipe. It introduces successor checks, negative tests, and state encoding while keeping every concrete rule source-gated.Covenant Design PatternsToccataDesign patterns help readers recognize covenant shapes before building them.Covenant Head Indexer StarterToccataA covenant app needs a reliable way to find the current head after accepted activity and restart.Covenant IDs And LineageToccataCovenant ID is lineage evidence, not the whole app rule.Covenants And StateToccataA covenant is taught as a script-controlled UTXO that validates a spend and the next output, not as account storage mutated in place.Dice RollRegistry Case StudyToccataThe local dice/RollRegistry experience can teach reusable checks, but it is labeled local experience and cited only through public mechanisms.Introspection Opcodes And Script ContextToccataIntrospection lets script logic inspect transaction context, but every inspected field needs a source-backed meaning.Successor Output ValidationToccataSuccessor validation is the covenant safety center: the script must check what the next output is allowed to be.Vault Covenant StarterToccataA vault starter is design-question guidance until a concrete upstream vault implementation, wallet flow, and accepted-evidence path are verified.Developer IntegrationDeveloper IntegrationMap docs, APIs, SDKs, indexers, tests, and tooling into a source-checked integration guide.Developer Environment, Networks, RPC, And WalletsDeveloper IntegrationDeveloper environment setup begins with network selection, node access, RPC shape, wallet authority, and reproducible local tooling.Developer Knowledge BaseDeveloper IntegrationDeveloper integration starts by deciding what kind of claim is being made: interface, convenience, observation, or protocol behavior.Docker And Self-Hosted NodesDeveloper IntegrationSelf-hosted node pages explain environment and operation without turning deployment snippets into protocol authority.Indexers And Accepted EvidenceDeveloper IntegrationIndexers make accepted data usable, but they must recover, replay, and handle stale heads.REST APIDeveloper IntegrationREST API pages are convenience and observation pages, not consensus authority.RPC And wRPCDeveloper IntegrationRPC and wRPC are interfaces into node behavior and must preserve field meaning across clients.SDKs And Wallet BuildersDeveloper IntegrationSDK pages teach build/decode/sign/submit/observe loops while keeping wallet authority and network evidence separate.Testing And ToolingDeveloper IntegrationTesting pages connect source claims to reproducible evidence and named limits.Economics, History, And EcosystemContextKeep economics, launch history, project status, and ecosystem catalogs useful without turning the guide into market commentary.DAGLabs And Early HistoryContextDAGLabs and early-history material belongs in dated context pages rather than current protocol guides.Excluded Trading, Price, And Profitability MaterialContextThis exclusion page records why trading, exchange, price, profitability, and hype material cannot close educational or protocol claims.Genesis And Launch ClaimsContextGenesis and launch pages separate source-defined genesis configuration from historical launch narratives and community context.MerchantsContextMerchant pages explain payment-resource context and wallet integration boundaries without drifting into promotion.PrehistoryContextPrehistory captures early context and community history while routing current claims elsewhere.Software EcosystemContextSoftware ecosystem pages help readers find public projects without claiming compatibility beyond sources.TimelineContextTimeline pages use dates and release evidence without mixing history and current instructions.TokenomicsContextTokenomics explains supply and emission with source-backed care and no market framing.ToolsContextTool catalogs group resources by task while avoiding endorsement language.Updates And ProjectsContextProject-status pages are volatile catalogs and need last-checked dates.FoundationsFoundationsBuild the entry path into Kaspa without stopping at a slogan. This category explains the network identity, the reason blockDAG vocabulary appears, the first operational branches, and the boundary between historical context and current protocol claims.Background ReadingFoundationsBackground reading is a research shelf, not a shortcut around implementation review.FAQFoundationsThe FAQ uses question-led sections to answer common Kaspa questions directly while pointing deeper pages to source-checked explanations.Getting StartedFoundationsA practical start page points readers toward the first action they are trying to take: hold keys, run a node, mine, build, or study source behavior.How This Guide Uses SourcesFoundationsThis page teaches the source hierarchy used by the v1 guide so public wiki prose does not confuse orientation, implementation, releases, KIPs, papers, tools, and local experience.Kaspa Documentation Flow And Contribution StyleFoundationsThis page records how the guide borrows the useful information flow of wiki.kaspa.org without copying its prose or weakening source discipline.PrehistoryFoundationsPrehistory is useful context for how Kaspa emerged, but it is not a source for current protocol mechanics.TerminologyFoundationsKaspa terminology should be introduced as a working vocabulary that connects wiki prose to implementation terms.TimelineFoundationsTimeline material gives dates and sequence without converting history into current operational advice.TokenomicsFoundationsTokenomics pages explain supply, emission, genesis, fees, and miner incentives without drifting into trading claims.What Is KaspaFoundationsKaspa is introduced as a proof of work cryptocurrency network whose core learning path quickly leads into blockDAG consensus, UTXO transactions, node operation, and source-backed verification.Why blockDAG MattersFoundationsThis page gives the first transition from ordinary chain intuition into Kaspa's blockDAG model, while keeping paper vocabulary separate from implementation behavior.Why KaspaFoundationsThis page explains the problem Kaspa is trying to address before it introduces deeper protocol terms.SilverScript, vProgs, And Based AppsToccataExplain authoring, compiler/lowering, based app architecture, vProgs runtime layers, settlement, indexers, and readiness caveats.Based AppsToccataBased apps use L1 ordering evidence with off-chain execution and settlement, not generic smart-contract calls.Based Lane StarterToccataA based lane starter walks from lane design to ordering observation and settlement evidence.Declarations And Covenant MacrosToccataDeclaration macros are teaching aids for common covenant patterns, but their output must still be reviewed against state rules.Minimal dApp TemplatesToccataTemplate pages organize counter, vault, ZK transition, based lane, and dice-style lessons into source-labeled starters.Settlement And Indexer ResponsibilityToccataSettlement pages answer who reconstructs activity, who proves it, who submits it, and who tracks state after restart.SilverScript AuthoringToccataSilverScript authoring is a convenience layer for writing covenant scripts, not a replacement for protocol review.SilverScript Compiler And LoweringToccataCompiler and lowering pages explain how higher-level declarations become scripts and what still needs manual review.User Ops, Payloads, And LanesToccataUser operation pages teach payload encoding, gas, lane namespace, and ordering evidence.vProgs ArchitectureToccatavProgs is treated as evolving reference/runtime work that needs tooling-readiness labels.ToccataToccataExplain Toccata as a sourced upgrade and application surface without blending docs, releases, implementation, proposals, and local experiments.Activation, Releases, And ParametersToccataActivation pages teach how to verify Toccata status without blending mainnet, testnet, and history.Compute Budget And Script PricingToccataCompute budget and script pricing are described through docs, KIP-0025-PR proposal text, and source paths; this page should not treat proposal-only material as final deployed behavior.Sequencing CommitmentsToccataSequencing commitments describe how based-app activity can be committed and proven across lane partitions.Subnets, User Lanes, And GasToccataLanes and subnetwork fields should be taught as application ordering and payload surfaces with source-backed boundaries.Toccata Decision ReferenceToccataThe decision guide asks for the smallest model that carries the invariant: ordinary transaction, covenant, ZK covenant, based app, or vProgs-style execution.Toccata FAQ And Failure ModesToccataThis question-led page corrects common Toccata misreadings before they become unsafe app designs.Transaction V1ToccataTransaction v1 is the field-level foundation for Toccata-era application behavior, but implemented source fields and KIP-0024-PR proposal text must be read as separate claim classes.What Toccata ChangesToccataToccata is an application surface made of several connected protocol and tooling changes, not one isolated feature.Topic PathsTopic PathsThe deeper topic guide layer inherited from the v1 guide and wrapped by the source-linked reference.Transactions, UTXO, Fees, And MempoolTransactionsTurn ownership, UTXOs, transaction format, mass/fees, mempool admission, and accepted evidence into one source-backed learning path.UTXO Model And OwnershipTransactionsKaspa ownership is best taught as spendable outputs rather than account balances.Transaction StructureTransactionsA transaction is a structured object interpreted by validation, hashing, signing, mempool, RPC, wallet, and block-template code.Inputs, Outputs, And OutpointsTransactionsInputs, outputs, and outpoints are the vocabulary of UTXO spending.Transaction ID, Full Hash, Payload Digest, And Rest DigestTransactionsTxid and full transaction hash must be explained separately because they answer different identity and commitment questions.Sighash And Signing CommitmentsTransactionsSighash defines what a signature commits to and is one of the highest-risk wallet/developer surfaces.Mass, Fees, And Storage MassTransactionsMass is resource accounting, not just a fee-size synonym.Transaction Validation LayersTransactionsTransaction validation is layered, and each layer rejects different classes of mistakes.Mempool Policy, Orphans, RBF, And RelayTransactionsMempool admission is local node policy and not final chain acceptance.Block Templates And Transaction SelectionTransactionsBlock templates turn node state and mempool candidates into miner work.Accepted Transaction EvidenceTransactionsAccepted evidence is the boundary between transaction intent and consensus-visible consequence.RPC, UTXO Index, And Explorer BoundariesTransactionsRPC and indexer shapes expose transaction data to tools, but they do not replace consensus source review.Wallets, Nodes, And MiningOperationsConnect user-facing operation with the node, wallet, mempool, P2P, and block-template paths that make a workflow real.Docker And Self-Hosted NodesOperationsSelf-hosted and Docker node pages explain deployment surfaces while keeping image tags and commands freshness-sensitive.Mempool And Block TemplatesOperationsThis page bridges operations and protocol source: a node may admit a transaction, but miners still need a valid block template and consensus still decides acceptance.Message Signing And KIP-0005OperationsMessage-signing support is treated as feature-specific wallet behavior that needs source and KIP evidence before current claims are made.MiningOperationsMining joins node state, block template construction, and proof of work search. It should be explained without profitability or hype framing.Mining Hardware And High-Staleness CatalogsOperationsMining hardware, hashrate tables, pools, and profitability references are volatile catalog material, not durable protocol education.Mining TroubleshootingOperationsMining troubleshooting separates node sync, template construction, miner connection, proof-of-work attempts, pool policy, and accepted block evidence.Node Sync, Logs, Ports, And IndexesOperationsNode sync, logs, ports, and indexes are the practical evidence surfaces operators inspect before trusting local state.NodesOperationsA node is the local participant that syncs, validates, communicates with peers, serves APIs, and provides the state surface wallets and miners depend on.Operational TroubleshootingOperationsTroubleshooting is symptom-led: the first job is to identify whether the failure lives in wallet, node, network, mempool, miner, indexer, or source freshness.P2P And IBDOperationsP2P and IBD explain how a node becomes useful by connecting to peers and catching up to network state.Setting Up A CLI NodeOperationsThe CLI node page turns Kaspa documentation operation flow into a source-checked checklist.Setting Up A CLI WalletOperationsThe CLI wallet guide follows an operation-guide shape: prepare, create or import, back up, connect to a node, build a transaction, sign, submit, and verify.Solo And Pool Mining FlowOperationsSolo and pool mining are explained as different operational routes from block templates to proof-of-work attempts and payout evidence.Wallet Roundtrip EvidenceOperationsWallet roundtrip evidence checks whether intent survives build, signing, decoding, submission, and accepted-state observation.Wallet Safety And BackupOperationsWallet safety pages focus on backup, seed handling, wallet files, network selection, and avoiding accidental loss of authority.Wallet TroubleshootingOperationsWallet troubleshooting maps symptoms to wallet file, daemon, node connection, network, UTXO index, signing, and broadcast layers.WalletsOperationsA wallet is best understood as key and transaction workflow software, not as the place where coins physically live.