Bitcrumb Whitepaper · Version 1.0 · 2026 · Crumby Labs
Introduction
Most software still answers the question of who you are and why it should trust you through a password database, an OAuth provider, or an API key sitting in a config file. Every one of those is a single party that has to be trusted, kept online, and kept honest. Bitcrumb answers that question differently, by letting identity, trust, and a history of good behavior live with the participants themselves instead of with a company in the middle.
A Bitcrumb node is a self-hostable service that anyone can run. A cluster of these nodes reaches agreement, through a real cryptographic voting protocol, on the facts that matter: that an identity was created honestly, that a session proof is genuine, that a token transfer is backed by an actual balance. Wallets and client applications hold their own signing keys and never hand them to a server.
System Architecture
Bitcrumb runs as a cluster of identical nodes joined together over Apache Ignite, an in-memory distributed database that also handles cluster membership. Every node runs the same REST API, the same consensus logic, and the same ledger. There is no separate leader process and no dedicated database server sitting alongside it.
A client such as a wallet or a browser session connects to any node in the cluster. That node validates the request, proposes any state change to its peers for a vote, and returns a result once the cluster agrees. If a node goes down mid-round, the round still completes as long as enough of the remaining nodes can reach a majority.
Consensus and the Ledger
Every meaningful write in Bitcrumb, a new identity, a token transfer, a session proof, has to pass a consensus round before it is committed. Nodes sign their votes with Ed25519 keys generated locally and never transmitted anywhere, and every peer independently re-derives the proposal hash before voting on it, closing off payload substitution as an attack.
Whether a round passes or fails, the outcome is sealed into a certificate before the function that started it ever returns. Each certificate carries the position it occupies in the chain and the hash of the certificate before it, so the full history forms a hash-linked sequence the same way a blockchain does. Altering an earlier entry breaks every hash that comes after it, visibly, on every node holding a copy of the chain.
Identity and Sessions
A wallet creates its own signing keypair locally and never sends the private half anywhere. Once an identity is registered, it can establish a session proof, an object that proves ongoing presence without asking Bitcrumb to sign off on every single action. From there the wallet mints its own short-lived tokens against that proof, entirely on its own, and a service can validate those tokens locally as long as it can reach the proof they were minted from.
Sessions can be scoped narrowly to a single wallet-to-wallet handshake or broadly to a whole service made up of many backend nodes, and they can be revoked at any time by whoever owns the identity behind them.
Selective Disclosure
Bitcrumb lets a client register a schema describing a shape of data, then submit an actual object matching that schema to be tokenized. Tokenizing hashes each field individually against a shared salt, so a specific field value can be proven to belong to a specific, previously committed record without revealing every field to every verifier.
A verifier handed one disclosed field and its hash can confirm it belongs to the package. Nobody who only has the package's overall reference can see any of the underlying values.
The CRUMB Token
CRUMB is easy to misread as a currency, and Bitcrumb deliberately pulls away from that framing. It is better understood as a record of an identity's history on the network, a signal that a given identifier has actually done things here over time rather than having just appeared.
CRUMB is mined by real events and activity across the network rather than issued on a schedule or handed out centrally. It is tradeable, and its value is whatever the market attaches to it, not something Bitcrumb sets.
Aggregate Pools
An aggregate pool is a configurable, sharded state machine for situations where multiple independent parties need to contribute to a shared outcome without a central coordinator making the final call. A pool is split into lanes at creation time, each processed independently, so throughput scales with lane count and no two operations in different lanes can ever block each other.
Different pools can be configured to tally votes, sum a running total, or require a set of approvals before closing, supporting patterns like voting, bill-splitting, and escrow-style approval on top of the same primitive.
Where Things Stand
The identity, consensus, and session proof layers described here are real, running, and tested today. Bitcrumb is still young software, and it is being built in the open about that: validator reputation weighting, deeper selective disclosure, and expanded pool tooling are active work, not finished features.
Bitcrumb's bet is that identity and trust work better as something participants carry and prove themselves than as something a central service issues and revokes. This whitepaper describes where that bet stands today, not where it will eventually land.
Want to see it running?
Explore Bitcrumb