Would this be a valid implementation for an ether staking pool if the goal was to eliminate the need for depositors to forfeit control of their ether to the pool owner?

  • Depositor creates a contract and sends the ether they wish to stake to that contract

  • The contract controls 2 of 3 keys in a multisig address and the pool owner controls the other key

  • The pool owner calls a function in the contract, providing info on the block they want to vote on

  • The contract would then generate a signature for the block using one of the depositors two keys and return the signature to the pool owner

  • The pool owner would also create a signature using the key they control

  • Together, the signatures from the depositor and pool owner constitute proof of ownership of the staked ether and therefore a vote for whatever block the pool owner provided info on

  • The pool owner would then be able to submit a vote and repeat the process all over again

  • The contract would have a spending limit of 0 ether unless the keys used to sign a tx included both of the depositors keys (prevent pool operator from stealing funds)

I was reading about the necessity of speed in updating block votes to reduce lost funds due to DDoS here, and was trying to think of possible implementations that would prevent the depositor from introducing additional delay into the voting process.

If the pool needed to request a signature from a depositor, and the depositor had their ether staked using an 'EthPool-Qt' client running locally that generated signatures for the pool, wouldn't the delay introduced by the network significantly increase the potential not switching votes fast enough, getting left on the losing side, and therefore losing the ether at stake?

Do you think pools that require depositors to forfeit control of their ether will have an advantage in staking because they can simply vote on blocks because they would literally own all of the depositors ether and could create votes without needing to collect additional signatures?

1 Answer 1


The simplest pooled staking approach would be to have the validation code for an account be a multi-sig verifier instead of a single-sig verifier, ie. it would expect signatures from M of a given set of N public keys (you can make this more efficient using threshold sigs instead of multisig).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.