Deep Dive into Shardeum: The First Layer Blockchain with Auto-Scaling via Dynamic Sharding

In this episode, Shardeum’s Chief Technology Officer Srinivasan Parthasarathy shared how Shardeum builds an auto-scaling Layer 1 blockchain through dynamic state sharding and a blockless transaction model. This architecture achieves linear scalability while maintaining a low threshold for node requirements, providing a unique balance between performance and decentralization.

He also discussed the lessons learned from testnet operations, key vulnerability reward discoveries, and the security methods of the network, including a customized Proof of Quorum that rotates node responsibilities every 60 seconds. As an open-source, community-driven project, Shardeum plans to launch its mainnet on May 5th, with phased support for smart contracts and incentive programs to follow.

Audio transcription completed by GPT may contain errors. Please listen to the full podcast:

Little Universe:

YouTube:

Introduction and Overview of Shardeum

Ehan: Welcome to Wu Says No Crypto Podcast. Today, we are pleased to invite Srinivasan, the Chief Technology Officer of Shardeum. Welcome, please introduce yourself and Shardeum.

Srinivasan: Yes, hello everyone, I am Srinivasan. I am the Chief Technology Officer of Shardeum. At Shardeum, we are building the world’s first automatically scalable Layer 1 Blockchain, and I am very happy to be here.

My journey into Blockchain started in 2016. In 2017, I built my first NFT marketplace. Since then, I have worked in multiple places and built many products related to Web3. I served as Vice President of Engineering at DraftKings, helping to build the Blockchain infrastructure for their flagship product. Recently, I have been working at a company called Six, where we sell NFT tokens representing resource rights in the United States.

I am leading an outstanding team at Shardeum, where we focus on building this groundbreaking auto-scaling Layer 1 Blockchain.

How does Shardeum scale while maintaining a low barrier to node access?

Ehan: Shardeum claims to be the first automatically scalable Layer 1. How does its architecture achieve high transaction throughput while keeping Node requirements accessible?

Srinivasan: I think it would be helpful to explain how Blockchain works and the differences of Shardeum using a visual analogy - is that okay?

A good way to think about an event-driven blockchain is to think of it like a spreadsheet with rows and columns. Each row represents a block, while each cell is a transaction. This spreadsheet is open to anyone and transparent, but can only be written by one person at a time—specifically, only one person can write a new row at a time. In most blockchains, the key question is: who has the authority to write to the next line? The essence of all consensus protocols is to determine who can write this line.

Now, imagine that this spreadsheet has a billion rows and a single process to manage it all. As the number of rows increases from a billion to two billion to ten billion, it will become slower and less scalable. But what if it’s not a huge table, but 1000 tabs, like Google Sheets? You can assign data to these tabs through a letter grouping algorithm, so you’ll spread out smaller data sets across many tables. That’s basically how sharding works, and that’s what Shardeum does.

But Shardeum goes a step further. We are not a fixed number of tabs—like 1000—but dynamically adjusting them at runtime. You might start with only 10 tabs, but as the transaction volume increases, you can scale up to 200, 1000, or more tabs. When the transaction volume drops, you can scale back down. This is called dynamic state sharding, and it is what allows us to auto-scale.

There is another important difference. Most blockchains operate around the concept of “Block”, which means that writers must write a complete row in our spreadsheet analogy. This allows the person writing the row to see the pending transactions, which could potentially lead to manipulation— for example, reordering transactions.

Shardeum does not rely on the concept of blocks. Instead, we process transactions in their purest form. The smallest unit we do is a cell in that row. We don’t need to write an entire row at once. While we mock blocks externally for EVM compatibility—so that JSON-RPC clients know how to interact with us—internally, we’re not really constrained by this structure.

This architecture enables us to modify individual cells rather than entire rows, dynamically shard and redistribute workloads based on transaction volume, and horizontally scale with minimal performance bottlenecks. This is a challenging technical problem, but it is precisely this aspect that sets Shardeum apart.

Ehan: So, are there any trade-offs with this auto-scaling design?

Srinivasan: The obvious trade-off is that this design introduces a higher level of communication between nodes. In traditional Blockchain, each validating node maintains a complete copy of the entire Blockchain state — in our previous analogy, essentially the entire spreadsheet. This means that each node requires a significant amount of processing power and storage capacity.

In Shardeum, because we’re dividing the data into smaller fragments—or tabs—each node only needs to process a small fraction, say one out of 1000 tabs. This significantly reduces the compute and storage requirements per node, making it more accessible. The downside, however, is that each node can now only see a portion of the overall state. It’s like only having access to the “A” section of the phone directory.

Therefore, when a Node needs data outside its allocated Shard, it must first determine which Node holds the required data and then request the data from it. This introduces a layer of communication between Nodes, making things more complex.

Nevertheless, we addressed this challenge through a customized communication protocol that enables nodes to efficiently locate and share data. Yes, this adds complexity, but the rewards are immense — Shardeum can scale transaction throughput almost linearly simply by adding more nodes.

Therefore, although inter-process communication in a decentralized environment is a difficult technical challenge — and has not been fully resolved in other systems — we believe we have cracked a scalable model that makes Shardeum a truly unique Layer 1 Blockchain.

What have we learned from the incentive test network?

Ehan: What key insights have you gained from operating a large-scale, truly decentralized incentive testnet?

Srinivasan: yes, that’s a good question. We ran four incentivized testnets with an incredible level of engagement – people running nodes almost all over the globe. Our homepage says “Decentralized for all”, and we really think so. We want to build a system that not only allows people in developed countries with expensive hardware to participate, but also allows anyone—even those with limited resources—to start a node.

This approach helps to promote decentralization while enhancing network security. Therefore, one of the key experiences gained from our incentive testnet is how to make node participation truly global and accessible. We must figure out how to clearly communicate the requirements for nodes, the onboarding steps, how staking and unstaking work, and how to create a user experience that makes these processes intuitive and easy to understand.

Many user experience improvements come directly from observing how people interact with the testnet. We learned which interfaces work best and which aspects can cause confusion. In addition to user experience, we also used the testnet to identify and patch multiple security issues.

Another key insight is about network coordination. When you have many nodes, each with only partial data, you need a strong protocol to achieve consensus — especially since we do not control any nodes. Someone might start a node in Fuzhou, another in Siberia, and another in India — they all need to reach consensus in a decentralized environment. You can imagine having a node in Siberia and another in India — they both need to achieve consensus in a decentralized environment. Ensuring that this coordination can happen smoothly in real-time without centralized control is a huge technical challenge. But solving this problem is the key to what makes Shardeum unique.

What key vulnerabilities have been discovered in the bug bounty program?

Ehan: Can you share the most critical vulnerabilities found in the bug bounty program and how you resolved them?

Srinivasan: Absolutely. We’ve run multiple bug bounty programs, and some of the issues we’ve found are quite unique. First of all, everything we do is open source, so all fixes and changes are publicly visible. Anyone can visit our GitHub repository to see the specific changes we’ve made to support the network.

That being said, we did find some important issues in these plans. Some of these issues relate to how we sign transactions—such as choosing the wrong hash or inconsistencies in the signing process. These vulnerabilities can pose risks, such as replay attacks, where transactions from testnets have the potential to be replayed in mainnet. Therefore, we must carefully analyze and fix all these vulnerabilities.

The vulnerability bounty program is extremely valuable to us. We have discovered a large number of issues, especially in protocol layer features such as multi-signature support, which we have directly implemented at the protocol layer. White hat hackers have helped us rigorously test these functionalities, and their feedback has led to critical security improvements.

All these fixes have now been integrated into our upcoming mainnet version — scheduled to launch on May 5.

How will you handle security issues after the mainnet launch?

Ehan: What measures will Shardeum take for ongoing security monitoring and threat mitigation after the mainnet launch?

Srinivasan: We have taken a multi-layered approach. We have a dedicated internal security team focused on monitoring the health of the system and assessing potential attack vectors.

We have also established and continuously developed a comprehensive telemetry and observability system that allows us to understand in real time what is happening in the network. This enables us to detect anomalies, track system behavior, and respond to threats in a timely manner.

Although we have established this system, we will continue to improve it as we approach the mainnet launch. In fact, we are building a complete open telemetry framework from scratch to ensure that the network remains secure while scaling.

How does your RPC layer differ from other EVM chains?

Ehan: How does Shardeum’s RPC layer differ from other typical EVM compatible chains in terms of performance, scalability, or reliability?

Srinivasan: That’s a good question. As I mentioned earlier, using the spreadsheet analogy — most EVM-compatible chains view the entire blockchain state as one massive spreadsheet, with each Node maintaining the complete data. In contrast, Shardeum breaks this spreadsheet into multiple Shards or tabs, with each tab managed by a portion of the Nodes.

Each process is responsible for one or more specific labels—for example, label 33—and this assignment is dynamic. Shardeum runs on an internal clock cycle of 60 seconds. At the end of each epoch, nodes are rotated: five out of a thousand active nodes may be replaced with five new nodes, which are selected from the standby pool based on certain criteria, such as the length of inactivity. The system then reassigns responsibilities—so a node that just enters may suddenly be responsible for labels 33 and 37 without knowing beforehand and not knowing which other nodes share those responsibilities.

This mechanism greatly enhances security. Randomness and rotation make it extremely difficult to target or influence specific parts of the network. For any transaction to be finally confirmed, a supermajority is required — for example, 67 out of 100 participating nodes must agree. And these 100 nodes do not know who else is in the group, nor do they know how they were selected. This uncertainty helps ensure Decentralization and tamper-resistance.

We refer to this consensus mechanism as Proof of Quorum. It is closely integrated with our 60-second cycle structure. To disrupt the network, an attacker would need to identify and control two-thirds of the randomly assigned set of validators within a cycle — which is nearly impossible.

From a performance perspective, our architecture allows for nearly linear scalability. We can dynamically scale between 100 and 10,000 Sharding (or labels) and reduce when necessary. This flexibility allows Shardeum to excel in scalability, reliability, and security, while maintaining full EVM compatibility through our RPC layer.

Will you continue with the audit and bug bounty program?

Ehan: Does your security policy include ongoing third-party audits or community-driven bug bounty programs?

Srinivasan: Yes, absolutely. We are an open-source project — our entire codebase is available on GitHub — every technical decision we make fully adheres to our commitment to Decentralization. We are very fortunate to have an excellent community supporting us, and we are deeply grateful for this.

We plan to continue collaborating with third-party auditors and launch a community-driven bug bounty program. In fact, we have a dedicated team focused on working with the community to build products around Shardeum. Some of these projects we will help initiate, ultimately handing them over to the community.

We also plan to hold hackathons and other events to encourage active participation from the community. Once we launch the mainnet on May 5, all these initiatives will accelerate. We look forward to the community playing a central role in the continued success of Shardeum.

How do you strengthen the community and ecosystem?

Ehan: How does Shardeum build its community and ecosystem? What specific projects or incentives are the most effective?

Srinivasan: Our community is really one of our greatest strengths. For example, in our recent incentivized testnet, ITN4, we had about 5,200 validators participating globally (171,000 testnets). We’ve built a large and active presence on social platforms like Discord and X, and our ecosystem team is fully committed to engaging with this community and growing it.

We have adopted a phased development approach — first the token transfer functionality, followed by support for smart contracts and other key features. Our community will be involved in the progress of each phase.

We also have a dedicated team focused on designing and executing community projects. This includes incentives, onboarding training, educational content, and collaborative activities to ensure that the ecosystem continues to expand sustainably and in a decentralized manner.

What projects are currently being built on Shardeum?

Ehan: So, what types of projects or applications are currently being developed on Shardeum?

Srinivasan: That’s a good question. As a self-scaling Layer 1 blockchain, Shardeum is particularly well-suited for use cases where scalability and transaction costs are primary concerns. Let me give you an example: at my previous company, we sold NFTs that represented real-world resources, such as horses, for $1,200. At the time, Ethereum’s gas fees were around $200 per transaction. There’s no point in adding a 20% fee to the purchase price—it’s simply not sustainable.

At Shardeum, we have achieved linear scalability, so our gas fees remain low and stable regardless of network congestion — even when a meme coin is launched on the chain. This makes the platform very suitable for fee-sensitive financial and decentralized finance applications.

Since Shardeum is EVM-compatible, developers can deploy Solidity-based smart contracts with minimal effort. Any contracts running on other EVM chains can be easily migrated over. This means we inherit the enormous network effects of the EVM ecosystem—ten years of tools, developer knowledge, and infrastructure.

Therefore, although we have anticipated that decentralized finance and NFT projects will migrate to Shardeum, I believe… structure.

Although we have anticipated that decentralized finance (DeFi) and non-fungible token (NFT) projects will migrate to Shardeum, I believe the community will bring us unexpected surprises. Once the mainnet launches, I hope to see a wave of innovative applications emerge that will fully utilize Shardeum’s EVM compatibility, low fees, reliable performance, and dynamic scalability.

How will the tokens be used for staking and governance?

Ehan: How will the Shardeum token be applied to staking, governance, or network incentives?

Srinivasan: We’re still finalizing the specifics of governance, which will be available soon. That said, our core principle is fully decentralized – anyone who holds a small amount of Shardeum tokens can run a node. These tokens will be available in our token sale.

In terms of incentives, the reward mechanism is based on the participation time of nodes in the “active set,” which is the group of nodes currently participating in consensus. When you start a node, it first joins the “standby pool.” Every 60 seconds, during each cycle of our internal clock, we rotate some nodes out of the active set and introduce new nodes from the standby pool. Once a node enters the active set, it begins to earn rewards.

Rewards are proportional to the active time that nodes participate in network tasks — including validating transactions, signing blocks, and maintaining network security. Node selection will also take past performance records into account. Nodes that meet expectations — online time, responsiveness, and correct behavior — are more likely to remain in the active set for longer, thereby earning more rewards.

We will not punish underperforming nodes, but if a node fails to meet performance standards, it will be rotated out of the active set more quickly, reducing its ability to earn rewards. This is a gentler, incentive-based approach to guide behavior rather than direct punishment.

These contents are still being refined, and more details about the governance and reward mechanisms will be announced before the mainnet launch. Please stay tuned to 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 great question. As I mentioned earlier, Shardeum is a completely open-source project. Everything we do is public—it’s like working in a fishbowl. All of our code is available on GitHub, and anyone can see how our system works.

You can check our consensus mechanism, the algorithms used for node selection and reward distribution, as well as every other aspect of the protocol. The logic behind node performance evaluation and network expansion decisions is completely transparent.

After the mainnet launch, we will no longer have any centralized control over who can start nodes or where to start nodes. The design of the network is aimed at adapting to a decentralized environment, dynamically handling node participation and consensus. This openness and lack of centralized authority is the foundation of Shardeum’s commitment to transparency and independence.

When will the mainnet launch, and why is this important?

Ehan: Can you share the recently announced mainnet launch date and what this milestone means for Shardeum?

Srinivasan: Our mainnet will launch on May 5, which is an important milestone for Shardeum. This network has been in development for some time, and we have an excellent team working on it.

The importance of this launch lies in the complexity we are building. The automatic scaling of Level 1 Blockchain, as well as the design of an entirely new transaction protocol, are highly challenging technical tasks — this requires time and profound expertise.

We believe that now is the best time for Shardeum to enter the next phase. The launch of the mainnet will be carried out in stages, with the first phase starting on May 5. From then on, we will gradually introduce more community-oriented features, continue to improve performance, and make the system more scalable and accessible to users worldwide.

How will you attract and develop a contributor base?

Ehan: What strategies do you have to promote 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 the content being built and how to publish it. We have seen tremendous participation in the previous incentive testnet, and I want to thank all the friends who took part.

Our community team actively collaborates with partners and contributors, and we expect this level of engagement to significantly increase after the mainnet launch. We look forward to continuing to build together with the community.

Ehan: Is there anything else you would like to share with our audience?

Srinivasan: Yes — thank you all for the tremendous support. Your feedback and participation during the testnet have been indispensable in ensuring network security and shaping Shardeum. Please visit shardium.org for the latest updates, and we greatly appreciate your continued support.