Could someone briefly explain how the uni names work?

the technical docs are over my head. from what i can see theres no subnames under uni.eth so these seem to be a completely different kind of mechanism than the subs i’m familiar with

can these uni subs also host records, to change resolution address or add other chain addresses? are they unruggable like a wrapped + burned fuses sub is?

thanks

Similar to *.cb.id subnames, they are so-called “offchain” names. They are not registered on the actual Ethereum blockchain. Instead, an ENS resolver allows clients to fetch data from some web2 centralized server. That is what’s happening here. The subnames and all records in this case, are stored in a company’s private database usually. They are not unruggable, as they are not NFTs, and not onchain at all.

Such subnames can still support all record types, but it’s up to the company hosting them to provide access to update those records. For example if you claim a cb.id name in Coinbase Wallet, then I believe you can change a few things in your profile that will reflect in the ENS name records.

3 Likes

So this only works if the service, platform or provider supports their off-chain resolver?
Maybe I should dig into EIP-3668 & ENSIP-10 a little more. The way I am and have comprehended the way this works; while as If I remember correctly, I do not remember signing a message when ‘registering’ (or assigning in this particular mechanism) my subname.uni.eth. With being off chain in an unknown database, essentially these addresses are not secure and could easily be changed to route funds to a different address in the event of a security breach of this said daabase?

In more realistic terms: Uniswap is using the EIP-3668 CCIP READ & ENSIP-10 WILDCARD RESOLUTION to skip registration fees, and use this for no benefit of the DAO. So if platforms or provider are not required to support this; where is the data being communicated to the off-chain provider?

i.e; the (URI?) exists somewhere in the their front-end which points to the off-chain resource. If that were to be compromised then the off-chain resolver becomes at risk of redirecting to a malicious provider that would in theory return one address for all subnames?

Well in this case the library becomes the resolver in lieu of an on-chain immutable mechanism, right?

No, the service/platform/provider does not have to support any specific resolver. It only needs to be using a client library that supports CCIP Read and ENSIP-10 (and all the major ones do to my knowledge, like ethers, viem, ensjs, web3.py, etc).

So a frontend developer does not need to do anything special, everything will work seamlessly out-of-the-box with any of those common libraries.

The return data cannot be spoofed by a mitm, as it gets verified onchain in a subsequent call, that is part of the CCIP Read spec.

Who is the authority of assigning a sub-name with a wallet address?
Does this have anything to do with why Uniswap chose to only support creating the subnames via mobile device, which is more difficult for people to look at source code rather than the desktop browser experience?

Ok so the libraries you mentioned support CCIP but where is the infrastructure ? Where does the library differentiate what resource to read from?

If you own a name, you can create any subname you want and point it to wherever you want. That goes for .eth names as well as imported DNS names, whether they are onchain or offchain.

1 Like

I think the author wanted it “briefly” :upside_down_face:

I just registered a *.uni.eth and the process is very easy. :+1:

1 Like