Neuroware · 2016

Everstore Protocol

A complete relational database engine on UTXO blockchains
RoleAuthor
Year2016 (pre-EVM)
OriginDBS Bank Hackathon

The Constraint

In 2016, Bitcoin's OP_RETURN output allowed roughly 38 bytes of usable payload per transaction. Prior to Segregated Witness and Taproot, that was the ceiling for arbitrary data storage on a UTXO chain. Most developers looked at 38 bytes and concluded you couldn't build anything meaningful. The question Everstore asked was different: what if the 38 bytes aren't the database, but the schema?

The Insight

Everstore maps a complete relational database engine onto BIP32 hierarchical deterministic key derivation. Each branch of the key tree has a defined purpose, a node map: Meta (route 1), Schema-Tree (route 2), Index-Tree (route 3), Record-Tree (route 4), Accumulation-Tree (route 5), Public-Tree (route 6). Each route derives a unique blockchain address. A path like 2 | 6032 | 38 means Schema-Tree → datastore #6032 → field #38.

Data lives in the OP_RETURN of transactions sent from those derived addresses. The latest transaction from a node represents the current value. Previous transactions form an immutable audit trail. Reading is a lookup of the most recent output from a known address. Writing is sending a new transaction from that address with updated OP_RETURN data. Anyone with the master public key can independently derive all addresses and read all public data. Only writing requires the private keys.

The result: full CRUD operations, up to 999 million datastores each with 999 million fields, unlimited records, three encryption levels (public, secure, private), indexed lookups, relationships, and pseudo-delete via hashbang commands. All entirely on UTXO blockchains. Smart contract functionality before smart contracts and EVM were even a thing.

Origin

Everstore emerged from a 2015 hackathon organised by DBS Bank in Singapore, where teams needed to store structured data beyond Bitcoin's OP_RETURN limits. The constraint forced a design that's actually superior to "put everything on-chain" approaches: minimal chain footprint, flexible auxiliary storage, and deterministic addressing that doesn't depend on any single storage provider.

Design Philosophy

  • Blockchain-agnostic — works on any UTXO chain with OP_RETURN and BIP32 support (Bitcoin, Dogecoin, etc)
  • Everything on-chain — no auxiliary storage, no IPFS, no external dependencies. The blockchain IS the database
  • HD keys as dual-purpose — derivation paths define both the schema (what the data means) and the address (where to find it). Master public key = read access to all public data
  • Three encryption tiers — public (anyone can read), secure (node key holders), private (master key only) — using AES with key hash as secret
  • Perpetual availability — no server management, no database administration, no single point of failure. Every previous transaction is an immutable audit trail

First Deployment

BlockAuth was Everstore's first public deployment, a decentralised identity protocol that stored identity claims using Everstore's structured on-chain schema. The identity concept was sound but premature; consumer key management in 2016 made the UX impossible. Nine years later, Oviato solved the same problem using passkeys, proving the architecture was right, but the platform needed to catch up.

Result
Smart contract-like database functionality on UTXO chains in 2016, before Ethereum's EVM made programmable blockchains mainstream