In February 2016, I published an opinion piece arguing that the Bitcoin community was squandering the network's potential by treating it exclusively as a financial ledger. The block size wars were consuming all the oxygen (Core vs. Classic vs. Unlimited) while the more interesting question went unasked: what else can an immutable, distributed event store actually do?
That same month, I shipped the answer. Everstore was a protocol that delivered smart-contract-like database functionality on UTXO chains (fields, indexes, relationships) using nothing but 38 bytes of OP_RETURN and hierarchical deterministic key derivation. This was before Ethereum's EVM had made programmable blockchains mainstream. Before Segregated Witness. Before Taproot. I was building structured applications on Bitcoin when the consensus opinion was that Bitcoin couldn't do anything beyond payments.
Nine years and three more protocols later, I can articulate something I was doing instinctively back then: design for constraints, borrow existing trust, keep the chain dumb, and accept that sometimes you're just early.
Everstore (2016): Build on Hostile Constraints
Everstore emerged from a 2015 hackathon organised by DBS Bank in Singapore. Teams needed to store structured data on Bitcoin, and Bitcoin's OP_RETURN gave them roughly 38 bytes after protocol overhead. Most people looked at that ceiling and concluded you couldn't build anything useful. I asked a different question: what if the 38 bytes aren't the database, but the schema?
Everstore maps a complete relational database engine onto BIP32 key derivation. Each branch of the key tree has a defined role, a node map: Meta, Schema-Tree, Index-Tree, Record-Tree, Accumulation-Tree, Public-Tree. Each route derives a unique blockchain address. Data lives in the OP_RETURN of transactions sent from those addresses. The latest transaction equals current value, previous transactions form an immutable audit trail.
Route: 2 | 6032 | 38
↳ Schema-Tree → datastore #6032 → field #38
↳ derives unique blockchain address
↳ OP_RETURN = current value
↳ tx history = immutable audit trailAnyone with the master public key can derive all addresses and read all public data. Only writing requires private keys.
The result: full CRUD operations, 999 million datastores, 999 million fields per store, unlimited records, three encryption tiers, indexed lookups, relationships, and pseudo-delete via hashbang commands. All entirely on UTXO blockchains. All data on-chain. No external storage. No auxiliary servers. The blockchain is the database. Blockchain-agnostic, tested on Bitcoin and Dogecoin, works on anything with OP_RETURN and BIP32.
The political context matters. I'd just published Distributed Politics for Myopic Protocols, arguing that if Bitcoin's protocol must be limited in scope, it should at least be generic enough to accommodate diverse applications. Everstore was the engineering answer to a governance question: you don't need the protocol to change. You need to be clever about what you do with what already exists.
The lesson: constraints aren't limitations. They're architecture. The 38-byte ceiling forced a design where HD derivation does double duty: schema and addressing in one mechanism. No external dependencies, no auxiliary storage to maintain, no trust in anything beyond the chain. If I'd had unlimited on-chain space, I'd have designed something worse. Something that didn't need to be clever.
DN-Key (2016): Borrow Trust, Don't Invent It
DN-Key is absurdly simple. Publish your cryptographic public keys as DNS TXT records. Verification is a DNS lookup. That's it. That's the entire protocol.
_dnkey.example.com TXT "v=DNKEY1; k=bitcoin; p=xpub6CUGRUo..."
_dnkey.example.com TXT "v=DNKEY1; k=ethereum; p=0x742d35Cc..."
_dnkey.example.com TXT "v=DNKEY1; k=nostr; p=npub1xyz..."The insight was that DNS already solves the trust problem for everything else. SPF proves email sending authority. DKIM publishes signing keys. SSL certificates prove domain ownership. The infrastructure for broadcasting machine-readable key material is globally distributed, battle-tested across billions of lookups per day, and already trusted by compliance teams at regulated institutions. The audit procedures are written. The management tools exist. The trust model is established.
I didn't need to convince anyone that DNS is trustworthy. I didn't need to explain a new security model. I just needed to show that the same pattern proving email authenticity can prove key ownership.
ATA Plus ECF adopted DN-Key in 2016 for their custody infrastructure, a regulated Malaysian financial services context where "we built our own key server" would have added months to the compliance process. DN-Key slotted into existing DNS management workflows that were already audited.
Two years later, DN-Key was cited by name in the Securities Commission Malaysia's official capital markets blueprint during Project Castor. The SC's own document describes using DN-Key for multi-signature redeem scripts, deterministic key creation, and enforcement of pre-approved multi-signature accounts. A national regulator formally incorporating an independently authored protocol into their capital markets architecture, because the protocol was simple enough that compliance teams could understand it in one meeting.
The lesson: the best protocol is one that borrows trust from systems people already believe in. DN-Key's entire value proposition is that it introduces nothing new. No custom infrastructure. No registration. No third-party trust. Just DNS TXT records. The same mechanism that's been proving domain authority since 1993.
DN-Key's real vindication came nine years later.
SADO (2023): Minimal Chain Footprint, Maximum Utility
By 2023, Bitcoin Ordinals had created a marketplace problem: people wanted to trade inscribed satoshis, but every existing solution required custodial escrow or centralised order books. The ecosystem needed a trustless trading mechanism open enough that competing marketplaces could all use it.
SADO (Self-Authenticating Decentralised Orderbook) uses PSBTs (Partially Signed Bitcoin Transactions) as the core primitive. A seller creates a half-signed transaction offering their ordinal. A buyer completes and broadcasts it. No intermediary touches the assets. No server holds custody. The protocol is the transaction format itself.
The original design stored order data on IPFS with content identifiers published on-chain. IPFS introduced reliability issues and pinning dependencies that contradicted the "no trusted third party" principle. We moved to leaner on-chain pointers: minimal data published directly in transactions, referencing off-chain order books that anyone can mirror.
Ordzaar adopted SADO because it was the only option that didn't require trust. Not because we pitched them. Not because of a partnership. Because when you design a protocol with zero trust assumptions, adoption becomes a technical decision rather than a business negotiation. We built developer tooling around SADO (the Ordit SDK for indexing and parsing), but the tooling isn't the protocol. Protocols without developer experience don't get adopted, but DX without a sound protocol is just a nice API over a bad foundation.
The lesson: minimise what touches the chain. Every byte on-chain is permanent, expensive, and inflexible. PSBTs as the primitive means the protocol is just Bitcoin transactions with a specific structure. No custom opcodes, no chain upgrades, no new consensus rules. The chain stays dumb. The intelligence lives in how you structure what's already there.
Oviato (2025): Sometimes You're Early, Not Wrong
BlockAuth was Everstore's first public deployment, a decentralised identity protocol that stored identity claims on-chain using Everstore's structured schema and verified ownership via DN-Key. The architecture was sound. The UX was impossible. In 2016, "manage your own private keys" was not something consumers would do. The technology to abstract that away didn't exist yet. BlockAuth failed.
Nine years later, WebAuthn and passkeys made that abstraction possible. Devices handle key management invisibly. Users authenticate with a fingerprint or face scan. The private key never leaves the secure enclave. The UX problem that killed BlockAuth simply evaporated. Not because someone solved it, but because the platform caught up.
Oviato's identity layer reuses DN-Key (the same protocol from 2016) for passkey-native, chain-agnostic identity. The domain proves organisational identity. The passkey proves user identity. One identity across Bitcoin, EVM, and Solana. No key duplication, no bridging, no intermediary. DN-Key was also made Nostr NIP-05 compatible, extending the same DNS-based verification to decentralised social identity.
The gap between 2016's "publish a public key via DNS TXT record" and 2025's "one identity across every chain with passkey auth and agentic payments" is enormous. Nonetheless, the trust model is identical. Domain proves org. Device proves user. No intermediary. DN-Key required no modifications to work with passkeys, because it was designed to be simple enough that future systems could build on it without asking permission.
The lesson: if the architecture is sound but the platform isn't ready, you're early, not wrong. DN-Key was forward-compatible with protocols that didn't exist when it was written. Everstore's identity concepts waited seven years for the hardware to make them usable. The designs were right. The world needed to catch up.
The Thread
Four protocols. Four lessons. One philosophy:
- Design for constraints — they force better architecture than unlimited resources ever would
- Borrow existing trust — don't ask people to trust new things when existing trust infrastructure works
- Keep the chain dumb — minimise on-chain footprint, maximise off-chain intelligence
- Accept that timing matters — a correct design that's too early will wait for the platform to catch up
Nine years, four production protocols, one consistent thread. The technology changes. The chains change. The market context changes. However, one thing that never changes is the philosophy. Because it's not about any specific technology. It's about understanding where trust lives, where constraints create value, and when to wait for the world to be ready for what you've already built.