Over the past few weeks, we’ve been discussing a major collaboration with NuCypher.
We’ve gotten to know the the team and community over the years, and have huge respect for what they’ve built. A couple weeks ago, a few shared Keep and NuCypher community members reached out. We all got on a call, and realized we have a lot in common.
We have shared goals: driving the adoption of threshold cryptography, privacy-preserving technology, and decentralized Bitcoin on Ethereum. And we have aligned communities: stakers who want to realize a vision for a freedom-preserving world built on cryptography, and developers who refuse to compromise end-user security.
This conversation led to an interesting idea, and since then we’ve pulled in stakers, community members, and developers from both networks to get early feedback. And now, together, we would like to propose something new… the first decentralized, on-chain protocol hard merge.
With the consent of our stakers and community governance multisig, I propose we execute a hard merge with the NuCypher protocol, forming an extended network in a 50/50 on-chain collaboration between both communities.
What, exactly, is a hard merge?
The idea is to combine protocols and staking networks as well as development efforts, allowing both communities to rally behind a new network inheriting the best aspects of each original network. As far as I know, this is the first effort to merge protocols in this way, sharing some similarities with a “hard spoon”, while bringing together two different networks using an interoperable third network.
We believe that teaming up is the best way forward. As we see every day in Ethereum, cooperation and composability often trump competition. The Keep and NuCypher networks have built similar technology with similar goals. Rather than continuing to split the market, we think we can achieve significantly more together. And while both dev teams will remain independent, we’ll all be focused on a single protocol.
Keep and NuCypher combining forces to bring more useful services, and more fees, into a joint network is the surest path to long term sustainability and success of the work-token model for threshold cryptography.
Implementing a combined network
Combining the NU and KEEP protocols requires committing to a few important decisions upfront to ensure the resulting network is more resilient, decentralized, and sustainable than the sum of its parts.
A phased roll-out
I propose the new protocol be rolled out in 4 phases, allowing partitioned functionality and iterating toward complete integration.
- A new staking contract, supporting both NU and KEEP as work tokens
- A DAO, managed by stakers in the new contract
- Deploying the random beacon and tBTC v2
- Integrating the client networks
The staking contract
The first component in the new network is a staking contract.
The staking contract should accept any candidate work token on an allowlist, each with a governable relative staking weight. The first two tokens on this allowlist will be NU and KEEP. The staking weights should be algorithmically or manually managed such that they take into account each existing network’s emissions schedule, giving each a collective 50/50 stake in the network.
Building in the ability for governance to add future work tokens keeps the new network flexible.
The new network will need its own governance to enable upgrades, to adjust staking weights, and to ensure fair fee distribution.
The new network DAO should give every staker a vote, proportional to their total staking weight. Additionally, the DAO will periodically elect a council as a form of representative democracy. This council will freely decide ongoing economic parameters that are in the best long-term interest of the network. As a balance against a rogue council, they can be recalled and replaced by a high-quorum DAO vote.
Deploying tBTC v2
tBTC v2 will be deployed to the combined network, increasing the number of candidate stakers to as many as 2200 at launch. The minimum stake will be adjusted to allow further participation and increase network resilience. Because v2’s rollout is more iterative than v1, council-based governance will be crucial to a successful deployment.
After the rollout of v2, the new network will not only host the most widely decentralized custodial solution in existence, it will have removed all economics bottlenecks present in tBTC v1, opening the door to surpass WBTC.
Integrating the client networks
Initially, the client network will move forward as dual deployments. Proxy re-encryption stakers will use the nucypher client, random beacon and ECDSA stakers will use the keep-core and keep-ecdsa clients.
The teams will begin work on a shared network specification and release plan, with the goal of shipping two compatible clients for the new network.
This integration will bring proxy re-encryption and future NuCypher applications to the combined network.
Proposed voting methodology
I hope to use the next week to discuss the direction and details of this proposal, both among ourselves and with the NuCypher community.
Once we’ve had time to discuss and address any feedback on the proposal, I’d like to put the issue to community multisig and staker signaling votes. Though Keep SEZC won’t vote its holdings, all employees and contributors are free to vote for whatever they think is in the best interest of the network.
If our community is behind the move and the NuCypher community agrees, we’ll move toward a more detailed implementation plan.
This is an incredible opportunity. As the first on-chain hard merge, we have a chance to change how collaboration in the space works, forever… seizing the narrative and the momentum we need to be the leading Bitcoin bridge everywhere. I look forward to hearing everyone’s thoughts
Token holders have asked how the new network can be split evenly between both communities, considering the difference in each token’s economics.
The invariant we want to hold can be modeled by calculating or estimating the total “stakeable” tokens on each respective network at a given time, and adjusting the staking weights of each work token in the new staking contract to match.
StakingWeight_KEEP = KEEP_stakeable / (KEEP_stakeable + NU_stakeable) StakingWeight_NU = NU_stakeable / (KEEP_stakeable + NU_stakeable)
Maintaining this invariant will normalize the NU and KEEP emissions schedules as well as any specific contributor vesting schedules.
Some additional care needs to be taken to allow for any unvested tokens in either network that aren’t immediately stakeable in the original network (eg some older KEEP grants), but the respective staking adapter should be able to handle those edge cases.