Shardeum is an EVM-based, autoscaling L1 blockchain that uses dynamic state sharding to scale linearly and maintain low gas fees forever with true decentralization and solid security.
Shardeum aims to be the smart contract platform that can onboard over a billion people to the blockchain and decentralization movement by addressing the scalability trilemma. Our mission, ‘Decentralization for everyone,’ reflects our commitment to making blockchain technology both affordable and accessible.
OCC is short for Open, Collaborative and Community-Driven. OCC is the core principle of Shardeum. Much like the Internet, Shardeum will be open, collaborative, and community-driven and would democratize accessibility to decentralization. Shardeum will be the infrastructure on which the next iteration of the Internet, Web3, will be built.
Yes. SHARD (SHM) will be the name of the token. It is still in the development stage
Here is the link to Shardeum whitepaper.
You can find our roadmap here.
Shardeum recently implemented code freeze, positioning our latest incentivized testnet as the final phase prior to mainnet. After successfully completing the incentivized testnet and resolving the issues identified by our engineering team, Shardeum is set to proceed with its mainnet launch, currently planned for Q1 (March) 2025, as outlined in the roadmap.
As announced here, Shardeum has implemented code freeze on December 17th, 2024 — a critical milestone as we approach mainnet.
What does it mean?
We will announce the details via our official channels soon. Stay tuned!
Energy efficiency means the consensus algorithm used by the network should not require excessive energy beyond what is necessary to process the transactions. Bitcoin and other networks based on the Nakamoto consensus are designed to use high energy expenditure to secure the network from a 51% attack. However, efficient consensus algorithms such as Paxos and PBFT do not require high energy expenditure. The tradeoff is that these algorithms need the nodes to be assigned a node id before joining the network. Thus, these algorithms have been used in permissioned networks and not for nodes that can participate without requiring a node ID.
Shardeum will use an energy-efficient consensus algorithm that requires nodes to have a node ID upon joining the network. However, a novel approach does not need a central entity to decide which nodes are part of the network.
Autoscaling means that the network should self-govern the number of nodes the network needs and properly incentivize nodes to achieve the desired size. This implies that the network can effectively use the available nodes to achieve desired tradeoffs, for example, scaling of throughput proportional to the number of nodes available. Otherwise, there is no benefit in a network trying to auto-scale.
In networks like Bitcoin, there are conflicts in the desired size of the network. The low bandwidth requirement would favor having as few nodes as possible. In contrast, the high security and decentralization requirement would prefer having as many (unrelated) nodes as possible. Shardeum will aim to build a network that can auto-scale.
Fast finality means having a quick turnaround time between submitting a transaction to the network and knowing that the transaction is irreversible.
In networks like Bitcoin, there is a probabilistic finality time. The longer you wait, the lower the chance that a transaction confirmed in a block cannot be reversed. Thus, the finality time is not just for the transaction being included in a block. Still, some blocks are being produced after that to reduce the probability of the transaction being reversed. For large value transfers on the Bitcoin network, it is recommended to wait for at least six blocks (about an hour) to ensure irreversibility.
Shardeum’s immediate finality sets it apart from other blockchains, which offer probabilistic or absolute finality. It is further a breakthrough in blockchain technology, as it provides finality without the need to wait for multiple blocks to be confirmed. You can read more about this in our detailed blog.
Low bandwidth means that the network should minimize the amount of data transfer needed when distributing transactions and achieving consensus.
This does not imply just compressing the data or using binary formats; instead, the more critical factors are network architecture and algorithmic details of the consensus algorithm. In bitcoin-like networks, adding more nodes increases the amount of bandwidth used to process each transaction.
Shardeum will aim to create a network where the amount of bandwidth consumed by a transaction is constant and does not increase proportionally to the number of nodes.
Low latency means the total turnaround time between submitting a valid transaction to the network and knowing that the network has committed to the transaction in a short period of time.
In networks like Bitcoin, latency is the time between submitting the transaction and including it in a block. For such networks, the fastest latency is no less than the average block production time which is around 10 minutes.
Shardeum will provide a latency of just a few seconds by processing each transaction individually before grouping them into blocks.
High capacity means that the network should provide persistent storage for massive amounts of state data. Global-scale applications could require exabytes of state data. The current blockchains and distributed ledgers appear to be functional only because they have not been stressed in this dimension.
Shardeum will aim to build a network that can horizontally scale throughput and capacity.
High fairness means that a transaction received by the network earlier than another one should be processed accordingly.
In a blockchain-based network, transactions within a block are considered to have occurred simultaneously, and the order in which they are applied does not matter. For some applications like games, this does not provide sufficient time resolution. Also, it is possible for transactions that were received much later to be processed before earlier transactions. In bitcoin-like networks, you can get priority by paying more gas.
Shardeum will aim to create a network that processes and applies transactions in the order received. You can take a look at this blog that goes into details of why time based transactions ordering have been practically hard to implement so far and how Shardeum will process transactions in a FCFS basis as a result of its design to solve scalability trilemma.
High throughput means that the network should process a vast number of transactions per second.
In networks like Bitcoin, where every node must process every transaction (i.e., validate and apply), the bottleneck is the processing power of the slowest full nodes. If the bitcoin network were to increase the self-imposed block size limit, it would run into a more natural bottleneck of processing power. The only way to speed up the network would be to raise the processing power of all the nodes (vertical scaling). So all networks where every full node must process every transaction have the same theoretical throughput limit.
But in actuality, we see considerable differences when comparing networks like Bitcoin, Litecoin, and Dash. These differences are mainly due to different self-imposed block size limits and block rates. If devs removed these self-imposed limits, the differences due to different consensus algorithms would start to appear. Networks that used proof-of-stake would be much faster than networks that used proof-of-work since the node’s processing power is not being used up by proof-of-work computation. Ideally, the rate at which the network processes transactions should be proportional to the number of nodes in the network. Increasing throughput means increasing the number of nodes (horizontal scaling). Shardeum will aim to build a horizontally scalable network.
In simple words, sharding breaks the job of validating and confirming transactions into small and manageable bits, or shards. While sharding is ultimately the best way to tackle the scalability issue, applying it to blockchain-based networks is not nearly as easy as applying it to centralized databases.
The good news with Shardeum is that the consensus and processing are done at the transaction level and not at the block level. And, through dynamic state sharding, the network will shard its state by evenly and dynamically distributing compute workload, storage, and bandwidth among all the nodes. This not only allows for parallel processing of transactions but also very low storage requirements for validator nodes as they will store only the state data of transactions/accounts they are involved in.
The protocol assigns each node to cover one or more unique address ranges in such a way that for any given address there is a well defined number of nodes holding the data for that address. Each node added to the network allows other nodes to slightly reduce the total addresses they cover while still ensuring that any given address has the specified level of redundancy.
And why are they important? Well, this is how Shardeum will get to maintain low transaction fees for developers and end users forever. Dynamic state sharding will help the network to scale linearly making it the first Web3 network to do so. Read this blog for a more detailed explanation of how Shardeum will make use of dynamic state sharding.
With the help of dynamic state sharding, every node added to the network will increase the transaction throughput instantly. By simply adding more nodes from the network’s ‘standby nodes’ set during peak demand, the TPS will increase proportionally making Shardeum the first Web3 network to scale linearly. And this is the main X factor that impacts every other outcome on a blockchain network favorably including throughput, decentralization, security, and constant transaction fees irrespective of the demand in the network.
We are glad to inform you that Shardeum’s source code is open-sourced as we completed defensive patent filings for innovations in our protocol, including the consensus algorithm, autoscaling, and dynamic state sharding.
We have a dedicated webpage for our open-source initiatives. Explore all our projects, discuss your ideas and questions with our open-source team, and contribute to the development. Visit the webpage here.
Yes, we are planning a bug bounty program in early Q1 2025, as outlined in our updated roadmap, to support preparations for the mainnet launch.
Validator Nodes (also known as Validators):
These nodes validate network transactions by actively participating in the consensus process. Shardeum rewards honest validators with SHM. Validator nodes store only the state of the accounts they manage, ensuring they remain lightweight, while historical data is offloaded to archive nodes. To participate, validators must stake SHM and may face slashing penalties for non-compliance with network protocols, such as leaving the network prematurely or failing to sync on time, among other violations. Detailed information will be shared in the months leading up to the mainnet launch
Archive Nodes:
Archive nodes maintain the entire transaction history. Archive nodes may also be required to stake SHM and could face slashing penalties for failing to adhere to network protocols, such as leaving the network without prior approval. Additional details will be provided in due course. The reward for running an archiver is expected to be about 10x more than running a validator since the hardware requirements for running an archiver will be much higher.
Standby Nodes:
Standby nodes are validator nodes within the network that are not actively participating in consensus. These nodes enable the Shardeum network to scale quickly when transaction volume increases. To ensure optimal security and fairness, the network randomly rotates the oldest active validators out at the end of each cycle, replacing them with standby validators. Standby nodes must have SHM staked to become active and are eligible for rewards only after successfully completing their active validator period.
Other than the aforementioned nodes, there are other types of nodes needed to move data and transactions in and out of the Shardeum as well as monitor the health of the network. These include connector nodes, relayer nodes, and additionally, a monitor server. The connector nodes provide an entry point for external wallets and clients to query and submit transactions to the network. These are the similar to RPC nodes in the Ethereum ecosystem. Relayer nodes communicate with archiver nodes or other relayer nodes to store and stream data produced by the network to downstream services used by exchanges and explorer services. These are similar to exit nodes in the Ethereum ecosystem. The monitor server is an important component here receiving status updates from active validator nodes and providing a visual view into the health of the network. You can read more about them in our whitepaper.
You can express your interest in partnering with Shardeum by submitting the partnership enquiry form. You can also alternatively reach out to Hasan Ansari, our Ecosystem Projects and Investor Relations Manager. You can start with submitting the partnership enquiry form though which will help us to understand your needs better and how we can best partner with you.
We are pleased to partner with anyone who wants to use our secure and scalable technology to provide their solutions and products to their end users. You can start by submitting the partnership enquiry form.
Shardeum is built with scalability, security, and decentralization in mind. To date, many L2s are viewed as a mitigation for L1’s inability to solve the blockchain trilemma. Shardeum combines the decentralization and security of legacy blockchains with with innovative, virtually limitless linear scalability. Thus it is solving all the problems at the root level as a L1 blockchain. Keep in mind though, as a permissionless blockchain platform, you can deploy any type of dapps and integrations, including layer 2 and enterprise solutions for additional privacy and other use cases.
Any EVM-based wallet will work on Shardeum. Developers can also develop and deploy new EVM-compatible wallets on/for the network.
| Features | Shardeum | Harmony | Near | Elrond |
|---|---|---|---|---|
| EVM Compatible | Yes | Yes | via Aurora | No (WASM) |
| Smart Contract Language | Solidity, Vyper | Solidity, Vyper | Rust | C, C++, C#, Rust |
| Explorer | EtherScan-like | Custom | Custom | Custom |
| Tx Fees in $ | Very Low & Constant | 0.000001 | 0.00044 | 0.005 |
| Txs Per Second (TPS) | 1 per node (100k TPS @ 100k nodes) | 2k per shard (8k TPS @ 4 shards) | 10k per shard (100k TPS @10 shards) | 3.75k per shard (15k TPS @ 4 shards) |
| Nodes per Shard | 128 | 250 | 100 | 800 |
| Latency | 10 Sec always for EIP2930 txs | 10 Sec per involved shard | 10 Sec per involved shard | 10 Sec per involved shard |
| Consensus Algorithm | PoQ + PoS | FBFT | PBFT | SPoS |
| Consensus Level | Transaction | Block | Block | Block |
| Current Shards | NA | 4 but contracts on 1 | 1 unsharded | 3 + metachain |
| Sharding Type | Dynamic | Static | Static | Static |
| Scaling Type | Linear TPS per node | Stepwise TPS per shard | Stepwise TPS per shard | Stepwise TPS per shard |
| Archive Nodes | Yes | No | No | No |
| Cross Shard Composability | Yes | No | No | No |
No. The TPS (transactions per second) of a blockchain network should be based solely on the transactions initiated by actual users which are processed successfully. So ideally, TPS should exclude internal network activities, say, between nodes on the network, and it should also exclude any failed transactions.
