staking

Staking

In the following description when we talk about "a staker" this somewhat imprecise term is in essence the control of a key pair that can sign transactions and produce validate blocks on the chain. This key pair could also be used by a delegation contract for delegated stake.

Constants:

• MINIMUM_STAKE: The minimum amount of tokens required to be eligible for leader selection in any given epoch.

Participant's Balances:

• Total Balance (TB): The total number of tokens a participant has deposited in the staking contract via the stake() function.

• Locked Balance (LB): The max of staked amounts over the current staking cycle, i.e., epochs N to N + C, where C is the number of epochs in the staking cycle (in our case, C = 3).

• Available Balance (AB): The portion of the Total Balance that is not locked in the current staking cycle.

  • AB = TB - LB

• Staking Schedule (SC): A mapping of epochs to the amount of tokens the participant has committed to stake in each of those epochs and onwards if not changed. As an ordered list ({epoch, stake amount, locked amount})

Automatic Restaking: Unless adjusted, the stake for an epoch automatically continues into future cycles.

---

API Functions

1. deposit(producer:pubkey) (Payable Endpoint)

   • Description: Allows a participant to deposit tokens into the staking contract, increasing their Total Balance (TB) and Available Balance (AB).

   • Parameters:

     • producer - the pubkey of the producer who can become leader and then produce and sign blocks.

     • (the amount is determined by the value of tokens sent with the transaction).

   • When Callable: At any time.

   • Behavior:

     • Increases TB by the amount of tokens sent.

     • Increases AB by the same amount.

2. withdraw(amount:unsigned integer)

   • Description: Allows a participant to withdraw tokens from their Available Balance (AB).

   • Parameters:

     • producer: The pubkey of the producer given in Call.caller.

     • amount: The amount of tokens to withdraw.

   • When Callable: At any time.

   • Constraints:

     • amount must be less than or equal to AB.

     • Cannot withdraw tokens locked in the current staking cycle (i.e., tokens committed in SS for epochs N to N + C).

3. adjustStake(amount:integer)

   • Description: Adjusts the amount of tokens a participant wishes to stake for the next staking cycle.

   • Parameters:

     • producer: The pubkey of the producer in Call.caller.

     • amount: The amount to adjust (positive to increase stake, negative to decrease stake).

   • When Callable: Only during the Staking Epoch of a cycle, but every epoch is the staking epoch of some cycle, so you can always call it.

   • Constraints:

     • Adjustments made in the current epoch N affect the staking cycle starting in epoch N, with leader election and production in epoch N + 3.

     • Positive amount:

       • Must have sufficient AB to cover the increase.

     • Negative amount:

       • Cannot reduce the stake below zero for the next staking cycle.

     • Minimum Stake Requirement:

       • After adjustment, if the participant's stake is below MINIMUM_STAKE, they will not be eligible for leader selection in the upcoming cycle.

   • Behavior:

     • SC: is an orderd list [{epoch, stake amount, locked amount}| ... ]

     • Calculate new_stake: find the stake for current_epoch in SC or take the value of the last epoch in the list.

       • new_stake = stake + amount

     • drop all values in SC where epcoh < current_epoch

     • n = current_epoch (n1 = leder selection epoch, n2 = production epoch, n3 = payout epoch)

     • Recreate the list:

     case SC of
       [{n, n_stake, n_lock}|Rest1] ->
           [{n, new_stake, max(new_stake, n_lock)} | case Rest1 of
               [{n1, n1_stake, n1_lock} | Rest2] ->
                   [{n1, new_stake, max(new_stake, n1_lock)} | case Rest2 of
                       [{n2, n2_stake, n2_lock} | Rest3] ->
                           [{n2, new_stake, max(new_stake, n2_lock)} | case Rest3 of
                               [{n3, n3_stake, n3_lock} | Rest4] ->
                                   [{n3, new_stake, max(new_stake, n3_lock)} | case Rest4 of
                                       [{n4, n4_stake, n4_lock}] ->
                                           [{n4, new_stake, max(new_stake, n4_lock)}];
                                       [] ->
                                           [{n4, new_stake, max(new_stake, n3_lock)}]
                                   end];
                               [] ->
                                   [{n3, new_stake, max(new_stake, n2_lock)},
                                   {n4, new_stake, max(new_stake, n2_lock)}]
                               end];
                       [] ->
                           [{n2, new_stake, max(new_stake, n1_lock)},
                           {n3, new_stake, max(new_stake, n1_lock)},
                           {n4, new_stake, max(new_stake, n1_lock)}]
                       end];
               [] ->
                   [{n1, new_stake, max(new_stake, n_lock)},
                   {n2, new_stake, max(new_stake, n_lock)},
                   {n3, new_stake, max(new_stake, n_lock)},
                   {n4, new_stake, max(new_stake, n_lock)}]
               end];
       [] ->
           [{n, new_stake, new_stake},
           {n1, new_stake, new_stake},
           {n2, new_stake, new_stake},
           {n3, new_stake, new_stake},
           {n4, new_stake, new_stake}]
     end

     • Recalculate LB (max of SC)

     • Recalculates AB = TB - LB

     • All these values are stored in a map with producer as key. Alternatively

4. stake(amount:unsigned integer)

   • Description: sets the amount of tokens a participant wishes to stake for the next staking cycle.

   • Parameters:

     • producer: The pubkey of the producer in Call.caller.

     • amount: The amount to stake in this staking cycle.

   • When Callable: Only during the Staking Epoch.

   • Constraints:

     • Staking made in the current epoch N affect the staking cycle starting in epoch N, with leader election in epoch N + 1.

     • Positive amount:

       • Must have sufficient AB to cover the increase.

     • Minimum Stake Requirement:

       • After adjustment, if the participant's stake is below MINIMUM_STAKE, they will not be eligible for leader selection in the upcoming cycle.

   • Behavior:

     • Updates the participant's stake commitment for the next staking cycle.

     • Recalculats LB:

       • LB = amount

     • Recalculates AB:

       • AB = TB - LB

5. getStakedAmount(producer:pubkey, epoch:integer)

   • Description: Returns the amount of tokens the participant has committed to stake in the staking cycle starting at epoch and ending in epoch + 3

   • Parameters:

     • producer: The pubkey of the producer.

     • epoch: The epoch number. (Or possibly a block height?)

   • When Callable: At any time.

6. getAvailableBalance(producer:pubkey)

   • Description: Returns the participant's current Available Balance (AB).

   • Parameters:

     • producer: The pubkey of the producer.

   • When Callable: At any time.

---

Explanation of Balances Across Epochs

Key Concepts

• Total Balance (TB): Sum of all tokens deposited via deposit() and not yet withdrawn.

• Locked Balance (LB): The total amount of tokens locked in the current staking cycle, i.e., epochs N to N + 4.

• Available Balance (AB): Calculated as the difference between TB and LB.

  • AB = TB - LB

Lifecycle of Tokens in the Staking Contract

1. Staking Tokens (deposit()):

   • Increases TB and AB.

   • No immediate effect on staking commitments until adjustStake() (or stake()) is called.

2. Adjusting Stake (adjustStake()):

   • Adjusts the participant's stake commitment for the next staking cycle.

   • Positive Adjustment:

     • Decreases AB by amount.

     • Increases the stake commitment for the next staking cycle by amount.

   • Negative Adjustment:

     • Increases AB by -amount.

     • Decreases the stake commitment for the next staking cycle by -amount.

   • AB Recalculation:

     • AB = TB - LB

3. Withdrawal (withdraw()):

   • Decreases TB and AB by amount.

   • Cannot affect tokens locked in the any of the 5 concurrent staking cycles.

4. Epoch Transition:

   • At the end of the Payout Epoch (N + 4):

     • Tokens locked in the current staking cycle become available.

     • LB decreases by the amount of tokens that were locked.

     • AB increases accordingly.

---

Example Scenario

Let's illustrate how the balances change over epochs. For simplicity we do not distinguish between the different roles of Alice in this example. Here Alice is both person who can commit a stake and the the running node that can validate and produce blocks, all roles have access to the same key pair which is used to identify as "Alice" in the example. Alice could also be a delegation contract used for delegated stake.

Constants and Parameters

• Current Epoch (N): 10 (Staking Epoch)

• Staking Cycle Length (C): 5 epochs (epochs 10 to 14)

  • Epoch 10: Staking Epoch

  • Epoch 11: Entropy Epoch

  • Epoch 12: Leader Election Epoch

  • Epoch 13: Block Production Epoch

  • Epoch 14: Payout Epoch

• Participant: Alice

• MINIMUM_STAKE: 100 tokens

Alice's Balances

• Total Balance (TB): 1000 tokens (Alice has already deposited these via deposit()).

• Available Balance (AB): 1000 tokens (initially, no tokens are locked).

• Locked Balance (LB): 0 tokens.

---

Epoch 10 (Staking Epoch)

Action 1: Alice Stakes 400 Tokens

• Alice decides to stake 400 tokens for this staking cycle (epochs 10 to 14) with production in epoch 13.

• She calls adjustStake(400).

• Available Balance (AB) decreases by 400 tokens:

  • AB = 1000 - 400 = 600 tokens.

• Stake Commitment:

  • Alice's stake commitment for this staking cycle is now 400 tokens.

• Locked Balance (LB) remains at 0 tokens till the end of the epoch (the stake will be locked in Epoch 11).

Action 2: Alice Withdraws 100 Tokens

• She calls withdraw(100).

• Total Balance (TB) decreases by 100 tokens:

  • TB = 1000 - 100 = 900 tokens.

• Available Balance (AB) decreases by 100 tokens:

  • AB = 600 - 100 = 500 tokens.

• Locked Balance (LB) 400 tokens.

---

Epoch 11 (Entropy Epoch)

• Alice can now plan her stake for the following staking cycle and decides on no change.

• System Process:

  • The system awaits the parent chain's hash to generate entropy.

• Alice's Balances:

  • No changes occur in this epoch.

  • AB remains at 500 tokens.

  • LB remains at 400 tokens.

---

Epoch 12 (Leader Election Epoch)

• Alice's stake of 400 tokens stays locked for the duration of the staking cycle (epochs 12 to 14).

• Alice's Balances:

  • LB = 400 tokens.

  • AB = 500 tokens.

Adjusting Stake for Next Cycle

• Alice can now plan her stake for the next next staking cycle (block production in epoch 15) and decides on no change.

• She decides to withdraw her stake after the current cycle:

  • She calls adjustStake(-400).

  • This action schedules her stake to be reduced by 400 tokens after the current cycle ends.

• Note: The AB and LB remain unchanged until the stake is unlocked.

---

Epoch 13 (Block Production Epoch)

• Block Production:

  • Alice participates in block production based on her locked stake of 400 tokens.

• Alice's Balances:

  • No changes occur in this epoch.

  • AB remains at 500 tokens.

  • LB remains at 400 tokens.

---

Epoch 14 (Payout Epoch)

Rewards Distribution

• Alice receives rewards based on her participation, paid out directly to her account.

• Alice's stake adjustment from Epoch 12 takes effect.

• Locked Balance (LB) decreases by 400 tokens:

  • LB = 400 - 400 = 0 tokens.

• Available Balance (AB) increases by 400 tokens:

  • AB = 500 + 400 = 900 tokens.

• Total Balance (TB) remains at 900 tokens.

---

Epoch 15 (Next Staking Epoch)

Adjusting Stake for New Cycle

• Alice decides to increase her stake to 500 tokens for the staking cycle in epochs 15 to 19.

• She calls adjustStake(500).

• Available Balance (AB) decreases by 500 tokens:

  • AB = 900 - 500 = 400 tokens.

• Stake Commitment:

  • Alice's stake commitment for the next staking cycle is now 500 tokens.

• Locked Balance (LB) remains at 0 tokens (the stake will be locked in Epoch 16).

---

Epoch 16 (Entropy Epoch)

• Alice's stake of 500 tokens becomes locked for the duration of the staking cycle (epochs 16 to 19).

• System Process:

  • The system waits for the parent chain's hash for entropy.

• Alice's Balances:

  • The stake become locked

  • AB remains at 400 tokens.

  • LB is set to 500 tokens.

---

Epoch 17 (Leader Election Epoch)

• Alice's Balances:

  • No changes occur.

  • AB remains at 400 tokens.

  • LB is set to 500 tokens.

---

Epochs 17 to 19

• Block Production and Payout:

  • Alice participates in block production.

  • Rewards are earned and distributed in the Payout Epoch (epoch 19).

• Actions:

  • Alice cannot adjust her current stake but can plan for the next cycle during Epoch 20.

---

Summary of Alice's Balances Over Epochs

Epoch	TB (tokens)	AB (tokens)	LB (tokens)	Notes
09	1000	500	0	Inital balance 1000 tokens
10	900	500	0	Staked 400 tokens, withdrew 100 tokens
11	900	500	400	Stake locked at start of Entropy Epoch
12	900	500	400	Leader Election Epoch
13	900	500	400	Block Production Epoch
14	900	900	0	Stake unlocked; AB increases by 400 tokens
15	900	400	0	Staked 500 tokens for next cycle
16	900	400	500	Stake locked at start of Entropy Epoch
17	900	400	500	Leader Election Epoch
18	900	400	500	Block Production Epoch
19	900	400	0	Stake unlocked; rewards added to AB

---

SC Over Epochs

Epoch	TB	LB	AB	SB	SC Entries (epoch, stake, locked amount)	Notes
09	1000	0	1000	0	Empty	Initial balance
10	900	0	500	400	{10, 400, 0}, {11, 400, 400}, {12, 400, 400}, {13, 400, 400}, {14, 400, 400}	Staked 400 tokens, withdrew 100 tokens
11	900	400	500	400	{10, 400, 0}, {11, 400, 400}, {12, 400, 400}, {13, 400, 400}, {14, 400, 400}	Stake locked at start of Entropy Epoch
12	900	400	500	400	{12, 400, 400}, {13, 0, 400}, {14, 0, 400}, {15, 0, 0}	Reduced stake by 400 tokens
13	900	400	500	400	{12, 400, 400}, {13, 0, 400}, {14, 0, 400}, {15, 0, 0}	Block Production Epoch
14	900	400	500	0	{12, 400, 400}, {13, 0, 400}, {14, 0, 400}, {15, 0, 0}	Payout Epoch
15	900	0	400	500	{15, 500, 0} , {16, 500, 500}, {17, 500, 500}, {18, 500, 500}, {19, 500, 500}	New Stake of 500
16	900	500	400	500	{15, 500, 0} , {16, 500, 500}, {17, 500, 500}, {18, 500, 500}, {19, 500, 500}

---

Edge Cases and Additional Notes

• Adjusting Stake During Staking Epoch:

  • Participants can only adjust their stake for the current staking cycle during the Staking Epoch.

  • Once the Staking Epoch ends, the stake commitments are locked till the end of the cycle.

• Insufficient AB for Adjusting Stake:

  • If a participant tries to increase their stake but does not have sufficient AB, they must first increase TB via deposit().

• Withdrawal Limitations:

  • Participants cannot withdraw tokens that are locked in the current staking cycle.

  • Attempting to withdraw more than AB will result in an error.

• Automatic Re-Staking:

  • Tokens do not automatically unlock, instead if no change in staking is registerd they remain at stake.

  • Participants must call adjustStake() during the next Staking Epoch to free tokens during the next staking cycle.

---

Example with Varying Stakes Across Epochs

If participants can adjust their stake for each epoch within the staking cycle, the LB calculation becomes the maximum over the epochs.

Suppose Alice stake different amounts in each epoch:

• Epoch 11: 500 tokens

• Epoch 12: 300 tokens

• Epoch 13: 400 tokens

Then in epoch 13, we are still in the cycle started in epoch 11.

• LB = max(SS[11], SS[12], SS[13])

• LB = max(500,300,400) = 500 tokens

Locking

In the current proposal a stake is only locked for one cycle. We could consider adding a network/hyperchain parameter stating the number of epochs or cycles that a stake is locked. In this case the adjustStake function would need to be updated to keep track of the locking for the whole locking period.

Block Rewards

Glossary and Concepts

• Leader Schedule: Blocks are produced in accordance with a predetermined leader schedule. Each validator is assigned specific slots during which they are responsible for producing blocks.

• Timely Block Production: Validators are expected to produce blocks on time during their assigned slots to ensure the smooth operation of the network.

• Missed Blocks: If a validator fails to produce a block in their assigned time slot, this results in a missing block.

• Producing a 'Hole':

  • The subsequent validator in the leader schedule is allowed to produce a special type of block called a 'hole'.

  • Hole Characteristics:

    • Represents the absence of the expected block.

    • Contains no transactions.

    • Serves as a placeholder to maintain the continuity of the blockchain.

  • No Rewards for Holes:

    • Validators producing holes do not receive any rewards for these blocks.

    • The missed block's potential rewards are effectively forfeited, including the award of fees for following the previous block, and for the following block.

Reward Distribution for Correct Blocks

When a validator successfully produces a block on time, the rewards are distributed as follows:

Components of Rewards

1. Block Fees: Transaction fees collected from transactions included in the block.

2. Epoch Coinbase: Newly minted tokens allocated for that epoch.

Distribution Breakdown

• Block Producer (Current Validator):

  • Receives X% of the block fees, X defaults to 40% but is configurable in genesis.

  • Receives the full epoch coinbase reward.

  • Incentive: Encourages validators to produce blocks promptly and include transactions to maximize fees.

• Next Validator (Following Validator):

  • Receives Y% of the block fees, Y defaults to 30% from the previous block.

  • Role:

    • Validates the correctness of the previous block.

    • Builds upon it by producing the next block in the chain.

  • Incentive: Motivates validators to participate actively in the validation process and ensures they have a stake in the accuracy of preceding blocks.

• Previous Producer (Preceding Validator):

  • Receives (100-(X+Y))% of the block fees from the following block.

  • Role:

    • Validates the correctness of the previous block.

    • Is encouraged to produce the block in time so that the next validator builds on top of it.

  • Incentive: Motivates validators to produce blocks in a timely manner.

Visualization of Reward Flow

+-----------------------+         +-----------------------+        +-----------------------+
|                       |         |                       |        |                       |
|  Validator: A         |         |  Validator B          |        |  Validator C          |
|  Block: N-1           |         |  Block: N             |        |  Block: N+1           |
|  (Previous Producer)  |         |  (Block Producer)     |        |  (Next Validator)     |
|                       |         |                       |        |                       |
| - Validates Block N-2 |         | - Validates Block N-1 |        |  - Validates Block N  |
|  - Produces Block N-1 |         |  - Produces Block N   |        |  - Builds Block N+1   |
|  - Receives Fees:     |         |  - Receives Fees:     |        |  - Receives Fees:     |
|    * 30% of N-2       |         |    * 30% of N-1       |        |    * 30% of N         |
|    * 40% of N-1       |-------->|    * 40% of N         |------->|    * 40% of N+1       |
|    * 30% of N         |         |    * 30% of N+1       |        |    * 30% of N+2       |
|    * Epoch Coinbase   |         |    * Epoch Coinbase   |        |    * Epoch Coinbase   |
|                       |         |                       |        |                       |
+-----------------------+         +-----------------------+        +-----------------------+

Fee Payout Timing

• Payout Fee Epoch: The rewards (fees and coinbase) are not distributed immediately but are paid out during the Payout Fee Epoch of the staking cycle.

• Staking Cycle Phases:

  1. Staking Epoch: Validators stake their tokens.

  2. Leader Selection Epoch: Leaders (validators) are selected based on their stake.

  3. Block Production Epoch: Validators produce blocks according to the leader schedule.

  4. Payout Fee Epoch: Accumulated rewards are distributed to validators.

• Benefits:

  • Allows for accounting of all rewards and penalties within a cycle.

  • Provides a window to resolve disputes or adjust for any detected misbehavior before rewards are paid.

---

Reward Distribution Mechanics

Configurable Parameters

• 30/40/30 Fee Split:

  • The proportion of fees allocated to the block producer and the next validator is configurable for a Hyperchain.

  • Networks can adjust the split (e.g., 10/70/20, 20/30/50) based on governance decisions or to incentivize certain behaviors.

• Epoch Coinbase Amount:

  • The coinbase reward (newly minted tokens) per epoch is configurable per chain.

  • Allows for economic flexibility and inflation control across different Hyperchains.

Reward Accumulation and Distribution

• Accumulation:

  • Fees and coinbase rewards earned by validators are accumulated during the staking cycle.

  • Rewards are tracked per validator and stored within the protocol until payout.

• Distribution:

  • During the Payout Fee Epoch, rewards are disbursed to validators' accounts.

  • Validators receive their total accumulated rewards for the cycle in a lump sum.

Payment to Delegator Contracts

• Delegator Contracts:

  • Validators may have associated delegator contracts, where other token holders delegate their stake to the validator.

  • Rewards can be configured to be paid directly to these contracts.

• Benefits:

  • Facilitates the distribution of rewards to delegators according to agreed terms.

  • Encourages participation from token holders who may not run validator nodes themselves.

---

Example Scenario

Assumptions

• Fee Split: 30% previous produer, 40% to block producer, 30% to next validator.

• Epoch Coinbase: 10 tokens per epoch.

• Block Fees: Varies per block.

Block Production Sequence

1. Validator A has produced Block N-1 on time.

2. Validator B produces Block N on time.

3. Validator C is scheduled to produce Block N+1.

Reward Distribution

• Validator A (Block N-1 Producer):

  • Receives:

    • 30% of Block N Fees.

    • Epoch Coinbase (10 tokens).

• Validator B (Block N Producer):

  • Receives:

    • 40% of Block N Fees.

    • Epoch Coinbase (10 tokens).

• Validator C (Block N+1 Producer):

  • Receives:

    • 30% of Block N Fees (for validating and building upon Block N).

    • Their own rewards for producing Block N+1 when applicable.

Missed Block Scenario

• If Validator B fails to produce Block N:

  • Validator C produces a hole instead.

  • No Rewards:

    • Validator C receives no rewards for the hole.

    • Validator B forfeits potential rewards for Block N.

  • Continued Operation:

    • Validator C continues with Block N+1.

---

Configurability and Governance

• Hyperchain Configurability:

  • The fee split ratio and coinbase amounts are parameters that can be adjusted through governance mechanisms.

  • This flexibility allows each Hyperchain to tailor economic incentives to its specific needs.

• Possible Governance Process:

  • In future versions we could add:

    • Changes to the reward parameters can be proposed and voted upon by stakeholders.

    • Ensures that adjustments reflect the consensus of the network participants.

Penalties & Slashable Offenses

Here we describe the effects of penalties on staking and rewards for validators who commit slashable offenses. It outlines how these penalties impact a validator's staked tokens, their eligibility for rewards, and their future participation in the network.

Overview of Penalties and Slashable Events

Penalties are enforced to deter malicious actions or protocol violations. Slashable events are actions that result in the forfeiture of a validator's stake, reputation, or other penalties to maintain network integrity and fairness. Any participant can submit proof of such wrongdoing, ensuring a decentralized and fair enforcement mechanism.

Slashable Offenses

1. Producing Two Versions of a Block at a Specific Height (Double-Spending Attack)

2. Double Voting

3. Consistently Failing to Submit Blocks on Time

Minor Offenses

1. Ignoring the finalize_epoch Fork

2. Ignoring a Correctly Pinned Fork

For minor offenses like ignoring forks (items 1 and 2), the protocol ignore the validator's actions without imposing penalties.

Details TBD

The exact details of what these offenses and how proof of these offense should look and the penalties is yet to be decided.

Effects of Penalties on Staking

Slashing of Staked Tokens

• Reduction of Total Staked Balance: When a validator commits a slashable offense, a portion or the entirety of their Total Balance (TB) of staked tokens is slashed (i.e., permanently deducted).

• Impact on Locked Balance (LB): The Locked Balance, which is the amount currently staked and locked for participation, decreases by the slashed amount.

• Available Balance (AB): The Available Balance, representing tokens that can be withdrawn or restaked, remains unaffected by the slashing unless the slashed amount exceeds the LB, in which case it may be reduced to cover the penalty.

Example Scenario

• Before Penalty:

  • Total Balance (TB): 1,000 tokens

  • Locked Balance (LB): 800 tokens

  • Available Balance (AB): 200 tokens

• Penalty Imposed: 400 tokens slashed due to a severe offense.

• After Penalty:

  • TB: 600 tokens (1,000 - 400)

  • LB: 400 tokens (800 - 400)

  • AB: 200 tokens (unchanged)

Implications

• Reduced Staking Power: With a lower TB and LB, the validator's influence in leader elections and block production diminishes.

• Risk of Falling Below Minimum Stake: If the remaining LB falls below the Minimum Stake Requirement, the validator becomes ineligible for leader selection until they top up their stake.

---

Effects of Penalties on Rewards

Forfeiture of Rewards

• No Rewards Paid Out: Validators who commit slashable offenses forfeit any pending rewards for the current and possibly future epochs.

  • Block Rewards: They lose eligibility for block rewards associated with blocks they produced during the period of misbehavior.

  • Transaction Fees: They forfeit any transaction fees collected in blocks they produced or validated.

• Redistribution of Forfeited Rewards:

  • To Honest Validators: The forfeited rewards may be redistributed among honest validators as an incentive for maintaining network integrity.

  • To Reporter: A portion of the forfeited rewards or slashed stake may be awarded to the participant who submitted the valid proof of misconduct.

Process for Applying Penalties

Submission of Proof of Misconduct

• Any Participant Can Report: Network participants can submit evidence of a validator's wrongdoing via a special "Proof of Misconduct" transaction to the election contract.

• Required Information:

  • Evidence: Detailed and verifiable proof of the validator's misconduct. TBD.

  • Reporter Address: The identity of the participant submitting the proof.

  • Signature: Digital signature of the reporter to ensure authenticity.

Verification and Enforcement

1. Verification of Evidence:

   • The network validates the submitted evidence against blockchain data. TBD.

   • Ensures that the proof is legitimate and the offense is verifiable.

2. Application of Penalties:

   • Slashing of Stake: Deducts the specified amount from the validator's TB and LB.

   • Forfeiture of Rewards: Removes any pending rewards owed to the validator.

3. Distribution of Slashed Funds:

   • Reporter Reward: Allocates a portion of the slashed stake to the reporter as a reward for maintaining network security.

   • Network Treasury: Remaining slashed funds may be burned or allocated to other stakers. TBD.

---

Impact on Validator's Future Participation

Loss of Stake Balance

• Loss of staking power: By loosing staking power in the staking contract the ability of a validator to earn future rewards is decreased.

• Below Minimum Stake: If slashing reduces the validator's LB below the required Minimum Stake, they become ineligible for:

  • Leader Selection: Cannot be selected to produce blocks.

  • Voting Rights: May lose the ability to participate in governance decisions.

• Reputation Loss: Validators with a history of penalties may be viewed as untrustworthy, affecting their chances of being selected in delegation pools or staking contracts.

Rebuilding Stake and Reputation

• Re-Staking Required: Validators must deposit additional tokens to meet the minimum stake if they wish to resume participation.