16 Million Operations
a Second.

What changed when the Bitcoin moved?

Funds leaving a reserve could support customer withdrawals, move into different storage, or head toward exchange activity. Your team needs to establish which.

An exchange may use different wallets for deposits, withdrawals, and reserves. Transfers between those wallets can serve the same business.

Regulatory requirements, jurisdictions, and security procedures can shape those arrangements. The wallet’s role matters when interpreting its activity.

A treasury team needs to understand funds leaving storage. An exchange needs to distinguish movements between its own wallets from payments involving other services.

A security team needs to check unexpected activity against earlier payments and the team’s approval records.

The relevant information stretches across time. A destination may be familiar because of months of prior activity. A transfer may matter because it breaks a long period of inactivity.

Consider funds leaving institutional cold storage for exchange hot wallets. Cold storage is designed for safekeeping; hot wallets support more immediate operational use.

That movement can mark a shift from long-term storage toward potential distribution. A return toward cold storage can show a shift back toward longer-term safekeeping.

Bitcoin reaching exchange wallets may become available for trading or other exchange activity. The transfer alone does not establish a sale.

The earlier balances, the transfer, and the receiving wallet’s role help distinguish those explanations.

The state engine builds that historical foundation. Reports measure the changes, and your team combines the evidence with its own records.

Keep the balances and history each transaction changes.

We archive Bitcoin’s blocks and transaction records. Each new transfer changes the funds available at the addresses involved and adds to their history.

A transaction spends Bitcoin received earlier and creates new spendable amounts, called outputs. The engine updates the balances and histories of the addresses involved.

We call that change a state transition. The State Transition Engine applies those changes in order and builds the resulting record.

State is what is true at a particular point in time. Here, that means the available funds, recorded balances, and connected activity at a defined date.

Bitcoin activity often spans many addresses. A wallet group brings together addresses linked through observed spending, so their balances and activity can be examined together.

Grouping addresses does not establish their legal owner or purpose. Identifying an organization and a wallet’s role requires separate supporting evidence.

One transaction can require many internal operations. The engine resolves earlier funds, records outgoing and incoming funds, updates accumulated facts, and preserves the relevant history.

This is why we describe it as a state database. It maintains a usable account of the system as operations change it.

An operational profile describes how a wallet group receives, holds, and sends Bitcoin.

It measures incoming and outgoing amounts, transfer counts, typical sizes, busy hours, pauses between transfers, and recurring counterparties.

A counterparty is the other wallet group in a transfer. Its share of activity shows where an operation’s relationships concentrate.

Balance records include opening, closing, highest, lowest, and average balances. The average accounts for time between movements, including periods without activity.

Reports also compare the amount moved with available funds and average balances. A wallet can process substantial transfers while retaining a much smaller balance.

Completed-month Operations reports compare the final week, month, and three months with their preceding periods. Monthly flow charts provide a twelve-month view.

These reports focus on selected wallet groups and identify their coverage. Each Operations report holds its month-end address set fixed across comparisons.

That keeps changes in the address list from being mistaken for changes in activity. Earlier comparisons describe the history of that same address set.

They do not reconstruct which addresses or ownership labels were known to a reviewer at every earlier date.

Transaction evidence retains identifiers, amounts, recorded times, and block heights. Readers can inspect the records behind selected movements.

How the history distinguishes a reserve release from funds remaining in storage.

A weekly payment becomes worth examining when its size, timing, or destination changes. Earlier activity makes that departure visible.

A transfer within one organization can mean something different from a payment to another service. Attribution evidence helps establish which wallets are involved.

For wallets your team operates, payment and account records help explain the purpose. For other organizations, the history shows changes your team can follow.

An exchange-associated reserve sent no BTC in October 2025. The following month, it sent roughly 32,909 BTC.

The relationship record adds another part of the picture: where the funds went.

The same history also shows funds staying in place. A treasury-linked wallet received about 26,916 BTC in January 2026.

One record shows reserves becoming active. Another shows received funds remaining in place. That distinction matters when assessing large holders’ storage strategies.

These anonymous examples use published monthly reports, verified on 2026-10-19. Read the evidence and methodology.

Build the history as the chain is processed.

Bitcoin’s public record is available to anyone. It provides transactions, rather than a ready-made history of an institution’s activity.

Building that history requires connecting incoming funds to their later spending, linking related addresses, and updating the resulting balances.

The engine resolves those dependencies and carries the resulting facts forward as it processes the chain.

Reports perform their own analysis using the prepared balances and relationships. They can compare completed periods or examine more recent activity.

A new operational question begins with the underlying history already assembled.

The test was the full history.

The production rebuild completed on 10 September 2026 covered 1.429 billion source transactions.

Its measured peak was nearly 16 million internal state-building operations per second. Each counted operation processes a record while constructing the history.

A Bitcoin transaction can create several such records. This rate measures one phase of database construction, rather than the number of Bitcoin transactions processed.

The engine processed the history in batches. The median was 7.80 million operations per second: the middle of the measured rates.

Across 14 large batches in denser recent history, the average was 3.64 million operations per second.

All three rates come from the same completed rebuild. They describe internal state construction; they are not Bitcoin transaction throughput or report response times.

The 14 denser batches showed 6.1% relative variation. Their rates stayed close to the average, rather than relying on one exceptional result.

The practical result is a reusable history of balances and connected activity. Reports can examine new questions without reconstructing every earlier payment themselves.

Keep completed work usable when processing stops.

Across billions of operations, an engine also needs to preserve what it has completed. A failure must leave a clear account of usable progress.

We built the engine in Rust. It gives us direct control over how much work stays in memory and which work runs in parallel.

That control matters because Bitcoin history varies in density. The engine has to process a changing workload while maintaining the ordering required for correct state.

The engine saves progress at defined boundaries and validates the resulting state. Each boundary identifies the history covered and where processing can resume.

Recovery can continue from verified saved work without rebuilding the entire history.

Give each team a specific change to examine.

TrackBTC delivers this history through Operational Reports. They show how a wallet group normally operates, what changed, and which records support the finding.

Monthly reports profile completed months. Weekly Intelligence compares recent balances and transfers with earlier behavior. Teams can examine recent activity alongside the history that gives it meaning.

A larger share of incoming Bitcoin identifies a concentration worth understanding. Your team’s records establish whether it represents customer deposits, internal transfers, or another service.

Connecting those records gives the team a documented explanation: what changed, what it checked, and how it responded.

CWOS is our first-party decision platform. It has exclusive, direct access to the complete internal intelligence foundation: chain data, historical state, behavioral models, and evidence.

TrackBTC delivers reports to customers. CWOS works directly with the underlying intelligence. Its AI workflows are in development; the engine benchmark does not measure them.

Choose a question we can examine together.

Public alerts show selected findings. Private reports provide deeper history. A pilot starts with an agreed workflow and evaluates the evidence alongside your team.

Bitcoin is a demanding workload for a broader problem.

Many operational systems turn ordered actions into a changing account of the world. They need current state, a reliable history, and a way to recover.

A payment system turns instructions into balances and settlement records. A trading system turns orders and executions into positions and exposure.

An industrial system connects commands and measurements with the equipment’s changing condition. An agent platform needs to connect actions with the state those actions produce.

These are possible applications of the architectural pattern. Bitcoin provides our production workload and the foundation behind TrackBTC.

The next step is navigating how state evolves.

Today’s production foundation builds state forward, keeps dated balances and connected history, and supports verified recovery.

Our architecture direction is a reversible state runtime: a system that retains versions and can move through changes backward or forward.

Saved versions would let applications revisit earlier states. Branching would let an application try a different sequence of actions from the same starting point.

Our separate AI layer is in development. It uses preserved history to construct examples of what was known, what happened, and what followed.

The next article explains how operational history becomes experience for AI, including the importance of keeping future information out of past decisions.