Adopt the xERC20 Open Standard for wstETH Across All Chains

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.


  • 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.


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 Lockbox for multiple networks promises enhanced liquidity and encourages the adoption of this unified model.
  • Flexibility in bridging Providers: The Lockbox model allows for diverse bridge adapters, enhancing independence and flexibility.
  • Standardized Bridging Architecture: A unified standard simplifies scalability and management compared to ad-hoc solutions.


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.


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

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)


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).


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.