Why Make Another L1?
The Short Answer
Because global teleoperation has hard requirements—predictable latency, verifiable activity, and operations-grade reliability—that we can’t guarantee by renting space on someone else’s chain. A purpose-built L1 lets us set the rules, recover quickly, and evolve without waiting on another network’s roadmap.
Modulr isn’t just moving tokens—it’s coordinating live robots, AI, and data across the real world. That requires an architecture we can fully control, audit, and optimize for this purpose alone.
Why not just use an existing chain?
1) We need control over the fundamentals
Running real-world robotics through a shared network means we can’t rely on default parameters or someone else’s upgrade cycle. We need to define how fast transactions settle, how rewards are calculated, and how the network behaves during high traffic or maintenance.
Most blockchains lock these settings at launch. They also come with unnecessary modules that increase complexity and cost.
By building our own, we can:
Tune timing and responsiveness for live robot control.
Set reward rules tied to useful work, not generic activity.
Implement on-chain modules specific to teleoperation, session accounting, telemetry proofs, and reputations.
Understand every line of code so we can fix or improve it fast, and remove code we don’t need to keep the system lean.
Essentially, using another chain means inheriting its params, fee dynamics, and upgrade schedule. Building our own L1 gives us end-to-end understanding and the ability to modify anything—faster bug fixes, targeted features, and realistic recovery procedures (snapshots, replays, validator coordination). This mirrors our lead blockchain dev’s experience running Ethereum/Solana nodes and experimenting with the Cosmos SDK: tutorials often stop at sandbox, production-grade runbooks and code-level clarity are on you.
2) Solana is fast—but not predictable enough for us
Solana’s performance is impressive, but it’s also experienced major network outages and congestion events, including full restarts after validator failures.
During peak demand, even standard transactions have failed to confirm consistently, and developers often have to wait for fixes from core maintainers.
For social apps or DeFi, that’s inconvenient. For teleoperation, it’s a deal killer.
Even basic notions like “confirmation vs finality” require app-level choices around commitment levels; Solana’s own docs and community posts emphasize the difference and evolving documentation around consensus.
We can’t build a real-time robotics network on infrastructure we can’t fully trust to stay live or be repaired on our timeline.
3) Peaq/Polkadot parachain model adds external dependencies
Peaq runs on Polkadot’s relay chain—meaning its performance and uptime ultimately depend on how Polkadot allocates and schedules its resources.
That setup has evolved over time (slot auctions, now “Coretime”), but it still means your project’s cost and capacity are governed by a broader ecosystem’s decisions.
For Modulr, that means: coordination, upgrades, and long-term economics would be partly governed elsewhere.
That’s a dealbreaker.
We can’t have our teleoperation performance or update cycles dictated by another network’s governance or priorities. We need independence to tune throughput, fees, and on-chain logic for teleop sessions—not compete for or time-slice them.
We need our own system purpose-built for constant global uptime.
4) Operations and recovery come first
Modulr connects to physical machines that represent real value. If something breaks, we can’t just restart a node and hope for the best.
We need full knowledge of how to:
Recover from network errors or outages
Perform backups and audits
Deploy upgrades safely without downtime
Securely handle real money and real-world activity
Existing blockchains don’t give that level of visibility. They’re optimized for developers, not operators. We need both.
What we gain with a custom L1
Performance tuned for teleoperation: fast, consistent confirmations and predictable behavior.
Proof of Utility at the base layer: rewards tied to verifiable work—distance covered, jobs completed, data processed.
Complete transparency: we know what’s running, why it’s running, and how to fix it.
Upgrade flexibility: new features and optimizations without external approval or delays.
Neutrality you can verify: Modulr's rules, economics, and modules exist to serve robot teleoperation first—not a generalized transactions per second race.
Independence: On our own chain, we're not competing for blockspace or beholden to another chain’s roadmap.
Integration Still Matters
We’ll still connect to major networks for liquidity, bridging, and interoperability.
But the control layer—the network where robots actually operate and earn—has to be ours.
That’s the only way to deliver the reliability and accountability that real-world automation demands.
Bottom line
Using an existing L1 can be faster to start, but slower—and riskier—at scale. For Modulr’s mission, a dedicated L1 is not bloat; it’s the safety, reliability, and flexibility layer that lets the world operate robots like software.
Next, let's explore all the ways Modulr can be used in the real world.
So now you know why we're building everything from scratch. Here's our plan to build it all out: Roadmap & Key Milestones
Last updated