Kaspa One StopTopics

Kip

Pages grouped by this topic tag.

Block Added Vs Transaction AcceptedWorking Model BridgesWhy adding a block to the DAG is not the same as proving a transaction's accepted consequences.Toccata Application LifecycleWorking Model BridgesA status-safe bridge from transaction v1 through covenant state, inline ZK, and based-app observation.Consensus, GHOSTDAG, And blockDAGConsensusBuild the bridge from public Kaspa descriptions into GHOSTDAG, virtual state, and source-level consensus review.DAGKnight Research EdgeConsensusDAGKnight belongs in research edge unless current implementation and release evidence supports stronger status.Virtual State And Accepted TransactionsConsensusVirtual state is where ordered consensus consequences become transaction and UTXO evidence for tools and applications.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.Pruning And Pruning ProofsCore ProtocolPruning is about keeping enough evidence for security and synchronization while bounding stored history.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.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.FAQFirst ContactQuestion-led answers for common first-contact Kaspa guide confusions.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.User Ops, Payloads, And LanesToccataUser operation pages teach payload encoding, gas, lane namespace, and ordering evidence.ToccataToccataExplain Toccata as a sourced upgrade and application surface without blending docs, releases, implementation, proposals, and local experiments.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.Transactions, UTXO, Fees, And MempoolTransactionsTurn ownership, UTXOs, transaction format, mass/fees, mempool admission, and accepted evidence into one source-backed learning path.Mass, Fees, And Storage MassTransactionsMass is resource accounting, not just a fee-size synonym.Accepted Transaction EvidenceTransactionsAccepted evidence is the boundary between transaction intent and consensus-visible consequence.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.ZK, Groth16, And RISC Zero SuccinctToccataTeach inline ZK as a covenant-adjacent proof verification path, while separating proof validity from whole state-transition validity.Proof Binding To Covenant StateToccataProof binding connects verifier success to the covenant state transition the app actually cares about.Testing Evidence And ReadinessToccataReadiness labels prevent local proof output from being mistaken for production evidence.ZK Source Path And Review PlaybookToccataThe ZK review playbook turns a claim into source work: docs, KIP, tags, costs, verifier source, tests, releases, and claim labels.