Tokenomics

Shardeum employs dynamic state sharding to attain linear scalability, ensuring that every node added boosts network throughput instantly. As a result, Shardeum can enhance its TPS capacity and maintain low fees sustainably. Our simulations revealed that the economics of linear scalability required a unique approach to how the native coin SHM is issued.

1.1 SHM Coin

The native coin on Shardeum is Shard and has SHM as its ticker symbol. SHM is the foundational monetary unit of Shardeum and serves a wide range of functions. Each SHM is divisible to 18 digits, similar to ETH on the Ethereum network. We will also refer to it as the SHM token, since a tokenized version of the coin is also used by smart contracts and to be consistent with common terminology.

SHM is a utility token with various uses, including:

Staking: Network participants can stake their SHM, increase the network’s overall security and earn rewards for their active participation.
Governance: SHM is a governance token conferring stakers governance rights, allowing them to decide and vote on the future of the network. Shardeum will not use a 1 token 1 vote system
Reward Token: SHM is given as a reward, for example: via airdrop, ecosystem rewards and network participation
Gas Token: SHM is a gas token allowing network users to pay fees to execute the required compute units for transactions and other more complex transactions involving smart contracts on the network
Transaction Fee Burning: All transaction (tx) fees on Shardeum are burned, allowing the network to remove the SHM from the circulating supply
User Staking: We are considering the possibility of users staking during deflationary periods. Since Shardeum is not based on Delegated Proof of Stake (DPoS), there are no delegation pools

1.2 SHM Allocation

Max supply: 508 million SHM

Distribution:

51% Community (259,080,000 SHM) – reward to validator and archiver nodes
18% Sale (91,440,000 SHM) – 3 month cliff then 2 year daily linear vesting
15% Team (76,200,000 SHM) – 3 month cliff then 2 year daily linear vesting
11% Foundation (55,880,000 SHM) – unlocked at Token Generation Event (TGE)
5% Ecosystem (25,400,000 SHM) – unlocked at TGE

Since transaction fees are burned, the maximum SHM supply of 508 million will never be reached. The following image shows the SHM distribution as a bar chart and pie graph.

1.3 Sale

Of the 18% of SHM supply allocated for Sale, about 32% has been sold to private investors in two seed rounds.

Seed Round (September '22) - $0.80 per SHM, $18,719,600 raised
Strategic Round (June '23) - $1.00 per SHM, $5,916,037 raised

1.4 Shardus License

The Shardeum project will obtain a license for the Shardus software by allowing Shardus token (ULT) holders to claim 1% of the max supply (5,080,000 SHM) in proportion to the Shardus tokens they hold. More details about the claim event will be posted on the Shardeum website in the near future. The founders and several members of the team hold Shardus tokens.

1.5 Emission After Genesis

The following accounts will receive SHM immediately at Genesis/mainnet launch:

Foundation account: 11% of 508M; 55.88M SHM; becomes available at mainnet launch
Ecosystem account: 5% of 508M; 25.4M SHM; becomes available at mainnet launch

The following accounts will start receiving SHM 3 months (90 days) after the mainnet launch in 730 daily installments:

Team account: 15% of 508M; 76.2M SHM; about 104,383 SHM per day after 90 days
Sale account: 18% of 508M; 91.44M SHM, about 125,260 SHM per day after 90 days

The remaining 51% is set aside for node rewards; SHM is created when given, starting at mainnet launch, based on the node reward setting.

The graph below shows the liquid supply of SHM in the 820 days after network Genesis. The data encompasses the entire Team and Sale SHM vesting period, but does not include any of the 51% SHM supply that will be used for node reward during this time.

1.6 Monetary Policy

The Shardeum monetary policy has been designed with help and feedback from the community since April 2022.

The SHM monetary policy is designed to make the supply stable, predictable, adaptable and scarce. First, we will evaluate how SHM is scarce:

SHM has a fixed max supply, making it a deflationary asset
There will only ever be a maximum of 508,000,000 in existence and this parameter is inalterable even by any form of future voting
All transaction fees are burned on Shardeum, with no transaction fees going to any miner or validator nodes, making SHM scarcer by design
SHM tokens from slashed validators are also burned, adding to the scarcity of SHM
This fee structure bolsters the scarcity of SHM’s tokenomics as Shardeum undergoes technological maturity and sees greater adoption (with increased transaction total, smart contract deployments, etc.) SHM’s supply will likely become ultra deflationary as the number of burned tokens will become higher than those given out as node rewards

In summary, Shardeum’s tokenomics have been designed to be programmatically scarce at launch and for the scarcity to increase simultaneously with increased burning, linear scaling and overall adoption, making it exceptionally scarce in the future.

1.6.1 Design Considerations

The first step in understanding why a unique issuance method is required is to comprehend how Shardeum scales from a hardware perspective. Shardeum increases its network throughput (TPS) by increasing the number of active validator nodes. This requires a pool of standby nodes to be ready to join as needed. The rewards given to active validator nodes must be enough to ensure that the nodes will be profitable, even though they would not be earning any rewards while in standby. By increasing the reward given to active validators the network can ensure there will be sufficient nodes ready to join when traffic (TPS) increases. Not having enough standby nodes to draw from would cause the active nodes in the network to become overloaded and the network would have to reject some transactions.

The figures below compare horizontal and vertical scaling. The two figures on the right demonstrate how non-sharded networks achieve higher throughput (TPS) by scaling vertically; this scaling method increases the CPU, RAM and network resources of each node to increase the network's capacity. This approach has two significant drawbacks. Firstly, no matter how many nodes join the network, the lowest-performing node will determine the TPS (lower right figure). The other drawback is hardware cost; these networks require high-end equipment to reach high network capacity, making it expensive to become a validator and reducing overall decentralization. Shardeum uses horizontal scaling to increase network throughput (TPS). As demonstrated by the two figures on the left; this approach adds more nodes with similar resources per node and uses parallel processing to increase the network's capacity. The network TPS is practically unlimited, providing more nodes can be added to the network (lower left figure) and due to the low hardware cost/requirement, overall decentralization increases.

Unstable validator numbers pose a significantly higher risk for a sharded horizontally scaling network like Shardeum; this is because if the network becomes unprofitable for the node operators and the number of validators drops, so does network throughput (lower left figure), this could result in probabilistic transaction rejection as a result of TPS decreasing or the network coming to a temporary halt due to the network safety mode being triggered. These risks don't apply to non-sharded vertically scaling networks because the lowest performing node determines network throughput (TPS); if validator numbers reduce, the network throughput (TPS) stays the same (lower right figure).

1.6.2 Existing Approaches

Scaled predefined issuance schedules reduce reward percentage through disinflation at different points, whether approximately every 4 years (210,000 blocks) as in the case of Bitcoin or every year with a 1.5% disinflation rate as in the case of Solana. Linear issuance schedules mint a set amount of the network’s native asset over a specified duration and this is the issuance schedule of projects like Algorand. These issuance schedules did not apply to Shardeum; they caused an inefficient and unpredictable network, a lack of profitability, or too high an APY for long-term sustainability.

Secondly, we ran simulations on the network to see how some of these pre-existing tokenomics models applied to SHM, confirming they were not applicable due to the aforementioned reasons and that the optimal SHM model would always be flexible enough to reach supply equilibrium.

Thirdly, the unique scalability properties of Shardeum, necessitate a unique tokenomics model and monetary policy. Shardeum can automatically assemble and disassemble shards to expand and contract the network to increase throughput or storage capacity, as Shardeum uses dynamic state sharding, autoscaling and linear scaling to solve the blockchain trilemma.

These unique scalability properties necessitated the creation of standby nodes and active nodes. The ratio between these nodes is called the S:A ratio and is critical to the efficient and secure operation of the network. The S:A ratio is the number of standby nodes to the number of active nodes. Standby nodes are randomly selected each cycle and rotated into the active set to start consensus; simultaneously, active nodes participating in the active set for the longest time are removed and rotated back into the standby set, becoming standby nodes again. This kind of rotation increases node and network decentralization. A higher S:A ratio ensures the network can scale more effectively, enhances decentralization and mitigates the risk of a majority takeover or a Sybil attack. If the S:A ratio gets too high, negligible benefit to the network occurs and can lead to the network becoming inefficient. Conversely, the network is more efficient if the S:A ratio is lower, but if the ratio falls too low, it poses the most significant risk because the network would lose its ability to scale.

The graphs below demonstrate how following a predefined issuance schedule with a horizontally scaling architecture results in massive fluctuations in APY%. In the bull case (Ethereum), the native asset increases in value rapidly, causing the network to become wildly profitable for node operators and resulting in the network becoming inefficient (delivering a higher APY% than needed). In the bear case (Algorand), the price of the native asset decreases, which results in the network becoming unprofitable for node providers (delivering negative APY% returns when hardware expenses are considered). The likely outcome would be a massive reduction in node operators; this causes significant problems for horizontally scaling networks, which could mean the network loses its ability to scale (increase TPS).

In reality, in the Shardeum network, APY% would likely always find some form of equilibrium; when the network is more profitable, it would have a much higher S:A ratio. Likewise, the S:A ratio would reduce if the network becomes less profitable. The graphs below highlight how, depending on native token price action, the network could end up in the bull case (Ethereum) with an S:A ratio that is unnecessarily high and wasteful of computing resources. In the bear case (Algorand), the S:A ratio could become so low it compromises security and could cause the network to lose its ability to scale (increase TPS).

An active node can only collect the reward after it has been cycled out of the active set into a standby node and is no longer active. Giving a reward to standby nodes would incentivize them to try and collect the reward without actually participating in the network and going active. Thus, standby nodes do not receive a reward.

We deduced the ideal issuance approach would be adaptable enough to:

Ensure running a validator node on Shardeum is profitable, providing reasonable hardware costs
Ensure the SHM supply is always heading toward equilibrium (SHM burned = SHM issued), enabling the network to reward node operators forever
Keep the S:A ratio high enough that the network always retains its ability to scale and never sacrifices security
Keep the S:A ratio low enough so that the network never issues more SHM than required to secure the network and avoid the unnecessary waste of natural and computational resources
Actively promote network efficiency by adjusting the validator node reward to ensure operators receive just enough APY% to match market rates

All pre-existing monetary policies achieved only some of the above. Therefore, we opted for a bespoke approach called a capped elastic supply model.

1.6.3 Capped Elastic Supply

A capped elastic supply model is a tokenomics model in which the token issuance schedule is elastic and not predefined. Token issuance can be inflationary, deflationary, or disinflationary, depending on what is optimal in the current micro or macroeconomic environment. A capped elastic supply model allows optimal token issuance in the overall economic climate but will never exceed its maximum supply (508 million).

1.6.3.1 Adjustable Parameters

The literature above shows that controlling the S:A ratio and finding supply equilibrium is critical to the network’s smooth yet efficient operation. We understand that attempting to predict countless variables to create a predefined issuance schedule is impossible. Instead, we introduce a small number of adjustable network parameters that can initially be overseen by the FDAO.

FDAO - We refer to the Foundation and DAO collectively as the FDAO. The adjustable parameters are:

Tx Fee $ - This is the target fee for a token transfer transaction. The complexity of the transaction determines the fee paid. For example, simple SHM transfer transactions will cost less; more complex transactions, such as AMM transactions, will cost more.

Adjusting this parameter can either increase or decrease the network income (daily tx volume * tx fee) because all tx fees are burned; this parameter can cause the supply to be inflationary or deflationary and steer it towards equilibrium.

Node Reward $/hr - This defines how much each active node in the network receives as dollars per hour. Although it is specified in $, it is paid out in SHM.

Adjusting this parameter can increase or decrease the network operating cost (active nodes * node reward). Because the node reward parameter is how new SHM are issued; this parameter can cause the supply to be inflationary or deflationary and steer it towards equilibrium.

The secondary impact this parameter can have is either increasing or decreasing the S:A ratio. If the node reward per hour increases, the network can sustain a higher number of nodes at a given APY%, increasing the S:A ratio. Conversely, if the node reward per hour is reduced, the network will not be able to sustain the current number of nodes at a given APY%, causing the S:A ratio to reduce.

Stake Amount $ - The amount of SHM a node must stake to join the network. It is specified in $ but staked in SHM based on the Stable Price. Some or all of the stake can be lost if the node misbehaves or falls behind in processing; this ensures that operators run nodes on suitable hardware.

Adjusting this parameter can either increase or decrease a node’s overall APY(%)/year (100 income 365 / stake amount); this will either increase or reduce the S:A ratio as running a node becomes more or less profitable.

1.6.3.2 Effects on Supply

It’s essential to understand how the relationship between the tx fee $ and node reward $/hr allows the supply to be elastic. This relationship can be in one of three states:

If Network Revenue < Network Expense then Supply Inflation

where

Network Revenue = daily tx volume \tx fee $*

Network Expense = active nodes node reward $/hr 24

Supply Inflation: If the network’s daily revenue (from transaction fees) is less than its daily expenses (the cost of operating nodes), the network is not generating enough income to cover its costs (pay node operators). In this case, the network will issue more SHM to node operators than it is burning from transaction fees. The network will become inflationary, increasing the supply of SHM in circulation.

If Network Revenue > Network Expense then Supply Deflation

Supply Deflation: If the network’s daily revenue (from transaction fees) is greater than its daily expenses (the cost of operating nodes), the network is generating more income than it needs to cover its costs (pay node operators). In this scenario, because all the transaction fees are burned, the network will become deflationary, reducing the supply of SHM in circulation.

If Network Revenue = Network Expense then Supply Equilibrium

Supply Equilibrium: When the network’s daily revenue (from transaction fees) equals its daily expenses (the cost of operating nodes), it operates in a balanced financial state. In this case, the network is neither inflating nor deflating its token supply; it’s maintaining a stable supply (Equilibrium).

If the parameters overseen by the FDAO can change which of these states the network is in, it will ensure smooth and efficient operation.

1.6.3.3 Static Simulations

The left figure below shows the network has a positive income and delta; this means it generates more income from transaction fees than it spends paying nodes for validating the network. In this case, the network is deflationary because it will burn more SHM from the transaction fees than it will be issuing to the node operators.

The right figure below demonstrates how changing a single FDAO-overseen variable can move the network into a different issuance state. The node reward $/hr variable was adjusted from $1 to $1.2, balancing the revenue and expenditure of the network, resulting in the network finding supply equilibrium.

The left figure below demonstrates how a change to another key FDAO-overseen variable (tx fee $) can impact the issuance state. In the example below, the network is moved from the equilibrium state in the above right figure to an inflationary state with a minor change to the tx fee $; after the change, the network is issuing more SHM via node reward than it’s burning from the received transaction fees.

The right figure below is another example of how the FDAO-overseen variables can be changed to create a state of supply equilibrium. In this example, the tx fee $ and node reward $/hr variables are used to balance the network revenues and expenses (run more parameter scenarios here).

1.6.3.3 Model Properties

In a previous section, we discussed how no pre-existing issuance model satisfied all the ideal criteria required to guarantee the network’s secure, efficient and smooth operation.

In this section, we will discuss how using a capped elastic supply model will:

Ensure running a validator node on Shardeum is profitable, providing reasonable hardware costs

If running a validator node becomes unprofitable, the S:A ratio will begin to reduce as some node operators unstake and leave the network; this reduction in S:A ratio will mean the remaining nodes will spend less time in standby and more time earning rewards for actively validating the network. If the S:A ratio reduction is too extreme, the node reward $/hr parameter can be increased to make the network more profitable and ensure an adequate S:A ratio.

Ensure the SHM supply is always heading toward equilibrium (SHM burned =SHM issued), enabling the network to reward node operators forever

We can not know demand, usage and adoption in advance; having a capped elastic supply model allows us to oversee and respond to these unpredictable factors optimally and not contribute to a misalignment of incentives, which need to be sufficiently adjustable as would be the case with other models.

The adjustable network parameters, specifically tx fee $ and node reward $/hr, can push the supply into an inflationary or deflationary state; having the ability to control this means the supply can be encouraged to find equilibrium (SHM burned = SHM issued); maximum supply (508 million) should never be reached and the network will always have SHM to issue to incentivize node operators.

Keep the S:A ratio high enough that the network always retains its ability to scale and never sacrifices security

The S:A ratio can be raised by increasing the node reward $/hr parameter. The FDAO will actively monitor the S:A ratio; if it drops low enough that security or the network’s ability to scale is compromised, the increase in node reward $/hr will make the network more profitable (able to sustain more nodes at a given APY%), attracting more node operators to the network and therefore increasing the S:A ratio.

Keep the S:A ratio low enough so that the network never issues more SHM than required to secure the network and avoid the pointless waste of natural and computational resources

The S:A ratio can be lowered by decreasing the node reward $/hr parameter. The FDAO will actively monitor the S:A ratio; it is deemed inefficient if it reaches a level that no longer benefits the network from a security or scalability perspective; the decrease in node reward $/hr will make the network less profitable (unable to sustain the current number of nodes at a given APY%), resulting in nodes unstaking, leaving the network and reducing the S:A ratio.

Actively promote network efficiency by rewarding the validator node operators enough APY% to stay in the network but no more

We cannot predict in advance what is “enough” APY% for node operators to continue validating the network; the micro, macro and socio-economic climate all play a significant role in how well entire asset classes perform. The S:A ratio is used as a collective representation of the current economic environment to allow us to make informed decisions on the future profitability of the network.

In the event that the S:A ratio is too high, the node reward $/hr parameter would be lowered to reduce profitability. In these circumstances, the most inefficient nodes will likely leave the network first, as they will become unprofitable sooner, resulting in a consistently efficient network.

1.6.3.5 Dynamic Simulations

We extensively tested our model using the price action and transaction volumes of other well-known Layer 1’s. The model finds equilibrium (SHM burned = SHM issued) naturally or with minor adjustments to the FDAO-overseen parameters in every circumstance.

The figure below shows how Shardeum’s capped elastic supply model would react following Ethereum’s price action and transaction volumes. In the first 180 days, the supply is highly inflationary as transaction volumes are low and the network still needs to reward the validator nodes (600 nodes minimum). Between 180 and 600 days since Genesis, the network transactions continue to increase; this slows supply inflation and finally results in the supply reaching equilibrium from 600 to 2000 days.

Natural equilibrium occurred in almost all our simulations. The figures below are based on the Polygon and Algorand data; both follow the same pattern as the Ethereum simulation above, achieving equilibrium as the network matures.

Occasionally, when we mixed the price and transaction volumes of different networks, we found examples where the supply did not naturally find equilibrium. The FDAO-overseen variables were tweaked in these scenarios to encourage the supply toward equilibrium. The figure below combines price action from the Algorand network and the transaction volumes from Polygon; in this model, the supply initially starts inflationary before quickly becoming highly deflationary.

The following simulation is the same as above with the FDAO-overseen variable Node Reward $/hr changed from $1 to $1.2; this demonstrates how minor changes to these variables can steer the network toward equilibrium.

The following figure combines Polygon price action with Algorand transaction volumes. In this model, the supply still finds equilibrium but at a level that exceeds the node reward max supply (259 million SHM).

The above model can be adjusted to find equilibrium at a lower supply level (figure below) by reducing the FDAO-overseen node reward $/hr from $1 to $0.6.

The above simulations prove that no matter how Shardeum's price and transaction levels materialize, the issuance policy can ensure the SHM supply is always heading toward equilibrium (SHM burned = SHM issued), enabling the network to reward node operators forever (run more simulations here).

Ecosystem

2.1 DApps

Decentralized Applications, commonly known as dApps, are applications that operate on smart contract platforms, eliminating the need for centralized intermediaries while providing transparency, security and immutability. In the Shardeum ecosystem, we encourage and incentivize the development of dApps that are optimized for, or can benefit from, parallel transaction processing. This is particularly beneficial for dApps with high transaction volumes or those that need to execute complex computations that can be broken down into smaller concurrent tasks.

Transactions are processed in a first come first served (FCFS) manner; this approach is beneficial as it provides predictability, fairness, prevents higher fees via bidding, offers MEV resistance and opens up a pathway for new types of dApps. For instance:

Auction Platforms: In an auction, bids should be processed in the order they're made. FCFS ensures that if two participants place a bid at nearly the same time, the one who bid first gets precedence
Ticketing Systems: For events with limited seats or special editions of items, a FCFS system ensures that early birds get the tickets or items without facing potential delays or out-of-order processing
Queue-based Service Platforms: Any dApp where users queue for a service (like a virtual waiting room) would benefit from FCFS. This ensures fairness and reduces potential disputes
Gaming: Certain online games, especially those where players compete for limited in-game resources, could use FCFS to determine the order of acquiring these resources
Decentralized Domain Registration: As new domains or domain extensions become available, FCFS processing can fairly determine who gets a specific domain name if multiple parties are interested

Additionally, we are committed to promoting dApps that are predicated on the usage of low transaction fees, opening the door for innovative use cases previously rendered impractical on other platforms due to prohibitive costs. Such dApps include, but are not limited to:

Loyalty point systems for merchants
Coupon systems for product businesses
Voting systems for small communities
Crowdfunding platforms akin to Kickstarter
Automated payment solutions
Membership services reminiscent of Patreon
Algorithmic stablecoins
Low investment games such as lotteries

The rationale for championing this direction is multifaceted. Our incentivization of dApps reliant on low transaction fees is grounded in our commitment to ushering in a broader array of applications that could revolutionize entire existing industries and even spawn entirely new ones. Furthermore, for the first time ever, dApps can scale to levels commonly found in popular web2 services without reaching bottlenecks. Additionally, all dApps within Shardeum maintain Ethereum compatibility, offering a dual advantage: the vast developer community familiar with Ethereum can easily transition or port their projects to Shardeum while users benefit from the widespread familiarity and trust associated with Ethereum-based applications.

For the Shardeum community, these strategies herald a future of increased innovation, interoperability and inclusivity. The Ethereum compatibility not only ensures the seamless portability of dApps between platforms but also amplifies the potential for Shardeum to integrate with the broader ecosystem, enriching the user experience and fostering a cohesive, interconnected community.

2.2 Relayers

In the Shardeum infrastructure, relayers serve as an integral part of the data propagation mechanism. Once archivers have aggregated the essential data from validators, it is the responsibility of relayers to distribute this consolidated data to various services that require it, such as blockchain explorers, RPCs, exchanges and more. To enhance the efficiency of this data distribution process, there may be hierarchical tiers of relayers, designed to fan out network data extensively across multiple service providers. As the complexity and demand of the Shardeum network evolve, both archivers and relayers are envisaged to vertically scale, ensuring that the pace of data dissemination is always in step with the network's growth.

Contrary to some conventional models, Shardeum's relayers are not directly compensated by the network. This stems from the understanding that these relayers will predominantly be operated by the very services that necessitate the data, such as the explorers. Instead, to foster a vibrant ecosystem, these services are financially supported as ecosystem projects. This model lays the foundation for a novel economic dynamic: certain service providers, instead of operating their own relayers, might opt to subscribe and receive data from relayers managed by third parties.

For the Shardeum network and its community, the proposed approach presents several benefits. Firstly, by decoupling network compensation from relayer operation, it encourages service providers to optimize their infrastructure based on their specific needs, potentially leading to more efficient data distribution pathways. Additionally, the potential emergence of an economic ecosystem for data distribution fosters innovation and diversification in service offerings. This not only enhances the robustness and adaptability of the Shardeum network but also cultivates a community where collaborative synergies are central.

2.3 Connectors

Shardeum uses Remote Procedure Call (RPC) nodes similar to Ethereum. On Shardeum, a RPC node, also called a connector node, acts as a bridge, enabling external clients such as wallets to communicate with the Shardeum networks. By offering an interface to send requests and receive responses, connector nodes allow decentralized applications to access, interact, request, query or retrieve data on distributed ledgers. For example, a client such as Metamask could submit a transaction to the network, which is first passed to the connector node and then forwarded to the active nodes for consensus and validation.

For Shardeum, integrating connector nodes is paramount. Firstly, they provide a streamlined connection point for external applications and services to interact with the Shardeum network, ensuring that these interactions remain efficient and seamless. This is especially vital for facilitating real-time data access, transaction broadcasting and smart contract execution.

Secondly, by acting as intermediaries, connector nodes alleviate the need for every application to run a full node, thereby reducing the overhead and fostering a more scalable ecosystem. Lastly, in a decentralized landscape like Shardeum, connector nodes enhance redundancy. Multiple connector nodes can be deployed across the network, ensuring that even if one faces downtime, applications can reroute their requests for uninterrupted service. In essence, connector nodes fortify Shardeum's infrastructure, promote scalability and ensure consistent and reliable network access for all integrated applications.

Shardeum also encourages third parties to operate connector nodes and will incentivize such operators through the ecosystem fund during an incubation period.

2.4 Explorers

In the realm of decentralized platforms, Shardeum recognizes the significance of building upon proven, user-familiar foundations. Our approach revolves around enhancing Layer 1 scalability and decentralization, while deliberately retaining well-established elements of the ecosystem. This means that instead of reimagining the smart contracting language, the virtual machine, or the explorer, we seek optimizations in areas that genuinely require innovation. Such a strategy is central to achieving swift adoption by both developers and users.

In line with this philosophy, the Shardeum Explorer was conceived with both user-centric and developer-centric design principles. Drawing inspiration from Etherscan, we've ensured the Shardeum Explorer offers a user experience that feels familiar to SHM users and developers previously acquainted with Ethereum. This intentional design continuity not only streamlines the transition for those migrating from Ethereum but also underscores our commitment to enhancing user experience without unnecessary alterations.

Shardeum also encourages third parties to develop Explorers and will incentivize such development through the ecosystem fund during an incubation period.

2.5 Oracles

We believe oracles are an indispensable component of the web3 technology stack and therefore are essential for Shardeum. We will use decentralized oracles networks (DONs) which will allow on-chain smart contracts to be empowered by off-chain data such as price feeds, data feeds and hybrid smart contracts. DONs are necessary for Shardeum as they provide cryptographic truth guarantees which are both tamper-proof and immutable; unlocking the next generation of advanced decentralized applications. Here’s some of the potential use cases unlocked by DONs interacting with Shardeum:

Any stablecoins require oracles for accurate price pegging
AMMs, DEXs and other DeFi protocols require accurate data feeds of token pairs
Collateralization and loans also require accurate data feeds of prices to prevent users getting prematurely and unfairly liquidated
Prediction markets and futures require oracles to provide authentic off-chain data for proof of outside events
Mirroring of financial assets and instruments require accurate data feeds of the assets
Commodity prices
Election results
Proof of events

Furthermore, beyond price feeds, data feeds and hybrid smart contracts, DONs facilitate other forms of smart contract applications using a Verifiable Random Function (VRF) which generates random numbers and can be used in other smart contracts for lottery or gaming applications.

Consequently, DONs will broaden the sphere of possible applications on Shardeum and enhance security through authentication of off-chain data, mitigating the risks of inaccurate data and any potential arbitrage opportunities that could be exploited if a centralized data feed were used. Ultimately, DONs on Shardeum expand the utility of smart contracts, facilitating the creation of advanced hybrid decentralized applications that are turbo-charged with real-world data sources that are both immutable and verified.

2.6 Bridges

Lack of interoperability between disparate networks has been a much remarked upon problem historically but recent solutions in the form of bridges, trust-minimized communication protocols such as the Interblockchain Communications Protocol (IBC) and cross-consensus messaging formats such as (XCMP) have all facilitated interoperability between heterogeneous blockchains.

Shardeum will benefit from the interoperability solutions that have already been developed. It shares the sentiment espoused by other networks that heterogeneous chains should be able to transact and interact and thus that interoperability between networks is a necessary feature.

Initially, Shardeum will accomplish interoperability through integration with multi-chain protocols and cross-chain bridges such as Axelar and Layer 0. Bridges facilitate cross-chain transactions and asset flows between disparate Layer 0, Layer 1 and Layer 2 networks. This bestows numerous benefits upon Shardeum, as well as other networks with which it interoperates, including:

Interoperability between key Layer 0, Layer 1 and Layer 2 ecosystems
Increased SHM utility and functionality as SHM can now be integrated into DEXs, AMMs, liquidity, treasury and other types of dApps and DeFi instruments
Increased utility for external assets from Layer 0s, Layer 1s and Layer 2s entering the Shardeum ecosystem, enabling their integration with DEXs, AMMs, liquidity pools and other DeFi platforms on Shardeum
Cross-chain transactions
Cross-chain liquidity pools for DEXs, AMMs, liquidity pools and other types of DeFi primitives
Cross-chain DAO treasuries
Expanding Shardeum’s dApps and SHM use cases
Inherently larger user base for SHM and dApps on SHM
Opening up multi-market liquidity opportunities on different networks
Unlocking multi-chain future and streamlining the creation of multi-chain dApps between disparate networks

Besides Bridges, a crucial technological component is our smart contract interoperability facilitated by the EVM. This will allow existing dApps that enable synthetic and atomic swaps to be deployed on the Shardeum network, thereby reducing the need to use a bridge.

2.7 Wallets

Cryptographic wallets serve as digital interfaces that facilitate the generation, storage and management of cryptographic keys, enabling users to interact with DLTs. These keys represent a user’s digital identity and ownership of assets on a network. At Shardeum, while we recognise the importance of wallets in the web3 space, we have strategically chosen not to develop our own proprietary wallet solution. Instead, we prioritize ensuring that our network is accessible via RPCs and thus making it compatible with a wide range of existing Ethereum wallet providers.

There are several critical reasons underpinning our decision. By choosing not to create a Shardeum-specific wallet, we avoid misallocating our efforts and instead can direct our resources toward mission critical areas, like enhancing the core infrastructure to optimize performance, scalability, and security. Furthermore, this approach promotes the seamless integration of Shardeum with renowned and widely adopted wallets such as Metamask. Due to the native Ethereum compatibility of Shardeum, users can leverage their favorite and most familiar wallets when interacting with our network. This level of compatibility not only lowers the barrier of entry for new users but also reduces fragmentation in the user experience.

For the Shardeum community, the implications are profound. By ensuring compatibility with well-established Ethereum wallets, users benefit from the reliability and security that the best Ethereum compatible wallets have to offer. Additionally, this compatibility reinforces the ease of transition and continuity of experience for prior Ethereum users and developers looking to explore Shardeum.

2.8 Shardus

The Shardeum project will continue to support the development of the Shardus protocol. Even after mainnet launch it is expected that upgrades and enhancements to the Shardus protocol layer will be needed. Shardeum views Shardus as a critical component of the ecosystem and will continue to support it in the future. Shardeum will also be obtaining a license to the Shardus software as mentioned in the Tokenomics section. The founders and several members of the team hold Shardus tokens.

Shreya Bhardwaj's blog