TokenStake
TokenStake

About Elrond

Elrond is a high-throughput public blockchain focused on providing security, efficiency, scalability, and interoperability by employing two key elements: Adaptive State Sharding and a new Secure Proof of Stake (“SPoS”) consensus mechanism. Elrond is a complete redesign of blockchain architecture with the aim to achieve global scalability and near instant transaction speed.

How is Elrond different?

State sharding

The Elrond network is the first to present a viable solution where all the three aspects of sharding - state, network and transactions - have been implemented at once. Combined with its “Adaptive” component, this novel architecture allows for dynamic network configuration to maintain a high level of security while scaling with demand.

Secure Proof of Stake

In addition to scaling through sharding, Elrond also approaches the consensus problem with a mechanism called Secure Proof of Stake, which mitigates potential attack vectors when compared to Proof of Work, while also enabling large throughput and fast execution.

Low cost per transaction

By solving some of the hardest consensus and sharding problems in the blockchain space, Elrond is able to provide a very high level of performance on a network made of inexpensive computers, which results in a very low cost per transaction. In addition to performance and cost, Elrond also stands out through the quality of the developer experience and the resulting boost in usability on the end-user side.

Important achievements

First live blockchain architecture with state sharding
Mainnet launched in July 2020
15,000 TPS, 6s latency, $0.001/tx
263k TPS in public testnet
IDE with debugger and Rust framework for SCs
Validated through multiple audits from Trial of Bits & others

Delegation process

Any number of eGold holders can participate in staking indirectly by delegating their eGold (thus becoming a Delegator) to existing Staking Providers, usually professional staking-as-a- service providers, that choose to accept delegations. An eGold holder indicates which Staking Provider candidate they trust and puts some eGold at stake to support their delegation. If one or more of the nodes of the Staking Provider chosen are elected as validators in an epoch, they will share with them any economic rewards or punishments, proportional to their delegated stake. Delegating eGold is a way of investing one's eGold as well as contributing to the security of the system. The larger the total amount of eGold staked, the higher the system security, thanks to the increased amount of stake needed by an adversary to get any nodes elected as validators.
The rewards earned by a delegator are assigned as claimable at the start of each epoch for the last epoch, basically every 24 hours. Delegation rewards need to be manually claimed by the delegator at their own choosing. The unclaimed rewards are adding up and they can be claimed at any point in time. This means that there is no compounding of the delegated funds as it has to be done manually by the user. On the other hand, the delegation rewards that are not claimed, in some jurisdictions, are perceived as deferred earnings and are not taxable until they are claimed. Keep in mind that claiming the rewards involves a Delegation (system) Smart Contract transaction and some fees are involved (it might not make sense to claim rewards every 24 hours because of this fee). Also, those rewards that need to be claimed become fully unlocked once they are claimed.

HOW TO DELEGATE

To delegate, an eGold holder needs to send appropriate transaction(s) to the Delegation (system) Smart Contract corresponding to the chosen Staking Provider by accessing his own Elrond web wallet and selecting the corresponding action - Delegate. The minimum amount to delegate is 10 eGold.

CLAIM REWARDS

Every user who delegated can claim the currently accumulated rewards for his account. A transaction has to be sent to the Delegation (system) Smart Contract with the “claim” action. At processing time, it is calculated how many rewards the account the account should get, by calculating the difference between the last time the claim was called and the current nonce, calculating the total earned rewards by the Staking Provider on that time period. The service fee is taken out and the rest is sent to the user. Only the account that delegated can claim the rewards (same public key). A separate claim transaction needs to be sent to the Delegation (system) Smart Contract of each separate Staking Provider to which a user is delegated.

VIEW REWARDS

A Delegator or anyone can view the rewards associated with an address by accessing the web wallet or by querying the reward address in the blockchain explorer.

REWARDS RULES

The separation of nodes from rewards came from the fact that the Delegation (system) Smart Contract cannot ensure the number of nodes which are eligible in a certain epoch. Therefore, it cannot ensure that a given amount of eGold will be earned every day. Moreover, nodes are shuffled in and shuffled out. Thus, the rewards can vary from epoch to epoch. Furthermore, in case the staking- as-a-service provider is malicious or has a set of bad machines or just bad-luck, its rating might get affected or it might be getting jailed, producing even less rewards. It is up-to the community delegating into such a service to decide when to get out, if the Staking Provider is good enough and the terms and conditions are met. The Delegation (system) Smart Contract is the narrow waist on which other conditions might be added by different communities. The Staking Provider owner of such a Delegation (system) Smart Contract can be a DAO that makes their own rules.

DISTRIBUTED REWARDS

At the end of each epoch, when the rewards are distributed, the Delegation (system) Smart Contract of a Staking Provider will get the reward tokens at the reward address for those Staking Provider nodes which are in the contract’s address. In order to keep the rewards separately, the total of accumulated rewards is saved under a special key in the smart contract’s trie. Then these rewards are claimable by those who delegated in the contract. Delegators who claim their rewards will need to pay the transaction fees (gas) themselves for the claim transaction.

UN-DELEGATE

If a user decided to withdraw from the Delegation (system) Smart Contract, this process involves 2 steps: Un-delegate - a transaction which “tells” the Delegation (system) Smart Contract that the delegator wants a specific amount (all or just a part) to be withdrawn from delegation. After the un-Stake function is called, funds might still be locked for delegation several epochs depending on the system load ratio. For this reason, funds will remain locked in the Auction Smart Contract for 10 epochs. After 10 epochs have passed, the Delegation (system) Smart Contract should call the un-Bond function to actually retrieve the funds.

WITHDRAW OR UN-BOND

After a successful un-delegate and 10 epochs have passed the eGold can be withdrawn through a transaction which interacts with the Delegation (system) Smart Contract. The Delegation (system) Smart Contract will call Auction Smart Contract which will then give the requested amount. This will return all of the withdrawable tokens together to the given delegator.

Delegation smart contract guarantees
and invariants

Tokens lock

The contract can't lose or lock tokens of users.

Tokens deposited

If a user deposited X, the user should be able to withdraw at least X.

Tokens delegated

If a user successfully delegated X, the user can un-stake at least X.

Tokens un-staked

The contract should not lock un-staked funds for longer than 10 epochs* after un-stake action.

Withdraw funds

The Staking Provider can't withdraw funds from delegators.

Delegation Smart Contract

The Staking Provider can't delete the Delegation (system) Smart Contract if there are nodes still staked.
NOTE: Guarantees are based on the no-slashing condition. Once slashing is introduced, the contract will no longer provide some guarantees.
* Except when not enough nodes would remain active and the un-stake is delayed.
lockenterexitleafbriefcasecodeunlinklayers