Accounts and blocks

Each BURST account has its own ordered chain of signed blocks. A block names its predecessor and describes one operation. Different accounts can advance independently, but a receive depends on the payment it claims, and shared rules such as verification and governance require agreement across the network.

The latest block hash is the account's head, also called its frontier. Two blocks with the same predecessor compete for the same account position. Representatives vote to resolve that conflict.

Opening an account

Generating keys creates an address locally. It does not create a ledger block. The first block is an Open with a zero predecessor. It can claim a pending payment or open the chain with no TRST. Opening and verification are separate: receiving money does not grant BRN accrual or verified voting rights.

An account may already have verification state before its first signed block. Opening its chain preserves that state.

Operations

These are the current BlockType names. Their presence in the format does not mean every operation is enabled on every network.

Block type	Purpose
Open	Start an account chain, optionally claiming a pending payment.
Burn	Spend BRN to create an equal amount of pending TRST for a recipient.
Send	Transfer existing TRST into a pending payment.
Receive	Claim a payment or acknowledge a return credit.
RejectReceive	Refuse a pending payment and create a return receipt for its sender.
Merge	Combine holdings without renewing their age.
ChangeRepresentative	Choose the representative receiving the account's consensus weight.
ChangeSigner	Replace the account's active signing-device grant.
Endorse	Support another account's verification application.
VerifierOptIn, VerifierOptOut	Volunteer for or leave the verifier pool. Opt-in alone does not establish selection eligibility.
VerificationVote	Record a selected verifier's judgment.
Challenge	Challenge an account, or name a prior outcome for an appeal where enabled.
GovernanceProposal	Submit a proposed parameter, constitution or representative-status change.
GovernanceEndorse	Burn BRN to support a proposal entering voting.
GovernanceVote	Vote on a proposal.
GovernanceWithdraw	Withdraw the signer's proposal during its proposal phase.
Delegate, RevokeDelegation	Update governance voting delegation. These do not select a consensus representative.
GovernanceVeto	Exercise the creator's temporary bootstrap veto before activation.
Epoch	Add a bootstrap-authorized marker to an existing account chain. It installs no software.
GovernanceActivation	Retained encoding; current nodes reject account-authored activation blocks. Activation occurs through a certified boundary.

For payment rules, see sending and receiving. Verification, governance and bootstrap operations have their own eligibility, stake, timing and availability requirements.

Fields to understand before integrating

Use the wallet library's builders rather than guessing fields from another block. The current block version is 9; params_hash RPC reports the node's version and current signing context.

Field	Meaning
account, previous	Account and predecessor hash; previous is zero for Open.
representative	The account's selected consensus representative.
brn_balance	Serialized name for cumulative BRN committed by burns and stakes. It is not available BRN. Rust calls this field brn_spent.
trst_balance	Transferable TRST balance after this block, not the amount of the operation.
link	Operation-specific reference: recipient public key for a payment, source block for a receive, proposal hash for a governance vote.
origin, transaction, target_head	Operation-specific provenance, vote or dependency fields. They are not interchangeable transaction IDs.
merge_sources	Holding IDs to consume in a merge, up to 256. An empty merge list requests deterministic selection.
release_sources	Sorted, distinct vote-set hashes acknowledging stake releases, up to 1,024.
signing_grant	Active signing-device grant before this operation; zero means unenrolled.
payment_epoch	The agreed economic boundary used when preparing the operation; initially the configured genesis hash.
params_hash	Commitment to the parameter values used by the operation.
timestamp, work, signature, hash	Signed timing, anti-spam work and authentication fields. Use the library's canonical hash and signing functions.
delegation_payload	Scoped governance-key operation or secondary ballot, where enabled. It does not replace the account signature or authorize spending.

Blocks do not contain the whole account state. Holdings, provenance, pending receipts, eligibility and shared protocol state are stored separately. Saving only account heads is insufficient to validate or restore a node.

Submit and confirm

A valid signature proves authorization, not sufficient balance or confirmation. The node also checks dependencies, work, the current protocol context and the operation's rules. A submission may wait for missing dependencies or compete with another block at the same position.

Keep the signed bytes and hash, submit with process, then query confirmation. If the request times out, check that hash before constructing another payment. See wallet recovery.

Source: block format and validation, block processing, wallet signing.