I have been working on ENS-based naming system for our user reserve contracts, enabling more human-readable and interoperable identifiers across the ecosystem.
By leveraging ENS + CCIP gateways, each user’s locker (reserve contract) can be resolved using a simple subdomain — for example:
alice.superfluid.eth→ resolves to Alice’s reserve contract address
Motivation
Currently, each participant in the protocol has an individual reserve contract where their allocated tokens are streamed to and the whole process of staking, withdrawing etc. will continue involing these contracts, but currently there isn’t a nice and easy way to get a users locker address unless you go through etherscan and look at locker factory contract.
ENS integration would:
- 
Give users a human readable identifier for their locker contract 
- 
Allow wallets, dApps, and explorers to more easily integrate and display locker balances 
- 
Provide an additional utility for staking — users who stake can claim an official subdomain 
Example flow:
- 
User stakes protocol tokens → becomes eligible to claim ENS subdomain 
- 
User connects wallet → dApp automatically detects their locker contract address 
- 
CCIP gateway resolves: 
 username.superfluid.eth → 0xUserReserveAddress
Open Questions for Discussion
Currently a subdomain has not been chosen to use for the locker resolving , so feel free to propose some, most likely we will shy away from using superfluid.eth due to needing to change the ENS resolver contract to an offchain resolver contract which would mess with the currently registered subdomains.
Should users be able to choose their subdomain, or should it be automatically derived from wallet ENS, handle, or address hash to prevent scalpers?
Should there be a fee for name registration?
Should subdomains expire if user stops staking?
Should we reserve ENS names for certain roles (team, ambassadors, DAO multisigs)?
What would you consider a fair eligibility threshold for being eligible to claim a name?
Should this ENS system receive SPR funding?
 Thanks for this.
 Thanks for this.