Transactions
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.Transaction LifecycleWorking Model BridgesThe required bridge from wallet intent to accepted evidence and public observation.UTXO To Virtual State To IndexerWorking Model BridgesHow spendable state, consensus processing, and observation layers connect without collapsing into one layer.Virtual State And Accepted TransactionsConsensusVirtual state is where ordered consensus consequences become transaction and UTXO evidence for tools and applications.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.Successor Output ValidationToccataSuccessor validation is the covenant safety center: the script must check what the next output is allowed to be.Indexers And Accepted EvidenceDeveloper IntegrationIndexers make accepted data usable, but they must recover, replay, and handle stale heads.Where Coins Live: UTXOFirst ContactA first-contact explanation of outputs, inputs, outpoints, validation, and spendable state.Wallet Signing ReadinessReadinessWallet signing readiness checks that a wallet preserves intent through build, sign, decode, submit, and observe.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.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.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.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.