[DIP-55] Adding ENS names for the Core Protocol Contracts for increased Security and Verification

Abstract

To mitigate security risks ahead of the launch of SSV Staking, this proposal advocates integrating Ethereum Name Service (ENS) with the protocol’s core smart contracts. By mapping complex contract addresses to readable ENS names (e.g., ssvnetwork.eth) and using Reverse Records, we create a verifiable “source of truth.” This integration aims to reduce impersonation, phishing, and user error by enabling wallets and block explorers to display human-readable names for critical transactions.

Motivation

The imminent launch of SSV Staking with DIP-50, a critical protocol upgrade that introduces high-value, ETH-denominated fee flows and new contract interactions, elevates the risk profile for our users. This proposal outlines integrating ENS (Ethereum Name Service) as a critical security and UX layer to combat the urgent threat of hackers impersonating the new staking site and its core contracts.

Interacting with staking contracts often requires significant capital and “blind signing” of hexadecimal addresses, making them prime targets for phishing.

  • Impersonation Risk: Attackers frequently create malicious contracts with addresses that look similar to legitimate ones to trick users.
  • Verification Friction: Manually verifying a contract address on Etherscan is a technical hurdle that many users skip.
  • User Error: Copy-pasting errors remain a top cause of lost funds in DeFi.

By mapping our smart contract addresses to human-readable names (e.g., ssvnetwork.eth), we provide users with a verifiable “source of truth.” This integration leverages the native security features of modern wallets and block explorers to prevent impersonation and phishing attacks and enhance user confidence during these high-value, critical transactions.

By adopting ENS, we transform these opaque strings into recognizable brand assets that wallets can display, making it nearly impossible for a typo or a fake site to go unnoticed.

Mechanics

Upon the proposal’s passage, the Multisig Committee must set the ENS reverse resolution for the contracts and names outlined below. The SSV Foundation must set the forward resolution and ensure proper registration and management of the names.

  • Contract Naming Mapping:
    • Using the DAO-owned primary protocol domain ssvnetwork.eth, it is proposed to register the following specific subdomains for each mainnet contract:
Contract Address ENS Name
SSV Token 0x9D65fF81a3c488d585bBfb0Bfe3c7707c7917f54 ssv.ssvnetwork.eth
cSSV Token 0xe018D31F120A637828F46aFD6c64EC099d960546 cssv.ssvnetwork.eth
SSVNetworkViews 0xafE830B6Ee262ba11cce5F32fDCd760FFE6a66e4 views.ssvnetwork.eth
SSVNetwork 0xDD9BC35aE942eF0cFa76930954a156B3fF30a4E1 ssvnetwork.eth
DAO Treasury 0xb35096b074fdb9bBac63E3AdaE0Bbde512B2E6b6 treasury.ssvnetwork.eth
SSV Foundation 0xeC29418bc30FED20dE85706F32c7D77Da0be7afB foundation.ssvnetwork.eth
IMP 1 0xe16d6138b1d2ad4fd6603acdb329ad1a6cd26d9f v1-imp.ssvnetwork.eth
IMP 2 {to be deployed} v2-imp.ssvnetwork.eth
Lido SDVT/CSM 0x13006e447608bB62383D1d59bb11a93e957Be7cF v1-imp-lido.ssvnetwork.eth
  • Reverse Record Configuration: The Multisig Committee is tasked with setting the Reverse Resolution record for each smart contract address where technically possible. This ensures that when a wallet or Etherscan queries the address, it returns the human-readable name.
  • UI/UX Integration:
    • The SSV dApps will display the ENS name prominently alongside the address.
    • All official documentation and social channels will reference the ENS names as the definitive addresses.
  • Security and Renewal Monitoring Policy: The foundation is to establish an SOP and manage ownership via the foundation’s multi-sig, ensuring names cannot be hijacked or pointed to malicious addresses and are renewed at a fixed interval.
2 Likes

Great idea, makes contracts easier to verify and much harder to fake.

1 Like

I might suggest using ssvtoken.ssvnetwork.eth and cssvtoken.ssvnetwork.eth.

That seems like a more long-term compatible way of naming them, allowing for future tokens if necessary.

1 Like

Thank you @GBeast for your feedback. This has been raised by others, and we propose the following updates:

Contract Address ENS Name
SSV Token 0x9D65fF81a3c488d585bBfb0Bfe3c7707c7917f54 ssv.ssvnetwork.eth
cSSV Token 0xe018D31F120A637828F46aFD6c64EC099d960546 cssv.ssvnetwork.eth

Note that the contract address for cSSV was also added in the proposal above.

Thank you!
—Ben

2 Likes

Voting is now live :vertical_traffic_light:
https://snapshot.org/#/s:mainnet.ssvnetwork.eth/proposal/0xc6dda95fd5cc77d84c881228c533c8c9c49b98cfb91fa96497efef9b9eb6f849

@fod
@spookyg
@derfredy
@h.m.23-0neinfra
@hackworth
@markoinether
@flo
@monitorssv
@yuting
@thomasblock
@llifezou
@sigmaprime
@damon
@lemmagov
@hashkeygov
@ethernodes
@chainupgov
@kenway
@allnodes
@dsrvgov

1 Like

Fully support this! Adding ENS is definitely an industry best practice for both security and user experience.

1 Like