Conversation
Deploying ensips with
|
| Latest commit: |
f4ed924
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://e6650744.ensips.pages.dev |
| Branch Preview URL: | https://edits-evm-chain-reverse-reso.ensips.pages.dev |
ensips/19.md
Outdated
| * Reverse registrars will be setup on each EVM-chain, with a corresponding registry | ||
| * Reverse registrar will only allow setting the name and text record without resolver customisability. | ||
| - Reverse Registrars will be setup on each EVM-chain, with combined registry/registrar/resolver functionality. | ||
| - Registrars will only allow setting the name, without resolver customisability. |
There was a problem hiding this comment.
| - Registrars will only allow setting the name, without resolver customisability. | |
| - Reverse resolvers will only allow setting the name, without resolver customisability. |
There was a problem hiding this comment.
did you mean it should be "Reverse registrars" rather than "Registrars"? otherwise the change makes the terminology inconsistent
There was a problem hiding this comment.
Fair enough. In that case it should make it clear that reverse registrars set their own custom resolver, which only allows the name to be set.
There was a problem hiding this comment.
i might need to reword some of this. "Reverse registrar" = L2 contract that maintains the registrar capability, "Reverse resolver" = L1 contract that resolves to the L2 registrar values.
adraffy
left a comment
adraffy
left a comment
There was a problem hiding this comment.
funny, I just talked to Nick about this ENSIP. I think your changes to the steps are good (rather than using the UR's perspective.)
| - For a valid resolution, the user must also set the appropriate `addr()` record on their ENS name | ||
| - This completes the two-way verification between address and name |
There was a problem hiding this comment.
I am interested in something resembling this draft acting as a fallback for the ENSIP-11 close-loop addr check. Not sure if it should be enshrined here against the ENSIP-19 spec or just added as additional functionality for ENSIP-11.
|
|
||
| ### Resolving an avatar by a dapp on another EVM chain | ||
| 1. Let `chainId` be the chain ID of the client. | ||
| 2. If `chainId` is an L1 chain ID (including Ethereum testnets), set `reverseName = "[address].addr.reverse"` and `coinType = 60` and go to step 5. |
There was a problem hiding this comment.
Maybe: If default (chainId = 0), set reverseName = "[address].default.reverse" and coinType = 0x80000000 and go to step 5.
| 9. Set `node = namehash(name)` | ||
| 10. Fetch the forward-resolved address from the resolver: | ||
| - If `coinType == 60`, with: `resolvedAddress = ensip10.resolve(reverseName, encodeCall('addr', [node]))` | ||
| - Otherwise, with: `resolvedAddress = ensip10.resolve(reverseName, encodeCall('addr', [node, coinType]))` |
There was a problem hiding this comment.
This and the prior line, reverseName should be name
There was a problem hiding this comment.
I've discussed this a bit with Tate before, but should we include the forward fallback logic? or add another ENSIP after this? (I prefer including it.)
If resolvedAddress is null and chainFromCoinType(coinType) > 0, then resolvedAddress = ensip10.resolve(reverseName, encodeCall('addr', [node, 0x80000000])).
Note: chainFromCoinType() > 0 ⟺ "non-default EVM coin type"
Note: this can be accomplished with a multicall.
5 participants
No description provided.