stETH on Optimism upgrade announcement and action plan

Proposals Lido Multichain
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