spike/root-wildcard-resolver #2

Closed

peersky wants to merge 0 commits from spike/root-wildcard-resolver into main

pull from: spike/root-wildcard-resolver

merge into: peersky:main

peersky:main

Conversation 0 Commits - Files changed -

peersky commented 2026-09-12 12:46:03 +00:00

Owner

Copy link

No description provided.

peersky added 5 commits 2026-09-12 12:46:03 +00:00

feat(contracts): a spike of one wildcard resolver at the root, reading the whole tree from Multipass ... 9baabf732d

- Added Function `RootAttestationResolver`: one ENSIP-10 resolver for every name under the root, mapping the name's path to a Multipass domain (root, subject, vouch, platform, masked) and answering nothing where Multipass has no domain
- Added Interface `docs/root-wildcard-resolver.md`: why the per-mount registries exist, what the spike proves and lacks, a reversible level-by-level migration on Sepolia, and the upgrade path for factory, bridge and API
- Added Function ten forge tests: each path, expiry, humanity hops, reverse, the masked branch, and unknown paths never falling back to the root name

test(contracts): the root resolver forwards text records, oracle data and aliases, and roles stay the inner resolver's ... 7d234ddb04

- Added Function six forge tests: a user's text records at every depth, the role check on the stock resolver, oracle data keys, a propagated inner revert, an alias applied before locating, and a subject's own records on the mount's name

feat(contracts): the root resolver carries answer namespaces and operator texts, and the migration has a script ... 0f4f9af0a6

- Added Function on `RootAttestationResolver`: `<slug>.<question>.<root>` reads from the `<question>:<slug>` domain, and `setAbout(domain, label, key, value)` keeps an operator's text for a label nobody holds, never over a record's own answer
- Added Function `script/MigrateRoot.s.sol`: deploy, point, unmount, remount, unpoint — one owner transaction per step, each with its rollback — with a forge test walking every step against the local stack
- Added Ability for `DeployLocal.s.sol` to run in `ROOT_MODE=1`, deploying the root resolver and pointing the root label at it, and writing `rootResolver` into the deployment file the API reads as `ROOT_RESOLVER`
- Added Interface: the Sepolia runbook in `docs/root-wildcard-resolver.md` and a section in `docs/architecture.md`

feat(api): root resolver mode reads the tree from Multipass and provisions a domain with one call ... 55719696f5

- Added Ability `ROOT_RESOLVER` (env, or `wildcardResolver` in the deployment file): every mount — root, subject, vouch, platform open and masked, answer — is derived from Multipass domains and the name rule
- Improved Function of provisioning in that mode: a vouch domain, an answer domain or a DNS namespace is `initializeDomain` + `activateDomain` and nothing else; no factory, no registry, no `setSubregistry`
- Added Function five unit tests on the derivation and the provisioning, `rootResolver` on `/healthz`, and `E2E_ROOT_MODE=1` on the docker stack, which passes the API suite 35/35 that way

fix(contracts): the bridge grants a new name its text records through the root resolver, without a factory ... 07e0847085

- Added Function `RootAttestationResolver.parentNameOf(domain)`, the inverse of `locate`, with the platform list mirroring `PLATFORM_DNS_NAMES` off chain so `www` and the at-sign level agree
- Added Function `AttestationBridge.setRootResolver`: where the factory does not know a domain, the bridge asks the root resolver where the name lives before granting the four profile keys; a nameless record grants nothing
- Added Function `STEP=bridge` in `MigrateRoot.s.sol`, `ROOT_MODE=1` wiring the bridge locally, and tests for the inverse rule, the grant in root mode and the migration step
- Fixed Bug where the deployment file's `rootResolver` key would have flipped the Sepolia API into root mode against the old root instance resolver; the new key is `wildcardResolver`

peersky added 1 commit 2026-09-12 12:48:45 +00:00

fix(contracts): STEP=bridge deploys a new bridge and reporter, since the deployed bridge cannot learn the root resolver ... ee4e1630e4

- Fixed Bug where the runbook asked the Sepolia bridge for `setRootResolver`, a function its bytecode does not have and cannot gain: the step now deploys a bridge with the same resolver roles, pointed at the root resolver
- Added Function a reporter in front of the new bridge when `CRE_FORWARDER` is set, so the CRE write path moves in the same step; the test predicts both addresses and checks the wiring

peersky closed this pull request 2026-09-13 04:09:19 +00:00

Some checks failed

Hide checks

ci / docker (pull_request) Successful in 2s

Details

ci / check (push) Has been cancelled

Details

ci / docker (push) Has been cancelled

Details

ci / e2e (push) Has been cancelled

Details

ci / check (pull_request) Successful in 8m40s

Details

ci / e2e (pull_request) Successful in 5m35s

Details

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

peersky/ETHGlobal_Online_2026!2

No description provided.