wstETH deployment on Starknet

Proposals Lido Multichain
1

Introduction

StarkWare proposes the deployment of wstETH (Wrapped staked ETH) to Starknet, with the ultimate goal of recognition of the wstETH bridge endpoints as canonical by the Lido DAO.

Starknet’s Growth and Ecosystem

We believe in the potential of wstETH on Starknet to bring new opportunities within the DeFi ecosystem and boost the demand for wstETH across various platforms.

Since Nov ‘21, developers worldwide have worked tirelessly to build and develop Starknet’s Mainnet, the first Turing-complete Validity Rollup on Ethereum. As a result, Starknet is now the largest developer ecosystem among all L2s, having grown 14% over the past year to become the 8th largest blockchain developer community and the leader in the L2 landscape.

References: Developers Report.

High Demand for wstETH

Lido’s (w)stETH has secured its position as a leading DeFi protocol on Ethereum mainnet. Starknet, as a leading Ethereum scaling solution, is seeing significant demand for the adoption of the wstETH as it opens up opportunities for users to utilize stETH holdings in various DeFi protocols. Launching wstETH on Starknet supports the missions of Lido, Ethereum, and Starknet, making Ethereum scalable, decentralized, and approachable. Therefore, major ecosystems such as Starknet have significant demand for wstETH as it opens up opportunities for users to utilize stETH holdings in various DeFi protocols.

Implementation

Currently, wstETH is bridged to Starknet via StarkGate, the canonical bridge of Starknet developed by StarkWare. All the bridge components, both L1 and L2, are upgradeable. Starkware will enable a cross-chain governance solution that will enable Lido to govern the bridge’s wstETH. We estimate that the feature will be available by the end of Q2 2024.

Next Steps

The relevant source code and audits will be made available after the development of the cross-governance future is finished. These will be published to provide full transparency and accessibility to the Lido community. In addition to the cross-governance feature, we will propose upgrading the wstETH bridge to the latest version of StarkGate, StarkGate 2.0. This version is already live on Goerli and will soon be launched on Mainnet (For other tokens). The community will be encouraged to review the code and raise any questions or concerns they might have before the mainnet launch.

Conclusion

The recognition of wstETH bridge endpoints as canonical of the bridging components by Lido DAO will represent a significant step toward enhancing the DeFi ecosystem within Starknet and the continued adoption of wstETH.The importance of this initiative is underscored by the steady growth and high potential of Starknet, together with the strong demand for wstETH.

We invite the Lido community to engage in discussions and provide feedback as we move forward with this exciting development.

Audits

Mainnet Contracts (StarkGate 1.0)

  • L1 wstETH token address: “0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0”,
  • L1 bridge address: “0xBf67F59D2988A46FBFF7ed79A621778a3Cd3985B”,
  • L2 bridge address: “0x0088eedbe2fe3918b69ccb411713b7fa72079d4eddf291103ccbe41e78a9615c”,
  • L2 wstETH token address: “0x42b8f0484674ca266ac5d08e4ac6a3fe65bd3129795def2dca5c34ecc5f96d2”

Testnet (Goerli) Contracts (StarkGate 2.0)

  • L1 wstETH token address: “0x6320cD32aA674d2898A68ec82e869385Fc5f7E2f”,
  • L1 bridge address: “0x190c98506a5396A30CA759A139F3Fb59EF519A5D”,
  • L2 bridge address: “0x0399a6011b666888d647665fd65d6dcc7c2690c72d4c4454cae987f19f6ef609”,
  • L2 wstETH token address: “0x0335bc6e1cf6d9527da4f8044c505906ad6728aeeddfba8d7000b01b32ffe66b”

Levers setup wstETH StarkGate bridge (suggested):

L1 Ethereum

  • governance_admin - StarkWare extreme cold wallet (Lido DAO agent):
    • Assign governance_admin
    • Assign upgrade_governor
    • Assign app_role_admin
  • upgrade_governor - StarkWare cold wallet (Lido DAO agent):
    • Can upgrade the bridge contract on L1.
  • app_role_admin - StarkWare cold wallet (Lido DAO agent):
    • Assign app_governor
    • Assign token_admin
  • app_governor - StarkWare cold wallet (Lido DAO agent):
    • Change Max TVL limit.
  • token_admin - StarkWare cold wallet (Lido DAO agent):
    • Register token.

L2 Starknet

  • governance_admin - StarkWare extreme cold wallet (Lido DAO agent through gov. feature):
    • Assign governance_admin
    • Assign upgrade_governor
    • Assign app_role_admin
  • upgrade_governor - StarkWare cold wallet (Lido DAO agent through gov. feature):
    • Can upgrade the bridge contract on L1.
  • app_role_admin - StarkWare cold wallet (Lido DAO agent through gov. feature):
    • Assign app_governor
    • Assign token_admin

Source code and Documentation

  • Source code repo for StarkGate (Live on Mainnet).
  • Source code repo for StarkGate 2.0 (Live on Goerli).
  • StarkGate Documentation.
6 Likes
2

Absolutely needed, and a huge step forward in terms of marking Starknet getting closer to its full launch as well as inspiring confidence that it will be a legitimate venue for scaling ethereum-based defi further than any other project before.

1 Like
3

I’d be really happy to see this, and the timing for this proposal makes a lot of sense as Starknet currently is lacking options in terms of ETH staking.

5

Hey, @Natan_SW

Absolutely amazing proposal given the StarkWare experience and proven track record in ZK-STARKs pioneering and adoption.

I am particularly in love with StarkWare x Herodotus collab to make storage proofs available across ecosystem paving the way for more robust bridging and DeFi opportunities.

With regards the proposal presented, would love to be in touch for connecting the dots with technical and security stuff counseling and advising, including a possible governance forwarder implementation.

As for me, having those is highly desirable to run a transparent Snapshot vote given the long-term opportunities and ecosystem maturity.

2 Likes
6

Hey @TheDZhon , thanks for your warm comment! I’m Ohad from the StarkWare team and I work closely with Natan. We are now in initial phases of designing the governance forwarder, and we think designing it with maximal collaboration and transperancy is essential for moving toward a vote and build trust between our ecosystems.

Therefore I’d love to discuss with you the governance forwarder design, as well as any other concern you have, around the proposed way to integrate wstETH to Starknet.

If anyone else would like to discuss it LMK! I’m @OhadStarkWare on TG.

4 Likes
7

wstETH Proposal update

We are thrilled to announce the successful completion of the cross-governance solution for wstETH on Starknet. This milestone has been made possible through dedicated efforts from the Nimbora team by SpaceShard and strong backing from StarkWare.

As we move forward, we encourage the Lido community to engage in discussions and provide feedback on this development.

The Starknet Foundation has also separately committed to assigning Defi Spring rewards to wstEth in order to incentivise wstEth holders to bridge and deploy their wstEth on Starknet.

Below is the updated information regarding audits, mainnet and testnet contracts, and source code repositories.

Audits

Mainnet Contracts - StarkGate 2.0

Testnet (Sepolia) Contracts - StarkGate 2.0

Source code and Documentation

  • Source code repo for StarkGate 2.0 (Live on Mainnet).
  • Source code repo for the Lido - Starknet governance forwarder.
  • StarkGate Documentation.
4 Likes
8

GM, thank you for updating the proposal, excited about the prospect of having wstETH recognized within the Starknet ecosystem.

To facilitate the upcoming snapshot vote, the Network Expansion Workgroup has engaged the well-known Nethermind Security team, who are deeply familiar with Starknet, to conduct a thorough review of the deployment artifacts and overall solution setup. Their insights might provide valuable information to help DAO token holders make a more informed decision.

Once the deployment verification report is finalized and any necessary adjustments are made, the report will be shared in this thread.

3 Likes
9

wstETH Proposal update

Hey everyone, I’m Shani from the StarkWare team, and I recently took over StarkGate, replacing Natan.

Below you can find the updated information regarding audits (including a recent audit report), mainnet and testnet contracts, and source code repositories.

Audits

Mainnet Contracts - StarkGate 2.0

Testnet (Sepolia) Contracts - StarkGate 2.0

Source code and Documentation

  • Source code repo for StarkGate 2.0 (Live on Mainnet).
  • Source code repo for the Lido - Starknet governance forwarder.
  • StarkGate Documentation .
5 Likes
10

Hey, @Shani_Rozenzweig!

Thank you for continuing the thread. It’s good to see that the up-to-date audit allowed to reveal and resolve quite a severe finding in the previously deployed version.

image
image1255×443 86.9 KB

image
image940×159 30.8 KB

I see that the L1 bridge proxy was upgraded to the following impl deployed 26 days ago and marked as ‘StarkWare_StarknetERC20Bridge_2.0_5’ as in the fix commit.

Nevertheless, as said earlier, to proceed, the Network Expansion Workgroup suggests waiting for the final deployment verification report from Nethermind Security to provide an outlook on the deployment artifacts’ state and overall setup.

Please stay tuned.

4 Likes
11

Happy to join the discussion :slightly_smiling_face:

I’m looking forward to moving this proposal because I think bridging wstETH between Ethereum and Starknet will not only boost the liquidity but also enhance Lido’s presence in Starknet’s growing DeFi ecosystem.

Starknet is a unique L2 and having significant wstETH presence on Starknet will grant Lido first mover advantage.

3 Likes
12

Hey everyone,

the Nethermind Security team has finalized the verification report, which contains an overview of the provided solution regarding the audited code state, roles, initialization, and previously used unofficial guidelines covering the design recommendations and bridging approaches.

The report has been uploaded to the audits repo: audits/L2/Starknet-2024-11-14-deployment-verification.pdf at main · lidofinance/audits · GitHub

It is worth highlighting that:

  • the levers setup hasn’t been finalized, as it is contingent on the Lido DAO’s potential bridging endpoints and token recognition
  • the token contract is unverified on Starkscan due to the longstanding issue with Cairo 1 support
13

General Thoughts

Thank you to all the work from the multiple teams pushing wstETH improvements on Starknet/Lido forward. In general, the more control Lido DAO exercises over the flow of wstETH and stETH to external chains, the better. Historically, we’ve seen similar social checks/balances on wstETH bridging solutions, like optimism’s, and believe that viewing the proposed wstETH improvements through a lens of past precedent may be prudent. While we read the final deployment verification report from Nethermind Security, we feel the following questions would be helpful answering for visibility:

Questions

  1. Who are the actors capable of upgrading/disabling/enabling the bridging solution on the L1 and L2 side?

  2. What safety measures are in place in case Lido governance experiences connectivity issues and loses the power to enforce its will?

  3. With the recency of LIP 22, which enabled rebasable stETH on L2s from the stable balancer wrapper of wstETH, we find it pertinent to ask why a similar transition from wstETH to stETH was not taken on Starknet?

Sources
1 Like
14

1. Who are the actors capable of upgrading/disabling/enabling the bridging solution on the L1 and L2 side?

  • We have a few roles defined, these roles are mapped to the various restricted calls.
    the roles names, heirarchy and general “order of things” are the same for L1 & L2.
    governance_admin is the root of the roles heirarchy, it’s the “owner” of the contract, it can nominate upgrade_governors (and app_role_admin)
    upgrade related actions - restricted to addresses that hold upgrade_governor role (applies to L1 bridge, L2 bridge, L2 token)

security actions:
enable_withdrawal_limit - restricted to the role of security_agent (both L1 & L2 bridge)
disable_withdrawal_limit - restricted to the role of security_admin (both L1 & L2 bridge)

security_admin can also nominate security_agent & security_admin (security roles are a separated role heirarchy).

on L1 bridge there is also the option to limit/disable deposit using setMAxTotalBalance
which is restricted to the app_governor (nominated by an app_role_admin)

2. What safety measures are in place in case Lido governance experiences connectivity issues and loses the power to enforce its will?

  • assuming connectivity issues are conceived as more probable on the younger chain, the L2, then the ones on L1 can be used. deposits can be blocked as aforementioned, and withdrawals can be limited.

if the discontinuation of governance is due to compromise - that indicates the importance of managing well the two different levels of roles. the gov admin - that cannot execute, but can nominate, and the upgrage gov ,that cannot nominate, but execute and its execution is (can be) time delayed.

  1. The enrollment of wstEth onto Starknet was done 18 ago, we didn’t know about LIP22. The basic pattern of token bridging does not do this wrapping pattern by default. we can talk about it :wink:
4 Likes
15

Is this still an issue?
You should be able to verify Cairo 1 contracts on voyager: https://voyager.online/
That’s where we have been doing it on Starknet. If any issue I can reach out to the team at Nethermind.

17

It seems that it’s not a blocker because the bytecode verification of the token deployed has passed against the audited commit (which is more strict and rigid).

Nevertheless, the request has been propagated to the team behind the proposal to check the feasibility of this approach and not delay the delivery.

18

The Voyager Verifier has a prerequisite that the contract code be built using Scarb, which is not the case for wstETH token (since it was built a while back). Refactoring the code to use Scarb would inevitably alter the class hash (even if the code is identical), because relative paths contribute to the class hash.
In short - we cannot use the Voyager tool to verify the deployed contract.

1 Like