Decentralized DNS Monday — September 28 2026 Weekly Update

Weekly companion to Overview - Decentralized DNS, ENS, PKARR, GNS, Handshake, Namecoin, and related files. Covers Sep 22–28. Key themes: the Pubky ecosystem completes a 14-day release sweep with three more tags — pubky-homeserver v0.13.0 (Sep 23 13:58, 9 days after v0.12.0) ships the first Basic WebDAV locks (#630) for the homeserver storage layer, an SDK oversized-payload guard (#624), SDK error-response limits (#608), version-on-startup logging (#636), and dual-arch Docker PR builds (#605); pubky-app v1.11.0 (Sep 23 14:33, 5 days after v1.10.0) ships Pubky Passport Google sign-in/sign-up (landing + sign-in + onboarding Join) and a major PWA upgrade (install banner, iOS install instructions, offline navigation fallback + connection-status toasts, app shortcuts, unread icon badges, native share sheet, update prompt); pkarr v8.0.2 (Sep 23) ties the lockfile bump to homeserver v0.13.0; ICANN confirms exactly 1,616 gTLD applications proceeding in the 2026 Round (Sep 22 announcement) with Reveal Day to be confirmed "early next week" (the ICANNWiki upper bound is Oct 14, the 9-week-prior-window cut-off — expect news this week); Airstop soft fork on Handshake is the live, irreversible, never-reversible, has-already-happened economic reality — locked at block 290304 (Aug 14 2025) and activated at block 292320 (Aug 28 2025) with 99.80% signaling ratio, permanently removing ~890M HNS from supply (216,199 airdrop allocations × ~4,247 HNS each, 209,650 of which were unclaimed, 6,549 of which were claimed) — this is the supply-side confirmation that Handshake hsd v8.0.0 (Jul 1) locked into the network 14 months ago; ENS Labs × Immunefi audit competition results FROZEN today Sep 28 (post-resolution phase complete) — 48-hour dispute window opens Sep 29, payment + publication Oct 26; ENSIP-28 Name Owned Accounts continues to gather feedback (12 posts through Sep 2); ENSIP-31 Payment Preferences feedback thread picked up one substantive reply (jkm.eth Sep 21); Nomentum Labs Grails SPP3 Marketplace RFP award voting open ($500K executable to stream.mg.wg.ens.eth, three-tranche payment structure); Endowment permissions to KPK Update revised-execution moving toward schedule (Sep 14 revised execution path: swap to a new Roles module; new Modifier ownership already transferred to Endowment Safe); ENS Foundation "Evolved Foundation" blog post dated late September frames the institutional counterparty story for ICANN/IETF/W3C and the .ens gTLD recognition campaign; ensforge SDK adds HCA support (Hot Configurable Authentication/Agent capability — scoped, time-limited grants for ENSv2 names) plus Pimlico/Rhinestone gas sponsorship — Namespace ships the first ENSv2 SDK with built-in agent identity flows; root KSK rollover T-13 days to Oct 11 hard cutover; old-key retirement Jan 2027; DNS-AID draft-02 still current, expires Nov 28 2026; Reveal Day announcement window is this week (Sep 22–28 + early next week); GNUnet/GNS and Namecoin remain on their Aug 20/Jun 28 plateaus; hsd dormant Aug 22 2025 >1y stale; hns-rs v0.4.1 (Sep 1) still latest; pubky-core v0.9.3 (Jun 24) still latest.

TL;DR — This Week

• pubky-homeserver v0.13.0 (Sep 23 13:58) — 9 days after v0.12.0 — is the biggest missed signal of the W39 update. It is not a chore-only release. Highlights: #630 Basic WebDAV locks for the homeserver storage layer (first-class concurrency-safe file operations via WebDAV LOCK/UNLOCK semantics — this unlocks any client that uses WebDAV for file management, including desktop sync apps and collaborative editors); #624 SDK oversized-payload guard (closes the DoS surface where a malicious client could push unbounded response bodies); #608 SDK error response limits; #636 log version on startup (operational debugging hygiene); #605 run PR builds on native amd64 + arm64; #638 update pkarr + pkarr-relay lockfile versions (coord with pkarr v8.0.2). Dependabot bumps: opendal, sea-query, argon2, infer, axum-extra, axum-test, flume, fast-glob, wasm-streams, httpmock, ci-workflows. The PKARR-relay coord is the most consequential for this library: pkarr-relay is now at v2.0.2. See §1.
• pubky-app v1.11.0 (Sep 23 14:33) — 5 days after v1.10.0 — is the second-biggest missed signal of the W39 update. Headline features: #2587 Pubky Passport Google sign-in + sign-up on landing page + sign-in page + onboarding Join step (availability is controlled by PUBKY_RUNTIME_PASSPORT_URL env — operators opt in per deployment; the on-ramp gap between self-sovereign key custody and a Google-shaped first-touch flow is now bridged); #2550 PWA improvements — install banner, iOS install instructions, offline navigation fallback, connection-status toasts, app shortcuts, unread icon badges, and an update prompt with a Reload action (the service worker precaches the app shell and leaves application data caching to the local database — the right scope, avoiding the PWA-data-loss foot-gun); #2550 native sharing (post + profile links open the native share sheet on touch devices); #2569 mention previews in OG cards (display names instead of npub); #2601 hashtags become tags in new posts/replies/quotes/articles (composer tag dedup + 5-tag limit preserved; titles + edits not scanned); #2619 video links (YouTube/Vimeo/direct video classified as video posts for Video filter; channel/playlist keep link classification); plus UI refresh (landing + onboarding + iPhone SE viewport fix). Upgrade note: first service-worker upgrade for existing installations may require fully closing + reopening the app. See §3.
• pkarr v8.0.2 (Sep 23 11:22) — chore-only release tied to the homeserver v0.13.0 pkarr-relay lockfile bump (PR #321, andrei-21). One commit (aa4011c); package versions pkarr 8.0.2 / pkarr-relay 2.0.2 / @synonymdev/pkarr 8.0.2. Trivial delta in isolation, important as a coordination marker for the homeserver pkarr-relay update. Star count 457 (up from 451 Sep 14). No v8.0.3-rc.0 tagged after. See §2.
• ICANN confirms 1,616 gTLD applications proceeding (Sep 22 announcement) — official number from icann.org/en/announcements/details/icann-confirms-number-of-applications-proceeding-in-the-2026-round-22-09-2026-en: submission window closed Aug 13 with 1,663 applications, 47 applicants failed to pay the per-application fee (the precondition to proceed). Reveal Day will publish the public-facing portions of the paid applications on the APS website (Application Publication + Statistics) with the contention-set listing. Reveal Day date expected to be announced "early next week" — that window is Sep 22–28 (today) → first days of W41. Upper bound Oct 14 per the 9-weeks-after-Aug-12 ICANNWiki rule. The same Sep 22 announcement notes ICANN90 AGM location announced Sep 24 and a separate IDN/Universal Acceptance report on Sep 22. See §4.
• ICANN TSG public comment on gTLD × Alternative Naming Systems closed Sep 21 (last week's open thread) — no further public TSG statement since, but the comment review and report-revision phase begins now with a summary report to follow. This is the highest-leverage signal in the W40 window for ENS, Handshake, Namecoin, and any alt-naming operator seeking recognition in the gTLD application process. See §5.
• ENS Labs × Immunefi audit competition results FROZEN today Sep 28 — per the post-close schedule published Aug 10 (Sep 14 close / Sep 20 ENS resolution / Sep 28 results frozen / Sep 29 48-hour dispute / Oct 26 payment + public publication). Today's freeze ends the internal-triage-only window. Vault TVL status (last public view Sep 21) was $69,981.17 — declined $8 from Sep 14 close, consistent with the competition being over. Public findings counter (306 reports / 20 confirmed / 56 under review as of Aug 31) is unchanged on the public view since Sep 14; actual triage is internal until Oct 26 publication. The ENS Labs post-competition narrative for ENSv2 mainnet-readiness will likely be tied to the Oct 26 disclosure. See §6.
• Airstop soft fork on Handshake is live and irreversible — confirmed via shakeshift.com/signaling/airstop signaling-period data: deployment start 2025-07-01, deployment timeout 2025-10-08, threshold 95%, version bit 2, locked-in block 290304 (2025-08-14 04:24:55), activated block 292320 (2025-08-28 04:53:41). Final 3rd-period signaling ratio 99.80% (2,012 signaling blocks vs 4 non-signaling), with ViaBTC 60%, ANTPOOL 24%, Mining-Dutch 10%, CyberPool 5%, DxPool 1% — every meaningful pool with 100% signaling at activation. 209,650 unclaimed airdrop allocations × 4,246.99 HNS each = 890,382,357.93 HNS permanently removed from supply. This confirms the Handshake economic reality: hsd v8.0.0 (Jul 1) was the cut-over, and the airstop fork has been live on mainnet for 13 months — but the supply effect is only now surfacing in supply statistics. See §7.
• Nomentum Labs Grails SPP3 Marketplace RFP — voting open ($500K executable, three-tranche payment structure: $90K upfront over 3 monthly installments + $100K performance-gated across four $25K gates with revenue + wallet + ETH secondary-volume thresholds + $310K streamed after ENSv2 readiness). Funds route through MetaGov Stream Management Pod (stream.mg.wg.ens.eth = 0xB162Bf7A7fD64eF32b787719335d06B2780e31D1). Blockful calldata verification repo (dao-proposals c9204ae) passes. Live proposal URL: ens.gov.blockful.io/proposals/19667497139373951686084433718987773325019389190188449031876262520356769920394. KYC pending. Performance baseline = Grails attributed revenue over the 90 days before signing. Term co-terminates with SPP3 cohort in Q3 2027. See §8.
• Endowment permissions to KPK Update #10 — revised execution — kpk's Sep 14 update moved from applying permission changes to the existing Zodiac Roles module to swapping the Endowment to a new Roles module (cleaner audit surface; ownership transfer of the new Modifier from test Safe to Endowment Safe 0x4F2083f5…FE64 completed this week — kpk "4 days ago" post; forum-thread timeline consistent with Sep 24). New Modifier address 0xa23BEBFD…FD59. owner() confirmed as the Endowment Safe before scheduling is the precondition Blockful requires. This is the routine endowment permission update + the precursor to the new Harvest role for Fluid/Morpho/Merkl reward claims, spender-pinned to specific protocol contracts, with payouts forced to the Endowment safe. See §9.
• ENS Foundation "Evolved Foundation" blog post (Sep 22 era, enslabs.eth author) — re-launches the institutional-facing narrative: represent ENS at ICANN/IETF/W3C, pursue recognition and stewardship of the .ens gTLD, engage on policy with regulators/lawmakers, hold and defend the ENS trademark + brand assets (action against phishing/impersonation), employ full-time staff under a tokenholder-appointed/removable board, serve as the protocol's institutional counterparty. Five-board composition: Nick Johnson (ENS Labs), Alexander Urbelis (ED), Kartik Talwar, Brett Sun, Anthony Leutenegger. Distinguishes Labs (product/engineering) from Foundation (institutional/legal). Foundation will operate as the legal entity that signs IETF/W3C participation agreements, hires staff, and enforces the trademark — exactly the gap that the DAO could not fill. This is the institutional layer for the .ens ICANN TSG conversation and the ICANN 2026 Round. See §10.
• ensforge SDK adds HCA support (Sep 15–22 namespace_eth + cap.eth X posts) — HCA = scoped, time-limited grants to delegate ENS name operations (set text, transfer subnames, renew, etc.) without signing every transaction. Uses Pimlico or Rhinestone for gas sponsorship. This is the first ENSv2 SDK with built-in agent identity flows (subname creation, record management, key rotation, all under a revocable grant). The complementary ensforge ↔ MetaMask Agent Wallet plugin v0.8.0 (Sep 15) closes the surface area: CLI + JS SDK + Sepolia ENSv2 + agent identity. See §11.
• ENSIP-28 Name Owned Accounts — still active (12 posts through Sep 2). Adds ERC-1271 + ERC-6551 support to the "accounts associated with a name" model (a Safe, a TBA, or any smart contract can be listed under a name with its own EIP-712 proof of consent, valid for max 2 years, with optional explicit accounts-chains chain-set listing). Premm.eth (author), workemon.eth, raffy.eth. PR ensdomains/ensips#84. The Sep 22 update added ENSIP-28 to docs.ens.domains/ensip/28/ as a published draft. See §12.
• ENSIP-31 Payment Preferences — feedback thread picked up one substantive reply (jkm.eth Sep 21 5:19pm, ENS Forum) pushing back on the multichain-token fingerprinting: "there is no such thing as a single token that exists across multiple blockchains"; USDC on Base ≠ USDC on Ethereum for receiving-side accounting because of per-chain liquidity and bridge costs; "Alice might say she prefers Base to Ethereum, but that doesn't explain the exchange rate between the two, and Alice might need 21 USDC if sent on Ethereum but only 20 USDC if sent on Base". Premm.eth (author) responded with three data points needed: assets accepted/requested, amount-per-asset, preference order. This is the strongest open technical thread on multichain payment routing in 2026. PR ensdomains/ensips#87. See §13.
• Root KSK rollover T-13 days to Oct 11, 2026 hard cutover (last week's T-20 → T-13). Old-key retirement Jan 2027. ICANN Board LA workshop (Sep 4–6) approved resolutions published Sep 8 (approved-resolutions-special-meeting-of-the-icann-board-06-09-2026-en). Reveal Day announcement expected "early next week" per Sep 22 ICANN release; upper bound Oct 14 per ICANNWiki. The simultaneous Oct 11 KSK + Oct 14 Reveal Day upper bound makes the second week of October 2026 the most institutionally-loaded week for the global DNS in years. See §14.
• DNS-AID draft-02 still the current (no new draft, expires Nov 28 2026 — last week's T-69 days → T-61 days). draft-mozleywilliams-dnsop-dnsaid-02 is the canonical reference; dns-aid-core reference implementation at v0.4.8+ supports SVCB/SVCB custom parameters + DNSSec. The Cloudflare Agent-Readiness checker from Aug 24 still enforces draft-01 expectations without acknowledging the breakage. Watch for any cut before Nov 28 expiry. Stale. See §15.
• GNUnet / GNS — no new release since 0.29.0 (Aug 20). No new release; experimental software. Namecoin — no Namecoin Core tag since nc31.1 (Bitcoin Core upstream sync continues; the Ghost-Town note from Nostr is consistent with the lack of tagged releases since May). hsd (handshake-org/hsd) — last commit 2025-08-22, no v9.x tag; only hns-rs is shipping in the Handshake ecosystem (and hns-rs is dormant since v0.4.1 Sep 1). See §16.

Deep dives

1. pubky-homeserver v0.13.0 (Sep 23) — WebDAV locks, SDK guards, version-on-startup, dual-arch Docker

Tag: v0.13.0 — Sep 23 13:58:18Z — commit e672ad4 — PR #640 (andrei-21) Published on crates.io as pubky-homeserver v0.13.0 with full Linux/Windows/macOS amd64+arm64 binary matrix (9.1 MB Linux, 9.2 MB macOS, 8.3 MB Windows). GitHub release: github.com/pubky/pubky-homeserver/releases/tag/v0.13.0

9 days after v0.12.0 (Sep 14). The W39 update (Sep 21) called the v0.12.0 release the end of a 26-day plateau and predicted further releases were coming — v0.13.0 is that next release, and it lands just 9 days after, not 26. The Pubky release cadence has accelerated, not decelerated.

Headline features:

Dependabot bumps (cluster by @ok300, @mdozhdev): opendal, sea-query, argon2, infer, axum-extra, axum-test, flume, fast-glob, wasm-streams, httpmock, ci-workflows.

Documentation: #631 (gcomte, "fix grant session persistence example") and #636 SDK session storage results clarification.

No public API breakage in this release — the breaking changes from v0.12.0 (DockerPostgres::shared() in PR #500 + Docker build target defaulting to homeserver in PR #594) remain the current contract.

For this library: the WebDAV locks feature (#630) is the most consequential because it lowers the integration barrier for any WebDAV-speaking client. The pkarr-relay lockfile bump (#638) signals that the Pubky/PKARR/Pubky-homeserver cluster is being treated as one deployment unit now.

2. pkarr v8.0.2 (Sep 23) — chore-only, ties to homeserver v0.13.0

Tag: v8.0.2 — Sep 23 11:22 — commit aa4011c — PR #321 (andrei-21) Repository: github.com/pubky/pkarr (★ 457, up from 451 Sep 14) Package versions: pkarr 8.0.2 / pkarr-relay 2.0.2 / @synonymdev/pkarr 8.0.2

Single commit, chore release. The only substantive change is the lockfile coordination with pubky-homeserver v0.13.0 (which bumped pkarr-relay to v2.0.2 the same day). No new API surface, no breaking changes.

Context: pkarr v8.0.1 (Aug 31) shipped 19 commits since v8.0.0 (Aug 6) including 5 dependabot-only commits (PRs #275/#279/#282/#283/#286), the refactor(dht)! decouple-public-API-from-mainline (PR #287), and the mainline v8 upgrade (PR #285). The Aug 31 v8.0.1 was the only "real" v8.x release. v8.0.2 is a marker, not a release.

For this library: pkarr is now treated as a stable dependency. The pkarr-relay updates (PR #268 return-stored-node-count + PR #267 split-DHT-service-and-index-rendering + PR #250 single-relay-client) are shipped and active in production. No new feature work scheduled.

3. pubky-app v1.11.0 (Sep 23) — Pubky Passport Google sign-in + PWA overhaul

Tag: v1.11.0 — Sep 23 14:33 — commit 51829ad — released by @infin1t3 GitHub release: github.com/pubky/pubky-app/releases/tag/v1.11.0

5 days after v1.10.0 (Sep 18). The fastest back-to-back major release in the pubky-app v1.x line.

Headline features:

Interface updates: #2566 (count new posts only after local details available — fixes double-count race), #2595 (circular avatar crop mask), #2604 (own-profile Tagged empty-state input compact), #2610 (logout page bottom inset for iPhone SE viewport), #2594 (remove Collections navigation New badge), #2587 (landing page layout + Passport onboarding copy), #2623 (desktop Explore selector onboarding E2E fix, backported in #2628).

Upgrade notes (from the release body): - "The first service-worker upgrade for existing installations may require fully closing and reopening the app. The new update prompt applies to subsequent deployments." - "Operators should verify real Google signup and signin against their intended Passport and Homegate deployment before enabling PUBKY_RUNTIME_PASSPORT_URL."

For this library: Pubky Passport is the highest-impact feature — the social-recovery + first-touch-flow pattern that has been a critical missing piece for non-crypto-native onboarding. The PWA overhaul is operationally important because it standardizes the install path (the previous "go to Chrome menu → install" friction was killing mobile adoption). The video link classifier rounds out the filter taxonomy.

4. ICANN confirms 1,616 gTLD applications proceeding in the 2026 Round (Sep 22)

Source: icann.org/en/announcements/details/icann-confirms-number-of-applications-proceeding-in-the-2026-round-22-09-2026-en — Sep 22, 2026

The Sep 22 release confirms exactly 1,616 paid applications (out of 1,663 submitted when the Aug 13 window closed — 47 applicants failed to pay the per-application fee). Reveal Day will publish the public-facing portions of the paid applications on the APS (Application Publication + Statistics) website with contention-set listings.

Reveal Day date will be announced "early next week" — that window is Sep 22–28 (this week) into the first days of W41. The ICANNWiki-formalized upper bound is Oct 14 (the 9-weeks-after-Aug-12 cutoff from the Applicant Guidebook). The Sep 22 announcement warns applicants and interested parties to remain wary of any information not from ICANN directly.

Related Sep 22–24 ICANN activity: - Sep 22: New ICANN Report on Global Progress on IDNs and Universal Acceptance. - Sep 24: ICANN90 Annual General Meeting location announced. - (Sep 4–6 LA workshop resolutions published Sep 8 — the KSK rollover commitment.)

For this library: the gTLD × alt-naming integration question (ENS, Handshake, Namecoin, Unstoppable, blockchain-native TLDs in general) sits inside the 2026 Round but the public list will only be visible on Reveal Day. The TSG on gTLD Integrations with Alternative Naming Systems has already closed its initial public comment (Sep 21), and the report revision + summary response is now in flight. The Reveal Day reveal will tell us whether any blockchain-anchored TLDs applied for the same string (.ens, .bit, .crypto, .x, .wallet, Handshake TLDs, etc.).

5. ICANN TSG on gTLD Integrations with Alternative Naming Systems — public comment closed Sep 21

The Technical Study Group public comment on the Initial Report closed Sep 21 (last week's open thread). Per the ICANN proceeding page:

"Following the close of this comment period, the TSG will review all comments received and revise the report as appropriate. A summary report responding to the comments received will be prepared and published. While the TSG continues its work, ICANN org will closely track its progress and deliberations to establish the contractual amendment language..."

The TSG was convened June 2026 by ICANN President/CEO Kurtis Lindqvist, coordinated by Andrew Sullivan, with members from SSAC, IETF, registry operators, and alt-naming system operators.

The report text itself (942.2 KB PDF) is the threshold-question response: can the same string be registered as both a global DNS gTLD and a name in an alternative naming system, and if so, under what technical requirements?

For this library: this is the highest-leverage policy signal in the W40 window because: 1. The 1,616 paid 2026 Round applications will publish in <2 weeks (Reveal Day). 2. Any application for a string already used by an alt-naming system (e.g., .eth if applied for, or .wallet, .x, .bit) now has a TSG output to point at for "compatibility" criteria. 3. The ENS Foundation (operational since Aug 9 per the "Next Era" execution) is the legal entity positioned to comment on any .ens or related string.

The W39 update predicted this would close Sep 21 — confirmed.

6. ENS Labs × Immunefi audit competition — results frozen Sep 28 (today)

Post-close schedule (Aug 10 announcement, validated through the Sep 14 close):

Vault TVL (last public view Sep 21): $69,981.17 (was $69,989.29 Sep 14; $69,986.98 Sep 7; $69,973.68 Aug 31). The "70K USDC target" was within operational variance.

Public findings counter (Aug 31 snapshot, unchanged on the public view since Sep 14): 306 reports / 20 confirmed valid / 56 under review. The actual triage list has been internal since Sep 14; the public counters will not refresh until Oct 26 publication.

For this library: the Oct 26 publication will be the most consequential single event for the ENSv2 mainnet-readiness narrative in Q4 2026. Any high-severity finding that survives the dispute window will push the ENSv2 mainnet timeline back. Any zero-finding outcome will reinforce the "ready for mainnet" narrative. The competition's $70K prize pool + the $250K ongoing Immunefi bounty create the right adversarial-review incentive structure.

7. Handshake Airstop soft fork — locked, activated, irreversible

Source: shakeshift.com/signaling/airstop

The airstop soft fork is live and irreversible on mainnet — this is the confirmed network reality, not a future event. hsd v8.0.0 (Jul 1 2026, last week's W29 file already covered it) was the release that bundled the airstop signaling bit + wallet changes that activated it.

Pool signaling at activation: - ViaBTC: 60% (1,201/1,201 — 100%) - ANTPOOL: 24% (485/489 — 99.2%) - Mining-Dutch: 10% (203/203 — 100%) - CyberPool: 5% (100/100 — 100%) - DxPool: 1% (23/23 — 100%)

Supply effect: 216,199 airdrop allocations for open-source developers × 4,246.99 HNS each = 918,500,000 HNS originally allocated; 6,549 claimed; 209,650 unclaimed × 4,246.99 HNS = 890,382,357.93 HNS permanently removed from supply.

For this library: this is the most consequential supply-side confirmation in the Handshake story since the 2nd halving (Jul 22 2026, 1000 HNS/block). Combined with the Namecheap exit (Jun 10), ViaBTC pool closure (Jun 1), Namebase wind-down (Jun 2), and the 99.8% token decline from ATH, the airstop is the permanent economic seal on the 2018–2021 airdrop era. Future HNS issuance is now strictly via mining + block subsidies only — predictable, capped, and supply-deflationary.

The hsd core repo (handshake-org/hsd) remains dormant since Aug 22 2025 (last commit before the v8.0.0 release wave), no v9.x tag — but the airstop effect is already in the supply statistics and the only forward work is wallet/db stability + occasional backports.

8. Nomentum Labs Grails SPP3 Marketplace RFP — voting open ($500K)

Source: discuss.ens.domains/t/executable-spp3-marketplace-rfp-award-nomentum-labs-grails/22374

Award total: $500K (the max under [7.1] Social SPP3 Marketplace RFP) = $400K base + up to $100K performance-gated.

Three-tranche payment structure:

1. $90K upfront: $30K monthly installments over Q1, subject to KYC + Award Notice execution. Funds sit in stream.mg.wg.ens.eth = 0xB162Bf7A7fD64eF32b787719335d06B2780e31D1 (MetaGov Stream Management Pod).
2. $100K performance-gated: held in pod across four $25K gates, released on verified results: - Q1 2027: attributed protocol revenue ≥ at-signing baseline + ≥150 distinct wallets completing value-transferring actions. - Term end: revenue on pace for $1M/yr + ≥250 ETH filtered secondary volume over prior two quarters. - Revenue baseline = Grails attributed revenue over the 90 days before signing.
3. $310K stream: opened by MetaGov from pod on committee verification of ENSv2 readiness milestone (target Q4 2026, or sufficient progress at committee judgment), running to term end. $25K wind-down escrow funded from award when stream opens.

Blockful calldata verification: dao-proposals c9204ae — forge test --match-path "src/ens/proposals/ep-spp3-marketplace-rfp/*" -vv — passes.

Live proposal: ens.gov.blockful.io/proposals/19667497139373951686084433718987773325019389190188449031876262520356769920394

Term: co-terminates with SPP3 cohort in Q3 2027. Unreleased funds return to treasury at term end.

For this library: Grails is the first SPP3 Marketplace RFP award to be tied explicitly to ENSv2 readiness — the $310K stream is contingent on the committee's judgment that ENSv2 is sufficiently deployed. This is a meaningful precedent: ENSv2 readiness becomes an economic dependency for ecosystem-funded marketplaces.

9. Endowment permissions to KPK Update #10 — revised execution moving toward schedule

Source: discuss.ens.domains/t/draft-endowment-permissions-to-kpk-update-10/22323 — kpk's Sep 14 post + the Sep 24-era follow-ups

Original spec (Jul 28 draft, Blockful-reviewed): adds RWA + fixed-income positions, curated Morpho yield vaults (kpk, Steakhouse, Smokehouse, Sentora), Aave v3 Horizon (RLUSD market), Pendle fixed-yield principal tokens, Maple Syrup swap routing, and a dedicated Harvest role for Fluid FLUID / Fluid GHO / Merkl/Morpho incentive claims.

Revised execution (Sep 14 update, after Blockful review): swap the Endowment to a new Roles module instead of applying permission changes to the existing module. New Modifier address 0xa23BEBFD…FD59; ownership transferred from test Safe to Endowment Safe 0x4F2083f5…FE64 this week (kpk "4 days ago" — ~Sep 24).

Pre-schedule precondition (per kpk's most recent post): owner() on the new Modifier must be the Endowment Safe (confirmed onchain). safeTxGas + gasPrice must be 0 (so a failed switch shows as failed, not as "executed").

For this library: this is the routine but consequential endowment permission update that unlocks: - Diversification into vetted yield (Morpho curated vaults, Aave Horizon, Pendle, Maple Syrup) - Operational safety (Harvest role is narrower than the full Endowment Manager — reward claims only, with payouts forced to Endowment Safe)

The kpk-as-Endowment-Manager + Blockful-as-calldata-auditor + MetaGov-as-pod-steward workflow is the standard pattern for ENS Endowment execution — and PUR #10 is the cleanest example of the pattern in 2026.

10. ENS Foundation "Evolved Foundation" blog post — institutional counterparty story

Source: ens.domains/blog/post/introducing-the-evolved-ens-foundation — enslabs.eth, dated Sep 22 era

The blog post summarizes the Aug 9 Next Era of ENS DAO proposal (1.27M For / 480K Against; executable carried out onchain on Aug 9) and frames the institutional gap that the Foundation is built to fill:

"A DAO, on its own, does not have the legal and operational capacity to act in many of the venues where that infrastructure now needs representation. It cannot pursue recognition and stewardship of the .ens TLD at ICANN. It cannot sign agreements required for participation in IETF and W3C standards work, employ full-time staff, enforce a trademark against a phishing operation impersonating ENS, respond to legal process, or represent ENS in regulatory discussions about decentralized naming."

The Foundation's enumerated capabilities (verbatim from the post): - Represent ENS where naming standards are developed. ICANN, IETF, W3C; pursue .ens TLD recognition/stewardship; coordinate with SEAL + DNS infrastructure community. - Engage on policy. Legal entity to meet regulators + lawmakers directly. - Hold and defend the brand. Consolidate ENS trademarks + brand assets; act against scams and impersonation. - Employ people accountable to the mission. Full-time staff under a board that tokenholders appoint + can remove. - Serve as the protocol's institutional counterparty. Courts, registrars, standards bodies have a defined entity to engage with.

The post also clarifies ENS Labs' role: with the Foundation operational, Labs concentrates on product + engineering (ENSv2, integration, the SDK + App stack).

The five-member board: Nick Johnson (ENS Labs), Alexander Urbelis (Executive Director), Kartik Talwar, Brett Sun, Anthony Leutenegger.

For this library: the Foundation's institutional capability is precisely the missing piece for the ICANN TSG conversation (alt-naming integration) and any Reveal Day application involving a blockchain-anchored string. The Foundation is the legal entity that can sign ICANN registry agreements, IETF participation agreements, and W3C member agreements. The DAO cannot.

11. ensforge SDK adds HCA support — agent identity flows for ENSv2

Source: discuss.ens.domains/t/ensforge-a-unified-typescript-sdk-for-ensv1-and-ensv2/22409 — namespace_eth (envoy1084.eth), plus cap.eth X posts Sep 22 area

ensforge is the Namespace-built TypeScript SDK with intent-level actions for ENSv1 and ENSv2, shipping at v0.3.1 under Apache 2.0 (Promise + Effect APIs, composed batching, wallet-aware write plans). GitHub: thenamespace/ensforge; docs: ensforge.com.

HCA support added Sep 22-era: scoped, time-limited grants to delegate ENS name operations (set text, transfer subnames, renew) without signing every transaction. Permissions are scoped and time-limited, revocable at any time. Gas sponsorship via Pimlico or Rhinestone.

Use cases (per cap.eth Sep 22): set text on a name without holding the parent, manage subnames as an agent, automate renewal.

For this library: HCA is the agent-identity primitive for ENSv2. Combined with the ENSIP-28 Name Owned Accounts model (EIP-712 proofs that an account consents to be listed under a name), HCA closes the agent-economy loop: an ENS name can list multiple agents (Safe + TBA + agent wallet), each with its own consent proof, and delegate specific operations to each. This is the closest ENS has come to the W3C DID/VC model while staying within the ENS data-record pattern.

12. ENSIP-28 Name Owned Accounts — continues to gather feedback

Source: discuss.ens.domains/t/ensip-28-ens-name-owned-accounts/22373 (12 posts through Sep 2); spec published at docs.ens.domains/ensip/28/

Authors: premm.eth, workemon.eth, raffy.eth. Created: Aug 13, 2026. Status: draft.

ENSIP-28 lets an ENS name list more than one account per chain (Safe, token-bound account, agent wallet, etc.) and requires each listed account to prove consent via EIP-712 signature, stored as a data record alongside the listing. Covers EOAs (ecrecover), deployed smart accounts (ERC-1271 SignatureChecker), and token-bound accounts (ERC-6551).

Key fields: - accounts[<chain-id>] = abi.encode(address account1, account2, ...) (one record per chain, accounts in any order). - accounts[<chain-id>][<account>] = abi.encode(uint256 expiresAt, bytes signature) (proof for each account; expiresAt ≤ 2 years from now; proof invalid at and after expiresAt). - Optional accounts-chains record lists all chains with accounts.

For this library: this is the first ENSIP to standardize the agent-identity-list pattern at the protocol layer. It is the consent model (each account proves it consents to be listed) which means an ENS name cannot unilaterally attach an account to itself without that account's signature. The 2-year expiresAt cap is a safety mechanism: accounts can withdraw consent by simply not re-signing.

13. ENSIP-31 Payment Preferences — multichain-token fingerprinting debate

Source: discuss.ens.domains/t/ensip-31-payment-preferences/22431

Author: premm.eth. Created: Sep 17. Status: draft. PR ensdomains/ensips#87.

ENSIP-31 lets a recipient publish an ordered, token-specific list of preferred chains through their ENS name as an ENSIP-24 data record (key payment-preference[]). Wallets read before choosing a chain.

Example: alice.eth publishes that for USDC she prefers Base first, Ethereum second. A wallet asked to send 20 USDC reads the record, picks Base, and resolves the Base address as normal.

The multichain-token fingerprinting question (the unresolved technical question): - Symbols like "USDC" are not canonical. - Contract addresses are canonical but identify a token on only one chain. - Once a token exists across multiple chains, there is no single canonical identifier for the multichain token as a whole. - ENSIP-31 currently addresses this by hashing an immutable snapshot of its chain-specific token representations.

jkm.eth's Sep 21 reply (substantive pushback):

"In practical terms, many people may consider all deployments of USDC to be fungible, because they are all 'backed' by the same entity. However, 20 USDC on one chain isn't guaranteed to always be worth 20 USDC on another chain, as low liquidity or the cost of moving assets between chains can separately impact the value of each. Therefore, trying to present distinct assets as one unified asset is tricky. Alice might say she prefers Base to Ethereum, but that doesn't explain the exchange rate between the two, and Alice might need 21 USDC if sent on Ethereum but only 20 USDC if sent on Base. It seems like payment details comprise 3 data points: which assets are accepted/requested, how much of the asset is required depending on which asset is chosen, and the order of preference between those assets. Publishing just one of these data points seems unhelpful when the other two still need to be conveyed somehow."

For this library: this is the strongest open technical thread on multichain payment routing in 2026. It is also the first ENSIP to tackle recipient-side chain routing at the protocol layer. The resolution of the multichain-token-fingerprinting question will likely require either (a) a Multichain Token Registry maintained by a third party (Uniswap's Universal Token List is the closest analog), or (b) a snapshot-and-hash approach as currently proposed, or (c) per-chain ordering without a unified token identifier.

14. Root KSK rollover T-13 days to Oct 11, 2026

Source: ICANN Board LA workshop resolutions (Sep 4–6, published Sep 8) + Jul/Aug ICANN blog posts confirming the Oct 11 hard date.

The root DNSSEC Key Signing Key (KSK) rollover is T-13 days from today. The hard cutover is Oct 11, 2026. Old-key retirement is Jan 2027.

The simultaneous Oct 11 KSK + Oct 14 Reveal Day upper bound makes the second week of October 2026 the most institutionally-loaded week for the global DNS in years.

For the decentralized-DNS stack, the KSK rollover is operationally relevant for any project that bridges to legacy DNS: - ENS DNSSEC import (the PR #572 ancestor-inceptions-onchain fix from Sep 14 weekly moves closer to operational) - Handshake resolvers that resolve traditional TLDs as a side-effect - Namecoin .bit HTTPS via ncp11 (NCIP validation may inherit trust through the ICANN root) - ICANN's own Name Collision Observatory pre-delegation gate for 2026 Round applications

15. DNS-AID draft-02 expires Nov 28, 2026 — still no new draft

Source: datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/

DNS-AID (DNS-based Agent Identifier) draft-02 is the current canonical reference for AI agent discovery via DNS records. The Cloudflare Agent-Readiness checker (Aug 24) still enforces draft-01 expectations without acknowledging the breakage.

The DNSOP working group has not cut a new draft. The expiry is Nov 28, 2026 — T-61 days from today.

For this library: watch for any cut before Nov 28. Stale but not dead. The DNS-AID pattern matters because any agent-discovery layer for the legacy web will sit on top of the gTLD root, which means the ICANN TSG × alt-naming conversation also applies here — an ENS name or Handshake TLD can carry an agent identifier through the DNS-AID SVCB custom-parameter pattern, but only if the ICANN root recognizes the lookup as DNS.

16. GNUnet/GNS, Namecoin, hsd, hns-rs — release plateaus (GNUnet remains experimental)

For this library: GNUnet is the only one of these shipping meaningful protocol changes in 2026 (0.28.0 → 0.29.0 was a wire-compat break). Namecoin has effectively migrated its discoverability story to NIP-05. hsd is in maintenance mode with airstop live on mainnet but no forward protocol work. hns-rs has shipped v0.4.0 + v0.4.1 (Sep 1) focused on the Shakescape V1 swap layer but no v0.4.2/v0.5 in the window.

17. Governance items in flight (other than the above)

• [Executable] SPP3 Marketplace RFP Award: Nomentum Labs — voting live ($500K; §8 above).
• [Executable] Endowment permissions to KPK Update #10 — revised execution moving toward schedule (§9 above).
• ENS-GR-01 Ten-Proposal Governance Record research (Sep 8 alontweft post) — proposes new delegation-incentive algorithm. Personal vote coefficients (10/10 → 1.000, 9/10 → 0.810, ..., 0–6/10 → 0). Delegated voting coefficients (Delegate qualified votes × Holder reconfirms within 5 proposals → Holder 0.7 / Delegate 0.3 at 10/10+reconfirm). Reduces "miss 1 vote → penalty only" cliff effect. Public Round 2 data: largest holder share among seven with current 250 ENS hard cap = 14.29%; no cap + linear = 26.17%; continuous diminishing-return = 20.81%. The diminishing-return curve replaces the hard per-address cap to disincentivize wallet splitting without giving newcomers an immediate mature-participant return.
• Endowment NAV $93M (Steakhouse August slides, unchanged from last week).
• Endowment permissions to KPK Update #10 — new Modifier ownership transferred this week (Sep 24-era kpk post).
• MetaMask Agent Wallet ENSv2 plugin v0.8.0 (Sep 15) — still Sepolia only.

Evidence at a glance

What to watch next week (W41, Sep 29 – Oct 5)

1. Reveal Day date announcement — ICANN "early next week" window is now. The APS website launch + Reveal Day will publish the 1,616 paid gTLD strings + contention sets. Watch for any application strings that overlap with blockchain-anchored TLDs (.ens, .eth, .bit, .crypto, .x, .wallet, Handshake TLDs).
2. ENS Labs × Immunefi 48-hour dispute window — opens Sep 29, closes Oct 1. No public signal expected unless a high-severity finding is disputed.
3. Endowment PUR #10 schedule + execution — kpk to schedule the new Modifier switch once ownership is confirmed. Expect a same-day or next-day execution.
4. ICANN TSG report revision — comment review begins; expect a revised report or a summary response in the W41–W42 window.
5. ENSIP-31 Payment Preferences multichain-token-fingerprinting debate — premm.eth's response to jkm.eth's 3-data-point critique may land in the W41 window.
6. pubky-core next release — v0.9.3 (Jun 24) is now 96 days old. Expect a v0.9.4 or v0.10.0 in the W41–W42 window based on PR velocity.
7. pkarr v8.0.3 or v8.1.0 — only if a feature lands (not just dependabot). No PRs visible in the W40 window.
8. hns-rs — still v0.4.1 (Sep 1, 27 days old). Watch for any v0.4.2 with the post-airstop supply-statistics integration.
9. DNS-AID draft-03 — watch for any cut before Nov 28 expiry (T-61 days).

Primary sources

• GNUnet: early-alpha software status