Version, changes and what is next
The current version stated plainly, what the 0.1.0 package actually contains, and an honest list of the parts that are not finished.
This page tells you what version you are reading about and what that version can actually do, without rounding anything up. It ends with the parts that are not built yet, listed without dates, because an honest list of gaps is more useful to you than a plan we cannot promise.
Where the project stands today#
Three numbers describe ChainBloom, and they move independently:
| Number | Value | What it describes |
|---|---|---|
| Package | @chainbloom/protocol 0.1.0 | The TypeScript implementation you install and call |
| Ruleset | 1 | The rules a world is created under, recorded in every world |
| Marker version | 1 | The format of the bytes in the itself |
The package is MIT licensed, ESM only, and needs Node 24.19.0. It has two runtime dependencies: bitcoinjs-lib for transaction handling and commander for the CLI.
What 0.1.0 contains#
Eight parts, all present and checked by npm run ci:
| Part | Where it lives | What it does |
|---|---|---|
| Codec | src/codec.ts | Encodes and decodes markers. One legal encoding per payload, both directions checked against the vectors |
| Builders | src/builders.ts | Five functions that build an unsigned for the five actions, at transaction version 2 with every input sequence 0xfffffffd |
| Validator | src/validator.ts | Decides whether a Bitcoin transaction is a ChainBloom event, and returns the issues if it is not |
| State engine | src/state.ts | Rebuilds confirmed worlds, paths and events block by block, with a snapshot before each block and single-block rollback |
| Renderer | src/render.ts | projectBloom and renderWorldSvg. Explicitly non-consensus: two galleries may draw the same world differently and both be right |
| CLI | src/cli.ts | Six commands: marker encode, marker decode, tx parse, psbt build, vectors verify, state replay |
| Vectors | vectors/ | Five valid and six invalid marker vectors, run by npm run check:vectors |
| Fixtures | fixtures/transactions.json | Five complete regtest transactions -- create, bloom, echo, meeting, close -- generated by scripts/generate-fixtures.ts |
The state engine is the part worth calling out, because it is the one that decides what a world is. It holds confirmed state only, requires each block to extend the current tip, restores the pre-block snapshot if anything inside a block fails, and undoes exactly one block at a time on rollbackTip(). Previews of unconfirmed transactions are computed by a separate overlay that never creates lineage, so an unconfirmed step can never become the parent of another.
Together that is enough to build a world, read a world, verify someone else's reading, and recover from a without human judgement anywhere in the loop.
What is not done yet#
Four things, stated without dates and without promises. Each one is a real gap, not a detail.
The package is not published. @chainbloom/protocol returns a 404 on npm. Every installation today is from the repository, and any documentation that shows an npm install line for it is wrong.
There is no public read index. An indexer exists as software, but the public read API is not connected: requesting the ChainBloom status endpoint on the live site returns an error saying the indexer URL is not configured. In practice that means there are no publicly readable worlds today, and nobody can quote a count of worlds, paths, or events. Any page or post that does is inventing numbers.
No wallet knows what a path output is. No wallet has ChainBloom support today, so nothing will currently warn you before an ordinary spend consumes a live path output. Until one does, keeping that output out of ordinary spending is the holder's job -- protect your path explains how, and wallet integration describes what support would involve for wallet authors.
There is no public browsing surface. No public timelines, profiles, bookmarks, watchlists, or notifications exist. Planning documents are not features, and this documentation does not describe them as if they were.
Which number matters to a world#
This is the distinction to keep straight, because only one of the three numbers above is written into the chain in a way that changes meaning.
The package version describes software. It will move often. A new package version can add exports, rename an internal, or make an indexer faster, and none of that touches a single confirmed transaction. 0.1.0 is a 0.x version, so the shape of the library may still change between releases.
The marker version is byte 4 of every marker. A reader that meets an unfamiliar version byte refuses the marker with UNSUPPORTED_VERSION rather than guessing at it.
The ruleset is the number recorded in every world when it is created, and it is the one that decides how that world is read -- forever. Ruleset 1 worlds are read under ruleset 1 rules, whatever the package version says and whatever is added later. New rules would arrive as a new ruleset number that new worlds opt into, never as a new reading of an old one. Governance explains why that is the hardest line in the project.
So the useful answer to "will this still work later" is: a world you create today is defined by ruleset 1 and the test vectors that pin its bytes, both of which are published, MIT licensed, and reproducible by anyone with a copy of the chain.
How to check what is running right now#
This page is written by hand and dated at the top. The status page is the one to trust for what is switched on at the moment you are reading, including whether the read index has been connected. When the two disagree, the status page is newer.