0x323a…b7e3

All memos sent from and to 0x323a…b7e3.

0x179a8627…9285sent to0x323a7639…b7e32026-09-04·#25,905,057·0xda6afccf…84755e

I support this. Abstaining since I was on the committee.

0xb778ddef…85e9sent to0x323a7639…b7e32026-09-03·#25,895,088·0x51359950…3228f9

I believe Grails brings real value to ENS. My vote is not against Grails, but against a model that funds only one marketplace. I would prefer ENS to support multiple strong projects and foster a diverse, competitive ecosystem.

0x1d5460f8…6359sent to0x323a7639…b7e32026-08-31·#25,877,353·0x95ae7477…734746

# [Executable] SPP3 Marketplace RFP Award: Nomentum Labs (Grails) https://discuss.ens.domains/t/spp3-marketplace-rfp-recommendation/22371 ## Abstract The SPP3 Marketplace RFP committee recommends Nomentum Labs, operating Grails (grails.app), as the Marketplace RFP awardee. The total award is $500,000, the maximum authorized under \[7.1] \[Social] SPP3 Marketplace RFP, consisting of a $400,000 base award and up to $100,000 released on performance-based traction gates. This executable moves the full award in USDC to the MetaGov Stream Management Pod (`stream.mg.wg.ens.eth`), from which it is released to Nomentum Labs under the Award Notice, after KYC. The awardee joins the SPP3 cohort's reporting and oversight structure for a term co-terminating with the cohort in Q3 2027. Unreleased funds return to the treasury at term end. ## Specification The award moves to the MetaGov Stream Management Pod (`stream.mg.wg.ens.eth`, `0xB162Bf7A7fD64eF32b787719335d06B2780e31D1`) in three USDC transfers, one per tranche of the payment structure: 1. **$90,000 upfront:** released to Nomentum Labs in $30,000 monthly installments over the first quarter, subject to KYC and the executed Award Notice. 2. **$100,000 performance-gated:** held in the pod across four $25,000 gates and released only on verified results. Q1 2027: attributed protocol revenue at or above the at-signing baseline, and at least 150 distinct wallets completing value-transferring actions in the quarter. Term end: revenue on pace for $1,000,000 a year, and at least 250 ETH of filtered secondary volume over the prior two quarters. The revenue baseline is Grails's attributed revenue over the 90 days before signing. 3. **$310,000 as a stream:** opened by MetaGov from the pod on committee verification of the ENSv2 readiness milestone (target Q4 2026, or sufficient progress at the committee's judgment), running to term end. The $25,000 wind-down escrow is funded from the award when the stream opens. Release mechanics (installments, gates, stream open, wind-down escrow) are executed pod-side by the MetaGov stewards using the existing custody structures. Unreleased funds return to the treasury at term end. ## Transactions | Address | Value | Function | Argument | Value | | --------------------------------------------------- | ----- | ---------- | -------- | --------------------------------------------------------------------- | | `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48` (USDC) | 0 | `transfer` | to | `0xB162Bf7A7fD64eF32b787719335d06B2780e31D1` (`stream.mg.wg.ens.eth`) | | | | | value | `90000000000` (90,000 USDC) | | `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48` (USDC) | 0 | `transfer` | to | `0xB162Bf7A7fD64eF32b787719335d06B2780e31D1` (`stream.mg.wg.ens.eth`) | | | | | value | `100000000000` (100,000 USDC) | | `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48` (USDC) | 0 | `transfer` | to | `0xB162Bf7A7fD64eF32b787719335d06B2780e31D1` (`stream.mg.wg.ens.eth`) | | | | | value | `310000000000` (310,000 USDC) |

0x76a6d08b…bbb8sent to0x323a7639…b7e32026-08-08·#25,711,884·0x480a7660…197cbb

Empowering the foundation is positive, but the feedback regarding the board selection being independent was not applied. This makes me concerned about keeping all funded entities equally and truly accountable.

0xe52c3932…d726sent to0x323a7639…b7e32026-08-07·#25,705,860·0x16ee8bb4…d1ebea

The ENS DAO had the opportunity to be an example of how to create a durable, self supporting system that protected itself and it's resources from the more manipulative aspects of human behavior.

0x5250265a…3149sent to0x323a7639…b7e32026-08-04·#25,679,474·0x8c574b1f…f99d9d

ENS needs futher reforms

0x3335cc8b…81e1sent to0x323a7639…b7e32026-08-04·#25,678,251·0x4b0172ef…55f081

I am voting against this proposal because it still transfers effective control of the ENS DAO Endowment "away from the DAO", (without establishing sufficiently strong, enforceable onchain safeguards). As Avsa has said, "After execution, the DAO appears nowhere in the control chain". The proponents of this proposal explain what they intend to do, but their statements, (that "protections, disclosures, renewals, or governance measures *should* be implemented" are *not* evidence that they have "actually been implemented"). Intentions, fiduciary duties, and policies are not substitutes for "verifiable execution, separation of powers, and durable" DAO-controlled mechanisms. Until those protections are demonstrably in place, (and the DAO retains "a meaningful, enforceable ability to constrain or recover the Endowment"), I cannot (and do not see how anyone can) support this transfer of authority.

0x5bfcb4be…8390sent to0x323a7639…b7e32026-08-03·#25,677,305·0x4abe4aa7…c059cd

https://discuss.ens.domains/t/draft-executable-next-era-of-ens-dao-empowering-the-ens-foundation/22329/2

0x809fa673…f68esent to0x323a7639…b7e32026-08-03·#25,676,137·0x315e13bd…6dfca5

I came here to vote for the proposal but after reading through it I ultimately couldnt. Here are my extended views: https://discuss.ens.domains/t/draft-executable-next-era-of-ens-dao-empowering-the-ens-foundation/22329/14?u=avsa

0xb8c2c29e…67d5sent to0x323a7639…b7e32026-08-02·#25,667,108·0x014faa46…f62e7c

# [Executable] Next Era of ENS DAO: Empowering the ENS Foundation ## **Abstract** This executable proposal establishes the ENS Foundation as an operating foundation, led by a full-time Executive Director and staff, and governed by a five-seat board ratified by the DAO, as set out in the [temp check](https://discuss.ens.domains/t/temp-check-next-era-of-ens-dao-empowering-the-ens-foundation/22175) posted June 19. It follows public discussion of that temp check and tightens the scope of the Foundation’s mandate in several areas in response to community feedback: the DAO's ENS tokens stay under tokenholder control, the operational wallet stays where it is, and Endowment transactions gain a timelock with Security Council oversight. Main changes from Temp Check in detail: (1) ENS tokens stay exactly where they sit today, under the same onchain mechanism and the same tokenholder control they are subject to now, and this proposal transfers no general authority over them. There is one exception: a single transfer of 1,000,000 ENS, restricted to Foundation employee compensation to support the Foundation in funding future employee compensation as the Foundation matures. Any future use of DAO-held tokens beyond this transfer, including for ecosystem programs, will be decided by the DAO as its own proposal through the standard governance process. (2) The operational wallet (wallet.ensdao.eth, approximately $16 million in ETH and stablecoins as of July 2026), which the temp check proposed delegating, stays with the DAO in its current place, with existing streams continuing to draw from it. (3) Treasury management is implemented with a dedicated security layer: the Foundation Board, acting through approved signers, assumes administrative control of the Endowment Safe (endowment.ensdao.eth, [approximately $65 million](https://app.syncrone.fi/public/ens?period=jun_2026) in ETH and stablecoins as of July 2026), with all Endowment transactions passing through a 9-day timelock by default, and an ability for the Security Council to cancel any timelocked transaction. Tokenholders will retain protocol control along with the authority over appointment and removal of Foundation directors. Every modification made from the original temp check was done in consideration of maintaining tokenholder control and security. ![image (3)|674x500](https://static.tally.xyz/8fc8d795-05f6-491f-8ad4-225aa3d4ff21_original.png) This proposal addresses Foundation governance and operational stewardship only. It does not transfer protocol control. For clarity, Foundation governance means the Cayman foundation company's board, Executive Director, staffing, grants administration, budget process, and Endowment stewardship. DAO governance means the public forum process, temp checks, Snapshot votes, executable proposals, delegation, and tokenholder voting. Protocol control means smart contract upgrades, ENS pricing and fee structures, root key and registry control, DAO-held ENS tokens, constitutional amendments, and director appointment, renewal, and removal. Protocol control remains exclusively with ENS tokenholders. ## **Motivation** The full problem statement, the research on comparable open-source foundations, and the reasoning behind this structure are in the temp check and its discussion thread. Onchain tokenholder governance is best suited for protocol-level decisions, constitutional authority, director appointment and removal, and other matters requiring broad legitimacy. Day-to-day operations, budgeting, staff management, grants administration, policy engagement, and vendor oversight require accountable execution within a legal entity that remains answerable to tokenholders. This proposal maintains protocol control, ENS tokens, and director appointment and removal with tokenholders, and moves operational and budgetary stewardship into a Foundation that remains structurally accountable to the DAO. For the sake of clarity, ENS Labs remains a separate Singapore-based entity with its own leadership and board. Participation by ENS Labs personnel in developing this proposal does not grant ENS Labs any governance right over the Foundation, the Endowment, DAO-held ENS tokens, protocol upgrades, fee structures, or director appointment and removal. ## **The Foundation Structure** The ENS Foundation becomes a fully operational foundation, led by a full-time Executive Director and staff, stewarding the ENS mission and values. The Foundation will hold the ENS trademarks, brand assets, and other intellectual property. ENS Labs continues to operate independently under its own leadership and its own board, with the Foundation licensing the ENS trademarks to Labs and funding Labs through the existing grant relationship. The Foundation is responsible for its mission, grants program, and stewardship of the protocol's revenue and Endowment. The Foundation represents ENS where policy and standards are made: active participation in ICANN, IETF, W3C, and adjacent forums, pursuit of recognition and stewardship of the .ens TLD at ICANN, regulatory engagement on policy questions affecting ENS and decentralized naming, the institutional and legal-process counterparty role for the protocol layer, and trademark and brand enforcement. The full advocacy mandate is described in the temp check. Staffing needs will be projected once the Foundation is stood up, and job applications will be made public. ## **Protocol Control Remains with Tokenholders** Protocol control such as smart contract upgrades, ENS pricing and fee structures, root key and registry control, the DAO’s ENS tokens, and constitutional amendments remain exclusively with tokenholders. The Foundation has no role in protocol governance decisions. Director appointment, term renewal, and removal also remain with tokenholders, under the Foundation's Articles of Association, unchanged by this proposal. ## **Foundation Leadership and Board** The Foundation Board has five voting seats: * One voting seat for the Founder of ENS, Nick Johnson, with succession to a designated ENS Labs representative in the event of the Founder's resignation or departure from the Board. * One voting seat for the Foundation's Executive Director. * Three voting seats for independent directors. The Executive Director (ED) is a full-time Foundation employee and voting Board member who leads Foundation operations and the grants program, with day-to-day authority subject to Board oversight, approved budgets, conflict-of-interest requirements, and the onchain controls in this proposal. The ED cannot unilaterally transfer Endowment assets, alter protocol control or ENS token permissions, or bind the Foundation outside approved authority. The Board holds exclusive authority over the ED's employment, with compensation set annually by the three independent directors, the ED and Founder recused. Independent directors serve two-year terms renewable by the DAO and are compensated at 40,000 USDC per year, donated to a non-profit or public good of their choosing if declined. Following a search process led by the existing ENS Foundation Board with input from ENS Labs leadership, the proposed inaugural slate is: * Executive Director: Alexander Urbelis * Director: Nick Johnson * Independent Director: Kartik Talwar * Independent Director: Brett Sun * Independent Director: Anthony Leutenegger Bios for each nominee, including baseline disclosure of material affiliations requiring recusal, are in the temp check. Furthermore, this proposal adds a documented process for exercising Director removal authority so that removal is legible and follows a clear process. The Foundation's bylaws will set out a standard process for tokenholder removal petitions: (i) a petition states the grounds for removal with supporting evidence; (ii) the petition is filed with the Foundation Board, which has a defined window to respond before a tokenholder vote is called; (iii) a 30-day period applies between petition and vote; and (iv) the director under petition may publish a written defense alongside the petition. These steps are designed to create notice, a documented record, and a fair opportunity to respond. They do not condition or limit tokenholders' removal authority under the Foundation's Articles: a removal vote validly conducted under the Articles is effective whether or not this process was followed, and no Board action or inaction under this process can delay or prevent it. ## **Conflicts of Interest** The Foundation will adopt, as Exhibit A to this proposal, an interim Conflict of Interest Policy effective upon adoption of this proposal. The interim policy requires written disclosure of actual and potential conflicts, recusal from deliberations and votes where appropriate, public recording of disclosures and recusals, and independent-director approval for ENS Labs funding. Within 90 days, the Executive Director will present a refined policy for Board approval and public publication. ## **Revenue and Treasury** Stewardship of the DAO's operating capital, meaning the Endowment and the Endowment Manager relationship, is delegated to Foundation governance consistent with Article III of the DAO Constitution. This proposal changes administrative control of the existing [Endowment Safe](https://app.syncrone.fi/public/ens) so the Foundation Board, acting through approved signers and subject to the timelock and Security Council cancellation right described below, oversees execution of Endowment transactions. This means no ETH or stablecoins are transferred by this proposal; the assets remain in the existing Endowment Safe at the same address. Alongside this change, a 9-day timelock is added to all Endowment transactions by default, and the Security Council can cancel any timelocked transaction. The Security Council cancellation right is included as a technical safeguard against unauthorized, erroneous, malicious, or mandate-inconsistent Endowment transactions. It is not a general governance veto over Foundation policy, Board judgment, approved budgets, or ordinary implementation of a ratified DAO proposal. The Security Council's cancellation function over Endowment transactions is conferred by this proposal and the Safe configuration, and does not amend the Security Council Charter. The Endowment Manager’s existing investment-management permissions remain unchanged. Any permission to transfer funds from the Endowment Safe to the Foundation multisig without timelock will be limited to approved budget funding and subject to recipient restrictions, Board approval, public reporting, and any technical controls specified in the Transactions section. The Foundation will not receive any general, uncapped, or discretionary non-timelocked withdrawal authority. The DAO operational wallet remains in its current place, with existing streams continuing to draw from it. The Foundation will receive no operating funding under this proposal until the Executive Director has presented a projected budget to the Board and a high-level version has been published to the DAO forum. Pending that publication, aggregate transfers from the Endowment to the Foundation may not exceed USD 500,000, covering standup costs only. The first annual budget will be published within 60 days of adoption, and annual Foundation spending thereafter is bounded by the published budget. The ~54.6 million ENS tokens the DAO owns stay under the existing onchain mechanism and tokenholder control. The single exception is the 1,000,000 ENS transfer for Foundation employee compensation, administered under a Board-approved compensation framework published before any grant is made: multi-year vesting, independent-director approval for any grant to the ED or a director, annual public reporting of aggregate token compensation, and reversion to the DAO treasury of any tokens ungranted at wind-down or recalled by DAO vote. Pending grants, the tokens will not be voted, delegated, lent, pledged, transferred to ENS Labs, or used to compensate ENS Labs personnel. Any other use of DAO-held tokens comes to the DAO as its own proposal through the ordinary governance process. For the avoidance of doubt, this proposal does not transfer beneficial ownership of ETH, stablecoins, or DAO-held ENS tokens to any director, officer, employee, ENS Labs, or other private party. The Endowment remains dedicated to the ENS mission and subject to the Foundation’s obligations, approved budgets, reporting commitments, technical controls, and tokenholder-retained protocol authority. ## **Grants & Working Group Transition** Any grant-making is consolidated under the Foundation's Grants program, focused on public goods and core infrastructure benefiting the ENS protocol and the broader Ethereum ecosystem. The Foundation works alongside the SPP Committee on SPP3, and going forward, SPP is absorbed into the Grants program, and reporting requirements for SPP recipients do not change. Existing stewards, active streams, and current-term commitments are honored through their natural conclusion, with a transition plan covering SPP3 disbursements, Endowment Manager continuity, and the working group wind-down developed collaboratively with all parties once the Foundation is stood up. No existing stream, award, or current-term commitment may be reduced, paused, or re-conditioned except per its own terms or with the recipient's consent. ## **Specification** The only ENS token transaction in this proposal is a single one-time transfer of 1,000,000 ENS to the Foundation, restricted to Foundation employee compensation. No other transaction moves, delegates, or re-permissions ENS tokens held by the DAO. *** ## **Exhibit A:** **Interim Conflict of Interest Policy** **1. Purpose and status** This interim policy takes effect on adoption of this proposal and governs the ENS Foundation Board and Executive Director until the Board approves the detailed Conflict of Interest Policy contemplated within the first 90 days. That later policy refines this one; it does not replace it with anything weaker. Any material change to this policy is published before it takes effect. **2. What counts as a conflict** A conflict exists when a director's or the ED's personal, financial, or professional interests could reasonably appear to influence their judgment on a Foundation matter. This includes, without limitation: a current role, employment, or compensation at an entity that receives Foundation funding; a financial interest in a grant applicant, service provider, or counterparty; a family or close personal relationship with any of the foregoing; and any matter concerning the person's own compensation, employment, or removal. Appearance matters: if a reasonable community member would question the person's impartiality, it is treated as a conflict. **3. Disclosure** Each director and the ED discloses actual and potential conflicts in writing: (a) on appointment, as a baseline disclosure of material affiliations; (b) at each Board meeting, as to any agenda item; and (c) promptly when a new conflict arises. Disclosures are recorded in the Board minutes and published with them. **4. Recusal** A conflicted person does not vote on the matter and does not participate in the Board's deliberation of it, beyond answering questions the non-conflicted directors ask. Recusals are recorded in the minutes and published. The following recusals are standing and automatic: · Any director or the ED, on any matter involving an entity in which they currently hold a role, employment, compensation, equity, or other financial interest. · The Founder seat, on any matter concerning ENS Labs funding, for so long as the seat carries succession to an ENS Labs representative. · The ED on all matters concerning the ED's own employment, compensation, or performance. · Any director on their own compensation, renewal, or removal. Prior roles or employment that have ended are disclosed in the public register under Section 6 but do not by themselves require recusal. **4A. Related-party decisions** Any decision concerning ENS Labs funding, in addition to any Board majority, requires the affirmative vote of a majority of the independent directors voting on the matter. **5. Quorum and decision on conflicted matters** A matter on which one or more members are recused is decided by majority of the non-recused directors, provided at least two non-recused directors participate. If recusals leave fewer than two, the matter is deferred until the Board has obtained independent advice on the matter, and the advice and the ultimate decision are recorded in the published minutes. **6. Public record** All disclosures, recusals, and votes on conflicted matters are recorded in the minutes and published. The Foundation maintains a public register of each director's and the ED's material affiliations, updated at least quarterly. **7. Gifts and personal benefit** No director or the ED may accept any gift, payment, or benefit offered to influence a Foundation decision, or use Foundation position, information, or assets for personal benefit. Gifts above a nominal value connected to Foundation business are disclosed and declined or surrendered to the Foundation. **8. Attestation** Each director and the ED signs an annual written attestation of compliance with this policy, published with the Foundation's annual reporting.

0x98311030…6744sent to0x323a7639…b7e32026-07-17·#25,552,504·0x49b2d005…3fa198

The entire process is illegitimate and everyone knows it.

0x7d6e5cee…ee0dsent to0x323a7639…b7e32026-07-17·#25,551,151·0x675075d0…8145b5

ԫ35>{-[K%]񛖣-

0x5bfcb4be…8390sent to0x323a7639…b7e32026-07-14·#25,533,408·0x90d29d6a…28333d

Fire Eyes has voted abstain on this proposal. Driven by a number factors, primarily that given the majority of the security council currently views the decisions of ENS Labs and Nick.eth as illegitimate and an attack on the $400m treasury, moving it from a decentralised DAO to a small group of insiders.

0x179a8627…9285sent to0x323a7639…b7e32026-07-14·#25,532,991·0x0ec524dc…fbf83c

I support this. Abstaining since I was on the committee.

0xb8c2c29e…67d5sent to0x323a7639…b7e32026-07-13·#25,524,727·0x76eefae4…ddef90

# [Executable] Establishing a new Security Council ## Abstract This proposal establishes the new ENS Security Council based on the results of EP 6.50 “Election of the New ENS DAO Security Council”. The term will last two years, until 16 July 2028. ## Motivation The Security Council was originally established in EP 5.13 as a 4-of-8 multisig with a single power: to cancel malicious proposals made to ENS DAO. It cannot propose, amend, or initiate any governance action. Its term was two years, ending 24 July 2026. The purpose of this proposal is to establish a new Security Council that will inherit the same responsibilities for the coming two years. ## Specification A single call to the DAO’s TimelockController, granting `PROPOSER_ROLE` to Blockful’s Security Council contract, which is owned by a multisig with the Security Council members elected in EP 6.50. The Security Council contract has been deployed to `0x2acBf518b3759f6e1fA163294eda55bF1d0ae051`, and the multisig to `0x7101B78638e34444F0a5AdE9e1149fbEeC029931`. After two years, any address may call `renounceTimelockRoleByExpiration()` to revoke its cancel power unless `extend()` is called first by a separate DAO proposal.

0xd5d171a9…cf2csent to0x323a7639…b7e32026-07-10·#25,500,761·0xa53279a1…fa5950

hope the new mechanism will generate better roi

0x1d5460f8…6359sent to0x323a7639…b7e32026-07-09·#25,496,915·0x748c8968…61e717

# [EP 6.49] SPP3: Cohort Recommendation https://discuss.ens.domains/t/draft-spp3-cohort-recommendation/22237 # Summary The committee recommends a four-provider SPP3 cohort totaling $1,690,000 of the \~$3.25M available under the ratified budget. The remaining is not allocated by this proposal. The committee received 26 applications requesting a combined $12.2M. Each qualifying application was evaluated by every member unless recused, and a structured interview was conducted with each qualifying team. One application was disqualified at the eligibility gate, the remaining 25 were scored against the published rubric. Five were initially selected with one (EthID) declining the offer This proposal names the final four selected providers, states the rationale for each, publishes the committee's assessment, and explains in aggregate why the other applicants were not funded. Per the ratified proposal, this recommendation will be submitted as an on-chain executable. If this proposal passes, streams will begin in accordance with the Award Notices pending the selected providers pass the KYC checkpoint. ## Cohort Scores | Provider | Category | Award | Application | | ---------- | -------- | -------------- | --------------------------------------------------------------------------------------------------------------------------- | | Namespace | 1, 2 | $500,000 | [Link](https://bronze-accused-porpoise-217.mypinata.cloud/ipfs/bafybeiee73y2jwinefaszeng3frn47wmqini562qtcibzgnh42cnqiu2la) | | Goldsky | 1 | $450,000 | [Link](https://bronze-accused-porpoise-217.mypinata.cloud/ipfs/bafybeidblcll7pt7s4jzlte6khv7twiqnckdoalanj2aoemd27afefhyou) | | Unruggable | 1, 2 | $400,000 | [Link](https://bronze-accused-porpoise-217.mypinata.cloud/ipfs/bafybeiedajocrvgfnj3y6ec2mrqyt62d46uiyfb6xyqraxyyosvto5tmyq) | | Fluidkey | 1, 2 | $340,000 | [Link](https://bronze-accused-porpoise-217.mypinata.cloud/ipfs/bafkreiaplckhk72bu3wuxofgkbdoky7jb3o24kk7olbb6urfaquz2os4sm) | | **Total** | | **$1,690,000** | | \*sovereignsignal.eth recused from the Namespace evaluation and vote under the program's conflict of interest rules. # The Cohort The initial cohort presented included five selectees. The application from EthID was withdrawn. The remaining four will continue unaffected. ### Namespace: $500,000 ([Application](https://bronze-accused-porpoise-217.mypinata.cloud/ipfs/bafybeiee73y2jwinefaszeng3frn47wmqini562qtcibzgnh42cnqiu2la)) Namespace is a third-cycle provider and one of the ecosystem's primary subname infrastructure teams: SDKs, APIs, CCIP gateways, and custom deployments including Celo, Filecoin, and Rootstock. Their SPP2 subname issuance exceeded target by more than an order of magnitude, though the committee notes that figure is concentrated in a small number of large deployments. The SPP3 scope covers the ENSv2 migration of their onchain subname stack, continued maintenance of existing tooling, and business development. The award reflects the counterfactual: no comparable subname infrastructure exists at this scale, and the ENSv2 transition makes that infrastructure work time-critical. Key milestones depend on ENSv2 shipping to mainnet; the committee has accounted for this in the negotiated milestone structure. \*sovereignsignal.eth recused from the Namespace evaluation and vote under the program's conflict of interest rules. ### Goldsky: $450,000 ([Application](https://bronze-accused-porpoise-217.mypinata.cloud/ipfs/bafybeidblcll7pt7s4jzlte6khv7twiqnckdoalanj2aoemd27afefhyou)) Goldsky, with eRPC, is funded to operate ENS indexing as a dedicated public service. The award reflects the expanded scope presented as Option B in their application, which the team confirmed at the committee's request before selection. Indexing is a shared dependency consumed across the ecosystem, and it has previously been funded as one component inside larger provider scopes. The committee's judgment is that a dependency of this weight is best held as a standalone mandate: one accountable owner, priced on its own merits, and decoupled from any broader award. Goldsky is new to the SPP and was evaluated accordingly. The team operates production indexing infrastructure across the EVM ecosystem at scale, and selection was conditioned on their explicit commitment to the full scope. ### Unruggable: $400,000 ([Application](https://bronze-accused-porpoise-217.mypinata.cloud/ipfs/bafybeiedajocrvgfnj3y6ec2mrqyt62d46uiyfb6xyqraxyyosvto5tmyq)) Unruggable is a returning SPP2 provider whose gateway infrastructure powers cross-chain resolution in production, including base.eth and ENSIP-19 reverse resolution. The SPP3 scope continues gateway operation and extends into developer tooling and interoperability R\&D. The committee funded the full ask on the strength of shipped, verifiable protocol infrastructure that ENS depends on today, and a delivery record with no abandoned commitments. ### Fluidkey: $340,000 ([Application](https://bronze-accused-porpoise-217.mypinata.cloud/ipfs/bafkreiaplckhk72bu3wuxofgkbdoky7jb3o24kk7olbb6urfaquz2os4sm)) Fluidkey is funded to build privacy-preserving ENS infrastructure: an ENSIP, wallet-agnostic contracts, and a resolver kit designed to be maintained independently of Fluidkey's own product. This is the smallest award in the cohort and the committee treats it as a deliberate position on an underdeveloped capability. The proposal cleanly separates the public-goods layer from the company's commercial product, budgets an audit, and self-funds its own reference integration. The registration upside is less proven than elsewhere in the cohort; the cost is priced accordingly. ## Committee Assessment Scores are the mean of individual Member scores against the published rubric. Weights: Prior Delivery 25%, Scope Clarity 15%, Milestone Structure 15%, Adoption/Revenue/Utility 40%. The 5% discretionary component is excluded from the weighted figure, which is therefore out of 4.75. The Chair scored every application independently but Chair scores enter the mean only in the case of Namespace which saw a recusal, noted below. Individual scoring records remain internal working documents, available to the accountability body or ENS Foundation on request per the ratified proposal. | Provider | C1 Prior Delivery | C2 Scope Clarity | C3 Milestones | C4 Adoption/Revenue | Weighted | | ---------- | ----------------- | ---------------- | ------------- | ------------------- | -------- | | Namespace | 4.1 | 3.4 | 3.3 | 3.5 | 3.43 | | Goldsky | 4.0 | 3.8 | 3.4 | 3.3 | 3.37 | | Unruggable | 4.5 | 3.4 | 3.1 | 3.0 | 3.30 | | Fluidkey | 4.0 | 4.0 | 3.8 | 2.4 | 3.11 | \*sovereignsignal.eth recused from the Namespace evaluation under the conflict of interest rules. The Chair's independent scores stand in for the recused seat on this row, keeping four scoring inputs. ## Why Applications Were Not Funded This section removed to fit character limit. See full post [here](https://discuss.ens.domains/t/draft-spp3-cohort-recommendation/22237). ## Process This section removed to fit character limit. See full post [here](https://discuss.ens.domains/t/draft-spp3-cohort-recommendation/22237). ## Next Steps 1. Award Notices have been issued to each selected provider for review; they will be finalized by the ENS Foundation 2. The executable proposal is scheduled for posting on Wednesday, July 8th. 3. Streams will turn on after successful completion of KYC and signing of Award Notices by both the selected providers and the Foundation. # Specification The attached payload includes five transactions that facilitate the provider and committee streams, and four transactions to pay the committee as defined in [\[6.42\] \[Social\] SPP3: Program Authorization and Committee Model](https://discuss.ens.domains/t/6-42-social-spp3-program-authorization-and-committee-model/22086#p-61193-term-and-payment-12). Source: [Github](https://github.com/blockful/dao-proposals/pull/93/changes#diff-abce5ec202f8620398bdf4ede6d54defa3acbee46708fd9b8fcc83e57d9e2e3e). Nine transactions, all run by the timelock: 1. USDC.approve(USDCx, 517,500e6) - lets the USDCx contract pull the USDC we are about to wrap. 2. USDCx.upgrade(517,500e18) - wrap it. 517,500 is one month of the stream ($267,500) plus the pod margin ($250,000). 3. USDCx.transfer(pod, 250,000e18) - send the margin to the pod. It carries the pod through the overlap until the switch. 4. CFAv1Forwarder.setFlowrate(USDCx, pod, 101720934415475068) - set the master stream to $3.21M/yr. 5. USDC.approve(autowrapper, 4,547,500e6) - refresh the autowrap allowance (\~17 months, the ratio SPP2 used). 6. USDC.transfer(coltron) - committee chair 9k USDC 7. USDC.transfer(sovereignsignal) - committee member 7k USDC. 8. USDC.transfer(austingriffith) - committee member 7k USDC. 9. USDC.transfer(abdullah) - committee member 7k USDC.

0x534631bc…42cfsent to0x323a7639…b7e32026-07-02·#25,446,081·0x93ca4e5e…183e29

I support a security council. However, this is the stronger proposal: https://discuss.ens.domains/t/draft-social-proposal-for-a-new-security-council/22219

0xac50ce32…c039sent to0x323a7639…b7e32026-07-02·#25,445,108·0xd6410409…c93fed

Heads we win, tails you lose governance.

0x36f79385…a589sent to0x323a7639…b7e32026-07-01·#25,436,113·0x48559bee…6eda1d

It’s the whole community against one entity.

0x7f7720bd…1caasent to0x323a7639…b7e32026-06-30·#25,430,393·0xc69b62b6…9c19ca

I was initially against this mechanism, but recent events have convinced me otherwise

0xe11da956…a20bsent to0x323a7639…b7e32026-06-30·#25,430,339·0xd5d58fb9…e83eae

the ego is the enemy

0xb8c2c29e…67d5sent to0x323a7639…b7e32026-06-30·#25,429,392·0x6f3e1f7e…72a252

Members of the current SC have made it clear that they intend to use their veto power to stop proposals they personally disagree with. The security council must exist as a backstop against compromise and violations of the ENS constitution, not as political officers. https://discuss.ens.domains/t/draft-social-proposal-for-a-new-security-council/22219

0xf3427890…3329sent to0x323a7639…b7e32026-06-30·#25,429,023·0xd0a15316…a48e90

https://discuss.ens.domains/t/draft-social-proposal-for-a-new-security-council/22219

0x8f198ebb…540csent to0x323a7639…b7e32026-06-30·#25,428,662·0xf6dc2e7a…7c619f

In favor of the 2-year Security Council renewal. The cancel-only mandate, timelock-governed extension mechanism and active signer rotation maintain a balanced and reliable safety guard for the DAO.

0x8f198ebb…540csent to0x323a7639…b7e32026-06-30·#25,428,632·0x7271292e…72d1ca

Support this delegation incentives program to activate idle voting power and improve governance health. Transparent fund management with unspent tokens returned to the DAO treasury is a sound design.

0xd5d171a9…cf2csent to0x323a7639…b7e32026-06-30·#25,427,846·0x5348277a…a56385

I previously voted 'For' on snapshot because a Security Council is essential and we had no alternative. However, the newly proposed on the forum framework is a much better solution.

0x809fa673…f68esent to0x323a7639…b7e32026-06-29·#25,424,113·0x1fc3d713…2dc6a4

# [6.48][Executable] Renewal of the Security Council (Term 2) https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145 ## Abstract The ENS DAO Security Council's veto authority expires on 24 July 2026, when renounceTimelockRoleByExpiration() becomes callable at Fri, Jul 24, 2026, 18:52:59 UTC. This proposal renews the council for a further two-year term. It deploys an updated SecurityCouncil contract that adds a extend() function callable only by the DAO timelock, so future renewals are a single governance vote rather than a fresh deployment and role re-grant. The new contract is audited before it is deployed, with the Meta-Governance Working Group funding the audit. The 4-of-8 multisig and the council's cancel-only emergency mandate are unchanged, with one signer rotation: lefteris.eth, who is no longer active in the DAO, is removed and coltron.eth, the largest active delegate not currently on the council, is added. This post has gone through the temperature check; and the Snapshot social vote, and now we are voting on the executable. ## Specification ### Background The Security Council is a 4-of-8 [Safe multisig](https://app.safe.global/home?safe=eth:0xaA5cD05f6B62C3af58AE9c4F3F7A2aCC2Cdc2Cc7) with a single power: to cancel malicious proposals in the ENS timelock. It cannot propose, amend, or initiate any governance action. It was approved through [EP 5.7 \[Social\]](https://snapshot.box/#/s:ens.eth/proposal/0xf3a4673fe04a3ecfed4a2f066f6ced1539a5466d61630428333360b843653c54), [EP 5.10 \[Social\]](https://snapshot.box/#/s:ens.eth/proposal/0xa0b1bfadf6853b5b0d59d3c4d73c434fc6389339887d05de805361372eb17c3a), and [EP 5.13 \[Executable\]](https://www.tally.xyz/gov/ens/proposal/42329103797433777309488042029679811802172320979541414683300183273376839219133) (passed 25 July 2024). The current contract is deployed at [0xb8fa0ce3f91f41c5292d07475b445c35ddf63ee0](https://etherscan.io/address/0xb8fa0ce3f91f41c5292d07475b445c35ddf63ee0) and its authority is time-limited: two years plus a 7-day buffer after deployment, anyone may call renounceTimelockRoleByExpiration() to permanently disable the cancel power, which occurs on 24 July 2026. The threat that motivated the council, a large treasury relative to active voting power, has not changed, so the recommendation is to renew rather than let it lapse. ### New contract The current contract has no way to extend its own expiration, so renewing it requires deploying a new contract, passing an executable proposal to grant PROPOSER\_ROLE, and letting the old role expire. We propose deploying an updated SecurityCouncil contract ([blockful/security-council-ens](https://github.com/blockful/security-council-ens)) with the same cancel-only mandate and 4-of-8 ownership, plus an extend() function. The key safety property is that only the timelock can call extend(), so only a passed ENS DAO proposal can extend the term and the multisig cannot extend its own power. After this renewal, each subsequent renewal is a single extend() proposal with no redeploy and no re-grant.

0x809fa673…f68esent to0x323a7639…b7e32026-06-29·#25,424,099·0x2fa39ccb…76e473

# [6.47][Executable] Delegation Incentives Program (Funding Transfer) https://discuss.ens.domains/t/temp-check-delegation-incentives-program/21824 ## Abstract This is the on-chain executable proposal to fund the **Delegation Incentives Program**, already [approved](https://snapshot.box/#/s:ens.eth/proposal/0xf0ad5ad5a1ee353a65424a83e74f2b8846b16885a4be99af26b5162bfa78c644) by ENS governance via Snapshot (\[6.31] Delegation Incentives Program). It transfers **90,000 ENS** and 5 ETH from the DAO treasury to the **MetaGov stewards multisig**, which will manage distribution over the program's three monthly rounds. The program is ready to launch: * **Start date:** July 1st, 2026 * **Duration:** 3 months (three monthly distribution rounds) * **Launch campaign:** Planned (redelegation campaign with sponsored gas via `delegateBySig`, plus a visibility campaign). * **Website:** Live. ## Motivation ENS is safer when voting power sits with active delegates rather than idle wallets. This 90-day pilot pays viewpoint-neutral incentives to active delegates and their delegators, using time-weighted balances, per-recipient caps, a 1 ENS minimum payout, and a lottery for sub-1 ENS amounts. Full program design, reward formulas, and guardrails are specified in the approved Snapshot proposal. * **Funding:** 90,000 ENS, managed by the MetaGov stewards for distribution. Actual usage scales with results and can range from 15,000 to 90,000 ENS. **Any remainder is returned to the treasury after the program ends.** 5 ETH is transferred to sponsor gas on delegations, votes for the long term. * **Distribution:** Monthly, claimless transfers executed by the MetaGov multisig, with public snapshots, data, and distribution files published each round. ## Specification 90,000 ENS tokens + 5 ETH sent to [MetaGov multisig](https://etherscan.io/address/0x91c32893216dE3eA0a55ABb9851f581d4503d39b).

0x1d5460f8…6359sent to0x323a7639…b7e32026-05-10·#25,061,691·0xcfd0befc…6c5161

{"rolesMod":"0x703806e61847984346d2d7ddd853049627e50a40","roleKey":"0x4d414e4147455200000000000000000000000000000000000000000000000000","removeAnnotations":["https://kit.karpatkey.com/api/v1/permissions/eth/cowswap/swap?sell=ETH%2C0xE95A203B1a91a908F9B9CE46459d101078c2c3cb%2C0xC0c293ce456fF0ED870ADd98a0828Dd4d2903DBF%2C0xba100000625a3754423978a60c9317c58a424e3D%2C0xc00e94Cb662C3520282E6f5717214004A7f26888%2C0xD533a949740bb3306d119CC777fa900bA034cd52%2C0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B%2C0x6B175474E89094C44Da98b954EedeAC495271d0F%2C0xA35b1B31Ce002FBF2058D22F30f95D405200A15b%2C0x6f40d4A6237C257fff2dB00FA0510DeEECd303eb%2C0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2f%2C0x5A98FcBEA516Cf06857215779Fd812CA3beF1B32%2C0x58D97B57BB95320F9a05dC918Aef65434969c2B2%2C0x856c4Efb76C1D1AE02e20CEB03A2A6a08b0b8dC3%2C0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38%2C0xae78736Cd615f374D3085123A210448E74Fc6393%2C0xD33526068D116cE69F19A9ee46F0bd304F21A51f%2C0xc20059e0317DE91738d13af027DfC4a50781b066%2C0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84%2C0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD%2C0x48C3399719B582dD63eB5AADf12A40B4C3f52FA2%2C0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48%2C0xdC035D45d973E3EC169d2276DDab16f1e407384F%2C0xdAC17F958D2ee523a2206206994597C13D831ec7%2C0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2%2C0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0&buy=ETH%2C0xE95A203B1a91a908F9B9CE46459d101078c2c3cb%2C0x6B175474E89094C44Da98b954EedeAC495271d0F%2C0xA35b1B31Ce002FBF2058D22F30f95D405200A15b%2C0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2f%2C0x856c4Efb76C1D1AE02e20CEB03A2A6a08b0b8dC3%2C0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38%2C0xae78736Cd615f374D3085123A210448E74Fc6393%2C0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84%2C0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD%2C0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48%2C0xdC035D45d973E3EC169d2276DDab16f1e407384F%2C0xdAC17F958D2ee523a2206206994597C13D831ec7%2C0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2%2C0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0"]}ROLES_PERMISSION_ANNOTATION{"rolesMod":"0x703806e61847984346d2d7ddd853049627e50a40","roleKey":"0x4d414e4147455200000000000000000000000000000000000000000000000000","addAnnotations":[{"schema":"https://kit.karpatkey.com/api/v1/openapi.json","uris":["https://kit.karpatkey.com/api/v1/permissions/eth/cowswap/swap?sell=ETH%2C0xE95A203B1a91a908F9B9CE46459d101078c2c3cb%2C0xC0c293ce456fF0ED870ADd98a0828Dd4d2903DBF%2C0xba100000625a3754423978a60c9317c58a424e3D%2C0xc00e94Cb662C3520282E6f5717214004A7f26888%2C0xD533a949740bb3306d119CC777fa900bA034cd52%2C0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B%2C0x6B175474E89094C44Da98b954EedeAC495271d0F%2C0x35fA164735182de50811E8e2E824cFb9B6118ac2%2C0xA35b1B31Ce002FBF2058D22F30f95D405200A15b%2C0x6f40d4A6237C257fff2dB00FA0510DeEECd303eb%2C0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2f%2C0x5A98FcBEA516Cf06857215779Fd812CA3beF1B32%2C0x58D97B57BB95320F9a05dC918Aef65434969c2B2%2C0x856c4Efb76C1D1AE02e20CEB03A2A6a08b0b8dC3%2C0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38%2C0xae78736Cd615f374D3085123A210448E74Fc6393%2C0xD33526068D116cE69F19A9ee46F0bd304F21A51f%2C0xc20059e0317DE91738d13af027DfC4a50781b066%2C0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84%2C0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD%2C0x48C3399719B582dD63eB5AADf12A40B4C3f52FA2%2C0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48%2C0xdC035D45d973E3EC169d2276DDab16f1e407384F%2C0xdAC17F958D2ee523a2206206994597C13D831ec7%2C0xCd5fE23C85820F7B72D0926FC9b05b43E359b7ee%2C0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2%2C0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0&buy=ETH%2C0xE95A203B1a91a908F9B9CE46459d101078c2c3cb%2C0x6B175474E89094C44Da98b954EedeAC495271d0F%2C0x35fA164735182de50811E8e2E824cFb9B6118ac2%2C0xA35b1B31Ce002FBF2058D22F30f95D405200A15b%2C0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2f%2C0x856c4Efb76C1D1AE02e20CEB03A2A6a08b0b8dC3%2C0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38%2C0xae78736Cd615f374D3085123A210448E74Fc6393%2C0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84%2C0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD%2C0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48%2C0xdC035D45d973E3EC169d2276DDab16f1e407384F%2C0xdAC17F958D2ee523a2206206994597C13D831ec7%2C0xCd5fE23C85820F7B72D0926FC9b05b43E359b7ee%2C0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2%2C0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0","https://kit.karpatkey.com/api/v1/permissions/eth/morphoVaults/deposit?targets=0xdaD4e51d64c3B65A9d27aD9F3185B09449712065","https://kit.karpatkey.com/api/v1/permissions/eth/morphoVaults/deposit?targets=0x870F0BF29A25A40E7CC087cD5C53e70C11F2C8A8"]}]}ROLES_PERMISSION_ANNOTATION

0x1d5460f8…6359sent to0x323a7639…b7e32026-05-06·#25,035,931·0xb135f74a…21d044

0x1d5460f8…6359sent to0x323a7639…b7e32026-04-29·#24,988,364·0x66e032f7…fbd169

# [EP 6.41] [Executable] Endowment permissions to KPK - Update #9 ## Abstract This proposal introduces a routine update to the permissions for the Endowment Manager. This update expands access to liquid staking and restaking protocols on Ethereum, adds exposure to Morpho USDT vaults, and extends CoW Swap routing to include weETH and eETH. ## Motivation The update opens positions in Stader and Ether.fi, two liquid staking and restaking protocols that allow the endowment to earn yield on ETH while preserving the ability to exit via standard or express unstaking paths. Adding Morpho's KPK USDT Prime vaults (v1 and v2) provides additional yield opportunities on stablecoin holdings consistent with the Investment Policy Statement (IPS). Extending CoW Swap permissions to cover weETH and eETH supports efficient token management across the expanded position set. These changes are additive and consistent with prior endowment strategy. ## Specification This proposal adds the following contracts: ### Additions #### 1. Liquid Staking & Restaking | Protocol / Contract | Description | Contract Address (Mainnet) | | ----------------------------------- | ---------------------------------------------------------- | ------------------------------------------ | | Stader / UserWithdrawalManager | Allows unstaking ETHx to receive ETH | 0x9F0491B32DBce587c50c4C43AB303b06478193A7 | | Ether.fi / LiquidityPool | Allows staking ETH/WETH/stETH/wstETH/eETH to receive weETH | 0x308861A430be4cce5502d0A12724771Fc6DaF216 | | Ether.fi / WithdrawRequestNFT | Allows unstaking eETH/weETH to receive ETH (Standard) | 0x7d5706f6ef3F89B3951E23e557CDFBC3239D4E2c | | Ether.fi / EtherFiRedemptionManager | Allows unstaking eETH/weETH to receive ETH (Express) | 0xdadef1ffbfeaab4f68a9fd181395f68b4e4e7ae0 | #### 
2\. Morpho Lending Markets | Market | Description | Vault Contract Address (Mainnet) | | ------------------- | ------------------------------------------- | ------------------------------------------ | | kpk USDT Prime | Allows approvals, deposits, and withdrawals | 0xdaD4e51d64c3B65A9d27aD9F3185B09449712065 | | kpk USDT Prime (v2) | Allows approvals, deposits, and withdrawals | 0x870F0BF29A25A40E7CC087cD5C53e70C11F2C8A8 | #### 3. Other | Protocol / Contract | Description | Contract Address (Mainnet) | | ------------------------------- | ---------------------------------------------- | ------------------------------------------ | | CoW Swap / Cowswap Order Signer | Expands swap routing to include weETH and eETH | 0x23dA9AdE38E4477b23770DeD512fD37b12381FAB | ## Reviewing Zodiac Roles Modifier Permissions Policy To review, the following resources are below: * **Payload:** [client-configs/clients/ens-dao/mainnet/payloads/ensPermissionsUpdate9.json](https://github.com/karpatkey/client-configs/blob/main/clients/ens-dao/mainnet/payloads/ensPermissionsUpdate9.json) * **Tenderly Simulation:** [https://dashboard.tenderly.co/public/tallyxyz/project/simulator/59b3d7f8-3196-475f-bd87-097e8ef672c6](https://dashboard.tenderly.co/public/tallyxyz/project/simulator/59b3d7f8-3196-475f-bd87-097e8ef672c6) ## Next Steps The proposal will be introduced in the next meta-governance call. Pending review from Blockful and no revisions following discussion during the meta-gov call, this proposal will progress to an on-chain executable vote.

0xb8c2c29e…67d5sent to0x323a7639…b7e32026-04-15·#24,884,455·0x50791336…4113f0

# [EP 6.40] [Executable] Update DNSSEC Algorithm 7 ## Abstract This proposal updates DNSSECImpl's algorithm 7 (RSASHA1-NSEC3-SHA1) to point to the same patched RSASHA1Algorithm contract that already serves algorithm 5. This was inadvertently omitted from the [previous proposal](https://discuss.ens.domains/t/executable-replace-dnssec-oracle-algorithms/21910) which patched algorithms 5, 8, and 13. ## Motivation The ENS deploy script ([`10_deploy_oracle.ts`](https://github.com/ensdomains/ens-contracts/blob/91c966febd7b55494269df830fc6775f040b927b/deploy/dnssec-oracle/10_deploy_oracle.ts#L64-L68)) maps both algorithm 5 and algorithm 7 to the same `RSASHA1Algorithm` contract, as they share identical RSA+SHA1 verification logic. When the [previous proposal](https://discuss.ens.domains/t/executable-replace-dnssec-oracle-algorithms/21910) was executed, `setAlgorithm` was called for algorithms 5, 8, and 13, but algorithm 7 was missed. Algorithm 7 currently still points to the pre-patch contract at [`0x6ca8624Bc207F043D140125486De0f7E624e37A1`](https://etherscan.io/address/0x6ca8624Bc207F043D140125486De0f7E624e37A1), which lacks PKCS#1 v1.5 padding validation. **Current impact is negligible** — no TLD in the ENS ecosystem currently uses algorithm 7. The TLDs affected by the original vulnerability (`.cc`, `.name`) used algorithm 8, which was patched in the previous proposal. However, this should be corrected to match the intended configuration and to close the gap left by the previous deployment. ## Specification A single `setAlgorithm` call on DNSSECImpl ([`0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5`](https://etherscan.io/address/0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5)): | Algorithm ID | Contract | Address | | ---------------------- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | 7 (RSASHA1-NSEC3-SHA1) | RSASHA1Algorithm (patched) | [`0x58E0383E21f25DaB957F6664240445A514E9f5e8`](https://etherscan.io/address/0x58E0383E21f25DaB957F6664240445A514E9f5e8) | No new contract deployment is needed — this reuses the same patched contract already serving algorithm 5. ## Transaction | # | Contract | Function | Parameters | | - | ---------- | ----------------------------- | ------------------------------------------------- | | 1 | DNSSECImpl | `setAlgorithm(uint8,address)` | `7`, `0x58E0383E21f25DaB957F6664240445A514E9f5e8` | Calldata: ``` cast calldata "setAlgorithm(uint8,address)" 7 0x58E0383E21f25DaB957F6664240445A514E9f5e8 ``` ## Verification After execution, confirm: ``` cast call 0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5 "algorithms(uint8)(address)" 7 # Expected: 0x58E0383E21f25DaB957F6664240445A514E9f5e8 ```

0x64291eeb…5c7esent to0x323a7639…b7e32026-04-13·#24,874,251·0xf5041f66…f20d76

I’ve been working on sepolia with the para wallet. I’m the one who submitted the bug report that got forwarded to the devs. Please let me be part of the community. It would be an honor to be able to discuss these proposals on the forums with everyone.

0x179a8627…9285sent to0x323a7639…b7e32026-04-13·#24,871,837·0x0e837402…08e864

Fine but we should update the contract soon with these changes https://discuss.ens.domains/t/21923/16

0xac50ce32…c039sent to0x323a7639…b7e32026-04-09·#24,841,048·0x30b05d69…5b4e5e

https://discuss.ens.domains/t/executable-treasury-flow-automation/21923/16?u=clowes.eth

0x1d5460f8…6359sent to0x323a7639…b7e32026-04-07·#24,828,897·0x2d970da5…73f40b

# [EP 6.39] [Executable] Treasury Flow Automation ## Abstract ENS protocol revenue currently requires three separate steps to move from registrar controllers to productive use in the endowment and fund operations. This proposal introduces a Registrar Manager contract that takes ownership of all registrar controllers and enables permissionless withdrawals directly to the endowment. It also configures a Zodiac module permission on the endowment to allow the treasury manager to send ETH and USDC to the timelock without a proposal, following a two-year stablecoin runway policy consistent with the current Investment Policy Statement. The result is zero proposals for routine treasury operations, faster yield on collected revenue, permissionless withdrawals, and increased income for the DAO. A conservative estimate suggests that since January 2024, approximately $1 million in yield was missed due to idle capital in registrar controllers and the timelock. ![](https://discuss.ens.domains/uploads/db9688/original/2X/3/398d621d97bf4820a875d790f220cab125667c48.png) ## Specification ### Problem ENS protocol revenue requires three steps to move from collection to productive use. Registrar controllers collect ETH from .eth registrations and renewals, and the current controller (controller.ens.eth) already sends withdrawn ETH to the timelock. However, the old registrar controller at 0x283Af0B28c62C092C9727F1Ee09c02CA627eb7F5 holds roughly 772 ETH that requires a dedicated proposal just to withdraw. Once ETH reaches the timelock, sending it to the endowment (endowment.ensdao.eth) for investment requires another proposal. Capital can sit idle in the timelock for several months before it starts earning yield. When the DAO needs to fund operational expenses like ENS Labs, the Service Provider Program, or Working Groups, yet another proposal is needed to transfer from the endowment back to the timelock or to execute operations with [twap.ensdao.eth](https://etherscan.io/address/0x02D61347e5c6EA5604f3f814C5b5498421cEBdEB). For context, [EP 6.32](https://discuss.ens.domains/t/ep-6-32-executable-transfer-2-5m-usdc-from-endowment-to-wallet-ensdao-eth/21882) proposed a $2.5M USDC transfer from the endowment to the timelock just to cover Working Group budgets that had already been approved. On top of that, there is currently roughly 4,148 ETH sitting in the timelock that could be earning yield in the endowment. The operational funding process today is reactive and not smooth. Each transfer requires a full governance cycle, and capital that could be generating yield sits idle throughout. #### Key Addresses • Timelock: 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7 (wallet.ensdao.eth) • Current Registrar Controller: 0x253553366Da8546fC250F225fE3d25d0C782303b (controller.ens.eth) • Old Registrar Controller (~772 ETH): 0x283Af0B28c62C092C9727F1Ee09c02CA627eb7F5 • Endowment: 0x4F2083f5fBede34C2714aFfb3105539775f7FE64 (endowment.ensdao.eth) • Governor: 0x323A76393544d5ecca80cd6ef2A560C6a395b7E3 (governor.ensdao.eth) • TWAP safe: 0x02D61347e5c6EA5604f3f814C5b5498421cEBdEB (twap.ensdao.eth) ### Solution This proposal introduces two components that eliminate all three bottlenecks: a Registrar Manager and an Endowment Zodiac Module permission. #### Registrar Manager The Registrar Manager is a contract that becomes the owner of all registrar controllers. Its key properties: a) Exposes a permissionless withdraw() function that anyone can call. When called, it pulls ETH from each controller and routes it directly to the endowment. b) The destination address is configurable by the DAO through the timelock, so governance can redirect the flow at any time. c) Acts as a pass-through for governance calls, meaning the DAO retains full control over controller parameters. d) New controllers can be added over time. e) Never holds funds. [Source code of Registrar Manager contract.](https://github.com/blockful/dao-proposals/blob/ep-registrar-manager-endowment/src/ens/proposals/ep-registrar-manager-endowment/contracts/RegistrarManager.sol) #### Endowment Zodiac Module The Zodiac module is already part of how the endowment is managed. This proposal adds a scoped permission that allows the treasury manager (Karpatkey) to send ETH and USDC to wallet.ensdao.eth without a proposal. It cannot send to any other address or use any other token. All other endowment operations remain unchanged. ### Funding Policy This is the current suggestion for the funding policy. The timelock maintains a 6 months runway in USDC (~$8M at current spending). Each quarter, Karpatkey calculates the current runway on the timelock. If it falls below 6 months, the endowment sends the shortfall. If it exceeds 6 months, no transfer is needed and the excess stays invested in the endowment. If an additional governance proposal requiring capital is approved, this may trigger an earlier runway evaluation and transfer, consistent with this policy. The initial policy is included in this executable proposal, so no separate vote is needed to get started. Any future changes to the funding policy require a social vote. This establishes clear expectations about responsibilities and decision-making: the treasury manager handles routine rebalancing within the policy, and the community sets the policy itself. This proposal remains aligned with the IPS. The required three-year stablecoin runway is calculated at the Endowment level, including stablecoins held and deployed there, as is currently done. The expansion guidelines reference transferring 33% of protocol revenue to the Endowment. This proposal modifies that mechanism by routing revenue directly to the Endowment to improve operational efficiency and capital deployment. ### Impact The operational funding process is reactive, requiring a full governance cycle for each transfer. Meanwhile, capital that could be earning yield sits idle in controllers and the timelock for several months at a time. With this proposal, capital flows from registrars to the endowment as soon as anyone calls withdraw(). The endowment begins generating yield immediately rather than after several months of governance overhead. Operational funding follows a clear quarterly process based on the two-year runway target, removing the need for ad-hoc proposals. To put this in perspective: looking at the period from January 2024 until now, and considering ETH staking yields if this capital had been allocated to the endowment, a conservative estimate of $1 million in yield was left on the table. This is based on the balances held in the [timelock](https://etherscan.io/address/0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7#analytics), the [current registrar controller](https://etherscan.io/address/0x253553366Da8546fC250F225fE3d25d0C782303b#analytics), and the [old registrar controller](https://etherscan.io/address/0x283Af0B28c62C092C9727F1Ee09c02CA627eb7F5#analytics) (which still have a relevant number of registrations). Going forward, every ETH collected will begin earning yield within days, compounding the DAO's income over time.

0xf462e5da…fd59sent to0x323a7639…b7e32026-03-29·#24,761,907·0xeb88ebb5…2d84e5

{"rolesMod":"0x703806e61847984346d2d7ddd853049627e50a40","roleKey":"0x4d414e4147455200000000000000000000000000000000000000000000000000","removeAnnotations":["https://kit.karpatkey.com/api/v1/permissions/eth/spark/deposit?targets=SKY_USDS","https://kit.karpatkey.com/api/v1/permissions/eth/cowswap/swap?sell=ETH%2C0xE95A203B1a91a908F9B9CE46459d101078c2c3cb%2C0xC0c293ce456fF0ED870ADd98a0828Dd4d2903DBF%2C0xba100000625a3754423978a60c9317c58a424e3D%2C0xc00e94Cb662C3520282E6f5717214004A7f26888%2C0xD533a949740bb3306d119CC777fa900bA034cd52%2C0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B%2C0x6B175474E89094C44Da98b954EedeAC495271d0F%2C0xA35b1B31Ce002FBF2058D22F30f95D405200A15b%2C0x5A98FcBEA516Cf06857215779Fd812CA3beF1B32%2C0x58D97B57BB95320F9a05dC918Aef65434969c2B2%2C0x856c4Efb76C1D1AE02e20CEB03A2A6a08b0b8dC3%2C0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38%2C0xae78736Cd615f374D3085123A210448E74Fc6393%2C0xD33526068D116cE69F19A9ee46F0bd304F21A51f%2C0xc20059e0317DE91738d13af027DfC4a50781b066%2C0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84%2C0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD%2C0x48C3399719B582dD63eB5AADf12A40B4C3f52FA2%2C0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48%2C0xdC035D45d973E3EC169d2276DDab16f1e407384F%2C0xdAC17F958D2ee523a2206206994597C13D831ec7%2C0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2%2C0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0&buy=ETH%2C0xE95A203B1a91a908F9B9CE46459d101078c2c3cb%2C0x6B175474E89094C44Da98b954EedeAC495271d0F%2C0xA35b1B31Ce002FBF2058D22F30f95D405200A15b%2C0x856c4Efb76C1D1AE02e20CEB03A2A6a08b0b8dC3%2C0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38%2C0xae78736Cd615f374D3085123A210448E74Fc6393%2C0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84%2C0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD%2C0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48%2C0xdC035D45d973E3EC169d2276DDab16f1e407384F%2C0xdAC17F958D2ee523a2206206994597C13D831ec7%2C0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2%2C0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0"]}ROLES_PERMISSION_ANNOTATION{"rolesMod":"0x703806e61847984346d2d7ddd853049627e50a40","roleKey":"0x4d414e4147455200000000000000000000000000000000000000000000000000","addAnnotations":[{"schema":"https://kit.karpatkey.com/api/v1/openapi.json","uris":["https://kit.karpatkey.com/api/v1/permissions/eth/cowswap/swap?sell=ETH%2C0xE95A203B1a91a908F9B9CE46459d101078c2c3cb%2C0xC0c293ce456fF0ED870ADd98a0828Dd4d2903DBF%2C0xba100000625a3754423978a60c9317c58a424e3D%2C0xc00e94Cb662C3520282E6f5717214004A7f26888%2C0xD533a949740bb3306d119CC777fa900bA034cd52%2C0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B%2C0x6B175474E89094C44Da98b954EedeAC495271d0F%2C0xA35b1B31Ce002FBF2058D22F30f95D405200A15b%2C0x6f40d4A6237C257fff2dB00FA0510DeEECd303eb%2C0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2f%2C0x5A98FcBEA516Cf06857215779Fd812CA3beF1B32%2C0x58D97B57BB95320F9a05dC918Aef65434969c2B2%2C0x856c4Efb76C1D1AE02e20CEB03A2A6a08b0b8dC3%2C0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38%2C0xae78736Cd615f374D3085123A210448E74Fc6393%2C0xD33526068D116cE69F19A9ee46F0bd304F21A51f%2C0xc20059e0317DE91738d13af027DfC4a50781b066%2C0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84%2C0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD%2C0x48C3399719B582dD63eB5AADf12A40B4C3f52FA2%2C0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48%2C0xdC035D45d973E3EC169d2276DDab16f1e407384F%2C0xdAC17F958D2ee523a2206206994597C13D831ec7%2C0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2%2C0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0&buy=ETH%2C0xE95A203B1a91a908F9B9CE46459d101078c2c3cb%2C0x6B175474E89094C44Da98b954EedeAC495271d0F%2C0xA35b1B31Ce002FBF2058D22F30f95D405200A15b%2C0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2f%2C0x856c4Efb76C1D1AE02e20CEB03A2A6a08b0b8dC3%2C0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38%2C0xae78736Cd615f374D3085123A210448E74Fc6393%2C0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84%2C0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD%2C0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48%2C0xdC035D45d973E3EC169d2276DDab16f1e407384F%2C0xdAC17F958D2ee523a2206206994597C13D831ec7%2C0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2%2C0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0","https://kit.karpatkey.com/api/v1/permissions/eth/spark/deposit?targets=SKY_sUSDS"]}]}ROLES_PERMISSION_ANNOTATION

0x1d5460f8…6359sent to0x323a7639…b7e32026-03-26·#24,740,886·0x5dcd240a…958d84

{"rolesMod":"0x703806e61847984346d2d7ddd853049627e50a40","roleKey":"0x4d414e4147455200000000000000000000000000000000000000000000000000","removeAnnotations":["https://kit.karpatkey.com/api/v1/permissions/eth/spark/deposit?targets=SKY_USDS","https://kit.karpatkey.com/api/v1/permissions/eth/cowswap/swap?sell=ETH%2C0xE95A203B1a91a908F9B9CE46459d101078c2c3cb%2C0xC0c293ce456fF0ED870ADd98a0828Dd4d2903DBF%2C0xba100000625a3754423978a60c9317c58a424e3D%2C0xc00e94Cb662C3520282E6f5717214004A7f26888%2C0xD533a949740bb3306d119CC777fa900bA034cd52%2C0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B%2C0x6B175474E89094C44Da98b954EedeAC495271d0F%2C0xA35b1B31Ce002FBF2058D22F30f95D405200A15b%2C0x5A98FcBEA516Cf06857215779Fd812CA3beF1B32%2C0x58D97B57BB95320F9a05dC918Aef65434969c2B2%2C0x856c4Efb76C1D1AE02e20CEB03A2A6a08b0b8dC3%2C0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38%2C0xae78736Cd615f374D3085123A210448E74Fc6393%2C0xD33526068D116cE69F19A9ee46F0bd304F21A51f%2C0xc20059e0317DE91738d13af027DfC4a50781b066%2C0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84%2C0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD%2C0x48C3399719B582dD63eB5AADf12A40B4C3f52FA2%2C0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48%2C0xdC035D45d973E3EC169d2276DDab16f1e407384F%2C0xdAC17F958D2ee523a2206206994597C13D831ec7%2C0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2%2C0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0&buy=ETH%2C0xE95A203B1a91a908F9B9CE46459d101078c2c3cb%2C0x6B175474E89094C44Da98b954EedeAC495271d0F%2C0xA35b1B31Ce002FBF2058D22F30f95D405200A15b%2C0x856c4Efb76C1D1AE02e20CEB03A2A6a08b0b8dC3%2C0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38%2C0xae78736Cd615f374D3085123A210448E74Fc6393%2C0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84%2C0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD%2C0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48%2C0xdC035D45d973E3EC169d2276DDab16f1e407384F%2C0xdAC17F958D2ee523a2206206994597C13D831ec7%2C0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2%2C0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0"]}ROLES_PERMISSION_ANNOTATION{"rolesMod":"0x703806e61847984346d2d7ddd853049627e50a40","roleKey":"0x4d414e4147455200000000000000000000000000000000000000000000000000","addAnnotations":[{"schema":"https://kit.karpatkey.com/api/v1/openapi.json","uris":["https://kit.karpatkey.com/api/v1/permissions/eth/cowswap/swap?sell=ETH%2C0xE95A203B1a91a908F9B9CE46459d101078c2c3cb%2C0xC0c293ce456fF0ED870ADd98a0828Dd4d2903DBF%2C0xba100000625a3754423978a60c9317c58a424e3D%2C0xc00e94Cb662C3520282E6f5717214004A7f26888%2C0xD533a949740bb3306d119CC777fa900bA034cd52%2C0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B%2C0x6B175474E89094C44Da98b954EedeAC495271d0F%2C0xA35b1B31Ce002FBF2058D22F30f95D405200A15b%2C0x6f40d4A6237C257fff2dB00FA0510DeEECd303eb%2C0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2f%2C0x5A98FcBEA516Cf06857215779Fd812CA3beF1B32%2C0x58D97B57BB95320F9a05dC918Aef65434969c2B2%2C0x856c4Efb76C1D1AE02e20CEB03A2A6a08b0b8dC3%2C0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38%2C0xae78736Cd615f374D3085123A210448E74Fc6393%2C0xD33526068D116cE69F19A9ee46F0bd304F21A51f%2C0xc20059e0317DE91738d13af027DfC4a50781b066%2C0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84%2C0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD%2C0x48C3399719B582dD63eB5AADf12A40B4C3f52FA2%2C0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48%2C0xdC035D45d973E3EC169d2276DDab16f1e407384F%2C0xdAC17F958D2ee523a2206206994597C13D831ec7%2C0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2%2C0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0&buy=ETH%2C0xE95A203B1a91a908F9B9CE46459d101078c2c3cb%2C0x6B175474E89094C44Da98b954EedeAC495271d0F%2C0xA35b1B31Ce002FBF2058D22F30f95D405200A15b%2C0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2f%2C0x856c4Efb76C1D1AE02e20CEB03A2A6a08b0b8dC3%2C0xf1C9acDc66974dFB6dEcB12aA385b9cD01190E38%2C0xae78736Cd615f374D3085123A210448E74Fc6393%2C0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84%2C0xa3931d71877C0E7a3148CB7Eb4463524FEc27fbD%2C0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48%2C0xdC035D45d973E3EC169d2276DDab16f1e407384F%2C0xdAC17F958D2ee523a2206206994597C13D831ec7%2C0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2%2C0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0","https://kit.karpatkey.com/api/v1/permissions/eth/spark/deposit?targets=SKY_sUSDS"]}]}ROLES_PERMISSION_ANNOTATION

0x1d5460f8…6359sent to0x323a7639…b7e32026-03-19·#24,693,037·0x8895f947…e647cc

# [EP 6.38] [Executable] Endowment permissions to karpatkey - Update #8 ## Abstract This proposal introduces a **routine update** to the Endowment Manager’s permissions. The changes remove deprecated permissions no longer required and upgrade the Roles instance to the latest version. ## Specification This proposal updates the Zodiac Roles Modifier configuration for the ENS Endowment by disabling the Roles V1 instance, updating the Roles V2 instance, and revoking token permissions that are no longer required. The following permissions are added: * Buy and sell GHO/FLUID via CoW Swap * Claim rewards from the Fluid Merkle Incentive distributor ### Summary of Updates #### **1. ZRM Instance Updates** | **Roles Version** | **Action** | | ----------------- | ---------- | | Roles V1 | Disabled | | Roles V2 | Updated | #### **2. Permission Additions** | **Roles Version** | **Action** | **Token Address (Mainnet)** | | ----------------- | ------------ | ------------------------------------------ | | Roles v2 | `buy` `sell` | 0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2f | | Roles v2 | `sell` | 0x6f40d4a6237c257fff2db00fa0510deeecd303eb | | Roles v2 | `claim` | 0xF398E66B1273a34558AeBbEC550DccaF4AcC7714 | > Added permission to Buy GHO and Sell GHO/FLUID through Cowswap > Added permission to be able to claim GHO rewards from the Fluid Merkle Incentive #### **3. Permission Removals** | **Token** | **Functions Allowed** | **Token Address (Mainnet)** | | --------- | --------------------- | ------------------------------------------ | | SPK | `claim` `transfer` | 0xc20059e0317DE91738d13af027DfC4a50781b066 | > Removed permission to claim and transfer SPK ## Reviewing Zodiac Roles Modifier Permissions Policy To review, the following resources are below: * **Payload:** [link here](https://github.com/karpatkey/client-configs/blob/main/clients/ens-dao/mainnet/payloads/ensPermissionsUpdate8.json) * **Zodiac Diff Page:** [link here](https://roles.gnosisguild.org/eth:0x703806E61847984346d2D7DDd853049627e50A40/roles/MANAGER/diff/44zkxJCEz3H0WcK87fvtfsKSrqb3KtOdlx2NJlAWiw?annotations=false) ## Next Steps The proposal will be introduced in the next meta-governance call. Pending review from Blockful and no revisions following the discussion in during the meta-gov call, this proposal will progress to an on-chain executable vote.

0x1d5460f8…6359sent to0x323a7639…b7e32026-03-11·#24,635,225·0x66940314…067a54

# [EP 6.37] [Executable] Transfer 900,000 USDC from Endowment to wallet.ensdao.eth ## Abstract The ENS DAO timelock (`wallet.ensdao.eth`) currently holds insufficient USDC to cover stream payments claimable by ENS Labs. This proposal requests a **one-time withdrawal of 900,000 USDC** from the ENS Endowment's stablecoin runway to cover that shortfall, bridging operations while the DAO works through more automated solutions such as [Treasury Flow Automation](https://discuss.ens.domains/t/executable-treasury-flow-automation/21923) proposal by @blockful. No new budget or funding program is created by this proposal. ## Motivation The ENS DAO timelock (`wallet.ensdao.eth`) currently holds insufficient USDC to cover stream payments claimable by ENS Labs. A transfer of **900,000 USDC** is sufficient to cover what is currently claimable by ENS Labs, enabling execution of previously approved governance decisions and maintaining operational continuity. No new budget or funding program is created by this proposal. > **Note:** The root cause of these recurring shortfalls is being addressed structurally through the [Treasury Flow Automation](https://discuss.ens.domains/t/executable-treasury-flow-automation/21923/6) proposal, which aims to automate USDC top-ups from the Endowment and eliminate the need for one-off transfers like this one. ## Specification Transfer **900,000 USDC** from the **ENS Endowment Safe** to **wallet.ensdao.eth (Timelock)**. **Addresses** | Label | Address | |---|---| | wallet.ensdao.eth (Timelock) | `0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7` | | ENS Endowment Safe | `0x4F2083f5fBede34C2714aFfb3105539775f7FE64` | **Transaction simulation:** [Tenderly](https://dashboard.tenderly.co/public/tallyxyz/project/simulator/41ec6e27-0532-4efd-8377-ad130b2982cc) **Transaction parameters:** ``` to: 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48, value: 0, data: 0xa9059cbb000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7000000000000000000000000000000000000000000000000000000d18c2e2800, operation: 0, safeTxGas: 0, baseGas: 0, gasPrice: 0, gasToken: 0x0000000000000000000000000000000000000000, refundReceiver: 0x0000000000000000000000000000000000000000, signatures: 0x000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7000000000000000000000000000000000000000000000000000000000000000001 ``` ## Next Steps Pending review from Blockful and no revisions following the discussion in during the meta-gov call, this proposal will progress to an on-chain executable vote.

0xb8c2c29e…67d5sent to0x323a7639…b7e32026-03-02·#24,569,499·0x131c8976…38d252

# [EP 6.36][Executable] Register on.eth to the ENS DAO wallet and set the resolver # Previous Context This proposal passed as [EP 6.34](https://www.tally.xyz/gov/ens/proposal/69304512515872868228453463730257567312488838925636819022683533220991373699419 "EP 6.34") and was queued for execution. Unfortunately, that proposal cannot be executed on-chain in its current form. Whilst the calldata was correct, and the simulations passed as expected, the calldata was generated against the blockchain state at the time and did not give consideration to other ongoing executable proposals. Alongside this proposal, another proposal was in motion ([Tally | ENS | Enable Root and Registrar Security Controllers](https://www.tally.xyz/gov/ens/proposal/7432320732701654700329828389963546575346476886035742386260284098817526767149 "Enable Root and Registrar Security Controllers")), which passed and was executed prior to 6.34. That proposal changed a dependency on which 6.34 relied - specifically, the ownership of the Base Registrar.  This proposal is the updated proposal with calldata that gives appropriate consideration to the updated ownership model. **There are no material changes.** Description =========== This proposal registers the \`on.eth\` ENS name to the ENS DAO wallet (`0xfe89cc7abb2c4183683ab71653c4cdc9b02d44b7`) and sets the resolver to an on-chain registry-resolver contract (`0x2a9B5787207863cf2d63d20172ed1F7bB2c9487A`). # Motivation The Chain Registry-Resolver is a smart contract that acts as a **canonical, on-chain registry** for blockchain metadata. It serves as the resolver for the `on.eth` namespace and enables applications and users to retrieve metadata for **any** blockchain using a single human-readable identifier, such as \`base\` or \`solana\`. Historically, blockchain metadata has been stored in centralized, fragmented repositories maintained by third parties. The Chain Registry-Resolver brings this metadata on-chain into a single, extensible registry, where control and update authority are delegated to the relevant chain operators. # Specification ## Additional Relevant Contracts * `RegistrarSecurityController` • `0x7dd4d97653A67C2FD7fbA0a84825eC09524D4E1b` • [Etherscan](https://etherscan.io/address/0x7dd4d97653A67C2FD7fbA0a84825eC09524D4E1b#code) Please see [https://discuss.ens.domains/t/executable-enable-root-and-registrar-security-controllers/21872](https://discuss.ens.domains/t/executable-enable-root-and-registrar-security-controllers/21872) for additional context. ## Updated Proposal This proposal includes four components. **1. Adding the DAO wallet as a controller on the \`BaseRegistrarImplementation\` smart contract through the RegistrarSecurityController.** `To: 0x7dd4d97653A67C2FD7fbA0a84825eC09524D4E1b` `Value: 0` `Calldata: 0xb229e85e000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7` Simulation: [https://www.tdly.co/shared/simulation/d0d646ce-ca82-4e1b-9777-e207292f5ee8](https://www.tdly.co/shared/simulation/d0d646ce-ca82-4e1b-9777-e207292f5ee8) **2. Registering the name \`on.eth\` to the DAO wallet.** `To: 0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85` `Value: 0` `Calldata: 0xfca247ac6460d40e0362f6a2c743f205df8181010b7f26e76d5606847fb7be7fb6d135f9000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b70000000000000000000000000000000000000000000000000000000012cc0300` Simulation: [https://www.tdly.co/shared/simulation/457f778d-110b-4ff3-a120-ac0801a7ac9a](https://www.tdly.co/shared/simulation/457f778d-110b-4ff3-a120-ac0801a7ac9a) **3. Setting the deployed \`ChainResolver\` as the resolver for**` on.eth` `To: 0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e` `Value: 0` `Calldata: 0x1896f70acabf8262fe531c2a7e8cd86e06342bc27fc0591ecd562fbac88280abc18ef8990000000000000000000000002a9b5787207863cf2d63d20172ed1f7bb2c9487a` Simulation: [https://www.tdly.co/shared/simulation/aaa4c105-0efb-4f5a-92a0-bfea8fa376c8](https://www.tdly.co/shared/simulation/aaa4c105-0efb-4f5a-92a0-bfea8fa376c8) **4. Removing the DAO wallet as a controller on the \`BaseRegistrarImplementation\` smart contract through the RegistrarSecurityController.** `To: 0x7dd4d97653A67C2FD7fbA0a84825eC09524D4E1b` `Value: 0` `Calldata: 0x246b813e000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7` Simulation: [https://www.tdly.co/shared/simulation/264b8117-23a3-47e4-b84e-be49d8ffc4b4](https://www.tdly.co/shared/simulation/264b8117-23a3-47e4-b84e-be49d8ffc4b4) ## Notes * For complete clarity, what differentiates this updated proposal from the original is that transactions 1, and 4 target **the RegistrarSecurityController**. The new security model for the \`BaseRegistrarImplementation\` proxies the addition and removal of controllers through this contract. * Explicit consideration has been given to other ongoing executable proposals. The only current proposal is [https://www.tally.xyz/gov/ens/proposal/28252712932062322633429808688780331957150867173093906455161078029287649387260](https://www.tally.xyz/gov/ens/proposal/28252712932062322633429808688780331957150867173093906455161078029287649387260) which does not modify any dependencies on which this proposal relies.

0xb8c2c29e…67d5sent to0x323a7639…b7e32026-02-25·#24,535,001·0xace13250…8038c8

# [Executable] Replace DNSSEC oracle algorithms ## Abstract This proposal replaces three DNSSEC oracle algorithms with newly deployed contracts to address the following two issues: * [feat: Replace EllipticCurve with EIP-7951 P-256 precompile for Algorithm 13](https://github.com/ensdomains/ens-contracts/pull/509) * [RSA Signature Forgery via Missing PKCS#1 v1.5 Padding Validation in ENS DNSSEC Oracle](https://github.com/ensdomains/ens-contracts-bug-62248-pr-509/blob/master/reports/REPORT.md) ## Motivation ### RSA Signature Forgery (Critical) The RSASHA256Algorithm and RSASHA1Algorithm contracts fail to validate PKCS#1 v1.5 padding structure when verifying RSA signatures. The contracts only check whether the last 32 (or 20) bytes of the decrypted signature match the expected hash, ignoring the required padding format defined in RFC 3447. This enables Bleichenbacher's 2006 signature forgery attack against DNS zones using RSA keys with low public exponents (e=3). Two ENS-supported TLDs — `.cc` and `.name` — use e=3 for their Key Signing Keys, allowing any domain under these TLDs to be fraudulently claimed on ENS without DNS ownership. The attack is permissionless, costs approximately 100k gas, and is difficult to detect as the forged proofs appear legitimate. Remediation requires governance intervention. This vulnerability class has resulted in critical CVEs in other systems (CVE-2006-4339 in OpenSSL, CVE-2014-1568 in NSS, CVE-2016-1494 in python-rsa). ### P-256 Precompile Upgrade (Gas Optimization) The current P256SHA256Algorithm contract uses a Solidity-based EllipticCurve library for signature verification, consuming approximately 200,000+ gas per operation. EIP-7951 introduces a native P-256 precompile (at address `0x100`) which reduces this to approximately 3,500 gas — a ~98% reduction. This upgrade takes advantage of the precompile available after the Fusaka hardfork. ## Specification ### Description And newly deployed contract information is as follows * RSASHA1\_ADDRESS = [0x58E0383E21f25DaB957F6664240445A514E9f5e8](https://etherscan.io/address/0x58E0383E21f25DaB957F6664240445A514E9f5e8) * RSASHA256\_ADDRESS = [0xaee0E2c4d5AB2fc164C8b0Cc8D3118C1c752C95E](https://etherscan.io/address/0xaee0E2c4d5AB2fc164C8b0Cc8D3118C1c752C95E) * P256SHA256\_ADDRESS = [0xB091C4F6FAc16eDDA5Ee1E0f4738f80011905878](https://etherscan.io/address/0xB091C4F6FAc16eDDA5Ee1E0f4738f80011905878) Steps overview are as follows * 1-3. DNSSECImpl: `setAlgorithm` of RSASHA1, RSASHA256 (RSA Signature Forgery patch), P256SHA256 (Using p-256 precompile) to newly deployed contracts * 4-5. Root: `setSubnodeOwner` of `cc` and `name` to 0 * 6-7: DNSRegistrar: Call `enableNode` for .cc and .name to re-enable them for DNSSEC. DNSSEC\_IMPL\_ADDRESS=0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5 ROOT\_ADDRESS=0xaB528d626EC275E3faD363fF1393A41F581c5897 DNS\_REGISTRAR\_ADDRESS = 0xB32cB5677a7C971689228EC835800432B339bA2B ### Transactions Summary This proposal contains **7** transaction(s) to be executed by the ENS DAO Timelock. | # | Contract | Function | Description | | - | ------------ | ----------------- | ------------------------------------------ | | 1 | DNSSECImpl | `setAlgorithm` | Set Algorithm of RSASHA1 to new address | | 2 | DNSSECImpl | `setAlgorithm` | Set Algorithm of RSASHA256 to new address | | 3 | DNSSECImpl | `setAlgorithm` | Set Algorithm of P256SHA256 to new address | | 4 | Root | `setSubnodeOwner` | Set owner of `cc` to 0 | | 5 | Root | `setSubnodeOwner` | Set owner of `name` to 0 | | 6 | DNSRegistrar | `enableNode` | Re-enable `cc` for DNSSEC | | 7 | DNSRegistrar | `enableNode` | Re-enable `name` for DNSSEC | ## Detailed Transaction Information ### Transaction 1: Set Algorithm of RSASHA1 to new address **Target:** DNSSECImpl **Address:** `0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5` **Function:** `setAlgorithm` **Parameters:** * `id` : 5 * `algo`: `0x58E0383E21f25DaB957F6664240445A514E9f5e8` **Encoded Calldata:** `0x020ed8d3000000000000000000000000000000000000000000000000000000000000000500000000000000000000000058e0383e21f25dab957f6664240445a514e9f5e8` ### Transaction 2: Set Algorithm of RSASHA256 to new address **Target:** DNSSECImpl **Address:** `0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5` **Function:** `setAlgorithm` **Parameters:** * `id` : 8 * `algo`: `0xaee0E2c4d5AB2fc164C8b0Cc8D3118C1c752C95E` **Encoded Calldata:** `0x020ed8d30000000000000000000000000000000000000000000000000000000000000008000000000000000000000000aee0e2c4d5ab2fc164c8b0cc8d3118c1c752c95e` ### Transaction 3: Set Algorithm of P256SHA256 to new address **Target:** DNSSECImpl **Address:** `0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5` **Function:** `setAlgorithm` **Parameters:** * `id` : 13 * `algo`: `0xB091C4F6FAc16eDDA5Ee1E0f4738f80011905878` **Encoded Calldata:** `0x020ed8d3000000000000000000000000000000000000000000000000000000000000000d000000000000000000000000b091c4f6fac16edda5ee1e0f4738f80011905878` ### Transaction 4: setSubnodeOwner of `cc` to 0 **Target:** Root **Address:** `0xaB528d626EC275E3faD363fF1393A41F581c5897` **Function:** `setSubnodeOwner` **Parameters:** * `label` : `0x68ce0763ca729318b714b0cf33478e4e228e19f58aeaf12cfa1535c9d4bbcaf9` * `owner`: `0x0000000000000000000000000000000000000000` **Encoded Calldata:** `0x8cb8ecec68ce0763ca729318b714b0cf33478e4e228e19f58aeaf12cfa1535c9d4bbcaf90000000000000000000000000000000000000000000000000000000000000000` ### Transaction 5: setSubnodeOwner of `name` back to DNS\_REGISTRAR\_ADDRESS **Target:** Root **Address:** `0xaB528d626EC275E3faD363fF1393A41F581c5897` **Function:** `setSubnodeOwner` **Parameters:** * `label` : `0x2361458367e696363fbcc70777d07ebbd2394e89fd0adcaf147faccd1d294d60` * `owner`: `0x0000000000000000000000000000000000000000` **Encoded Calldata:** `0x8cb8ecec2361458367e696363fbcc70777d07ebbd2394e89fd0adcaf147faccd1d294d600000000000000000000000000000000000000000000000000000000000000000` ### Transaction 6: Re-enable `cc` for DNSSEC **Target:** DNSRegistrar **Address:** `0xB32cB5677a7C971689228EC835800432B339bA2B` **Function:** `enableNode` **Parameters:** * `domain` : `0x02636300` **Encoded Calldata:** `0x6f951221000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000040263630000000000000000000000000000000000000000000000000000000000` ### Transaction 7: Re-enable `name` for DNSSEC **Target:** DNSRegistrar **Address:** `0xB32cB5677a7C971689228EC835800432B339bA2B` **Function:** `enableNode` **Parameters:** * `domain` : `0x046e616d6500` **Encoded Calldata:** `0x6f95122100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000006046e616d65000000000000000000000000000000000000000000000000000000`

0x76a6d08b…bbb8sent to0x323a7639…b7e32026-02-17·#24,477,942·0xf409983f…a7767b

This domain will not be used by end users, so it doesn't have the explicit necessity non technical. In private, I suggested cid.eth (chain ID), which was registered later by clowes.eth. That’s also a strong option and, importantly, doesn’t require a DAO proposal. I’d personally prefer to avoid going down the on-chain proposal route here. It could open the door to similar requests in the future, and one- and two-letter domains can become a meaningful revenue source for the DAO.

0xb8c2c29e…67d5sent to0x323a7639…b7e32026-02-12·#24,441,402·0x53ce413c…0028ac

# [EP 6.34] Register on.eth to the ENS DAO wallet and set the resolver # Previous Context * [\[Temp Check\] Registration of on.eth to support interoperable addressing standards](https://discuss.ens.domains/t/temp-check-registration-of-on-eth-to-support-interoperable-addressing-standards/21541) * [\[Temp Check\] l2.eth to Enable Chain-Specific Addresses](https://discuss.ens.domains/t/temp-check-l2-eth-to-enable-chain-specific-addresses/20862) * [Allowing the DAO to manually issue .eth 2LDs, including 1- and 2- character ones](https://discuss.ens.domains/t/allowing-the-dao-to-manually-issue-eth-2lds-including-1-and-2-character-ones/20851) # Description This proposal registers the \`on.eth\` ENS name to the ENS DAO wallet (`0xfe89cc7abb2c4183683ab71653c4cdc9b02d44b7`) and sets the resolver to an on-chain registry-resolver contract (`0x2a9B5787207863cf2d63d20172ed1F7bB2c9487A`). # Motivation The Chain Registry-Resolver is a smart contract that acts as a **canonical, on-chain registry** for blockchain metadata. It serves as the resolver for the `on.eth` namespace and enables applications and users to retrieve metadata for **any** blockchain using a single human-readable identifier, such as \`base\` or \`solana\`. Historically, blockchain metadata has been stored in centralized, fragmented repositories maintained by third parties. The Chain Registry-Resolver brings this metadata on-chain into a single, extensible registry, where control and update authority are delegated to the relevant chain operators. # Specification ## Relevant Contracts *  \`wallet.ensdao.eth\` • `0xfe89cc7abb2c4183683ab71653c4cdc9b02d44b7` * \`registry.ens.eth\` • `0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e`  * \`registrar.ens.eth\` • `0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85` * ChainResolver (Proxy)\` • `0x2a9B5787207863cf2d63d20172ed1F7bB2c9487A` * \`ChainResolver (Implementation)\` • `0x97df70ef350a5d2f606e0baf6d38de2ec26f7290` ### ChainResolver The \`ChainResolver\` GitHub repo can be found here: [https://github.com/unruggable-labs/chain-resolver.](https://github.com/unruggable-labs/chain-resolver.) In depth documentation outlining the functionality, interfaces, and implementation approach for the smart contract is available here: [https://github.com/ensdomains/docs/pull/508/changes.](https://github.com/ensdomains/docs/pull/508/changes.) ## Proposal This proposal includes four components. **1. Adding the DAO wallet as a controller on the \`BaseRegistrarImplementation\` smart contract.** `To: 0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85` `Value: 0` `Calldata: 0xa7fc7a07000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7` Simulation: [https://www.tdly.co/shared/simulation/709dde20-78e2-47e0-a952-d80d9772e5eb](https://www.tdly.co/shared/simulation/709dde20-78e2-47e0-a952-d80d9772e5eb) **2. Registering the name \`on.eth\` to the DAO wallet.** `To: 0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85` `Value: 0` `Calldata: 0xfca247ac6460d40e0362f6a2c743f205df8181010b7f26e76d5606847fb7be7fb6d135f9000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b70000000000000000000000000000000000000000000000000000000012cc0300` Simulation: [https://www.tdly.co/shared/simulation/2b0f1049-6820-4661-88bf-3b9fbee8ae84](https://www.tdly.co/shared/simulation/2b0f1049-6820-4661-88bf-3b9fbee8ae84) **3. Setting the deployed \`ChainResolver\` as the resolver for** \*\*\*\* `on.eth` The Resolver proxy is deployed at `0x2a9B5787207863cf2d63d20172ed1F7bB2c9487A`. `To: 0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e` `Value: 0` `Calldata: 0x1896f70acabf8262fe531c2a7e8cd86e06342bc27fc0591ecd562fbac88280abc18ef8990000000000000000000000002a9b5787207863cf2d63d20172ed1f7bb2c9487a` Simulation: [https://www.tdly.co/shared/simulation/291142ff-d41a-45ab-8263-34fad6b781b5](https://www.tdly.co/shared/simulation/291142ff-d41a-45ab-8263-34fad6b781b5) **4. Removing the DAO wallet as a controller on the \`BaseRegistrarImplementation\` smart contract.** `To: 0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85` `Value: 0` `Calldata: 0xf6a74ed7000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7` Simulation: [https://www.tdly.co/shared/simulation/e2430d87-5475-4cea-a320-0e44640b1d3d](https://www.tdly.co/shared/simulation/e2430d87-5475-4cea-a320-0e44640b1d3d) # Notes The Registry-Resolver contract is currently owned by an Unruggable controlled deployment wallet (`0x81c11034fe2b2f0561e9975df9a45d99172183af`). This temporary ownership is limited to initial bootstrapping of chain identifiers and will be transferred to a neutral multisig once the initial registry state is established.

0x9186aaa3…b6dasent to0x323a7639…b7e32026-02-11·#24,435,108·0xb1ec4ab5…f0f870

Routine treasury operation to enable execution of already-approved Working Group funding. Internal transfer with no policy implications and overwhelming community support.

0xb8c2c29e…67d5sent to0x323a7639…b7e32026-02-11·#24,434,380·0xf5a11cd9…dd61df

# Enable Root and Registrar Security Controllers ## Abstract This proposal enables two break-glass security controllers: * `RootSecurityController`, which can disable a TLD by taking ownership and clearing its resolver. * `RegistrarSecurityController`, which can disable a .eth registrar controller. ## Motivation At present, remediating a compromise or security vulnerability in critical parts of the ENS contracts requires a DAO vote, which takes a minimum of 9 days. This provides a significant window during which an attacker could take advantage of a vulnerability with no way to stop it. This proposal introduces two security controllers, which permit the security council to disable ENS functionality in an emergency, without granting them broad powers over the ENS system. Enabling the `RootSecurityController` allows rapid deactivation of a compromised TLD by transferring its ownership to the controller and clearing its resolver. Enabling the `RegistrarSecurityController` allows the security council to disable problematic registrar controllers, while still retaining DAO control over the base registrar. These 'negative' powers are in line with the security council's existing remit to veto DAO votes, but constitute an expansion of their powers; unlike the veto power, this one is not time-limited and would require a DAO vote to remove. However, we believe these powers are proportional and necessary. As they are subject to DAO review, the DAO can easily countermand any changes made by the council and/or remove the council's ability to make further changes. ## Specification ### Description Batch transaction for ENS DAO execution to enable and configure the security controllers. ### Transactions Summary This proposal contains **4** transactions to be executed by the ENS DAO Timelock. | # | Contract | Function | Description | | - | ----------------------------- | ------------------- | ------------------------------------------------------------------------------- | | 1 | Root | `setController` | Enable `RootSecurityController` as a root controller | | 2 | Base Registrar | `transferOwnership` | Transfer registrar ownership to `RegistrarSecurityController` | | 3 | Root Security Controller | `transferOwnership` | Transfer ownership of `RootSecurityController` to Security Council Multisig | | 4 | Registrar Security Controller | `setController` | Add Security Council Multisig as a controller of `RegistrarSecurityController` | ## Detailed Transaction Information ### Transaction 1: Enable RootSecurityController on Root **Target:** Root **Address:** `0xaB528d626EC275E3faD363fF1393A41F581c5897` **Function:** `setController` **Parameters:** * `address controller`: `0x95123B1ec97df0d3c52c728aB38FBbb7A3ca6da6` * `bool enabled`: `true` **Encoded Calldata:** `<TBD>` *** ### Transaction 2: Transfer Base Registrar ownership to RegistrarSecurityController **Target:** Base Registrar Implementation **Address:** `0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85` **Function:** `transferOwnership` **Parameters:** * `address newOwner`: `0x7dd4d97653A67C2FD7fbA0a84825eC09524D4E1b` **Encoded Calldata:** `<TBD>` *** ### Transaction 3: Transfer ownership of `RootSecurityController` to Security Council Multisig **Target:** RootSecurityController **Address:** `0x95123B1ec97df0d3c52c728aB38FBbb7A3ca6da6` **Function:** `transferOwnership` **Parameters:** * `address newOwner`: `0xaA5cD05f6B62C3af58AE9c4F3F7A2aCC2Cdc2Cc7` **Encoded Calldata:** `<TBD>` *** ### Transaction 4: Add Security Council Multisig as a controller of `RegistrarSecurityController` **Target:** RegistrarSecurityController **Address:** `0x7dd4d97653A67C2FD7fbA0a84825eC09524D4E1b` **Function:** `setController` **Parameters:** * `address controller`: `0xaA5cD05f6B62C3af58AE9c4F3F7A2aCC2Cdc2Cc7` * `bool enabled`: `true` **Encoded Calldata:** `<TBD>` *** ## Notes / Assumptions * `RootSecurityController` and `RegistrarSecurityController` are already deployed. * Controller ownership is already held by the DAO prior to execution.

0xac50ce32…c039sent to0x323a7639…b7e32026-02-09·#24,419,383·0xb85d07a2…5cb62b

https://discuss.ens.domains/t/ep-6-32-executable-transfer-2-5m-usdc-from-endowment-to-wallet-ensdao-eth/21882/5?u=clowes.eth

0x1d5460f8…6359sent to0x323a7639…b7e32026-02-07·#24,405,279·0x3bbb8697…809a96

# [EP 6.32] [Executable] Transfer $2.5M USDC from Endowment to wallet.ensdao.eth # Abstract Following the approval of the [\[Executable\] Collective Working Group Funding Request (Oct 2025)](https://www.tally.xyz/gov/ens/proposal/77525093718307720477107269225240955392442633055266271196124066559357053541713), the transactions included in that proposal cannot fully execute due to insufficient USDC in the ENS DAO timelock (`wallet.ensdao.eth`). This proposal enables a **one-time internal transfer of 2.5M USDC** from the ENS Endowment to the ENS DAO timelock (`wallet.ensdao.eth`) to ensure execution of already approved governance decisions. It is an operational treasury action designed to maintain execution continuity without requiring ETH sales under current market conditions. # Motivation The Working Group funding proposal was submitted on January 22, 2026, and its execution tests were performed against the block in which it was created (block 24293146). At that time, sufficient USDC was available. On January 25, 2026, Superfluid wrapped approximately 616K USDC using the AutoWrap functionality to fund SPP streams. When the proposal became ready for execution, it required 959K USDC, while the timelock held approximately 505K USDC. As a result, the approved proposal cannot execute as intended. This creates immediate operational risk, including: * SPP streams running out of funds and triggering liquidation on Superfluid * Labs and service providers being unable to claim approved streams * Failure of otherwise valid proposals due to insufficient timelock balance * Increased dependence on additional governance cycles for routine treasury operations Historically, the DAO has sold ETH to meet USDC-denominated obligations. However, given current market conditions, selling ETH to cover this shortfall is suboptimal. The ENS Endowment holds sufficient USDC reserves to cover near-term obligations. An internal transfer avoids unnecessary market impact and preserves overall treasury flexibility. This action enables execution of previously approved governance decisions, maintains operational continuity, and provides the Meta-Governance Working Group time to develop improved processes to prevent similar situations in the future. No new budget or funding program is created by this proposal. # Specification * Transfer **2,500,000 USDC** from the **ENS Endowment Safe** to **wallet.ensdao.eth (Timelock)**. **Addresses** * wallet.ensdao.eth (Timelock): `0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7` * ENS Endowment Safe: `0x4F2083f5fBede34C2714aFfb3105539775f7FE64` *** Acknowledgements: thanks to coltron.eth and the kpk team for the readiness and support to solve this together.

0x534631bc…42cfsent to0x323a7639…b7e32026-02-02·#24,366,244·0x68a3aa5a…7536f6

The co-mingling of this with steward elections caused disruption. https://discuss.ens.domains/t/temp-check-ens-retro-an-ens-dao-retrospective-stakeholder-analysis/21648/50

1-50 of 344