stETH on Optimism upgrade announcement and action plan

Proposals Lido Multichain
1

stETH on Optimism upgrade announcement and action plan

TL;DR

Lido stETH workstream contributors have developed a detailed action plan, built on the previously approved LIP-22 proposal. The objective is to upgrade the wstETH bridge smart contract endpoints, enabling the availability of rebasable stETH on the Optimism network alongside the already deployed wstETH as a part of the upcoming on-chain Aragon vote.

For a deeper understanding of both token availabilities, refer to the LIP-22 motivation section.

Recap and references

  • In March 2024, a proposal was published on the research forum to bring stETH token reference design for L2s and its practical pilot implementation for stETH on Optimism.
  • The proposed stETH on Optimism upgrade is based on the design supported by the Lido DAO through the LIP-22: stETH on L2 — wstETH on Optimism bridge endpoints upgrade snapshot vote.
  • The upgrade was successfully piloted on the Sepolia testnet, including:
    • Testing deposits and withdrawals of wstETH and stETH, including beta UIs from Superbridge
    • Reporting stETH rebases to the TokenRateOracle on Optimism Sepolia
  • The solution passed audits by MixBytes and Ackee Blockchain.
  • The Superbridge app will offer a bridging UI for both stETH and wstETH, being an official bridging interface for the Optimism network.
  • Wrap/unwrap UI functionality for Optimism will be implemented on stake.lido.fi to facilitate seamless switching from wstETH to stETH and vice versa.

Technical details

The implementation follows the architecture presented with LIP-22: bringing the stETH token to Optimism requires upgrading the endpoint contracts on two blockchains simultaneously: Ethereum and Optimism.

The following contracts were deployed upfront (see proposed marks) to be used for the upgrade procedure:

The upgrade will be implemented in two phases:

  • upgrade L1 parts and send L2 upgrade instructions to Optimism
  • upgrade L2 parts by executing the received instructions

For detailed initial parameters of the upgrade, please refer to this document

Deposits pause warning

:warning: To ensure safety and prevent vulnerabilities during the upgrade, L1 → L2 bridge deposits for wstETH will be paused before the vote starts by the Emergency Brakes Committee. This ensures that any pending deposits are processed before the upgrade. If any transactions are stuck on L2, they can be manually pushed through.

The Emergency Brakes committee will resume deposits once both endpoints are upgraded. The committee will temporarily hold the DEPOSITS_ENABLER_ROLE role on the L1 bridge endpoint, which will be renounced by the committee itself once the upgrade is complete.

:information_source: Note that L2 → L1 wstETH withdrawals will not be affected and can proceed as usual.

LegacyOracle deprecation notice

As part of the vote, the LegacyOracle contract will be deprecated. This step has been planned since the Lido V2 upgrade and has no impact on active protocols, as verified by the Lido contributors accessing the data from Dune Analytics and Tenderly [1, 2, 3, 4].

The only active LegacyOracle data consumer is Voltz Protocol, integrated with the Mellow liquidity vault. The Voltz Protocol has been discontinued since December 2023. It is no longer maintained and is in a withdrawal-only mode, as explicitly confirmed by dev contributors from both Mellow and Voltz Protocol.

Tentative upgrade timeline

  • Oct-7-2024 (Mon): :warning: Pause wstETH Ethereum to Optimism bridge deposits
  • Oct-8-2024 (Tue): Start Aragon voting.
  • Oct-10-2024 (Thu): Main voting phase ends.
  • Oct-11-2024 (Fri): Contingent on the voting outcome.
    • The objection phase and overall voting conclude. Enactment if passed.
    • Executing upgrade for L2 bridge endpoints after the vote is enacted
    • Resume Optimism bridge deposits
    • Renounce Emergency Brakes unpause role
  • Oct-12-2024 (Sat): First post-upgrade AccountingOracle report to come
  • Oct-14-2024 (Mon): Further announcements and new UIs availability

Voting Script

The voting script will be added to the omnibus on-chain Aragon vote, including the following actions:

  • Ethereum-side actions
    • Upgrade L1 bridge endpoint implementation
    • Initialize the new L1 bridge endpoint implementation
    • Upgrade LidoLocator by setting TokenRateNotifier instead of LegacyOracle as a token rebase receiver callback
    • Grant DEPOSITS_ENABLER_ROLE to the emergency brakes committee
  • Optimism (to be sent from Ethereum and executed via OptimismBridgeExecutor)
    • Upgrade L2 bridge endpoint implementation
    • Initialize the new L2 bridge endpoint implementation
    • Upgrade L2 wstETH token implementation
    • Initialize the new L2 wstETH implementation

Contingency planning

The proposed upgrade has passed a rigorous security process. Even though, In case of failure during the upgrade:

  • If the vote fails to reach quorum (the L1 bridge is still paused), suggest a vote restart and communicate further deposit pause delays
  • If the L1 upgrade fails, the L2 upgrade won’t proceed, and wstETH deposits will be suggested to resume via an Aragon follow-up vote (using the following unpause script)
  • If the L2 upgrade fails, a rollback vote will be initiated to restore L1 bridge functionality and resume wstETH deposits (using the following rollback script)
  • If the emergency committee brakes misoperates after the upgrade (e.g., hasn’t renounced the role or hasn’t unpaused the deposits), then an aragon on-chain vote should be launched to replace the committee and continue bridge operations
  • Postmortem will be issued accordingly for possible severe unforeseen cases.

Operational delays or last-minute security concerns will be communicated, and new dates will be announced accordingly.

Discussion

Any additional feedback or suggestions on this proposal would be highly appreciated.

8 Likes
2

It’s definitely quite scary (it’s about legacy oracle sunset) :scream:, probably no one really use it rn. By the way, what’s the current APR according to this legacy oracle? What’s about provide control to dev’s multisig as an emergency measure - like to being able to bump params manually?

1 Like
3

Thank you for bringing additional attention to this matter :saluting_face:

I believe that adding a multisignature (msig) to the LegacyOracle contract may not be the most desirable solution for the following reasons:

  1. Deprecation timeline: As previously communicated, the LegacyOracle contract was scheduled to be deprecated with the Lido V2 release, with explicit deprecation notices until the end of 2023. Extending its use for an additional year effectively prolonged the reliance on outdated infrastructure.

  2. Inaccurate APR calculations: The contract does not support accurate APR calculations under the new Lido V2 mechanics. Below, I’ve provided some illustrative calculations to demonstrate this point.

  3. Increased operational load and technical debt: Introducing a msig would increase operational complexity and add to the contributors’ technical debt. The contract would need to treat this msig as the Lido instance, as shown here: LegacyOracle.sol#L241. This change might necessitate further development and auditing of a new implementation.

  4. Outdated but operational: Lastly, while the contract does not handle new rebase updates, making it unsuitable for current needs, it remains operational regarding returning frame values and general data.

Obsolete APR calculation method (pre-Lido V2) using LegacyOracle

protocolAPR = (postTotalPooledEther - preTotalPooledEther) * secondsInYear / (preTotalPooledEther * timeElapsed);
lidoFeeAsFraction = 0.1; # protocol fee
userAPR = protocolAPR * (1 - lidoFeeAsFraction);

New APR calculation (post-Lido V2) using events from the Lido contract

// Event emitted when token rebased (total supply and/or total shares were changed)
event TokenRebased(
    uint256 indexed reportTimestamp,
    uint256 timeElapsed,
    uint256 preTotalShares,
    uint256 preTotalEther, // preTotalPooledEther
    uint256 postTotalShares,
    uint256 postTotalEther, // postTotalPooledEther
    uint256 sharesMintedAsFees // Fee part included in `postTotalShares`
);

preShareRate = (preTotalEther * 1e27) / preTotalShares;
postShareRate = (postTotalEther * 1e27) / postTotalShares;

userAPR = ((postShareRate - preShareRate) / preShareRate) * (secondsInYear / timeElapsed);

The new formula accounts for preTotalShares and postTotalShares, whereas the old formula did not. Additionally, the new formula eliminates the need to calculate lidoFee, as fee distribution now operates by adjusting the total shares amount internally.

Why this matters

When the protocol finalizes withdrawal requests, the Lido contract sends ether to the WithdrawalQueue, reducing totalPooledEther (thus decreasing TVL) and burns the corresponding stETH shares.

In essence, withdrawal finalizations decrease both TVL and total shares. The old formula is unsuitable because it captures changes in TVL but ignores changes in total shares.

Consider the latest AccountingOracle transaction: Etherscan Transaction

The transaction includes:

timeElapsed :86400
preTotalShares :8317538369147374530810532
preTotalEther :9818177186756829719177589
postTotalShares :8308253443885806736700615
postTotalEther :9808029338750230655290702
sharesMintedAsFees :76438336073114351864
  • APR using the old formula: Approximately negative 34%
  • APR using the new formula: Approximately 3%

As demonstrated, both the total ether amount and total shares decreased, which the old formula misinterprets as a negative rebase.

Given these points, I recommend we avoid adding a msig to the LegacyOracle contract and instead focus on the safety of the proposed upgrade operations.

1 Like
4

I didn’t expect the previous formula to produce such inaccurate data—this is a crucial piece of context, so thanks for sharing. I agree that there is no sense for fallback.

Why not fully deprecate the contract by, for instance, implementing a version that reverts on every call?

Relying on inaccurate data poses a greater risk to consumers than shutting it down completely. In the worst case, we can always roll back if someone reaches out to us.

2 Likes
5

I wouldn’t advise completely disabling LegacyOracle, as it is still utilized by AccountingOracle. lido-dao/contracts/0.8.9/oracle/AccountingOracle.sol at master · lidofinance/lido-dao · GitHub
We are going to disable receiving rebases, but the contract will continue receive data from AccountingOracle, saving the actual epochs.

1 Like
6

:warning: As suggested, the Emergency Brakes Committee has paused the wstETH deposits from Ethereum to Optimism to prepare for the bridge endpoints upgrade procedure.

3 Likes
7

Hi @kovalgek , following @TheDZhon 's post, the contract will still be operational.

Moreover, following a link to the documentation it seems like the contract will remain accessible through the LidoLocator for now.

Screenshot 2024-10-07 at 16.08.52
Screenshot 2024-10-07 at 16.08.521836Ă—810 79.8 KB

If you need it to be accessible specifically through the LidoLocator for example because a tool directly integrates with it (here) - until a specific time for accounting purposes, please provide a date when you can fully migrate and potentially this can be taken into account.

2 Likes
8

Here is the audit report with the deployment verification included: x.com

The report itself has been mirrored here: audits/L2/stETH-on-Optimism-2024-06-MixBytes-Audit-Report.pdf at main · lidofinance/audits · GitHub