Kaspa
Pages grouped by this topic tag.
Accepted Evidence Vs Mempool AcceptedWorking Model BridgesWhy node mempool admission and consensus accepted evidence are different.Block Added Vs Transaction AcceptedWorking Model BridgesWhy adding a block to the DAG is not the same as proving a transaction's accepted consequences.blockDAG To GHOSTDAG To Virtual StateWorking Model BridgesThe consensus bridge from graph structure into accepted consequences.Checking Source ClaimsWorking Model BridgesHow to read public source IDs, claim status, and Open Questions without upgrading uncertainty.Node Miner Template EvidenceWorking Model BridgesHow node operation, mempool policy, block templates, and miner work relate.RPC, wRPC, Indexer Observation BoundariesWorking Model BridgesHow developer interfaces expose observations without becoming protocol authority by themselves.Toccata Application LifecycleWorking Model BridgesA status-safe bridge from transaction v1 through covenant state, inline ZK, and based-app observation.Transaction LifecycleWorking Model BridgesThe required bridge from wallet intent to accepted evidence and public observation.Wallet Roundtrip EvidenceWorking Model BridgesWhat a wallet can prove by itself and what needs node, consensus, or indexer evidence.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.DAGKnight Research EdgeConsensusDAGKnight belongs in research edge unless current implementation and release evidence supports stronger status.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.Core Contributor PathContributionTurn the whole v1 guide into a source checking path for checking, modifying, reviewing, or documenting Kaspa-related code.ChecklistsContributionChecklists keep source changes, guide changes, and claim labels aligned.Exact Test Command MatrixContributionThe test matrix records which commands or upstream gates support which class of claim.Final Source CheckContributionThe final review page is the last evidence gate before a guide claim becomes stronger wording.GHOSTDAG Function WalkthroughContributionThe GHOSTDAG walkthrough turns consensus vocabulary into function-level review.Public Source OrderContributionA reading order prevents source review from becoming a flat folder crawl.Rusty Kaspa Source ListContributionThe Source List groups Rusty Kaspa by responsibility: consensus, transaction validation, mining/mempool, P2P, RPC, indexes, wallet, database, txscript, and tests.Source PriorityContributionContribution begins by deciding which source can support which claim.Toccata Internals Function WalkthroughContributionToccata internals require cross-module review because transaction v1 touches identity, signing, resource accounting, scripts, covenants, and ZK.Transaction Field TraceContributionA field trace teaches how to follow one field such as compute budget, payload, or covenant ID through structs, serialization, hashing, signing, RPC, mempool, and tests.Transaction Validation Function WalkthroughContributionTransaction validation walkthroughs tie isolation, context, UTXO, script, and mass checks to source review.Virtual Processing And Accepted TransactionsContributionVirtual processing walkthroughs show how accepted transactions and UTXO diffs become application-visible evidence.Core Protocol Source PathCore ProtocolCreate the code-reading path for validation, proof of work, constants, difficulty, pruning, reachability, storage, and upgrade behavior.Activation, KIPs, And Release EvidenceCore ProtocolKIPs and upgrades are a status map, not an automatic statement of deployed behavior.DAA, Difficulty, And ActivationCore ProtocolDifficulty adjustment and activation pages show how timing, work, and rule changes are checked against source and KIPs.Header, Body, And Virtual PipelineCore ProtocolThe consensus pipeline explains where headers, bodies, transactions, and virtual state are processed.P2P And IBDCore ProtocolP2P and initial block download connect a local node to the network and determine whether local evidence is useful.Proof Of Work And kHeavyHashCore ProtocolProof of work gives blocks an objective work signal; kHeavyHash and header checks belong to source-backed mining and validation pages.Pruning And Pruning ProofsCore ProtocolPruning is about keeping enough evidence for security and synchronization while bounding stored history.ReachabilityCore ProtocolReachability answers ancestry questions in a DAG and supports GHOSTDAG, pruning, and validation work.Rusty Kaspa Consensus MapCore ProtocolRusty Kaspa is the primary current implementation authority, but readers need a map before treating the repository as a flat list of files.Source Walkthrough ExercisesCore ProtocolExercises turn the Source List into contributor practice: trace one behavior from wiki claim to module to test evidence.Storage, Indexes, And State SurfacesCore ProtocolStorage and indexes expose state to tools, but indexer observation is not itself consensus authority.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.Integration Readiness ChecklistDeveloper IntegrationReadiness is a checklist of evidence: fields preserved, network selected, source current, tests run, accepted evidence captured, and recovery paths tested.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.Supply And Emission Source PathContextSupply source paths map public claims to source constants and Kaspa documentation orientation.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.FAQFirst ContactQuestion-led answers for common first-contact Kaspa guide confusions.GlossaryFirst ContactShort definitions for recurring Kaspa guide terms, with links into deeper mechanics.Proof Of Work To blockDAG To GHOSTDAGFirst ContactA bridge from ordinary proof of work intuition into Kaspa's graph and ordering vocabulary.Wallet, Node, Miner, Developer PathsFirst ContactThe first practical branches through the guide and the evidence each branch needs.What Is KaspaFirst ContactA direct explanation of Kaspa and the concepts that make its guide different from a linear-chain-only introduction.Where Coins Live: UTXOFirst ContactA first-contact explanation of outputs, inputs, outpoints, validation, and spendable state.Why blockDAGFirst ContactWhy Kaspa introduces blockDAG structure before explaining GHOSTDAG ordering and virtual state.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.Open Research GapsOpen Research GapsVisible unresolved source checking work that blocks a final authoritative release.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.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.Tooling Readiness And Production CaveatsToccataTooling readiness pages keep moving APIs, pre-check tools, wallet support, and mainnet safety gates visible.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.vProgs ZK PipelineToccataThe vProgs ZK pipeline connects transaction processing, batch aggregation, proof generation, journal/state transition, and settlement as tooling or architecture material, not as base-protocol authority.Site StatusSite StatusFinal source-linked reference verdict after three-reader review and strict check gates.Source PathsSource PathsPublic source-path map for implementation, KIPs, docs, tooling, and research sources.Source RegistrySource PathsA compact public registry of the source classes used by the source-linked reference.How To Read This GuideStart HereThe navigation rules for moving from first contact to implementation and research edge.Start Here: Kaspa In One PageStart HereA one-page public entry path into Kaspa, from first contact through source-level study.Status Labels: Current, Proposed, Historical, ResearchStart HereHow the guide labels claims so current behavior is not mixed with proposals, history, research, or local experience.Testnets And Production ReadinessReadinessTeach network selection, release checks, explorer/API observations, wallet signing, broadcast safety, and production gates with explicit freshness labels.API And Explorer Observation ChecksReadinessExplorer/API pages explain observation value and limits.Broadcast SafetyReadinessBroadcast safety separates local transaction construction from mempool admission and accepted network state.Operations Source PathReadinessThe readiness operations source path maps public claims about wallets, nodes, mining, broadcast, and accepted evidence to the upstream files that can support them.Production ReadinessReadinessProduction readiness is an evidence gate, not a confidence word.Readiness TroubleshootingReadinessReadiness troubleshooting maps symptoms to likely layers before making claims.Release And Version ChecksReadinessVersion checks prevent stale guide prose from turning into unsafe operation.TestnetsReadinessTestnets are environments for testing network behavior, not proof of mainnet behavior.TN10, TN11, And Historical Testnet ContextReadinessHistorical testnet pages preserve context without turning old network behavior into current instructions.TN10, TN11, And TN12 ReadinessReadinessTN readiness pages keep TN10, TN11, and TN12 evidence from blending.TN12 Covenant TestnetReadinessTN12 covenant-testnet guidance is source-sensitive and must name network selection, branch or release assumptions, and evidence checks.Verification And EvidenceReadinessVerification pages define which observations support which claim and what still needs source review.Wallet Signing ReadinessReadinessWallet signing readiness checks that a wallet preserves intent through build, sign, decode, submit, and observe.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.Toccata Source WalkthroughToccataA Toccata source walk ties transaction fields, hashing, sighash, mass, subnets, seqcommit, txscript, opcodes, and ZK precompiles into one review path.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.Source Path For Transaction ContributorsTransactionsTransaction contributors need a guided source order so a change does not silently break hashing, signing, mempool policy, RPC, or accepted evidence.Use Kaspa With A WalletStart HereA practical wallet-first path: choose a current wallet source, back up safely, receive a small amount, send a small test, and verify accepted evidence.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.ZK, Groth16, And RISC Zero SuccinctToccataTeach inline ZK as a covenant-adjacent proof verification path, while separating proof validity from whole state-transition validity.ZK First Contact And VocabularyToccataZK pages begin by defining proof, statement, prover, verifier, public input, witness, circuit, zkVM program, receipt, journal, tag, and precompile.Inline ZK Covenant ModelToccataInline ZK is best taught inside the covenant loop: current UTXO, proof, script verification, successor output.OpZkPrecompile Tags And CostsToccataTags and costs are high-risk source claims because they decide which verifier runs and whether the transaction has enough budget.Groth16 OverviewToccataGroth16 background explains circuits, witnesses, proving keys, verifying keys, proof bytes, public inputs, and trusted setup context.Groth16 Kaspa Verifier Source PathToccataThe Kaspa Groth16 source path explains verifying key/proof data, public input arity, metering, parsing, and verification failure cases.RISC Zero Succinct OverviewToccataRISC Zero Succinct pages explain zkVM receipts, image IDs, journal commitments, seals, and the difference between upstream concepts and Kaspa stack expectations.Proof Binding To Covenant StateToccataProof binding connects verifier success to the covenant state transition the app actually cares about.Negative Cases And Failure MatrixToccataA failure matrix makes ZK safer by naming what must fail.Groth16 Transition StarterToccataThe Groth16 starter is a draft implementation checklist for binding proof output to a covenant transition without citing local lab files as authority.RISC Zero Succinct Transition StarterToccataThe RISC Zero starter is a conceptual checklist until a concrete public upstream recipe is verified, and it makes image ID, journal digest, receipt/seal, and verifier boundaries explicit.Testing Evidence And ReadinessToccataReadiness labels prevent local proof output from being mistaken for production evidence.ZK FAQ And MisreadingsToccataThe ZK FAQ answers the mistakes that cause unsafe designs: valid proof is not whole transition validity, local proof output is not network readiness, and zkVM verification is not on-chain program execution.