Hey, @arjun! I’m following up on your proposal.
Disclaimer: My opinions are based on my experience as a contributor to the Lido on Ethereum core protocol and participant in the NEW tech wing.
Tl;dr
- Pros: The proposal could enhance wstETH’s cross-domain liquidity and facilitate the launch of new ‘wstETH on X’ through a unified liquidity source (
Lockbox). - Cons: However, it focuses mainly on technical aspects, lacking a comprehensive approach for Lido-specific needs and domain aspects. Key concerns include altered security and accountability dynamics, risk isolation model weakening, absence of risk management and execution frameworks, operational load, and additional implementation-wise considerations.
- My view is that the provided proposal is incomplete regarding the concerns above and might not be well-suitable for today’s evolution of L2s and other non-Ethereum networks.
Derivation and arguments
Let me explain the advantages, concerns, and technical issues.
Advantages
Hardly one can argue with the highlighted benefits in the case of the xERC-20 adoption based on general considerations:
- Shared Liquidity: Utilizing a common
Lockboxfor multiple networks promises enhanced liquidity and encourages the adoption of this unified model. - Flexibility in bridging Providers: The
Lockboxmodel allows for diverse bridge adapters, enhancing independence and flexibility. - Standardized Bridging Architecture: A unified standard simplifies scalability and management compared to ad-hoc solutions.
Concerns
Recap: state of the art risk model
Currently, the process of recognition of the bridged token and its endpoints is accomplished with the following:
- the DAO Agent contract is admin for proxies and administrative roles that might or might not exist for the token and its endpoints;
- there is only a single special committee entity called ‘emergency breaks’ that can potentially pause bridge-related deposits/withdrawals.
These measures are for adopting new standards, bridging flows, and addressing various systematic outage issues mostly, not presuming or encouraging any active and regular risk assessment and management by the DAO.
Moreover, the latter becomes especially controversial because the DAO can’t practically control bridge providers or external networks (i.e., L2 sequencers and their integrity).
Cross-domain risks isolation
Using a shared Lockbox may mix risks across domains, potentially affecting assets in unrelated networks during a breach.
As said, wstETH on L2 is bridged using the canonical bridges using the ‘lock-and-mint’ approach, while the bridged asset locks on the L1 bridge endpoint contract. There are a few unofficial and under-development but practical guidelines that facilitate new wstETH on L2 projects following the same typical future-proof architecture already applied to the following networks: Arbitrum, Optimism, Base, zkSync Era, Mantle, and partially for Linea.
The risks of different L2s are currently isolated because assets are escrowed on separate disentangled bridge contracts with 1:1 correspondence to their bridged counterparts.
In the case of using the shared Lockbox instance, cross-domain risks combine (at least partially), except for those who haven’t bridged at all.
DAO control and sovereignty
The proposal potentially overextends the DAO’s responsibilities, especially concerning bridge and network operation controls.
The DAO doesn’t run bridge infrastructure and message validations; the same applies to external network transaction inclusion and coherence. Therefore, saying that the DAO has sovereign control of the asset is a bit inaccurate or even wrong.
Maintainance of risks actively and regularly
Even though if the DAO control had been accepted and ratified with additional essential changes and assumptions, there are still two things that would have needed to be developed and maintained:
-
Risk assessment framework
To derive the principles and metrics on how to correctly estimate the risks and recommend/execute changes on rate limits and caps, onboarding new bridges, onboarding new networks
-
Risk management framework
To have action plans and runbooks that can be executed based on observed conditions and re-evaluating the result achieved to form a negative feedback loop for the long-term convergence
The standard has only a technical answer on those by defining the levers and their mechanics but doesn’t say by whom, how, and when to use them appropriately.
As a brief reminder, the full list of actions is presented in the following note as a comment on the original ERC-7281 proposal.
Once again, maybe the proposal design might be misalignmed with the DAO role, capabilities, and ownership principles.
Security baseline dilution
Adding numerous, potentially less secure networks could dilute the overall security baseline.
Two points to support the statement:
- increasing the number of networks leads to an enlarged set of parameters to manage simultaneously;
- it’s expected that the new networks will potentially be ‘greener’ and less battle-tested in the long run.
Protocol impact
The proposed architecture might have unforeseen consequences on the protocol, such as governance dynamics.
Let’s suppose the Lockbox might technically become the largest (w)stETH token holder. The latter might pose concerns to the Dual Governance risk assessments and parameters in case of possible disturbances.
Technical issues and limitations
In addition to the general design considerations above, more concrete technical issues should be brought up.
Upgradeability
The provided audited repo isn’t upgadeable
The proposed system’s lack of upgradeability could limit its ability to adapt to new standards.
Rough and quick example: wstETH on L1 is non-upgradeable
- it has the permit extension support, but it doesn’t support ERC-1271 that is a part of EIP-4337 AA vision;
- the same is true for ERC-4626 and its recent proposed additions and extensions (e.g., [1], [2])
- the token makes some of the stETH on L1 non-ERC20 interfaces to be strictly pinned (stETH.getPooledEthByShares and stETH.getSharesByPooledEth)
Incomplete implementation
The proposal misses crucial elements like network-specific adapters and support for various token standards (e.g., not only the mentioned above ERC-2612/ERC-1271, but for BNB, it might be BEP-20)
Migration
Transitioning to this system would require significant effort and coordination, posing operational risks.
As it’s said, to support the proposed architecture not only the DAO would need to approve and execute the migration campaign involving asset movements from the L1 bridging contracts.
It also involves considerable operational costs and efforts in coordination with foundations and communities to safely and seamlessly move more than 200k wstETH from multiple escrow contracts to a single Lockbox.
Lack of governance execution framework
The Lido DAO has Easy Track to execute lightweight repetitive actions robustly.
Governance decision forwarding isn’t considered as a part of the proposal, which is obviously a separate topic, still, the first question is whether the Easy Track model is applicable for bridging risk management execution at all.
The second question concerns the lack of the factories and technical scaffolds to streamline the execution (ubiquitous alerting and monitoring, new UI/UX flows, and additional safety nets).
Conclusion
Considering the above, adopting this proposal seems premature.
It needs more explicit alignment with Lido’s mission, purpose, and vision and a more comprehensive approach to active risk assessment, management, and operational execution load.
A more aligned, risk-focused, and operationally feasible approach is necessary. A potential path forward could involve isolated liquidity clusters for mature, technologically cohesive L2 networks (with their attached ‘superchains’ or ‘hyperchains’), assessed against specific criteria like rollup maturity stages and technological stacks compatibility.