TL;DR
The journey to conceive the oracle state machine wasn’t just a technical innovation—it was a profound exploration that began with deep reflection on the fundamental limitations of existing oracles and led to discovering the new paradigm of complete state synchronization. In this piece, I share the genuine concerns, doubts, and breakthrough moments I experienced as CPO during our design process. We realized that while technical excellence matters, the philosophical foundation of why this technology is necessary matters even more.
In early winter 2024, when our team first uttered the term “oracle state machine,” none of us could have predicted where this would lead. We initially thought of it as simply an extended version of existing oracle solutions.
But looking back, from that moment onward, we were stepping into completely uncharted territory.
Initial Skepticism: Is This Really Necessary Innovation?
Honestly, I was skeptical at first.
Proven oracle solutions like Chainlink and Band Protocol were already working well in the market. Why did we need to create an entirely new paradigm? Wouldn’t improving existing solutions be sufficient?
These doubts sparked intense debates within our team. Particularly heated were discussions about whether our goal of “complete state synchronization” was actually achievable, or merely idealistic theory.
“State synchronization isn’t an extension of data transmission—it’s a completely different paradigm. What we’ve been calling oracles until now weren’t truly oracles at all.”– Jay Kim, CPO of Oraclizer
It took several months before this realization dawned on us.
First Breakthrough: Discovering Regulatory Compliance
The turning point came when we began researching the Regulatory Compliance Protocol (RCP).
At the time, we were analyzing regulatory requirements for tokenized capital markets when we discovered something remarkable. Examining 31 core regulations from 15 global financial regulatory agencies revealed that most requirements could never be satisfied by existing oracle solutions.
Traceability, Confidentiality, Enforceability, Finality, Tokenizability—implementing these five regulatory properties perfectly required not simple data transmission, but synchronization of state itself.
Key Insight: At this moment we realized that the next stage of oracle technology wasn’t about performance improvement, but required an entirely different dimensional approach.
Establishing Design Philosophy: Paradigm Shift to State Machine
After analyzing regulatory requirements, we faced a fundamental question: What should an oracle actually do?
The existing answer was clear: “Securely transmit external data to blockchains.” But what we needed was far more complex.
In RWA tokenization, rather than simply transmitting data, state changes of off-chain assets needed to be reflected on-chain in real-time. Furthermore, changes occurring on-chain needed to propagate back off-chain.
Traditional Oracle: Off-chain Data → Oracle → On-chain
State Machine: Off-chain State ⇄ Oracle State Machine ⇄ On-chain StateFrom this point, we began redefining oracles as state machines—not simple data pipelines, but intelligent systems that manage and synchronize state transitions.
Technical Challenges: From Theory to Reality
Once our design philosophy was established, countless technical challenges awaited.
First Challenge: Economic Feasibility
State synchronization isn’t a single transaction. One oracle request can trigger dozens of sub-transactions. The existing gas fee structure made this economically unfeasible.
To solve this problem, we developed a triple strategy: L3 architecture, Validium mode, and zkVerify integration. While each was insufficient individually, their combination finally enabled gas cost reductions of over 93%.
Second Challenge: Balancing Decentralization and Performance
Complete state synchronization required high-level consensus. However, existing BFT algorithms had performance constraints.
While developing the D-quencer algorithm, our concern wasn’t simple technical optimization. It was securing practical performance without abandoning the philosophical value of decentralization.
Adopting BLS signature-based VRF and equal staking methods resulted from this philosophical deliberation.
Third Challenge: Coexistence of Regulation and Decentralization
The most difficult aspect was simultaneously satisfying regulatory enforceability and decentralization principles.
How could we technically implement regulatory agencies’ FREEZE, SEIZE, and CONFISCATE requirements without compromising the system’s decentralized nature?
Our solution was a dual governance model. Regulatory agencies can take direct action only within limited scope, while measures with broad impact require decentralized governance approval.
Unexpected Synergy with Horizen Partnership
Our partnership with Horizen initially seemed like simple technical cooperation. However, during zkVerify network integration, we discovered unexpected synergy.
Their modular ZK verification network was the perfect solution to our proof verification cost concerns. Sometimes these chance encounters bring greater innovation than meticulous planning.
Philosophical Reflection: Meaning Beyond Technology
The biggest realization while designing the oracle state machine was that technical perfection alone isn’t sufficient.
Why Is This Technology Necessary?
Rather than simply creating a “better oracle,” we were building infrastructure for true convergence of TradFi and DeFi. Bringing the $30 trillion RWA market on-chain is impossible with existing paradigms.
Innovation for Whom?
The technology we’re developing isn’t for developers. Ultimately, it’s about enabling people excluded from traditional finance to benefit from DeFi. Regulatory compliance attracts institutional investor participation, enabling greater liquidity and better services.
What Future Are We Envisioning?
Our vision is simple: enabling blockchain technology to truly permeate daily life. This requires regulation and innovation to harmonize rather than oppose each other.
Journey with the Team
None of this would have been possible alone.
The engineering team sometimes made my “seemingly impossible” requirements reality. The research team built solid theoretical foundations, while the business team accurately identified market needs.
Particularly memorable were the intense debates during D-quencer algorithm design. Opinion clashes based on individual expertise ultimately led to better solutions.
Future Challenges
Completing oracle state machine design doesn’t end our journey.
Technical Challenges
Advanced SMT smart merging technology, achieving near real-time finality, implementing multi-state rollback systems—numerous technical challenges remain.
Ecosystem Building Challenges
No matter how excellent the technology, it’s meaningless if unused. DeFi protocol integration, traditional financial institution onboarding, dialogue with regulatory agencies—ecosystem building becomes the more important challenge.
Philosophical Challenges
Most importantly, we mustn’t lose technology’s direction. While commercial success matters, we shouldn’t forget our original vision—financial democratization and improved accessibility.
What Ultimately Remains
Reflecting on two years of design process, what was most precious was the process itself.
While there’s satisfaction in finding perfect technical solutions, the learning gained from confronting seemingly impossible problems with the team is more valuable.
The oracle state machine isn’t just technology. It’s philosophy opening the next stage of blockchain technology. Witnessing this philosophy become reality is my greatest joy as CPO.
Many challenges await, but I’m confident we’re heading in the right direction. Please join us in watching how the new paradigm of state synchronization will transform the blockchain ecosystem.
