chore(ens): the workflow deploys the resolver only, a crate binding, named reverts - #22
Merged
Merged
Conversation
Two bare expectReverts asserted only that something failed: an outsider calling setUrls or setSigner, and a signature recovery refuses. Each now names its error and its argument, so a check that stopped firing would be noticed. The decode of a malformed gateway blob stays bare, and says why. Assisted-by: Claude Fable 5.1 Signed-off-by: xgreenx <xgreenx9999@gmail.com>
The stack component was the TODO the file was created with, kept beside the resolver as a step that exits 1. The contracts are deployed by chain-configurations (libid-deploy), so the component, its input and the paragraphs written around it go; what is left is the one thing the workflow does, and the KMS rationale names what that key really holds: the ENS name and the resolver, not a set of proxies. Assisted-by: Claude Fable 5.1 Signed-off-by: xgreenx <xgreenx9999@gmail.com>
The crate embeds the resolver's artifact so a consumer can deploy it without a checkout, but a consumer talking to it had no binding: the constructor tuple, the owner surface and the views were left to hand encoding, unlike every other covered contract. The anvil test deploys it from the embedded artifact with its constructor arguments and reads the configuration back. Assisted-by: Claude Fable 5.1 Signed-off-by: xgreenx <xgreenx9999@gmail.com>
IExtendedResolver justified being declared locally by analogy with IIdentityVerifier and INotary; neither exists on main any more. Assisted-by: Claude Fable 5.1 Signed-off-by: xgreenx <xgreenx9999@gmail.com>
ERC-7996 is the id the ENS universal resolver reads as leave to call a
resolver directly instead of through the batch gateway. On that route it
raises the OffchainLookup again under its own address, so the {sender} a
client fills into the gateway URL is the universal resolver, and a gateway
that signs for the URL's address signs for the wrong target. The NatSpec on
supportsInterface now records this, and a test pins the absence of the id.
Assisted-by: Claude Fable 5.1
Signed-off-by: xgreenx <xgreenx9999@gmail.com>
docs(ens): say why the resolver announces ENSIP-10 and nothing else
xgreenx
marked this pull request as ready for review
September 7, 2026 11:03
SupremaLex
approved these changes
Sep 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #15 (
feat/ens-resolver), after its merge withmain. Three follow-ups from reviewing #15 against whatmainadopted this week; the resolver contract itself is unchanged.stackcomponent was the TODO the file was created with, kept as a step that exits 1. The contracts are deployed by chain-configurations (libid-deploy), so the component, its input and the paragraphs around it are gone; the KMS rationale now names what that key really holds: the ENS name and the resolver.HandleResolver. The crate embedded the artifact "so a consumer can deploy it without a checkout" but offered no binding for the constructor tuple, the owner surface or the views, unlike every other covered contract. The anvil test deploys it from the embedded artifact with its constructor arguments and reads the configuration back.OwnableUnauthorizedAccount(account)andECDSAInvalidSignature()now. The malformed-blob decode stays bare and says why.Verification:
forge test424 passed (26 suites);cargo test --all9 passed with anvil (the new resolver deploy included); TS codegen, build, tests and lint clean; workflow YAML parses.Conventions check on #15 itself, for the record: nothing generated is committed;
HandleResolveris wired into the vendor list,COVEREDand the codegen list and nowhere by hand; every commit is signed off with anAssisted-bytrailer; not upgradeable by a documented choice (a resolver is replaced bysetResolveron the name).