Comparing the Keep and NuCypher networks today


Below, I’ve attempted to provide an overview of both networks’ major differences. This isn’t exhaustive, but should help both communities better understand each network.

I welcome thoughts and notes from anyone familiar with either system!


Staking in NuCypher involves two roles: the staker and the worker. A staker is a NU token holder, while a worker is the account operating a NuCypher node. NU stakers choose a length of time when they stake. Each must stake a minimum of 30 days, and will stay staked until “wind down” is initiated. Each staker may choose to immediately restake their rewards, or periodically receive liquid NU.

Staking in Keep involves a few different security roles: the owner, the operator, the authorizer, and the beneficiary. The owner delegates a minimum stake of KEEP tokens to an operator account, which will be used to run their node on the network. They also specify an authorizer account, which determines which contracts an operator may operate against, and a beneficiary account, which receives all staking rewards.

KEEP stakers receive rewards differently based on the applications in which they stake. The random beacon pays stakers based on the groups they participate in over the course of their staking duration, in both KEEP subsidies and ETH from beacon users. tBTC pays KEEP subsidies to stakers weekly, while TBTC is earned every time a deposit is redeemed. KEEP can be undelegated at any time, but is only fully unstaked after a 60-day undelegation period.

The difference in Keep and NuCypher’s staking models is mostly due to an architectural difference. In NuCypher today, there is one application that stakers operate — proxy re-encryption. In Keep, there are three — the random beacon (threshold BLS), threshold ECDSA, and the rest of tBTC.

Aside from that architectural difference, NuCypher’s “staker” role is isomorphic to Keep’s “owner” and “beneficiary” roles, and NuCypher’s “worker” is isomorphic to Keep’s “operator” role.

Staking experience

By and large, staking on the NuCypher network is simpler for operators than staking on Keep.

Staking on NuCypher requires daily heartbeats to check in, which have become expensive over the past few months due to gas prices.

Staking the Keep random beacon is also gas intensive, though the expenses are typically covered in ETH by beacon requestors.

Staking Keep ECDSA and signing for tBTC, however, are much more involved, requiring additional collateral, as well as maintaining ETHBTC collateral positions, a labor and gas intensive process.


The NuCypher network is governed by the NuCypher DAO, an Aragon-based DAO that allows stakers to vote on-chain to execute proposals. NU stakers opt into majoritarianism; a majority-supported contract upgrade can affect staking operations, regardless of individual staker consent.

The network has a privileged multisig, called the Emergency Response Team (ERT). The ERT can respond more quickly to network threats than a traditional DAO. ERT members are determined by the NuCypher DAO, which can add or remove members at will.

The Keep network, on the other hand, is governed by a “dev team proposes, stakers ratify” model. New contract upgrades require each staker’s authorization before putting their funds at risk. This is great for protecting minority rights and stakers who aren’t ready for an upgrade, but isn’t flexible enough for governing network parameters like emissions.

For that reason, the Keep network has also begun the transition to a community-elected multisig. Today, the multisig governs certain parameters in tBTC v1, and is in the process of taking over liquidity and staking reward management from the dev team.

Client networks

The NuCypher network of “Ursulas” is comprised of 2000 worker nodes today. Each communicates over exposed HTTP interfaces, managing their own network bootstrapping and discovery. Because NuCypher is a single-application network, additional service discovery on the network is unnecessary.

The Keep network is smaller, comprised of 200 operator nodes today. Each communicates over libp2p, utilizing common patterns for bootstrapping and discovery. The network also employs an authorization scheme, requiring a node to prove it has a minimum stake before joining, mitigating common DoS vectors.


Thanks for the good summary, @mhluongo.

One additional detail on staking mechanics in NuCypher, is that there is a 1:1 relationship between Staker and Worker. That is, each Staker bonds to exactly one Worker and vice versa. It’s not possible for a Worker to support multiple Stakers. I believe the same is true in Keep, but I’m not certain.

However, a Staker can be a smart contract so it’s possible to implement a form of stake pooling at this level. The pooling smart contract (example here) can accept deposits from multiple addresses and then bond to a Worker. In this model, the pool administrator doesn’t have access to deposits, but they are “semi-trusted” in that they control staking configs and are responsible for bonding to an operable Worker.

Currently, there are only 1 or 2 of these types of pools on the network.