# No rewards for first two epochs: There is no reward distribution for the first two epochs, as the root of the epoch is calculated two epochs in advance. Assumption: The network has reached the third epoch. Acceptance: Test that no rewards are distributed during the first two epochs. Acceptance: Verify that rewards are distributed starting from the third epoch.

# Stake table membership: Rewards are only distributed to a validator, and its list of delegators based on the epoch stake table. This stake table has its own set of requirements such as meeting minimum threshold. Acceptance: Test that reward is distributed to one validator and its list of delegators per hotshot block. Acceptance: Verify all the keys receiving reward are part of the current stake table. Acceptance: update the stake table in the contract, and test that rewards are distributed based on the new stake table.

# Block reward: ewards are distributed to validators and their delegators based on their stake and the commission. The reward for every block is a fixed number of espresso tokens, and this is calculated using the inflation rate of tokens, total supply, and average block time.

• Inflation rate for ESP tokens: 3%

• Average block time: 2 seconds

• Total supply: 10 billion ESP tokens (hardcoded)

• Calculated block reward: ESP tokens

  Assumption: The block reward is fixed.

  Acceptance: Verify that the total reward distributed among the validator and its delegators equals the calculated block reward. Acceptance: Confirm that the average block time is reasonable by running a load generator on a devnet over time and calculating average block time based on network uptime.
  

# Distribution: The reward is split between the leader proposing the Hotshot block and its delegators. The validator receives a portion based on its commission rate, and the remaining reward is distributed proportionally among delegators. The validator can delegate to itself or others.

Acceptance: Verify the validator receives both commission and delegator reward when also delegating.

Acceptance: Confirm the validator receives no commission reward when the rate is set to 0.

Acceptance: Confirm the validator receives the entire block reward if commission is set to 10,000 basis points.

Acceptance: Run a network with distinct stake weightings (e.g., 100, 200, 500, 1000) and verify that reward distributions align proportionally over time.

Acceptance: Remove a node from the stake table and verify rewards are no longer distributed to it; test that the overall reward distribution is now higher for the remaining validators over a period of time compared to before.

# Reward Accumulation: The reward Merkle tree tracks accumulated rewards for both validators and delegators. Each entry at a specific block represents total accumulated rewards for that account up to that block. The Merkle tree root is included in the block header, ensuring consensus on distributed rewards.

Acceptance: Verify the Merkle tree updates at every block by checking the reward Merkle tree commitment in the block header.

Acceptance: Confirm rewards for leaders and delegators accumulate correctly over time.

# Claiming: The reward claiming mechanism enables eligible accounts to submit proofs for their rewards based on the committed merkle root of the reward state for a specific epoch.

Assumption: The network has committed the merkle root of the reward state for an epoch

Acceptance: Verify that a leader can successfully submit a valid proof to claim their reward for a specific block

Acceptance: Test that the contract verifies the submitted proof against the committed merkle root and transfers the correct reward amount to the account.

Acceptance: Test that claims submitted without a valid proof are rejected.

Acceptance: Test that same rewards cannot be claimed more than once for any account.

Acceptance: Test that withdrawals are rejected for amount greater than what is specified in the merkle tree

Acceptance: Test that claims can only be submitted for rewards in the epoch for which the merkle root has been committed and not for any future or uncommitted epochs.

# Reward accounts catchup: If a node joins late or has been offline, it must catch up by requesting Merkle proofs from peers, ensuring accurate balances for all Ethereum reward accounts.

Acceptance: Shut down a node for some time, restart it, and verify it participates in consensus and voting.

Acceptance: Add a new node later and verify it can catch up on the reward Merkle tree. Query reward-state/reward-balance/{block_height}/{address} at multiple block heights and validator addresses to confirm rewards update correctly.

Acceptance: For every address in the stake table (leaders and delegators), query reward balances at blocks and . Confirm that the difference in total rewards equals the block reward.

# Slashing: penalize validators for malicious behavior or protocol violations