Data Infrastructure / Developer Tools

Academic researchers at the University of California, Irvine have tested a decentralized database architecture on BSV Blockchain mainnet that uses individual transaction outputs not merely to timestamp data, but to represent and update the data objects themselves.

SpendableStore: A UTXO-Based Decentralized Data Store, by Yinan Zhou and Faisal Nawab, appeared in the proceedings of the 2026 IEEE International Conference on Data Engineering (ICDE). An arXiv version was posted on July 2, 2026.

The research is therefore not a newly released October development. Its renewed visibility is nevertheless notable for BSV Blockchain because the researchers built and experimentally evaluated an implemented database architecture on the production network rather than referring to BSV Blockchain only as a theoretical option.

At the center of the design is what the authors call a Spendable Data Object, or SDO: a data object whose changing state is represented through a sequence of blockchain transaction outputs.

Turning a UTXO Into a Data Object

In a conventional database, updating a record generally changes the value stored at a particular location.

SpendableStore approaches an update differently.

Each version of a data object is represented by a transaction output. To change that object, a new transaction spends the current output and creates a successor containing the updated state.

The previous version therefore remains part of the object’s blockchain history, while the newest unspent output represents its current state.

The researchers use key-value pairs as their primary example. Each object contains a unique identifier, key, value, owner public key and writer public key. The owner can modify the object’s fields and assign or revoke writing authority, while a designated writer can update the value within the limits enforced by the locking script.

This gives the system a way to attach ownership and write permissions directly to an individual data object, rather than relying exclusively on permissions maintained by a conventional database administrator.

SpendableStore supports the familiar create, read, update and delete model, although deletion cannot erase historical blockchain records. Instead, the paper uses forms of tombstone deletion that make an object inactive or permanently prevent further updates.

Multiple objects can also be updated atomically within the same transaction. Because a UTXO transaction can contain several inputs and outputs, a transaction involving several Spendable Data Objects either validates as a whole or fails as a whole.

That gives the researchers a way to explore database transactions using the native spending relationships of a UTXO system.

A Hybrid Database Rather Than an Entire Database Inside the Blockchain

SpendableStore should not be understood as placing every conventional database operation directly on-chain.

It is a hybrid on-chain/off-chain architecture.

BSV Blockchain provides the persistent data states, transaction history, access-control enforcement and common record against which changes can be verified.

Above that layer sit independently operated SpendableStore instances. These maintain local caches and indexes, provide higher-level database query interfaces, construct transactions and manage transaction processing.

A database application can therefore offer familiar operations such as listing, inserting, retrieving, updating and deleting records without requiring every read to be expressed as a new blockchain transaction.

The design also allows multiple independent SpendableStore instances to work with overlapping data. They do not have to trust one another to determine the authoritative state because the blockchain provides the common transaction history underneath them.

Data owners retain a more direct relationship with their information as well. The architecture allows an owner to revoke or reassign a SpendableStore instance’s writing permission and, where appropriate, interact with the underlying blockchain independently of that database instance.

The researchers describe data owners as using SPV verification to check blockchain and SpendableStore responses rather than treating the off-chain database operator as the final source of truth.

Database History Becomes Transaction History

This creates a different relationship between database state and provenance.

If an object changes from one value to another, the earlier state is not merely replaced in an administrator-controlled table. The new state consumes the preceding output, creating a transaction-linked lineage of object versions.

A verifier can follow that history backward.

The authors present this as useful for applications in which different organizations need to establish what happened to shared data without depending entirely on one administrator’s records.

Their paper uses a supply-chain example in which objects representing items can change custody, receive quality-control information and move between independently operated database instances while retaining a common verifiable history.

That is closer to data-management infrastructure than simple blockchain timestamping.

The blockchain is not merely recording that a database existed at a particular moment. It participates in defining which version of a data object is current, which previous states led to it and which keys are permitted to change it.

Future Now Snapshot Isolation

Supporting individual records is only part of the database problem.

Real applications also perform concurrent operations, sometimes reading and updating several objects while other operations are occurring at the same time.

SpendableStore therefore introduces a transaction-isolation model called Future Now Snapshot Isolation, or FNSI.

Traditional database isolation attempts to ensure that concurrent transactions do not produce inconsistent results. Applying the strongest forms of those guarantees directly to a decentralized blockchain environment can create substantial computation and communication overhead.

FNSI instead defines several snapshot levels that trade different degrees of immediacy, concurrency and consistency.

The researchers evaluate these levels under read-heavy and write-heavy workloads and find that different approaches are appropriate for different transaction patterns. The important point is not that SpendableStore reproduces every guarantee of a centralized relational database.

It is that the researchers are treating transaction isolation itself as part of the UTXO database-design problem, rather than limiting the system to independent data writes.

Why the Researchers Used BSV Blockchain Mainnet

The experimental setup is particularly relevant to BSV TIMES.

SpendableStore was tested using BSV Blockchain mainnet.

For comparison, the researchers used the Ethereum Holesky testnet, Arbitrum Sepolia and Cardano Preprod.

The paper gives two practical reasons for that selection. Running the corresponding experiments on Ethereum mainnet and BTC was constrained by cost, while the authors also wanted to experiment with large data objects and identified BSV Blockchain’s lack of a fixed block-size limit as an advantage over BTC for that purpose.

The authors explicitly acknowledge that testnet and mainnet environments can produce different results.

They also published four WhatsOnChain addresses associated with their experiments, providing a public path to the mainnet activity generated during the research.

That makes the BSV Blockchain component more than an architectural assumption. The researchers implemented SpendableStore’s scripts and off-chain database components and used the production network during their experimental evaluation.

What the Reported 16× Result Actually Means

One result from the paper deserves attention, but also careful qualification.

In a benchmark consisting of 1,000 conflict-free update operations, the researchers report that SpendableStore achieved around 16 times the throughput of the Ethereum-based designs they evaluated and approximately four times the throughput of their Cardano-based implementation.

Those figures should not be interpreted as a general claim that BSV Blockchain itself is 16 times faster than Ethereum or four times faster than Cardano.

The comparison concerns particular decentralized-database implementations, running on different networks and under the paper’s experimental configuration.

The environments were also not identical: SpendableStore used BSV Blockchain mainnet, while the Ethereum, Arbitrum and Cardano implementations used test networks.

Most importantly, the experiment counted an operation as complete when the researchers received the network’s validation response. It did not wait for the transaction to be included in a block.

The result is therefore best reported as a finding about the evaluated database designs and their transaction-processing paths, not as a universal blockchain throughput comparison.

The Experiments Also Reveal a Bottleneck

Later experiments provide another useful boundary around the performance results.

For a read-heavy transactional workload, increasing the number of SpendableStore transaction managers improved how quickly transactions could be constructed locally, but blockchain validation throughput did not continue increasing at the same rate.

With four transaction managers, the researchers observed validation throughput peaking at around 90 transactions per second in that particular experiment. Adding more transaction managers did not increase validation throughput and could make it slightly worse because the validation nodes became the bottleneck.

The write-heavy experiments showed a similar limitation: local construction could scale while network validation became the constraining factor.

This is an important part of the paper’s contribution because it identifies where the current implementation stops scaling rather than presenting the architecture as unconstrained.

The research therefore provides both a promising comparison and evidence of where additional systems work would be required.

More Than Blockchain Storage

The broader significance of SpendableStore is that it explores a different question from simply asking whether arbitrary information can be written to a public blockchain.

The researchers ask whether UTXOs can become active database objects with ownership, access control, version history and transactional relationships.

That changes the role of the blockchain.

An off-chain database instance can still provide indexing, caching and convenient queries, but it does not have exclusive control over the underlying data history. Owners can verify the object states against blockchain evidence, and independent database instances can refer to the same underlying state without requiring one shared administrator.

The architecture remains hybrid, and local indexing remains important for practical database use. SpendableStore is not evidence that conventional database infrastructure can simply be discarded.

Its isolation model also makes explicit tradeoffs, while its experiments show that blockchain validation can become a processing bottleneck.

Those limitations are part of the research rather than reasons to overlook it.

A Concrete Data-Infrastructure Experiment on Mainnet

SpendableStore is particularly relevant to BSV Blockchain’s data-infrastructure discussion because the paper moves beyond a common pattern in which blockchain is used only to anchor a hash or timestamp an external database record.

Here, the UTXO architecture participates directly in the lifecycle of the data object.

Creating data creates an output.

Updating the object spends its current state and produces the next one.

Ownership and writing authority are enforced through transaction rules.

Several objects can participate in one atomic update.

The historical versions remain verifiable, while off-chain database instances provide the indexing and query capabilities needed by applications.

The work remains academic research rather than a deployed general-purpose database product, and its benchmark results should remain attached to the conditions under which they were obtained.

But it provides something especially useful for evaluating BSV Blockchain as data infrastructure: an implemented database-systems experiment conducted on mainnet, with the UTXO model itself forming part of the database architecture rather than merely serving as an external timestamping layer.

Developer Context

Yinan Zhou and Faisal Nawab are researchers at the University of California, Irvine.

Zhou is listed with UCI’s EdgeLab, which researches distributed data-management systems spanning cloud, edge and blockchain environments.

Nawab is an Associate Professor of Computer Science at UC Irvine and leads EdgeLab. His broader research focuses on distributed data management, edge-cloud systems and blockchain-based approaches to data infrastructure.

Related work from Nawab and the UCI research group includes RollStore, which examines hybrid on-chain/off-chain indexing for blockchain applications, and WedgeChain, an ICDE-published edge-cloud storage system designed around independently verifiable trust.

SpendableStore continues that broader research direction while applying it specifically to UTXO-based decentralized data management.

Source Links

SpendableStore — Full Paper on arXiv

IEEE ICDE 2026 — DOI 10.1109/ICDE65706.2026.00153

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.

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 24, 2026