Technical reference
Everything ChainBloom enforces, read from the source: marker bytes, transaction shapes, validation codes, state, and reorganization handling.
Every number, field name, and error code in this section was read from the source of @chainbloom/protocol version 0.1.0. You can build a transaction, check one, or index the chain from these pages without guessing at a single byte.
Who this is for#
Application and wallet authors need the transaction shapes, the 1000-satoshi rule, and the short list of things worth showing someone before they sign.
Indexer authors and operators need the validation rules, the state model, and what to do when Bitcoin replaces a block. Any that follows these pages rebuilds the same worlds as every other one. That is the point of writing them down.
Anyone checking a claim needs the layout and the published vectors. You do not have to trust this site: the generated tables are built from the package itself.
The sixteen pages#
Protocol architecture The design in one page, plus the marker byte layout and the network table.
Transaction lifecycle The exact input and output positions for all five operations.
Data structures Every field of WorldState, LaneState, EventState and the rest.
Validation rules Every check the validator runs, with the issue code it emits.
Reorganizations How a view stays correct when Bitcoin replaces its newest blocks.
Indexer requirements What a service must do to serve the same history as everyone else.
SDK The TypeScript package: codec, validator, builders, and the state engine.
CLI The chainbloom commands and the JSON they read and write.
Wallet integration What a wallet should do so a live path is never spent by accident.
Explorer integration What to show once a transaction turns out to be a ChainBloom event.
Test vectors The published markers a parser must accept and the ones it must reject.
Errors Every error and issue code in one index, with the file that raises it.
Security model What the protocol protects, what it cannot, and where the sharp edges are.
Reliability Failure modes, and what a service should do about each one.
Governance How the ruleset may change, and what a change may never do.
How to read a page here#
Each page carries a verified stamp naming the package version it was read from. Where a page states a limit it writes a token, and the build substitutes the value the code enforces. So if a rule here is wrong, the code is wrong too: report it against the repository, not against the page.