[BIP-622] Enable Gauge for saETH/wstETH pool on Mainnet

PR with Payload


This is a proposal on behalf of Aspida to enable two gauges on Ethereum. One for aETH/wstETH, one for saETH/wstETH.aETH serves as the deposit certificate of the native ETH token and can be minted with ETH at a 1:1 ratio. saETH is a staking ETH LSD staking token,it is an ERC-4626 compliant token that is minted upon aETH staking.

References/Useful links:


Documentation: https://docs.aspidanet.com/

Github: Aspida · GitHub


Telegram group: Telegram: Contact @aspida_net


Other useful links:

Twitter:@aspida_net x.com

Medium: Aspida – Medium

Protocol Description:

Aspida is a liquid staking infrastructure designed to enhance Liquidity Staking Token (LST) assets across major cryptocurrencies. We are committed to advancing decentralization by prioritizing the integration of underlying services that enhance decentralization, such as our collaboration with Distributed Validated Technology (DVT) solutions like SSV to decentralize validator sets. Our primary focus remains on optimizing risk-adjusted staking yields, achieved through initiatives like integrating native staking via Eigenlayer.

We offer a decentralized, secure, and highly compatible staking service for Liquidity Staking Derivative (LSD) assets. In addition to launching our inaugural ETH LSD asset (saETH), we are actively developing innovative LSD solutions for the Ethereum network.


Aspida aims to enable gauges for aETH/wstETH and saETH/wstETH to significantly increase the liquidity of aETH and saETH. Aspida is building on several L2 Networks, including Arbitrum, Blast, and Base. These pools will undoubtedly enhance the trading experience and lead to user growth for all parties involved.

We are also conducting ongoing incentive campaigns for users in collaboration with top DeFi protocols from these L2 networks. Increasing the market’s liquidity depth through Balancer will instill strong confidence in our users and provide them with the flexibility of asset exchange.

  1. Governance: Provide current information on the protocol’s governance structure. Provide links to any admin and/or multisig addresses, and describe the powers afforded to these addresses. If there are plans to change the governance system in the future, please explain.

    Aspida is is decentralized in nature but in current stage will be controlled by related multisig addresses under the structure of Aspida DAO due to development demand.

    Multisig addresses:


    name Contract Address etherscan GnosisSafe
    owner 0xEC852538b5b6A62390fEE1432756a61834B7D79A GnosisSafeProxy | Address 0xEC852538b5b6A62390fEE1432756a61834B7D79A | Etherscan Safe{Wallet} – Dashboard


    name Contract Address arbiscan GnosisSafe
    owner 0xdf8DeaF883b207BEB5b45467288D71E7A72e8fa0 GnosisSafeProxy | Address 0xdf8DeaF883b207BEB5b45467288D71E7A72e8fa0 | Arbiscan Safe{Wallet} – Dashboard
  2. Oracles: Does the protocol rely on external oracles? If so, provide details about the oracles and their implementation in the protocol.

    RateProvider for saETH:

    ethereum: saETH: 0x1aCB59d7c5D23C0310451bcd7bA5AE46d18c108C

    ERC4626RateProvider | Address 0x1aCB59d7c5D23C0310451bcd7bA5AE46d18c108C | Etherscan

    review: Aspida asETH Rate Provider · Issue #35 · balancer/code-review · GitHub

  3. Audits: Provide links to audit reports and any relevant details about security practices.

    Audit: documents/audits at main · aspidanet/documents · GitHub
    Bug bounty: Aspida Bug Bounties | Immunefi | Immunefi

  4. Centralization vectors: Is there any component of the protocol that has centralization vectors? E.g. if only 1 dev manages the project, that is a centralized vector. If price oracles need to be updated by a bot, that is a centralized vector. If liquidations are done by the protocol, that is also a centralization vector.

    Aspida is building on DVT network especially SSV network as a decentralized system where independent node operators work to power the growth. Further detailed information may be found here: DVT Network | Aspida

  5. Market History: ****

    No major volatility

  6. Value: Is this pool intended to be the primary source of liquidity for the token(s)? If this is not the case, explain the expected value add to Balancer (can this pool generate consistent fees?)

    The pool is intended to be the primary source of liquidity for saETH on Ethereum and allow for a healthy stimulation of volume.

Note: Please ensure the owner of your pool on Ethereum is set to 0xba1ba1ba1ba1ba1ba1ba1ba1ba1ba1ba1ba1ba1b If this is not done, please clearly explain why in your proposal.


Pool info:

Pool: Balancer

Gauge: Vyper_contract | Address 0x4B14d90f76FCF4D69CbCCdf87643E5DD7815D21A | Etherscan

The Balancer Maxi LM Multisig eth:0xc38c5f97B34E175FFd35407fc91a937300E33860 will interact with the GaugeAdderv4 at 0x5DbAd78818D4c8958EfF2d5b95b28385A22113Cd and call the addGauge function with the following arguments:

gauge(address): 0x4B14d90f76FCF4D69CbCCdf87643E5DD7815D21A

gaugeType(string): Ethereum

Pool: Balancer
Gauge: Vyper_contract | Address 0x192e80145D8A78B4eF6ec5De5c8fD51aFC7F9c5e | Etherscan

The Balancer Maxi LM Multisig eth:0xc38c5f97B34E175FFd35407fc91a937300E33860 will interact with the GaugeAdderv4 at 0x5DbAd78818D4c8958EfF2d5b95b28385A22113Cd and call the addGauge function with the following arguments:

gauge(address): 0x192e80145D8A78B4eF6ec5De5c8fD51aFC7F9c5e

gaugeType(string): Ethereum