The pages so far covered blocks: how they are made, how they are ordered, how they are paid for. Blocks are the container. This section covers the cargo.
What a transaction is
A transaction is a swap, not an edit. It names coins that already exist, proves the spender is allowed to move them, and declares the coins that replace them. The old coins stop existing at that moment. The new ones start.
Nothing anywhere is decremented. There is no running balance to update, because the network never stored one - the reasoning behind that is the UTXO model, and it is the next page.
Three parts and one absence. Inputs say what is being spent, outputs say what is being made, and the fee is the 0.0003 KAS that appears on neither side.
Inputs: what is being spent
Each input points at exactly one coin and proves the right to move it.
- The outpoint names the coin. It is a pair - the id of the transaction that created the coin, and which of that transaction’s outputs it was. Together they identify one coin out of the whole UTXO set, unambiguously and forever.
- The unlocking script is the proof. For an ordinary payment that is a Schnorr signature. For a pay-to-script-hash coin it also carries the redeem script the coin was locked to.
- An input spends its coin in full. There is no partial spend anywhere in the design, which is why paying a small amount out of a large coin always produces change.
Outputs: what is being made
Each output is a new coin, and a coin is an amount plus the rule for spending it.
- The value is an integer in sompi. The protocol has no fractional amounts; KAS is a display convention applied at the edge.
- The locking script decides who can spend it next. It is derived from the recipient’s address, and it is the only thing standing between the coin and anyone who wants it. Which lock types are actually in use across the network is charted at output script classes.
- Since Toccata an output can also carry a covenant binding. That is how the base layer enforces rules about what the next transaction may do with the coin. See Programmability.
What else a transaction carries
A short list of fields wraps the two sides:
- A version. Zero is the original layout and still valid for any ordinary payment. One arrived with Toccata and is what covenant bindings and priced script execution need.
- A lock time, which sets the earliest point the transaction may be included - either a minimum DAA score or a wall-clock timestamp.
- A payload, an arbitrary data field enabled for ordinary transactions at Crescendo.
And note what is not in that list. No fee field, no sender field, no balance field. The fee is the gap between the two sides, the sender is whoever satisfied the locks, and the balance was never stored to begin with. The full object model - every field, and the coin record a node has to supply alongside it - is the Transaction Model page.
The transaction id
A transaction’s id is a hash over it with the signature scripts and payload left out. Its hash covers everything.
That distinction does real work. Because signatures are excluded, the id is fixed before anyone signs - so several parties can agree on a transaction, pass it around, and each add a signature without the thing they agreed on changing underneath them. That is what makes the partially signed transaction workflows possible.
What a signature covers
The default signing mode commits to every input and every output in the transaction. Change one byte of it and the signature is void.
That is the guarantee behind the whole structure: a signed transaction is not a request to move money, it is a completed instruction that only that key could have produced, and that nobody - including the miner carrying it - can alter in transit.
The rest of this section
- UTXO Model - why the ledger is a set of coins rather than a table of balances, and why that fits a blockDAG.
- Transaction Model - the objects and fields a transaction is built from, and the coin record a node has to supply to check it.
- Fees & Mass - what a transaction costs, and why it is priced by mass instead of by size.
- The Mempool - where transactions wait, and how miners choose among them.
- Throughput - how much the network can actually carry, and what the ceiling is made of.