Stakehouse Protocol Progressive Immutability

Governance
1

Stakehouse Protocol Progressive Immutability

Stakehouse Protocol Deployment Notice

Background

The Blockswap Labs team has been developing the Stakehouse protocol since 2020. It started in Communitynet to stress test the core contracts during the largest on-chain testnet amassing over 24,000 ETH validators. This cemented the idea that ETH staking needed an Easy Mode to bring staking rewards to the masses.

Being first of its kind comes with many challenges. Without prior historical mainnet data, the testnets were conducted with limited infrastructure and tooling support from the Ethereum ecosystem. Because of this lack of historical data on the Mainnet consensus layer, the Stakehouse Protocol will initially launch with upgradeable smart contracts. This is a pragmatic mitigation measure that is referred to as a progressive release candidate.

Release Candidates

Release candidates represent consecutive stages of the Stakehouse protocol that the development team believes are “ready for public usage on mainnet”. These stages may or may not be fully immutable as the team still requires data from on-chain assessments. Release candidates progress from 0 - 4 until a candidate is deemed final and upgraded to a fully autonomous release. Each step below assumes a reasonable time frame at each checkpoint to monitor and ensure security. The objective is to monitor protocol resilience in the Ethereum environment.

  1. 0 KNOTs
  2. 100 KNOTs
  3. 1,000 KNOTs
  4. 5,000 KNOTs
  5. 15,625 KNOTs

KNOTs are Ethereum validators that have minted derivatives in the Stakehouse protocol.

The above are subjective reference points dependent on performance metrics. They represent the goals for removing access controls. It is important to note Stakehouse protocol doesn’t have a ceiling, guarded launch, permissions, or anything that prevents deposits. This is subjective to the amount of ETH compared to the timeframe it’s been maintained in the protocol.

Protocol Maintenance

Blockswap Labs being the core contributor to Blockswap Network will have the ability to do maintenance upgrades for the smart contracts. This is a limited steward role should anything in the protocol not function as per the audits. Blockswap Labs intends to hold this position for the shortest possible time. Once the protocol reaches the predetermined critical mass, upgradeability will be removed (made immutable) on a per smart contract basis; Smart contracts that are functioning as intended will be made immutable with exceptions made as required.

For example, an exception can be made on the AccountManager smart contract. This contract is assigned the withdrawal credentials for all of the derivatives in the platform. Until such a time that the Ethereum Foundation has defined the withdrawal mechanism, this contract should remain upgradeable. This is so that the required withdrawal functionality can be added for users that have Rage Quit, but have not yet received their staked ETH from the consensus layer.

Outside of maintenance upgrades, Blockswap Labs will also have the ability to extend the functionality of the Stakehouse protocol. Core Modules and adaptors can be added, removed, or frozen (locked) from the access controls registry contract which manages the contract-to-contract communication. The before mentioned capabilities do not include access to funds whatsoever.

Blockswap Labs nor any third party has access to users’ funds or validator keys. Only the corresponding user has access to those.

1600Ă—1363 155 KB

Figure 1

Access Controls

The access controls smart contract registry tracks privileged roles held by ECDSA public keys.

Below are clearly defined roles:

  • Admin: Account that can grant the proxy admin role to any account.
  • Proxy Admin: Account that can facilitate proxy upgrades and can make proxies immutable on a proxy by proxy basis.
  • Core Module Admin: Admin account for the core module hierarchy that can grant the core module manager role to any account.
  • Core Module Manager: Account that can add or remove core modules (provided the core module is not locked from removal).
  • Core Module: Whitelisted smart contract within the Stakehouse protocol. Both Core Modules and adaptors are granted this role and it allows contract to contract communication.
  • Common Interest Manager: Role that has the ability to whitelist router instances that can sign EIP712 signatures over consensus layer balance reporting packets.

Core Module Locking

Once any Core Module is performing as expected, it can be locked which will make its Core Module whitelisting status permanent. This is the process for making the protocol immutable. The protocol also needs to separately disable upgrades on the contract level to make it fully independent and immutable from changes.

3 Likes