# Staking asset: An ERC20 compatible staking asset (the ESP token) is deployed to Ethereum L1. Assumption: Requirements for Token Generation Event (TGE) have been finalized. Acceptance: The staking asset contract is deployed to L1. Acceptance: The staking asset implements the ERC20 interface.

# Validators can register: An operator of an Espresso node can execute a smart contract transaction from their L1 account to register their validator in the smart contract. As part of the registration the validator can choose a commission (in percent, with two decimal places) of rewards that will be assigned to the validator instead of the delegator. Assumption: The validator is in possession of consensus BLS and Schnorr verifying keys. Acceptance: A test that calls the method to register a validator and verifies a registration event is emitted. Acceptance: Assert the registration event contains the correct validator Ethereum address, consensus keys, commission. Acceptance: A test that verifies a validator cannot register twice with the same BLS verifying key. Acceptance: A test that verifies a validator cannot register twice with the same Ethereum address.

# Validators cannot be impersonated: Validators submit their public consensus keys (a BLS verifying key and Schnorr verifying key) to the stake table contract. These keys are publicly known. The validator will be required to sign their Ethereum address with the BLS signature key to proof that they own the private key. Acceptance: A test that fails to register a validator with incorrect signature while other inputs are correct.

# Protection from rogue public-key attack: The BLS signature scheme is susceptible to rogue public-key attacks¹ . The attack can be mitigated by proving knowledge of the private key. We already require this for the requirement that forbids impersonation of validators. Acceptance: A test that fails to register a validator with incorrect signature while other inputs are correct.

# Validators can exit: Validator submit a smart contract transaction from their Ethereum wallet to exit or de-register their validator. Acceptance: A test that successfully calls the method to exit and asserts an exit event is emitted. Acceptance: A test that fails if the call is not made from the validator’s Ethereum account.

# Validators can update their consensus keys: The GCL consensus nodes need to keep their consensus keys in memory (“hot wallets”) to sign consensus messages without users intervention. As part of best security practices GCL node operators may want to rotate their consensus keys periodically or after potential leaks. Note that on the other hand validators only need to use their Ethereum accounts to register and de-register in the stake table smart contract. Since there is no continuous access requirements for these keys the Ethereum wallets can be kept offline, in (“cold wallet”). We will therefore not implement functionality to rotate Ethereum addresses. To achieve this a validator would need to de-register and re-registering with a new Ethereum address. Acceptance: A test that calls the method to update the consensus keys and asserts an event with the validator address and new consensus keys is emitted. Acceptance: A test that fails to call the method if the transaction does not originate from the validator’s Ethereum account. Acceptance: A test that fails if the signature on the new consensus key does not prove ownership of the consensus key.

# Validators cannot modify their commission: To protect delegators the fee chosen by validators initially is can not be modified. Acceptance: Manual inspection: the smart contract code does not have a mechanism for validators to update the commission. The registration function is the only function that sets the validator’s commission.

# Transaction spam protection: Gas usage incurred by the validator’s smart contract interactions is not significantly influenced by actions of other protocol participants. Acceptance: Gas snapshot showing the number of registrations and delegations does not significantly influence gas usage for contract transactions pertaining to registration, exit and updating consensus keys.

# Ability to delegate ESP tokens: ESP token holders on L1 can choose to delegate their ESP tokens to any currently registered validator. Assumption: An Ethereum wallet with sufficient ESP token balance. Assumption: An amount of tokens the token holder would like to delegate. Acceptance: A test that shows a delegator can submit a transaction the contract function to delegate. Acceptance: Assert that the delegated amount is transferred to the stake table contract. Acceptance: Assert failure if the delegator has insufficient balance. Acceptance: A test where the delegator successfully delegates to multiple validators. Acceptance: A test where the delegator successfully delegates multiple times to the same validator. Acceptance: A test where a validator successfully delegates to themselves.

# Eventual ownership of funds held in escrow: Delegated funds will be safely held in escrow by the smart contract. The original delegator themselves can withdraw them at a point in time where the requirements imposed by the HotShot consensus protocol are met. The delegator will initiate the undelegation via a contract transaction. After a period of time, the exact value of which remains to be determined, the contract will unlock the funds and the delegator will be able to execute a withdrawal L1 transaction to the funds to their wallet. For a certain validator and delegation the amount remains reclaimable by the delegator as long as the validator does not commit a slashable² offense. Acceptance: A delegator can transact to the smart contract to initiate the undelegation. Acceptance: A test asserting the total delegated funds (to one validator) can be withdrawn by the delegator to the delegators wallet. Acceptance: A test asserting a custom amount can be withdrawn by the delegator to the delegators wallet. Acceptance: A test asserting that withdrawal of funds is impossible before consensus and slashing requirements are met. Acceptance: A test asserting any party other than the delegator fails to initiate the undelegation. Acceptance: A test asserting that any party other than the delegator do not receive the funds if they transact to the withdrawal method. Assumption: An honest validator with delegations de-registers. Acceptance: A test asserting the delegators can eventually withdraw all their delegated funds held in escrow.

# Transaction spam protection: Gas usage incurred by the delegators’ smart contract interactions is not significantly influenced by actions of other protocol participants. Acceptance: Gas snapshot showing the number of transactions by other participant do not significantly influence gas usage of contract transactions pertaining to delegation, undelegation and withdrawal.

# Agency over staked funds: The idea behind proof of stake is to provide security to the GCL. In order to do this the stake table smart contracts primary function is to safely hold the staked funds in escrow. In order to entice validators to act honestly the GCL will implement slashing for provably malicious behaviors of validators. The stake table smart contract will have to retain the staked funds for long enough to allow participants to submit slashing evidence. To this end it is essential that the smart contract does proper accounting maintain the associations between validators and delegated funds during the escrow period, so that it can for example partially burn and partially re-direct the funds until the end of a fixed escrow period defined in the contract. Acceptance: A test asserting that the minimum time period between requested withdrawals of funds and actual withdrawal of funds is equal to a fixed escrow period. Acceptance: A test calling a public slashing function (implemented only for testing on a mocked version of the stake table contract) shows that it’s possible to slash funds held in escrow on a per delegator basis. Acceptance: A test that shows that the escrow period can be updated by the contract admin and only the contract admin. Acceptance: Manual inspection: the agency over staked funds does not depend on the hotshot state prover liveness or update interval.

# Access to necessary information: The stake table smart contract on Ethereum L1 is the authoritative source from which the GCL computes the stake table (or active validator set). The stake table contract exposes a convenient way to build the stake table, including delegations, for a given HotShot epoch. It is therefore required that the contract exposes the necessary information to build the stake table. The canonical way to make data available to the outside world from within Ethereum smart contracts is via smart contract events. Smart contract events can have arbitrary EVM data attached to them. Acceptance: A test asserting validator address, consensus BLS and Schnorr verifying keys, and commission are emitted during validator registration. Acceptance: A test asserting validator address, delegator address and delegation amount are emitted during delegation. Acceptance: A test asserting the validator address is emitted during validator exit. Acceptance: A test asserting the validator address, the delegator address and the undelegation amount are emitted during undelegation.

# Spam protection: Assumption: The stake table smart contract is deployed on Ethereum L1. The GCL must be protected from spam that would render timely computation of the stake table impossible. In it’s current design we emit at most one event per Ethereum transaction and the number of events the GCL needs to process is therefore roughly bound by the number of Ethereum transaction. The processing of stake table events does not involve complicated computation and processing time should be dominated by the time it takes to fetch the events from an Ethereum RPC. Since it’s not a big ask for a node to process all Ethereum events it should also not be a big ask to compute the stake table. Assumption: A stake table with large number of validators and delegators (for example 1 million), the equivalent stake table events of an L1 block full of stake table transactions. Acceptance: Assert via a test that the time it takes to compute stake table update is significantly smaller than the L1 block time of 12 seconds.

# Access to information: Potential delegators must be able to obtain a list of currently active validators with their past performance, commissions and currently total delegated amount to make an informed decision about which validator to delegate to. However, most of this information is not easily obtained from the contract because its either unknown to the contract or requires processing many contract events. It is therefore expected that the UI obtains this information from the query service or block explorer, but not directly from the smart contract. The stake table contract must still make some information available to UIs. Acceptance: A test asserting de-registration of a validator emits containing the validator address and the timestamp when funds will be available for withdrawal. Acceptance: A test asserting that undelegation emits an event containing the timestamp when the funds will be available for withdrawal.

# Error handling: In order for the staking UI to provide the helpful error messages the contract needs to define error types for all explicit revert reasons. Acceptance: Each contract revert defines their unique specific error type.