Submission & confirmation

Submitting a signed transaction hands it to a node, which gossips it to the network and includes it in a block when capacity allows. Two surfaces: pending.submit(client) for transactions produced by the Generator (see Transaction Generator), and client.submit_transaction(...) (see RPC → Calls) for everything else.

From a PendingTransaction

tx_id = await pending.submit(client)
print(tx_id)

pending.submit calls submit_transaction for you. The right path for Generator-built transactions — including the managed Wallet (see Send Transaction), which is built on the Generator.

Manual submission

result = await client.submit_transaction({
    "transaction": signed_tx,
    "allowOrphan": False,
})
print(result["transactionId"])

The request takes:

• transaction — a signed Transaction (or its dict form via Transaction.to_dict() when shipping through another system; see Serialization).
• allowOrphan — whether to keep the transaction in the mempool when an input hasn't been seen yet (e.g. submitting a chain out of order). Default False unless you know you're submitting a chain.

What "submitted" means

Submission is acceptance into the mempool, not confirmation. The return value is the transaction ID; the transaction is now eligible for inclusion in a block.

A Kaspa transaction lifecycle has three observable states:

• In mempool — accepted by the node, waiting for inclusion. ID returned from submit_transaction.
• Virtual-chain accepted — included in a block that's part of the canonical DAG ordering. Surfaces via the virtual-chain-changed notification.
• Mature — confirmed past the maturity threshold; new UTXOs are spendable. Surfaces via a Maturity event on the managed Wallet (see Wallet → Events) or the UtxoProcessor (see UTXO Processor).

The right gate for confirmation is the Maturity event for the specific transaction, not "wait N seconds" and not the first time it appears in a block.

Failures and retries

submit_transaction raises if the node rejects the transaction. Common reasons:

• fee too low — recompute mass with update_transaction_mass after any input/output change, then re-sign.
• orphan — an input references a transaction the node hasn't seen. Wait for the parent to land, or set allowOrphan=True when intentionally submitting a chain.
• already in mempool — the same transaction_id is already pending. Safe to ignore.
• mass exceeded — the transaction is over maximum_standard_transaction_mass(). Split the inputs across multiple transactions; the Generator does this automatically.

A virtual-chain-accepted transaction can be reorged out — at which point its outputs are no longer mature. The SDK surfaces this as a Reorg event; see Wallet → Events.