Inside Shardeum: Auto-Scaling Layer 1 with Dynamic Sharding
In this episode, Shardeum CTO Srinivasan Parthasarathy shares how Shardeum is building an auto-scaling Layer 1 blockchain using dynamic state sharding and a blockless transaction model. The architecture enables linear scalability while keeping node requirements low, offering a unique balance between performance and decentralization.
He also discusses lessons from testnet operations, key bug bounty findings, and the network’s security approach, including a custom “Proof of Quorum” consensus that rotates node responsibilities every 60 seconds. As an open-source, community-driven project, Shardeum aims to launch its mainnet on May 5, with smart contract support and incentive programs to follow in a phased manner.
The audio transcription is done by GPT and may contain errors. Please listen to the complete podcast:
YouTube:
Intro & Shardeum overview
Ehan: Okay, welcome to WuBlockchain Podcast. For the latest blockchain and crypto insights, subscribe to WuBlockchain on YouTube and follow us on Twitter. Stay ahead and join the conversation. Today, we are excited to have Srinivasan, the CTO of Shardeum, joining us. Welcome. Could you please introduce yourself and Shardeum?
Srinivasan: Yes. Hi, my name is Srinivasan. I’m the CTO at Shardeum. At Shardeum, we’re building the world’s first auto-scaling Layer 1 blockchain, and I’m really excited to be here.
My journey into blockchain started back in 2016. In 2017, I built my first NFT marketplace. Since then, I’ve worked at several places and built a number of Web3-related products. I served as VP of Engineering at DraftKings, where I helped build their blockchain infrastructure for one of their flagship products. Most recently, I was at a company called Six, where we sold NFT tokens representing resource rights in the U.S.
Now at Shardeum, I’m leading a fantastic team, and we’re focused on building this pioneering auto-scaling Layer 1 blockchain.
How does Shardeum scale while keeping node access low?
Ehan: Shardeum claims to be the first auto-scaling Layer 1. How exactly does the architecture achieve high transaction throughput while keeping node requirements accessible?
Srinivasan: I think it would be helpful to use a visual analogy to explain how blockchains work in general, and how Shardeum differs — would that be okay?
A good way to think about an event-based blockchain is to imagine it like a spreadsheet, with rows and columns. Each row represents a block, and each cell in the row is a transaction. This spreadsheet is open for anyone to read, which makes it transparent, but only one person at a time can write to it — specifically, one person can write each new row. In most blockchains, the key question is: who gets to write that next row? All consensus protocols are fundamentally about determining who gets to write that row.
Now, imagine this spreadsheet has a billion rows, and there’s a single process managing all of it. As the number of rows grows — from a billion to two billion to ten billion — it becomes increasingly slow and unscalable. But what if, instead of one massive sheet, you had 1,000 tabs, like in Google Sheets? You could then split the data across those tabs algorithmically — say by alphabetical grouping — so you’d have smaller datasets spread across many sheets. This is essentially how sharding works, and it’s what Shardeum does.
But Shardeum goes a step further. Instead of having a fixed number of tabs — say 1,000 — it dynamically adjusts them at runtime. You might start with just 10 tabs, but as transaction volume increases, you can scale up to 200, 1,000, or more tabs. And when volume drops, you can scale back down. This is called dynamic state sharding, and it’s what enables us to auto-scale.
There’s another important distinction. Most blockchains operate around the concept of “blocks,” meaning a writer must write a full row in our spreadsheet analogy. That gives whoever’s writing the row visibility into pending transactions and allows for potential manipulation — like reordering transactions.
Shardeum doesn’t rely on the block concept. Instead, we handle transactions in their purest form. Our smallest unit of execution is a single cell in that row. We don’t require writing an entire row at once. While we simulate blocks externally for EVM compatibility — so JSON-RPC clients know how to interact with us — we’re not actually bound to that structure internally.
This architecture allows us to modify individual cells instead of whole rows, dynamically shard and reallocate workload based on transaction volume, and grow horizontally with minimal performance bottlenecks. It’s a difficult technical problem to solve, but it’s what sets Shardeum apart.
Ehan: And what trade-offs, if any, come with this auto-scaling design?
Srinivasan: Well, the obvious trade-off is that this design introduces a much higher level of communication between nodes. In traditional blockchains, every validator node holds a full copy of the entire blockchain state — essentially the entire spreadsheet in our earlier analogy. This means each node requires significant processing power and storage capacity.
In Shardeum, since we break the data into smaller segments — or tabs — each node only needs to process a small portion, such as one tab out of 1,000. That dramatically reduces the computational and storage requirements per node, making it more accessible. However, the downside is that each node now only has a partial view of the overall state. It’s like only having access to the “A” section of a telephone directory.
So, when a node needs data outside its assigned segment, it must first determine which node holds the needed data, then request that data from them. This introduces a layer of inter-node communication, which makes things more complex.
That said, we’ve solved this challenge with a custom communication protocol that enables nodes to locate and share data efficiently. Yes, it adds complexity, but the payoff is immense — Shardeum can scale transaction throughput almost linearly just by adding more nodes.
So while decentralized inter-process communication is a tough technical challenge — and hasn’t been fully solved in other systems — we believe we’ve cracked a scalable model that makes Shardeum a truly unique Layer 1 blockchain.
What did you learn from the incentivized testnets?
Ehan: And what were the key learnings from operating the incentivized testnet with a large-scale, truly decentralized network?
Srinivasan: Yeah, that’s a good question. We ran four incentivized testnets, and the level of participation was incredible — people were running nodes from literally all over the world. Our homepage says “decentralization for all,” and we genuinely mean that. We wanted to build a system that allowed not just people in developed countries with access to expensive hardware, but anyone — even those with limited resources — to spin up a node.
This approach helps drive decentralization and also enhances network security. So, one of the key learnings from our incentivized testnets was how to make node participation truly global and accessible. We had to figure out how to clearly communicate node requirements, onboarding steps, how staking and unstaking work, and how to create a user experience that made these processes intuitive.
A lot of UX improvements came directly from observing how people interacted with the testnet. We learned what kind of interfaces worked best and what caused confusion. Beyond UX, we also used the testnets to identify and patch several security issues.
Another major insight was around network coordination. When you have many nodes, each with only partial data, you need a robust protocol to achieve consensus — especially since we don’t control any of the nodes. Someone might spin up a node in Fuzhou, another in Siberia, another in India — and all of them need to reach consensus in a decentralized environment. Ensuring that coordination happens smoothly in real time, without centralized control, is a massive technical challenge. But solving it has been key to what makes Shardeum unique.
What critical bugs were found in the bounty programs?
Ehan: Could you share the most critical vulnerabilities discovered through the bug bounty programs and how you addressed them?
Srinivasan: Sure. We’ve run several bug bounty programs, and some of the issues that surfaced were quite unique. First off, everything we’ve done is open source — so all the fixes and changes are publicly available. Anyone can go to our GitHub repository and see exactly what we’ve modified to support the network.
That said, we found a number of important issues during these programs. Some involved how we were signing transactions — such as picking up the wrong hash or inconsistencies in the signing process. These bugs could have introduced risks, like replay attacks, where a transaction from a testnet might potentially be replayed on mainnet. So we had to carefully analyze and fix all such vulnerabilities.
The bug bounty programs were incredibly valuable for us. We found a significant number of issues, especially around protocol-level features like multi-signature support, which we’ve implemented directly at the protocol layer. White hat hackers helped us test these features rigorously, and their feedback led to key security improvements.
All of these fixes have now been integrated into our upcoming mainnet release — scheduled for April 15.
How will you handle security after mainnet launch?
Ehan: And what is Shardeum’s approach to ongoing security monitoring and threat mitigation post–mainnet launch?
Srinivasan: We’re taking a multi-layered approach. We have a dedicated internal security team whose sole focus is monitoring the health of the system and evaluating potential attack vectors.
We’ve also built, and are continuing to develop, a comprehensive telemetry and observability system that gives us visibility into what’s happening across the network. This allows us to detect anomalies, track system behavior, and respond to threats in real time.
While we already have this system in place, we’re continuously improving it as we approach mainnet launch. In fact, we’re building a full open telemetry framework from the ground up to ensure that the network remains secure even as it scales.
How is your RPC layer different from other EVM chains?
Ehan: How does the Shardeum RPC layer differentiate itself from other typical EVM-compatible chains in performance, scalability, or reliability?
Srinivasan: Great question. As I mentioned earlier using the spreadsheet analogy — most EVM-compatible chains treat the entire blockchain state like one giant spreadsheet where every node maintains the full data. In contrast, Shardeum breaks that spreadsheet into multiple shards or tabs, each managed by a subset of nodes.
Each process is responsible for one or more specific tabs — for example, tab 33 — and this assignment is dynamic. Shardeum operates on a 60-second internal clock cycle. At the end of each cycle, the system rotates nodes: it may replace, say, five out of a thousand active nodes with five new ones, selected from a standby pool based on certain criteria like inactivity duration. Then, the system reassigns responsibilities — so a node that just entered may suddenly be responsible for tabs 33 and 37 without prior knowledge, and without knowing which other nodes share those assignments.
This mechanism dramatically boosts security. The randomness and rotation make it extremely difficult to target or influence specific sections of the network. For any transaction to be finalized, a supermajority — say 67 out of 100 participating nodes — must agree. And those 100 nodes don’t know who else is in the group or how they were selected. This uncertainty helps ensure decentralization and tamper resistance.
We call this consensus mechanism Proof of Quorum. It’s tightly integrated with our 60-second cycle structure. To compromise the network, an attacker would need to identify and control two-thirds of a randomly assigned validator set within a single cycle — which is practically impossible.
From a performance standpoint, our architecture allows near-linear scalability. We can dynamically scale from 100 to 10,000 shards (or tabs) and scale back down as needed. This flexibility is what makes Shardeum highly scalable, reliable, and secure — all while maintaining full EVM compatibility through our RPC layer.
Will you continue audits and bug bounty programs?
Ehan: Will your security strategy involve ongoing third-party audits or continued community-driven bug bounty programs?
Srinivasan: Yes, absolutely. We’re an open-source project — our entire codebase is available on GitHub — and every technical decision we make is fully guided by our commitment to decentralization. We’re fortunate to have a fantastic community supporting us, and we’re deeply grateful for that.
We plan to continue engaging third-party auditors and running community-driven bug bounty programs. In fact, we have an entire team dedicated to working with the community to build products around Shardeum. Some of these projects we’ll help jumpstart and eventually hand off to the community.
We’re also planning hackathons and other events to encourage incentivized community participation. Once we launch the mainnet on May 5, all of these initiatives will accelerate. We’re counting on the community to play a central role in Shardeum’s continued success.
How are you growing the community and ecosystem?
Ehan: How has Shardeum built its community and ecosystem? What specific programs or incentives have been most effective?
Srinivasan: Our community has truly been one of our biggest strengths. For example, in our most recent incentivized testnet, ITN4, we had around 52,000 validators (171,000 validators across all testnets) participating globally. We’ve built a large and active presence across social platforms like Discord and X, and our ecosystem team is fully dedicated to engaging with and growing this community.
We’ve taken a phased approach to development — starting with token transfer functionality and soon rolling out support for smart contracts and other key features. As we progress through each phase, our community will be involved every step of the way.
We also have a dedicated team focused solely on designing and executing community programs. This includes incentives, onboarding, educational content, and collaborative events to ensure the ecosystem continues to expand in a sustainable and decentralized manner.
What projects are being built on Shardeum now?
Ehan: So what types of projects or applications are currently being developed on Shardeum?
Srinivasan: That’s a great question. As an auto-scaling Layer 1 blockchain, Shardeum is especially well-suited for use cases where scalability and transaction cost are major concerns. Let me give you an example: at my previous company, we sold NFTs representing real-world resources, like horses, for $1,200. At the time, Ethereum gas fees were around $200 per transaction. Paying a 20% fee on top of the purchase price made no sense — it was simply unsustainable.
With Shardeum, because we scale linearly, our gas prices remain low and consistent regardless of network congestion — even if a memecoin launches on the chain. This makes the platform ideal for financial and DeFi applications that are sensitive to fees.
Since Shardeum is EVM-compatible, developers will be able to deploy Solidity-based smart contracts with minimal effort. Any contract running on another EVM chain can easily be ported over. That means we inherit the massive network effect of the EVM ecosystem — ten years’ worth of tooling, developer knowledge, and infrastructure.
So while we already anticipate DeFi and NFT projects migrating to Shardeum, I believe the community will surprise us. Once mainnet is live, I’m hopeful we’ll see a surge of innovative applications that take full advantage of Shardeum’s EVM compatibility, low fees, reliable performance, and dynamic scalability.
How will the token be used for staking and governance?
Ehan: How will the Shardeum token be used across staking, governance, or network incentives?
Srinivasan: We’re still finalizing the specifics around governance, and those details will be shared soon. That said, our core principle is full decentralization — anyone with a small amount of Shardeum tokens can run a node. These tokens will be available through our token sale.
In terms of incentives, the reward mechanism is based on how long a node spends in the active set, which is the group of nodes currently participating in consensus. When you spin up a node, it first joins a standby pool. Every 60 seconds, during each cycle of our internal clock, we rotate a portion of the active set out and bring in new nodes from the standby pool. A node starts earning rewards once it enters the active set.
Rewards are proportional to the duration a node spends actively participating in network tasks — validating transactions, signing blocks, and contributing to network security. Node selection also considers past performance history. Those that meet expectations — uptime, responsiveness, correct behavior — are more likely to stay in the active set longer and earn more rewards.
We don’t slash underperforming nodes, but if a node doesn’t meet performance standards, it will be rotated out of the active set more quickly, reducing its ability to earn rewards. It’s a gentler, incentive-based way to shape behavior rather than penalize it outright.
All of this is still being refined, and additional details around governance and reward mechanics will be made available closer to the mainnet launch. Keep an eye on our website for updates.
How do you ensure transparency and independence?
Ehan: How does Shardeum ensure operational transparency and governance independence?
Srinivasan: That’s a very good question. As I mentioned earlier, Shardeum is a fully open-source project. Everything we do is out in the open — essentially like working in a fishbowl. All of our code is available on GitHub, so anyone can see exactly how our system works.
You can review our consensus mechanism, the algorithms we use for node selection and reward distribution, and every other aspect of the protocol. There’s full visibility into the logic behind node performance evaluation and network scaling decisions.
After mainnet launch, we won’t have any centralized control over who can launch a node or where they can launch it. The network is designed to adapt to a decentralized environment, dynamically handling node participation and consensus. This openness and lack of centralized authority is fundamental to Shardeum’s commitment to transparency and independence.
When is mainnet launching and why is it significant?
Ehan: Could you share the recently announced mainnet launch date and what this milestone represents for Shardeum?
Srinivasan: Our mainnet is launching on May 5, and it’s a huge milestone for Shardeum. This network has been in development for quite some time, and we’ve had an incredible team working on it.
What makes this launch significant is the complexity of what we’re building. Auto-scaling a Layer 1 blockchain, along with designing entirely new transaction protocols, is an extremely challenging technical endeavor — it takes time and deep expertise.
We believe this is the right moment for Shardeum to enter the next stage. The mainnet rollout will happen in phases, with the first phase starting May 5. From there, we’ll gradually introduce more community-oriented features, continue improving performance, and make the system even more scalable and accessible to users worldwide.
How will you engage and grow the contributor base?
Ehan: What’s the strategy for community growth and meaningful contributor participation?
Srinivasan: If I understand your question correctly, as I mentioned earlier, we have a dedicated team working closely with the community to guide what gets built and how it gets launched. We’ve already seen tremendous engagement during our past incentivized testnets, and I want to thank everyone who’s been part of that.
Our community team actively collaborates with partners and contributors, and we expect that level of participation to grow significantly after the mainnet launch. We’re excited to continue building with and for the community.
Ehan: Anything else you’d like to share with our audience?
Srinivasan: Yes — thank you all for your incredible support. Your feedback and involvement during the testnets have been invaluable in helping us secure the network and shape Shardeum. Please check out shardium.org for all the latest updates, and we truly appreciate your continued support.
Follow us
Twitter: https://twitter.com/WuBlockchain
Telegram: https://t.me/wublockchainenglish