Spike OS In-Depth Interview: Empowering Web3 Applications with Superpowers — The Blueprint and Determination of the Unsung Hero
TechFlow Selected TechFlow Selected
Spike OS In-Depth Interview: Empowering Web3 Applications with Superpowers — The Blueprint and Determination of the Unsung Hero
Spike OS provides a pluggable, multi-chain "L3" for Web3 applications.
Navigating Web3 tides with focused insights
The crypto market rises and falls, but breaking into the mainstream remains a critical topic. Today’s Web3 applications are better at making fleeting appearances in capital markets than actually attracting widespread adoption from users outside the crypto bubble. For every challenge faced, there's often a mismatch in solutions.
Where is the real cure for mainstream breakthrough? Most people wait for a standard answer, while others try to create their own.
Recently, TechFlow conducted an exclusive interview with Spike OS — an infrastructure project dedicated to enabling data interoperability and composability for Web3 applications, aiming to unlock new use cases that attract non-crypto-native users through shared data. Jeff, the founder, shared deep insights into the current challenges facing Web3 apps and provided a detailed explanation of Spike OS’s design philosophy, technical architecture, and future roadmap.
If you’re interested in infrastructure investment opportunities or building Web3 applications, this interview may offer valuable inspiration.
Section 1: Product Design Philosophy — A Ferry to Navigate Blue Oceans
TechFlow: What inspired the creation of Spike OS? What sparked this idea?
Jeff: The starting point is really about expanding Web3 to serve a broader user base. Web3’s so-called “mass adoption” shouldn’t be limited to financial use cases or tools only useful to finance professionals.
As Vitalik has pointed out, “blockchains have done reasonably well in financial applications, but non-financial applications represent a promising direction for the future.”
Looking at today’s Web3 landscape, mature non-financial applications remain scarce, and the industry is still far from true mass adoption. However, during the last cycle, NFTs and GameFi brought massive new traffic — projects like Bored Ape, StepN, and Axie Infinity. Despite their individual flaws, they showed one thing clearly: without non-financial applications, we won't see meaningful market growth or accelerated development.
Take GameFi as an example: there’s no standout AAA-level blockchain game yet, and fully on-chain games still lack broad appeal. So we believe a new kind of Web3 environment is needed: one where all assets are on-chain, delivering seamless interoperable experiences; where applications themselves achieve higher scalability and composability; and above all, where it’s genuinely fun to play.
Only such an environment can drive more non-financial applications and bring in large-scale user adoption. Currently, the infrastructure layer to support this vision is missing — and that’s exactly what we aim to build.
TechFlow: You mentioned gaming and non-financial applications. Are Web3 game developers your primary target audience? How else can other non-financial apps benefit from your product?
Jeff: First, we offer a general-purpose,底层-technical solution. The solution itself doesn’t distinguish between games and other applications.
In today’s ecosystem, the boundary between games and apps is increasingly blurred. Take Sandbox — it has a game-like interface, but its functionality extends far beyond gaming: hosting AMAs, collaborative workspaces, live performances, concerts, etc. It transcends the narrow definition of a “game.”
Therefore, Spike OS does not limit itself to games or any specific app category. Its core mission is to enable a future-ready environment focused on data availability, module composability, and user data interoperability.
That said, game developers might adopt Spike OS faster initially, since mainstream users tend to accept games more readily at early stages.
TechFlow: The issues of data availability, modularity, and interoperability in current Web3 apps sound abstract. Can you illustrate them with concrete examples?
Jeff: Let’s start with a tangible example to clarify modularity and composability. In Sandbox or other open worlds, developers embed mini-games within the world.
Suppose I build a Texas Hold’em app inside a casino zone. You can buy a table (an NFT), invite others to play poker (a business module), enjoy the experience, and split earnings based on rules. But if you want to play blackjack or mahjong on that same table (other modules), you’ll find it impossible to extend or modify existing applications — either because the original developer didn’t plan for it, or doing so requires significant rework.
Even if developers intend to add new features, opening up their apps takes considerable effort.
So today’s applications are inherently neither modular nor composable — which harms both users and developers. A better scenario would be turning apps into open, modular components that others can easily build upon. This enables secondary innovation on top of your work — something missing in both past Web3 and Web2 applications.
Next, consider data interoperability. Right now, when you build any application, all data belongs solely to the developer. User data resides on your server — AWS or Alibaba Cloud — and everything from app data, social relationships, to message content lives in your private database.
Other apps cannot access your data unless you explicitly expose APIs.
Imagine a new paradigm in Web3: users retain ownership of their assets, but all application data exists on an open network, freely accessible across apps. For instance, suppose I’m a Gold-tier player in shooter game A. A new game could automatically award me a special badge or easter egg just for achieving that rank.
When apps can freely call each other’s data, interoperability skyrockets. Imagine WeChat accessing Ant Financial’s credit score, or Xiaohongshu pulling TikTok follower demographics — such data sharing could fuel massive innovation across industries.
TechFlow: These problems do exist. Are there existing solutions in the market? If not, what gives Spike OS the confidence and edge to pioneer this space?
Jeff: Excellent question. Let’s first ask: did Ethereum and EVM already solve composability and data interoperability?
Take the “DeFi Lego” analogy: you build Protocol A using smart contracts, and I build Application B on top of it. That’s how we got DeFi Summer and successful protocols like Curve and Aave.
So yes, financial applications have achieved modularity, composability, and data interoperability. For standardized, simple financial use cases, EVM has proven innovative and effective. But this doesn’t apply to non-financial applications.
Non-financial or general-purpose apps involve complex general computing: voice streams, text, multimedia in social contexts; 3D models and visual effects in games; multi-dimensional user databases...
There’s currently no solution capable of efficiently handling these general computing needs. Or put differently, we’re building a generalized-computing EVM to address these gaps.
Developers use various languages — Java, C, Python — but within Spike OS’s virtual machine, they all compile into a unified machine language format. This allows developers from different backgrounds to easily build modules under one architecture, with full compatibility between modules.
Our team previously built a metaverse project called “Oasis,” launching the first Oasis Engine in 2019 to empower UGC in virtual worlds.
Oasis Origin also won first place in a BNB Chain hackathon.
Building on that foundation, we open-sourced the engine, standardized its data structure, and evolved it step by step into the current Spike OS product.
Over the past 3–4 years, we’ve expanded our team, hiring experts in open-source engines and low-level programming to help realize this product. So building Spike OS aligns naturally with our journey. But whether we’re the best ones to do it, or whether others couldn’t achieve the same — I wouldn’t claim that.
Today’s blockchain ecosystem thrives on mutual learning. Everyone brings strengths, and collaboration often leads to progress. From day one, we open-sourced Spike OS precisely for this reason: to invite better innovators to build upon our foundation. Just like Ethereum — smart contracts weren’t perfect at launch, but its open-source nature and governance model created immense positive externalities, drawing in countless ecosystem contributors.
That’s our motivation — and our confidence — behind Spike OS.
TechFlow: In Web2, OS-level products are notoriously hard to build. In Web3, what do you see as the biggest challenge in creating an OS-level product?
Jeff: We draw inspiration from Android. It’s open-source, and Android Studio — its official IDE — is also open. So you don’t need to use Google’s tools; you can fork and improve the architecture yourself.
So the first challenge is technical: does Spike OS have bugs or flaws at the foundational level? But these are relatively easier to fix.
The bigger challenge lies in consensus and ecosystem formation. Will our solution become an industry standard? Will more apps join? Will enough developers adopt it? These are key concerns. As more apps integrate, system complexity increases, placing greater stress on stability. Will we face bugs or expose weaknesses under pressure?
We’ll discuss strategies for tackling ecosystem growth later.
Section 2: Technical Architecture — More Than Just an "L3"
TechFlow: Before Spike OS, you released Spike Engine. Are they different products? What’s their relationship?
Jeff: Spike OS includes Spike Engine, much like Android OS includes Android Studio.
We can define Spike OS in three ways:
First, it’s a modular, composable solution. We’ve discussed this earlier. Within this framework, Spike Engine serves as the modular/composable development environment.
Second, it’s an open, decentralized compute system, with all data stored on an open network. Compute resources are provided by nodes joining the network.
Third, it’s an open, interoperable runtime environment for users. Similar to how we use Android/iOS smartphones today — users experience it as an interoperable data environment.
TechFlow: Engine, as a dev environment, is tangible — it has interfaces and UI. But what form does the "OS" take? Is it a blockchain? Or another layer stacked atop L1/L2?
Jeff: We view Spike OS as a pluggable, multi-chain "L3". Specifically, it’s a runtime environment for general-purpose application execution. Think of L1 and L2 as “ledger environments” — they handle tokens and transaction records. General computation, however, happens within Spike OS.
So for EVM-compatible chains like ETH/Polygon/BSC, we’re pluggable. We’ll extend support to chains like Aptos and Cosmos too.
Moreover, users may not perceive the OS directly. Their experience might be: sending a message in App A and having it appear in App B; or cross-app data access. A familiar analogy: Spike OS enables you to share a Feishu document directly in Tencent Meeting, or view someone’s TikTok video natively within Xiaohongshu.
But your wallet address and assets still reside on their original chain — e.g., if a DApp runs on ETH, transfers and asset logic follow ETH’s rules.
When users discover their data can flow seamlessly across platforms and apps, they’ll recognize it as groundbreaking. Whether they care who built it? Most probably won’t.
TechFlow: Looking deeper into Spike OS’s internal structure, your whitepaper mentions engine, nodes, contracts, and chains. Given the complexity, could you walk us through how these components work together via an example?
Jeff: Sure. Let’s walk through a developer’s journey using Spike OS:
Game Development — Spike Engine: Suppose you want to build a platformer game from scratch. Open Spike Engine, set up different modules, write code defining gameplay mechanics — jumping, movement, scoring, level progression, etc.
Module Integration — Spike Contract: Your game might have user, asset, scoring, and scene modules. These modules don’t inherently “know” each other. To connect your character’s spawn point to a checkpoint in the scene, or make your score unlock the next level, you’d use Spike Contracts to wire them together.
Compute Demand — Spike Node: In traditional game development, launching your game requires buying servers, databases, rendering capacity, voice services for chat, etc.
With Spike OS, this translates to purchasing “compute power.” Once your game is ready, click “Publish” — it deploys instantly within Spike Engine. You get a protocol address, e.g., “Spike/Platformer.” Share the link: mobile users download the app; web users play directly in-browser.
The general compute powering all this — rendering, communication, execution, downloads, CDN acceleration — is provided by our Nodes.
TechFlow: Regarding nodes and compute, what are the hardware and time requirements? Unlike Bitcoin, where running a full node is costly.
Jeff: Yes, our nodes are significantly lighter than Bitcoin or early Ethereum nodes. Ethereum is a global supercomputer — each node must theoretically validate the entire network and store unique state results.
Spike OS uses a P2P distributed model. If you deploy an app in Shanghai and locals are playing it, nearby users may act as nodes, handling your rendering and acceleration needs.
This doesn’t require global consensus, so node burden is much lower.
TechFlow: That was mostly architectural. Can you show Spike OS’s actual frontend? People are curious about current progress and real-world UX.
Jeff: Here’s a vivid demo:
-
Visit “Spike/BeanBoozled” to play the game directly;
-
To inspect how it’s built, go to “Spike/BeanBoozled/dev” to enter developer mode;
-
You’ll see module folders: “character – scene – actions – score”;
-
Want to replace the “orchard” scene with a “space” theme? Upload your custom space scene with one click;
-
Use contract code to integrate the new scene, pay gas fees, and voilà — you’ve remixed the game. It’s essentially a lightweight web-based dev interface.
TechFlow: This seems developer-focused. How can regular users engage with Spike OS? Can they join as nodes?
Jeff: Yes, we aim for a permissionless network with multiple participation paths. It’s similar to P2P networks like Xunlei: every device is also a node. While downloading, you simultaneously upload and contribute bandwidth. More users mean more seeds and faster speeds.
At its core, Spike OS is a permissionless network. Any computer, even smartphones, can join. If you and I are playing the same game, we can mutually provide compute — accelerating communication or rendering.
Initially, node requirements will be higher — we’ll score nodes based on uptime, speed, and accuracy. But over time, it will become more open. As user and developer counts grow, so will nodes — eventually becoming a truly open, barrier-free network.
TechFlow: What motivates people to run nodes? Is there economic incentive?
Jeff: Primarily token rewards. Developers used to rent servers — costing thousands or even millions monthly. Now, they pay tokens to Spike Network nodes for compute resources to run their apps.
Nodes earn token rewards proportionally to their compute contribution. As the ecosystem grows, the token also becomes a governance token, increasing in value. This creates stronger incentives for new participants to provide compute or become nodes.
Additionally, becoming a Spike OS node requires staking. Nodes must ensure efficient computation — no single node should slow down the network or an app. Staking amounts and reward levels will dynamically adjust based on performance scores.
Section 3: Go-to-Market Strategy — Collaboration, Not Disruption
TechFlow: Have you considered commercialization and outreach? Spike OS seems highly technical and B2B. How do you reach more projects and raise awareness?
Jeff: Great question — one we’ve been pondering. I have a tentative answer I’d like to test with the community: mature solutions often rely on BD teams to convince enterprises to adopt. That’s why major L1s and L2s — Polygon, Avalanche, Near, Aptos, Sui — deploy hundreds of BD reps to recruit new projects.
But early Ethereum had no BD. It didn’t actively court big companies. Why the difference? I believe the key is this: if a new solution enables use cases that are only possible — and vastly more efficient, effective, and user-friendly — with your tech, you’re competing on a different innovation curve.
A clear example is ICO. Though it ended in chaos, it proved smart contracts and EVM were powerful — and only Ethereum’s architecture enabled such innovation at the time. Similarly, we want to identify use cases that only work on Spike OS, offering superior UX, developer efficiency, and cost savings.
When innovation is clearly tied to your underlying technology, developers flock to your ecosystem organically — rather than needing aggressive BD. Otherwise, we risk straying from our core mission.
TechFlow: With that strategy in mind, what concrete steps will you take? Will you build showcase cases or launch developer incentives?
Jeff: Yes, we’ll proceed in three phases.
Phase One: We’ll build mature, on-chain applications ourselves. Our previous Oasis project was already developed using Spike’s approach. The “BeanBoozled”-style demo will also be available on our website. We’ll deploy such games on other chains so people can see what composable, non-financial apps look like.
First, we must demonstrate Spike OS’s superiority through our own use.
Phase Two: Partner with major L1s and L2s, likely through investments or grants, to encourage their developers to adopt Spike OS. This is also why we’re attending ETH Denver.
From feedback so far, public chains universally seek mass adoption and incremental growth. They’re open to new development environments that attract entertainment apps and external users. Since we don’t operate a standalone chain, we’re collaborators, not competitors.
Phase Three: Once Spike OS’s advantages are widely recognized, we’ll cultivate our own developer ecosystem. Through hackathons or incubation programs, we’ll attract developers specifically targeting Spike OS. But this is a later-stage goal — right now, we’re focused on Phases One and Two.
TechFlow: Side note — the last project with “OS” in its name was EOS. Its outcome fell far short of its ambitious vision. How do you avoid repeating that mistake in execution or messaging?
Jeff: EOS once ignited excitement, then disappointment, and ultimately faded.
I’ve always believed blockchain’s spirit lies in building upon predecessors’ successes, cooperating to serve more users — not forking ecosystems or claiming superiority by changing Ethereum’s fundamentals. That approach rarely wins trust.
From day one, Spike OS was designed to enhance existing chains — empowering Ethereum’s L1s and L2s, putting more assets on-chain, lowering development barriers, and accelerating innovation.
We don’t compete with chains. Instead, we help build more apps and onboard more users. That’s our key difference from EOS. Not reinventing the wheel, but riding the wave — hoping to succeed by helping others succeed first.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
