Developer Tools
A transaction fee may be tiny, but preparing the input that pays it can still create work for a wallet.
The wallet may need to select an available output, reserve it so another transaction does not use the same funds, construct the transaction, sign the input and update its storage. When many transactions are being created at once, those repeated operations can become part of the processing path even when the actual fee is only a few satoshis.
FuelKeeper is a new public BSV Blockchain project designed around a different approach: prepare a supply of small fee-paying outputs in advance, then let wallets reserve them when needed.
The project describes these outputs as fuel.
Instead of making the wallet prepare a fresh fee input for every transaction, FuelKeeper maintains a pool of small, fixed-denomination outputs whose unlocking data has already been prepared. A client can reserve one of those outputs and attach it as an additional input to its own transaction.
The important distinction is not that transactions no longer require signing.
Rather, the fee input itself does not need a signing service at the moment it is requested.
Preparing the expensive part earlier
FuelKeeper’s default design uses hash-puzzle outputs.
When one of these fuel outputs is created, the information needed to unlock it can also be prepared in advance. The resulting unlocking data can later be supplied with the reserved output rather than generated by a private-key signing service for each transaction.
That moves part of the work away from the transaction’s immediate processing path.
A wallet or application still constructs its own transaction and handles whatever signatures its own inputs require. FuelKeeper is addressing the narrower question of how the transaction receives enough additional value to pay its network fee without requiring another live signing step for that fee input.
The project’s September 29 design document describes this as a standalone service intended to turn fee funding into a fast reservation API.
The idea builds on earlier wallet-level fuel pools
The underlying idea did not begin with the standalone FuelKeeper service.
Its design document notes that earlier BSV Blockchain Go tooling already used denominated fuel baskets inside wallets. Preparing suitable fee outputs ahead of time reduced repeated coin-selection work and contention between transactions.
But those outputs were still ordinary wallet-owned P2PKH outputs.
The wallet holding them had to sign them when they were spent, and the fuel pool remained tied to that wallet’s own storage and transaction-processing path.
FuelKeeper moves the idea outward.
Instead of one wallet maintaining its own internal fuel basket, the new architecture is designed as a separate service that can maintain a much larger inventory, divide it among instances and hand reserved outputs to clients on demand.
That changes the problem from wallet coin selection into shared fee-input infrastructure.
Reserving an output safely is the harder part
Creating thousands of small outputs is relatively straightforward. Making sure the same output is never given to two active transactions is more difficult.
FuelKeeper therefore treats reservation state as a central correctness problem.
Its design assigns each fuel output a state such as available, reserved, quarantined or spent. State changes use compare-and-set operations so that competing service instances cannot both successfully claim the same available output.
The project defines one central guarantee: an individual fuel output should never be handed to two live reservations.
Durability matters here as well. If a database tells a client that an output has been reserved and then forgets that reservation after a failure, another client could potentially receive the same output.
That is why the current documentation places specific requirements on storage behavior.
PostgreSQL is the currently documented multi-process backend. SQLite and the in-memory backend are limited to single-process operation, while additional storage systems including PebbleDB, MongoDB and Aerospike remain part of later implementation work.
Uncertain outputs are quarantined rather than immediately recycled
FuelKeeper also has to deal with transactions whose status is not yet clear.
Suppose a client reserves a fuel output and attempts to spend it, but FuelKeeper cannot yet determine whether that transaction was accepted, rejected or simply delayed.
Immediately putting the output back into the available pool could create a double-spend conflict.
The design instead provides a quarantine state.
Expired or uncertain reservations can remain outside the available pool while an oracle checks whether the output has actually been spent. Only once its status is sufficiently clear can the output return to the pool or be marked as spent.
This is another example of why fee infrastructure involves more than generating tiny transaction outputs. At scale, the service has to maintain reliable knowledge about which outputs are available, temporarily committed or no longer usable.
Fuel can be distributed across service instances
The architecture is also designed around horizontal scaling.
Fuel outputs are grouped into shards, with individual FuelKeeper instances leasing responsibility for particular shards. If one instance fails, another can eventually adopt its shards after the lease expires.
The actual reservation still depends on persistent compare-and-set state rather than trusting the temporary lease itself for correctness.
That distinction matters because a distributed service can briefly contain overlapping views of ownership during failures or handovers. The database state remains the final mechanism preventing the same output from being successfully reserved twice.
FuelKeeper also batches reservation operations where appropriate, reducing the number of durable commits needed when many requests arrive together.
BEEF travels with the fee infrastructure
A client needs more than an outpoint and an unlocking script if it is going to use the fuel output as a transaction input.
It also needs evidence for the transaction from which that output originated.
FuelKeeper therefore organizes fuel into shards associated with their source transactions and provides references through which the client can retrieve BEEF transaction evidence.
Once a fuel transaction has been mined, that evidence can include its Merkle-path information. The consuming wallet can then use the fuel output as a caller-provided input while retaining the transaction evidence needed by SPV-oriented wallet infrastructure.
This makes FuelKeeper more than a database containing small balances. It is intended to provide both the spendable input and the evidence associated with that input.
An HTTP service and Go client are already implemented
The repository currently describes Plan 3 as complete.
That stage includes an HTTP API, a Go client and a serve command, on top of the earlier pool core. The pool implementation includes hash-puzzle fuel, sharded instance ownership, batched reservations and background jobs for tasks such as reaping expired reservations, watching proofs and replenishing the pool.
The development instructions can already start a server and request reserved fuel through the API.
There is an important maturity boundary, however.
The documented development configuration runs on an in-memory store with a mocked oracle and mocked treasury. The repository therefore shows a substantial working implementation, but that should not yet be read as evidence of a finished production service operating under real-world load.
FuelKeeper is already appearing in wallet throughput tooling
There is also evidence that the concept is being connected to the broader wallet stack.
The current Go Wallet Toolbox includes a throughput-mode demo dashboard in which an operator wallet works alongside FuelKeeper. The demo can use FuelKeeper to turn wallet funds into a reserve and then into fixed-denomination fuel outputs before starting a stream of transactions.
A separate Docker live-test configuration is sized around a 1,000-transactions-per-second target and includes a FuelKeeper warm-up stage before the load generator begins.
Those documents show that FuelKeeper is being designed with high-rate wallet processing in mind.
They do not, by themselves, establish a measured 1,000 TPS FuelKeeper result.
The dashboard defaults to a much lower transaction rate, and the documentation itself describes the larger figure as a target or live-test configuration. Published benchmark results and independently reproducible performance evidence would be a separate milestone.
Moving fee preparation out of the transaction path
FuelKeeper is ultimately addressing a small operation that becomes more significant when repeated at high volume.
A fee-paying input has to come from somewhere.
If each transaction causes a wallet to search for a suitable output, reserve it, generate its unlocking signature and commit all of that state before proceeding, fee funding remains part of the transaction’s immediate workload.
FuelKeeper attempts to separate those stages.
Funds can be divided into standardized fee inputs beforehand. Their unlocking data can be prepared beforehand. Their transaction evidence can be retained beforehand. The service can then concentrate on safely assigning an already prepared input when a wallet requests one.
Whether that architecture produces the intended gains under sustained production load still needs to be demonstrated.
But the implementation makes the underlying direction concrete: transaction-fee funding is being treated as infrastructure that can be prepared, pooled and managed separately from the wallet action that eventually consumes it.
Developer context
Dylan (@galt-tr) is an active maintainer across several BSV Blockchain Go infrastructure projects, including:
spv-walletgo-wallet-toolbox- Arcade
go-p2pgo-wire- Teranode Operator
He has also contributed directly to Teranode development.
Source Links
FuelKeeper Design — September 29, 2026
Go Wallet Toolbox — Throughput Dashboard
BSV TIMES – Under the Surface
Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.
Update — October 1, 2026
Leave a comment