Jsonrpc #51

makoto · 2025-10-06T13:56:43Z

ENSIP-16: Metadata Event Discovery

This PR significantly refactors ENSIP-16 to focus on event discovery and metadata standardization for offchain ENS names, shifting away from the previous GraphQL-centric approach to a more flexible JSON-RPC based system.

Replaced single graphqlUrl return value with rpcURLs, chainId, and baseRegistry
Supports both EVM-compatible chains and non-EVM sources (chainId = 0)
Change Grqphql schema API from compulsory to recommendation.

cloudflare-workers-and-pages · 2025-10-07T07:20:33Z

Deploying ensips with Cloudflare Pages

Latest commit:	`bd8f929`
Status:	✅ Deploy successful!
Preview URL:	https://d218331f.ensips.pages.dev
Branch Preview URL:	https://jsonrpc.ensips.pages.dev

View logs

ensips/16.md

Arachnid · 2025-10-06T14:56:00Z

ensips/16.md

 ## Abstract

-This ENSIP specifies APIs for querying metadata directly on the resolver for EIP-3668 (CCIP Read: Secure offchain data retrieval) enabled names. EIP-3668 will power many of the domains in the future, however since the retrieval mechanism uses wildcard + offchain resolver, there is no standardised way to retrieve important metadata information such as the owner (who can change the records), or which L2/offchain database the records are stored on.
+This ENSIP specifies APIs for querying metadata directly on the resolver for EIP-3668 (CCIP Read: Secure offchain data retrieval) enabled names. EIP-3668 will power many domains in the future, however since the retrieval mechanism uses wildcard + offchain resolver, there is no standardised way to retrieve important metadata information such as which L2/offchain database the records are stored on and where JSON RPC endpoint is to find event log information.


This will need a rewrite, but we can wait for feedback first.

One question about the practicality of creating synthetic events is that (non EVM chain/dbms) has to create not just events but also synthetic smart contract address and blocknumber so that filtering paramater also works

ensips/16.md

Arachnid · 2025-10-06T14:57:57Z

ensips/16.md

    event MetadataChanged(
-        string name,
-        string graphqlUrl,
+        bytes name,              // DNS-encoded name


We should specify that all names that are suffixed with this name are considered to be covered by this event.

We'll also need a way for an event to signify removing this association, such as emitting it with default arguments.

We should specify that all names that are suffixed with this name are considered to be covered by this event I remember we had conversation about this but didn't fully understand. Can you elaborate?

ensips/16.md

Arachnid · 2025-10-06T15:02:55Z

ensips/16.md

+  uint256[] values
+);
+
+// Standard ERC721 transfer event for name ownership changes


I don't believe we're using 721 anywhere in v2.

Please see my comment below.

Arachnid · 2025-10-06T15:03:42Z

ensips/16.md

-  resolver: Resolver!
-  expiryDate: BigInt
-}
+NOTE: Even though ENS v2 registry contract is ERC1155 (TransferSingle, TransferBatch), ERC721 events(Transfer) are also accepted if name owner choose to build their own registry with an NFT capability.


I don't think we can support it that simply; registries have to implement 1155 IIRC.

In V1, we support wrapped name (1155) and non wrapped (721) and so is many NFT market places, so don't see why not.

This is to allow compatibility with other contracts like Durin which uses 721. Even though we could enforce 1155, there isn't technical issue supporting both

Arachnid · 2025-10-06T15:29:27Z

ensips/16.md

 ```

-## Backwards Compatibility
+NOTE: In ENS v1, a resolver has a node property which is derived by the hash of subname and node of its parent name using namehash algorithm. In ENS v2 system, a resolver is used by a single registry which may have multiple parent registries. For example, a registry has a label called `foo` that has parent registry of `eth` and `xyz`, providing name for both `foo.eth` and `foo.xyz`. For a resolver to represent records for multiple names, the node of the v2 resolver is kept as 0x indicating that the node needs to be derived by combining the label information of the registry traversing from the subname all the way to the base/root registry. If a name owner choose to use their own contract with single registry and resolver, the node can be the namehash of the name as in v1.


I don't think this is true?

Do you mean for If a name owner choose to use their own contract with single registry and resolver, the node can be the namehash of the name as in v1? This is the case to support compatibility with simpler registry/resolver like Durin

ensips/16.md

Co-authored-by: Nick Johnson <[email protected]>

…sonrpc

lightwalker-eth · 2025-10-12T21:33:26Z

ensips/16.md

+        bytes name,              // DNS-encoded name
+        string[] rpcURLs,        // JSON RPC endpoint
+        uint256 chainId,         // Chain identifier (optional)
+        address baseRegistry     // Base registry address


Can we please document exactly what interface(s) baseRegistry is expected to implement?

gskril

This feels simpler than the GraphQL version! I'm missing how it's intended to be used though. Seems like indexers such as ENSNode are intended to get events from their own RPC URLs for any chain which makes sense, but how do they then expose that to apps?

In other words: I'm building an app the wants to load all available records for a given name. I get the resolver of a name, then check if that contract has a metadata() method. If it does, I get the RPC URL. What request do I make to it in order to get the list of available records?

I think what I described above is actually the most common case - more so than being interested in the full history of a name. And if that's true, having to encode and decode data in an eth_getLogs format seems overkill to me. Not to mention, it assumes that offchain subname providers keep a log of every database operation and can trivially expose that data in a new endpoint.

Perhaps a simple REST API standard that returns the current state of a name is sufficient? Like CCIP Read, a metadata URL could accept requests via https://api.example.com/lookup/{name} and return:

{
  "name": "ens.eth",
  "texts": {
    "description": "hi"
  },
  "coins": {
    "60": "0x0000000000000000000000000000000000000000"
  },
  "contenthash": "0x",
  "resolver": "0x0000000000000000000000000000000000000000"
}

Or if we don't want to include values for concerns around freshness:

{
  "name": "ens.eth",
  "texts": ["description"],
  "contenthash": true,
  "coins": [60]
}

New items could be added for additional metadata like expires, owner, etc.

I could be misunderstanding the eth_getLogs mention, but I think it's worth clarifying this type of thing in the spec.

gskril · 2025-10-28T21:37:04Z

ensips/16.md

-}
+```solidity
+// Emitted when a new subname is registered
+event NameRegistered(uint256 indexed tokenId, string label, uint64 expiration, address registeredBy);


For subnames that don't expire, is it safe to assume that expiration should be type(uint256).max?

yes. I will mention that at comment

ensips/16.md

ensdomains/ensips#51

makoto · 2025-10-29T06:28:48Z

@gskril this PR is the version to provide consistent way to discover event input for indexers. Unlike my previous PR #41 which aim to provide consistent way to discover api for apps, apps is expected to query via their preferred indexing service or index on your own. We are currently waiting from namehash team about the expected api for apps

gskril · 2025-10-30T06:51:53Z

Hmm since most RPC providers don't return all logs in a single request, how do we expect apps to use this directly to do something like get a list of all text record keys set for a name?

I thought one design goal was for apps to be able to use ENSIP-16 directly without relying on a larger indexer, but could be misunderstanding.

makoto · 2025-10-30T06:58:52Z

I thought one design goal was for apps to be able to use ENSIP-16 directly without relying on a larger indexer, but could be misunderstanding. again, that was the intention of the previous PR #41 but we proposed this version as namehash opposed to the previous version that had the API defined within the ENSIP. This PR is blocked until they come up with PoC indexing with API draft. To avoid the confusion, I will close this PR

makoto added 9 commits October 6, 2025 14:36

Apply ENSIP 16 changes from PR 41

5d06956

Replace graphql with rpcURLs

5e1ef21

Add events information

d54df98

Add more context

2731e0f

Fixed typo

bd867f1

Add requirements, event schema standardization, and key terminology

a7eec7e

Add requirements

0c4331a

Add requirements

d2a1244

Add recommendation for GraphQL API recommendation

b138bf7

makoto requested review from Arachnid, LeonmanRolls, TateB and gskril October 6, 2025 13:56

makoto added 2 commits October 7, 2025 11:19

Change format

ab7da6c

Remove graphql api

1c7bd78

Arachnid requested changes Oct 7, 2025

View reviewed changes

makoto and others added 7 commits October 7, 2025 11:36

Apply suggestions from code review

1e6dc35

Co-authored-by: Nick Johnson <[email protected]>

Change from three to two

cd061dc

Change from SHOULD to MUST

91ad1bf

Merge branch 'jsonrpc' of https://github.com/ensdomains/ensips into j…

078a7a9

…sonrpc

Remove link to namechain and v2 design doc

cf19b3b

Add TokenRegenerated event

eeaacf9

Remove expiry from SubregistryUpdate

afb6fe2

lightwalker-eth reviewed Oct 12, 2025

View reviewed changes

Rename NewSubname to NameRegistered

c528256

gskril reviewed Oct 28, 2025

View reviewed changes

gskril added a commit to namestonehq/durin that referenced this pull request Oct 29, 2025

Implement ENSIP-16 updates

64e8e99

ensdomains/ensips#51

Add comment about no expiration

bd8f929

adraffy mentioned this pull request Oct 29, 2025

Add IMetadataResolver for ENSIP-16 ensdomains/ens-contracts#500

Draft

makoto closed this Oct 30, 2025

makoto mentioned this pull request Nov 3, 2025

Minimum changes #57

Merged

Jsonrpc #51

Jsonrpc #51

Uh oh!

Conversation

makoto commented Oct 6, 2025

ENSIP-16: Metadata Event Discovery

Uh oh!

cloudflare-workers-and-pages bot commented Oct 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying ensips with Cloudflare Pages

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gskril left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

makoto commented Oct 29, 2025

Uh oh!

gskril commented Oct 30, 2025

Uh oh!

makoto commented Oct 30, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

cloudflare-workers-and-pages bot commented Oct 7, 2025 •

edited

Loading

gskril left a comment •

edited

Loading