Some design decisions feel so natural that you never stop to ask yourself why you made them. You brush it off with a simple “Isn’t that obvious?” and move on. But every once in a while—very rarely—you stumble upon the root of that “obviousness.”
A few days ago, while cleaning out an old hard drive, I discovered a memo file I’d written in 2017. The filename was “factom_study_notes.txt.” In that moment, memories from eight years ago suddenly came flooding back. And I realized something—I finally understood where those “intuitive” decisions we made when designing Oraclizer’s data availability strategy had actually come from.
2017: A Curiosity Born in a Bookstore
My first encounter with blockchain was in early 2017. I remember a close friend telling me that Bitcoin was “practically a scam.” It was the height of speculative frenzy, and his reaction was perhaps understandable.
Strangely enough, his words only sparked my curiosity further. When I visited the bookstore, there were barely one or two books on blockchain. Looking back now it seems almost comical, but at the time, those few books were all there was. I bought them and started reading, and the more I read, the more captivated I became. Distributed consensus, cryptographic proofs, decentralized trust—I realized these concepts weren’t just tools for speculation, but represented a fundamentally new computing paradigm.
“If I master this, it’ll be a blue ocean.”
With that thought, I studied as if memorizing everything by heart. Days were for work; nights were for diving deep into blockchain.
Meeting Factom: The One Nobody Was Watching
At the time, most people were focused on Hyperledger or Ethereum. The main debate was whether to go with enterprise blockchain or public blockchain. But my attention was drawn elsewhere.
Factom.
This project, launched in 2015, wasn’t getting much attention even then. No flashy ICO, no speculative hype. But from my perspective, Factom was the project that most honestly confronted blockchain’s fundamental problems—scalability and cost.
Factom’s core insight was simple:
“You don’t need to put everything on the blockchain.”
This single sentence captured me. At the time, most projects were caught up in the maximalism of “everything on-chain.” But Factom was different. Data was stored in a distributed hash table, and only the hash of that data was recorded on the blockchain. Then that hash was anchored to Bitcoin to inherit its security.
Two-layer architecture. The separation of data layer and proof layer.
This was the most important lesson I learned from Factom.
A Forgotten Lesson, A Design Principle Buried in the Unconscious
After finishing my Factom studies, I immersed myself in other things. I participated in Hyperledger projects, explored the Ethereum ecosystem, and eventually met the Oraclizer team to begin a new journey. Factom was forgotten—at least consciously.
In 2024, our team was designing the infrastructure for the oracle state machine. While building the L3 architecture, one of the most important questions arose:
“Where should we store state synchronization data?”
I answered almost reflexively.
“We don’t need to put all the data on-chain, do we? Let’s just put proofs on-chain and store the actual data in an external DA layer. Let’s go with the Validium approach.”
Team members asked, “Why does that seem so obvious to you?”
I paused. Why did it feel so obvious? In that moment, I couldn’t give a clear answer. I just said, “I don’t know… it just intuitively feels right.”
It was only after discovering that old memo file a few days ago that I understood. The principle of “separating data from proof” that had been imprinted in my mind while studying Factom eight years ago had been unconsciously guiding our design decisions all along.
Three Technical Connection Points
There exist remarkable parallels between Factom’s architecture and Oraclizer’s design. This wasn’t intentional imitation. Rather, it’s closer to arriving at similar answers when facing similar problems. But I now acknowledge the fact that those “similar answers” had already been planted as seeds in my mind.
Data Layer Separation: From Two-Layer to Validium
Factom’s most innovative design was the separation of data and hash. Actual data was stored in a distributed hash table (DHT), and only the Merkle root of that data was recorded on the Factom blockchain. This minimized blockchain burden while still ensuring data integrity.
Oraclizer’s Validium strategy is a modern implementation of this philosophy. We store state synchronization data in an external data availability layer like Avail, and record only state roots and zk proofs on L3. Conceptually, it’s the same approach:
- Factom: Data → DHT, Hash → Factom Chain → Bitcoin anchoring
- Oraclizer: Data → Avail DA, Proof → L3 → Base L2 → Ethereum L1
The lesson from eight years ago—”you don’t need to put everything on the blockchain”—has led to our design principle of “minimizing on-chain costs while maintaining security.”
Separation of Data & Proof
The Anchoring Philosophy: Inheritance of Security
Another core mechanism of Factom was anchoring. Factom recorded the Merkle root of its own blockchain to Bitcoin every 10 minutes. Later, it added functionality to simultaneously anchor to Ethereum as well. This allowed the relatively weaker Factom chain to “inherit” security from Bitcoin’s massive hash power.
This concept deeply influenced the design of Oraclizer’s L3 architecture. Our L3 operates independently, but ultimately settles on Ethereum L1 through Base L2. This hierarchical structure is essentially the same as Factom’s anchoring philosophy, where each layer inherits security from the layer above.
“Independent yet connected” design. The balance between autonomy and security inheritance. This is what Factom taught me, and the principle we unconsciously followed.
Directory Block: The Prototype of Batch Processing
Factom didn’t process individual entries immediately. Instead, it aggregated all Entry Blocks into a single Directory Block every 10-minute cycle, then anchored this to Bitcoin. This batch processing approach was a practical choice for efficiency and cost optimization.
Oraclizer’s OSS (Oracle State Synchronizer) follows a similar pattern. Rather than immediately recording individual state changes on-chain, D-quencer generates blocks at regular intervals and OSS processes state changes in batches. The 3-stage pipeline structure—Stage 1’s parallel collection, Stage 2’s sequential verification, Stage 3’s parallel propagation—is all built on this “periodic aggregation” philosophy.
Processing in batch units rather than individual transactions—this too is a case where lessons learned eight years ago have carried through to present-day design.
Why Did This Connection Only Dawn on Me Now?
Honestly, I feel embarrassed. Embarrassed at my past self who could only answer “intuition” when asked about the basis for design decisions. Embarrassed at the intellectual laziness of not tracing where that intuition came from.
But at the same time, this experience offers an interesting insight into how learning works. Even things we don’t consciously remember shape our thinking patterns. A single sentence from a whitepaper read eight years ago, through thousands of lines of code and hundreds of meetings, eventually manifests as a box in an architecture diagram.
There’s value in excavating the roots of things that feel “obvious.” It’s the path to understanding our own thinking more clearly, and simultaneously a way to pay respect to the pioneers who influenced us.
Remembering the Forgotten Pioneer
Factom has now essentially faded into history. The project was discontinued, the community scattered, and most people don’t even remember the name. In blockchain history, Factom will likely be classified as one of the “failed projects.”
But its philosophical contributions live on. “Separation of data and proof,” “inheritance of security,” “efficiency through batch processing”—these ideas seeped into the blockchain ecosystem in various forms even after Factom disappeared. From the rollup data availability debates to the rise of modular blockchain, and to our Oraclizer’s Validium strategy.
Innovation is not created from nothing. Every new idea grows on the soil of previous ideas. The me of 2017 studying Factom never imagined it would influence oracle state machine design eight years later. But it did.
In the next article, we’ll explore the specific data availability assurance mechanisms of Oraclizer built on this philosophical foundation. If Factom taught us the “why,” now it’s time to talk about the “how.” Validium architecture, Avail DA integration, and data availability assurance in the state synchronization process—we’ll examine how lessons from eight years ago are being implemented as concrete technology.
Sometimes it’s important to remember the forgotten pioneers. So we don’t forget that we stand on the foundation of their failures. And to hold onto the hope that someday our attempts might become seeds for someone else.
References
1. Snow, P., Deery, B., et al. (2014). Factom: Business Processes Secured by Immutable Audit Trails on the Blockchain. https://github.com/FactomProject/FactomDocs/blob/master/Factom_Whitepaper_v1.2.pdf
2. Al-Bassam, M., Sonnino, A., & Buterin, V. (2018). Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities. https://arxiv.org/abs/1809.09044
For research collaborations, technical partnerships or discussions, contact Jay Kim (CPO, Oraclizer) at jay@oraclizer.io.
