In Q4 2025, Unruggable was engaged across two main focus areas: Ethereum Interoperability and AI. We led the push to finalize ERC-7930 and ERC-7828, shipped the on.eth chain resolver, and authored four new standards for AI agent identity.
Move the stuck standards. Ship the registry.
on.eth — the chain resolver shipped this quarter.
In collaboration with Wonderland and the Ethereum Foundation, we worked to rewrite and polish the specification for ERC-7930: Interoperable Addresses, and ERC-7828: Interoperable Names.
Both specifications had stagnated. Over the years many established and respected ecosystem participants had contributed — it was widely accepted that they were promising standards with significant potential, but no individual team had taken ownership of the process of moving them forward.
We committed significant time to engaging with the Interop community, providing ENS-specific technical insight, writing and iterating on rewrites of both specifications, building proofs of concept, and transparently communicating with industry participants. We also architected and implemented the smart contracts to facilitate productionizing these specifications.
github.com/ethereum/ERCs/pull/1407/changes →
These specifications have the potential to be the core mechanism through which blockchain metadata is discerned, providing improved user experience and facilitating interoperability. There is no other piece of work across the ENS ecosystem that has the potential to put ENS front and center in all on-chain interactions.
github.com/ethereum/ERCs/pull/1447 →
One of the core issues we identified when working on these specifications was that ENS previously did not have a standardized mechanism for surfacing binary data. The on.eth chain registry surfaces the ERC-7930 Interoperable Address as a first-class citizen.
We worked to standardize the mechanism through which binary data is exposed — a new resolver profile defined in ENSIP-24. Arguably, this is the low-level mechanism through which all ENS data should be accessed moving forward; we look forward to seeing it implemented as part of ENSv2.
Within this standard we also proposed an optional discoverability mechanism. Significant value is lost if data is stored but not discoverable. The same mechanism has been informally adopted for discovering ENSIP-5 text records too.
The specification is powerful enough to allow storage of any piece of data — arbitrary hashes, encoded images, sound files, signed data. There are promising use cases for AI, and powerful opportunities for encoding Unruggable Gateway requests that allow efficient transmission, storage, and execution of complicated multi-chain data retrieval requests.
discuss.ens.domains/t/ensip-24-arbitrary-data-resolution/21535 →
Q4 2025 was a very busy period for the development of the on.eth chain registry. The standards were still in flux, including the proposed ENSIP-24, but we were actively developing the chain registry / resolver in parallel. Four chains live; ready to expand the moment the standard lands.
optimism.on.eth — OP Mainnet registered via the chain resolver.
Soon, most ENS names will identify AI agents. We’re building that stack.
ERC-8004 — ENS as a core identity primitive for AI agents.
There is significant time and energy going into research pertaining to AI. We have been proactive in researching mechanisms through which ENS can be used as an identity primitive for AI agents.
We contributed extensively to ERC-8004: Trustless Agents, a project spearheaded by the Ethereum Foundation and MetaMask with participation from Coinbase and Google. Our specific contributions include the on-chain metadata section and the ENS integration outlined within the standard.
ERC-8004 was extensively marketed and reached a wide audience. Its intention is to provide on-chain identity for AI agents, and as a result of our contributions ENS was included as a core component.
github.com/ethereum/ERCs/commit/cb7ae28320f7ef6f8794a17b031e874689757943 →
A way to group agents into verifiable agent organizations or collections. The specification was well received when presented at Devconnect Argentina in November 2025.
With thanks to Akindo — a Founder Success Platform running buildathons that help startups grow alongside their partner ecosystems — for the opportunity to share about AI agent identity and ENS.
eips.ethereum.org/EIPS/eip-8041 →
Presenting ERC-8041 — Devconnect Argentina, Nov 2025.
A way to standardize metadata for all token IDs of NFT tokens, including ERC-721, ERC-1155, and ERC-6909.
github.com/ethereum/ERCs/pull/1259 →
A companion specification standardizing metadata at the contract level, alongside ERC-8048.
github.com/ethereum/ERCs/pull/1260 →
Prem co-hosts the ENS×AI group he founded with Cap.eth from Namespace. Weekly calls. Public calendar.
ENS×AI working group — weekly calls, 10+ teams building.
Products presenting (building on ENS): ID Chain, ID Agents, JAW.id, Beaver AI, Namera AI, Agentic Trust, ENSemble, and ENS Node Metadata. The ERC-8004 team also presented updates, and ENSIP-25 and ENSIP-26 are in active discussion.
Dublin, then Miami. Listening to where ENS lands in the wider domain industry.
ICANN84 — Lightning talks on alternative naming & UDRP precedent for blockchain identifiers.
In October we attended the ICANN conference in Dublin. We sought out and participated in technical working groups with a specific focus on discerning areas where ENS might be a subject of conversation. We engaged with stakeholders across the AICANN ecosystem and provided technical insight where there were knowledge gaps.
It was insightful to discern exactly what the pain points are for wider acceptance of ENS as an alternate namespace. There are many, and continued collaboration to bridge the organizational gap is vital if ENS expects to reach widespread adoption.
We also connected with operators of alternate namespaces to have constructive conversations about how they approach common pain points such as name collisions and brand protection.
Following on from ICANN, we attended Namescon in Miami — a domain name industry conference focused on infrastructure (registries, registrars, aftermarkets) and domain names as an investment.
We engaged with corporate brand protection companies and domain name registries and registrars to understand their positioning in relation to ENS. We continue to work with these companies to help them build on top of ENS in a way that makes ENS attractive to their client bases.
We continued to contribute to discussion around ENSIP processes and protocol development.
A specification which enables contracts to declare their reverse ENS name during deployment.
Current reverse name registration requires the contract owner (when there is one) to perform a separate transaction to set the reverse name after deployment. This continues to be a barrier to adoption for contract naming initiatives, and we think it is an important area of research for putting ENS names in front of all users interfacing with blockchains.
discuss.ens.domains/t/contract-naming/21901/8 →
None of this work happens without the ENS DAO and the delegates who continue to back it. We’re grateful for the trust, the funding, and the steady stream of feedback that keeps us pointed at the right problems.
