[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.