One other reflection from our experience over the past year relates to how new teams enter the ENS ecosystem.
Web3 Labs first appeared in the ENS ecosystem around the end of March last year, just as SPP2 was kicking off. At that point we were effectively an unknown quantity, so the likelihood of being selected as a service provider straight away was understandably quite low.
At the same time, we didn’t yet know whether there would be viable paths for new teams to receive support while proving themselves by building directly for ENS.
We decided to start building anyway. We had some funds saved from previous work that allowed us to support development for a period of time, even though it wasn’t enough to sustain us for long, we felt our mission was important enough to keep pushing forward.
We’ve been fortunate that the ENS ecosystem supported this effort through two mechanisms:
- a grant from the ENS Ecosystem group supporting our early contributions
- the Contract Naming Season initiative pioneered by James, which allowed us to continue pushing the work forward
Contract Naming Season in particular has already produced some encouraging outcomes for the ecosystem (many are highlighted here). A number of protocols and people have begun naming their smart contracts, developers across the ecosystem are actively using the tooling to name contracts themselves, and the first ENS token disbursements to participants have happened.
Beyond the immediate activity, these disbursements help keep ENS visible as core infrastructure for Ethereum, while also introducing more developers and teams to the role ENS can play in managing onchain identity.
One of the most interesting learnings from this work has been the connection between smart contract identity and security practices.
Some of the teams we’ve spoken with described contract naming not just as a usability improvement, but as a component of their security practices.
When teams are managing large collections of contracts across different environments, clear identity and metadata become important for avoiding operational mistakes, reducing the risk of interacting with incorrect contracts, and helping developers and users reason about contract deployments.
In that sense, ENS has a significant opportunity to serve not just as a naming system, but as identity infrastructure for smart contracts and onchain systems more broadly. Especially when you start thinking of ENS-based identity being used in a hierarchical context.
Without the ecosystem support it would have been very difficult for us to continue building, and we’re grateful the ecosystem and DAO took a chance on the work.
Our experience does raise a broader question that may be relevant as ENS looks toward 2026: how do we create clearer pathways for new teams to enter the ecosystem and demonstrate value, while also ensuring that teams receiving ongoing support continue delivering meaningful contributions to ENS?
There are many excellent teams currently working as service providers, and the work they are doing is clearly valuable to the ecosystem. At the same time, it may be worth exploring slightly more structured ways for new teams to prove themselves and begin contributing to ENS.
The Contract Naming Season experiment has been an interesting example of what that kind of pathway might look like in practice.