Transactions
A transaction is a signed instruction to the chain: pay someone, issue a token, place an order, link an address to a group. ZooBC has no virtual machine for user code. Every feature is a built-in transaction type with fixed rules that every node applies in exactly the same way, so a wallet knows, before it signs, everything a transaction can do and what its minimum fee will be.
Built-in types
From version 0.5.8 ZooBC defines 73 transaction type numbers, type 0 included, in twelve families.
A type number is a group plus 256 times a subtype, so the numbering is sparse: 2 is NodeRegistration, and 258 (group 2, subtype 1) is its update. A number the chain does not define is refused, and every defined type is accepted from block 1.
Two numbers are special. Type 0, Empty, moves nothing: it exists to carry a message, it must still pay a fee above zero, and it does not raise the sender's nonce, the per-sender counter the chain keeps. Type 53, CancelLongevity, is retired: every chain refuses it, and CloseLongevity (309) is used instead.
The life of a transaction
- A wallet builds the envelope, the same layout for every type, and signs it for one chain.
- It submits the signed bytes with
POST /api/v1/transactions. HTTP 202 means the node accepted the transaction into its pool, not that it is in a block. Resending the same bytes is safe: the copy is marked as a duplicate. - Nodes pass the transaction on, and a block producer includes it. A block holds at most 2,000 transactions and 524,288 bytes of payload, and at most one transaction from each account (see one transaction per account per block, and batches).
GET /api/v1/transactions/<hash>/statusreports its progress: staging, mempool (with its position), confirmed (with the block height), rejected (with the reason) or not_found.
A transaction that no block includes within its window expires (see expiry and timestamps).
When the state changes in between
Between signing and inclusion in a block, other transactions can change what a transaction depends on: an escrow is settled, an offer is taken by someone else, a token expires. Such a transaction becomes a paid no-op: it is included in a block, it pays its fee, and it changes nothing else. The block stays valid on every node, so nobody can stall the chain by sending transactions that are about to go stale.
A block is invalid only for faults that every node sees the same way, such as a bad signature, a fee below the floor (see fees) or a payment larger than the sender's balance.
Articles in this category
- The transaction envelope: the fields every transaction carries, and its fee.
- Signing a transaction: the chain-bound digest and the key types that can sign.
- Expiry and timestamps: how long a signed transaction stays valid.
- One transaction per account per block, and batches: one transaction per account per block, and batches.
- Escrow: payments held by the chain until an approver decides.
- Multisignature: accounts that spend only with several signatures.
- Liquid payments (streams): money that streams to a recipient over minutes.
- Scheduled transfers: a series of payments signed once.
- Triggers and attestations: money released at a height or after an event.
- Account groups: many addresses that share one account.
See also
Articles in this topic
- Account groups
How a ZooBC account group lets many addresses, of any key type, share one balance, with a controller who decides what each member may spend. - Escrow
How a ZooBC payment can be held by the chain until a named approver decides, its four possible endings, what it costs, and escrow requests issued by the payee. - Expiry and timestamps
Why every ZooBC transaction carries its own time, how long it stays valid (an hour by default, at most a day), and how blocks and settlements use time. - Liquid payments (streams)
How a ZooBC liquid payment streams ZBC or a token to a recipient over a number of minutes, and how either side can stop it with a fair split. - Multisignature
How a ZooBC multisignature account spends only when a set number of its participants have signed, even when they use keys of different chains. - One transaction per account per block, and batches
Why a ZooBC block may carry only one transaction from each account, and how a batch lets one account make several payments or transfers in a single transaction. - Scheduled transfers
How one ZooBC ScheduledTransfer sets up a series of payments in ZBC or a token, locked up front or pulled when due, and how it can be cancelled or redirected. - Signing a transaction
What a ZooBC signature covers, how a transaction's hash and id are derived, which key types can sign, and how foreign wallets sign transactions of their own chain. - The transaction envelope
The fields every ZooBC transaction carries, in order, what each one holds and what is deliberately missing, such as a gas limit or a chain id. - Triggers and attestations
How a ZooBC trigger locks ZBC until a future block height or an event in the outside world, and how registered nodes resolve events by attestation.