Blockful - service provider reports and updates

[blockful]

We’ll use this thread to post all our past and future quarters updates under the scope of ENS service provider.

Q1/Q2 report

Summary

Our journey began with our proposal to the ENS DAO, where we outlined our vision for enhancing ENS. The challenge we decided to first work on was related to off-chain and L2 resolvers. After Vitalik’s tweet, it became clear that it was important.

Our approach is to create solutions and standards that enhance the whole ecosystem and do not fragment it by competing with other platforms. We want to support both existing and new builders.

Overview

Implementing a standard, not creating a competing platform. Let’s understand what that means:

Namestone is a service that creates and manages off-chain subdomains through an API. Data is stored in a database. Before performing any write operation, you should read their docs and know how to communicate with the API.

This is true for every other subdomain issuer you see: cb.id, base.eth, linea.eth, namespace, etc.

By having projects that use and contribute to this standard, we can build applications that can interact with all of these providers without needing to understand the implementation details for each one.

Success in this initiative means having significant players adopting the standard and having the ENS dapp and ensjs implementing the ENSIP.

Transparency: build in public

This is one of blockful’s core values. Not only are the repos open-source, but so are the task management, planning, and track records. You can see all the tasks done in the first semester, with all card descriptions, related pull requests, team discussions, and estimates keeping all the development and research contracted by the DAO accountable.

Foundation and Research

Following the proposal, we dove deep into research on Offchain ENS considering it would bring the most value to the ecosystem. Our team studied the intricacies of CCIP-Read (EIP-3668) implementation and investigated the potential of Cross Chain Write Deferral (EIP-5559). This foundational research shaped our understanding and approach to off-chain solutions.

We then moved into the development phase, creating the initial version of our Offchain Resolver. This was a significant step forward, translating our research and design into a functional implementation. During this process, we encountered a challenge with the Optimism integration due to updates in EVM Gateway data verification (addition of Fault Proofs on OP). We then pivoted our focus to Arbitrum, ensuring continued progress in our off-chain resolver development.

Good standards and research can only be done if you get hands-on, so we explored each off-chain resolver step to understand improvement opportunities.

Technical Contributions

External resolver (repo)

The goal of the external resolver repo is to be the industry standard for off-chain domains (using DBs and L2s), implementing the new ENSIP and past ENSIP support, with interoperability as the core value. This led us to the development of our own version of the CCIP-Gateway based on the Chainlink implementation as well as contract interfaces that made easier the implementation for multiple contexts.

We then launched our first version of the Arbitrum Resolver with CCIP-Read support, followed by the implementation of the Arbitrum Verifier based on the EVM Gateway. This further solidified our off-chain resolver’s capabilities within the Arbitrum ecosystem.

Go ENS (pull request)

Our team contributed to the Go-ENS library, adding support for CCIP-Read and ENSIP-10 to improve the broader ENS ecosystem. Also, a public bounty of 0.5 ETH helped prioritize it.

User-Facing Developments (repo)

Recognizing the importance of user accessibility, we began the development of the nameful dapp. This initiative aimed to bring our off-chain solutions closer to end-users, making them more accessible and user-friendly, as well as serving as proof-of-concepts for both the off-chain reading and writing standards we’re developing.

Our work on the Database Resolver saw several key achievements. We completed the EIP-5559 implementation, achieved the first subdomain registration using this protocol, and successfully deployed the resolver to the Sepolia testnet. These milestones marked significant progress in our off-chain capabilities.

To enhance user interaction with our solutions, we launched the domain management UI on nameful. This interface made it easier for users to manage their ENS domains using our off-chain features.

Expanding Capabilities

Our Arbitrum integration reached new heights as we deployed the Arbitrum Resolver to Sepolia testnet and registered the first subdomain on Arbitrum through EIP-5559. These achievements demonstrated the practical application of our off-chain solutions in a Layer 2 environment.

We then enhanced our Gateway functionality by implementing support for writing multicall. This improvement increased the efficiency of our off-chain operations, allowing for more complex interactions.

In a significant step towards bridging on-chain and off-chain capabilities, we registered the first 2LD on L1 with records stored in the database. This milestone showcased the seamless integration between traditional ENS infrastructure and our off-chain solutions.

Standards and Specifications

As already mentioned, the major purpose of the external resolver implementation is establish a standardized flow for managing offchain writing in the ENS ecosystem, creating an universal interface that can be applied across various scenarios of offchain domain storage.

The key value the standard brings is the communication with the L1 redirecting the request to the given destination by relying on the EIP-5559. The complete flow can be visualized on the following diagrams:

L2 subdomain registering [WIP]

Database subdomain registering

During the development of the nameful dapp, we faced a challenge in integrating offchain domains with existing ENS components. This led us to propose improvements to the existing ENSIP-16 (Offchain Metadata API). Our proposal aims to enhance the developer experience by reducing the number of requests required to fetch all the data of a given domain. The proposal is currently under discussion in the ENS community, and we’re actively gathering feedback.

Finally, we drafted the first version of what we’ve called Wildcard Writing ENSIP, a standard interface that standardizes the off-chain writing methods. This contribution, which has yet to be posted on the ENS forum, aims to achieve the interoperability we mentioned at the beginning of the report.

Community education

As an initiative to educate and involve the Latin American community in the ENS and ETH ecosystem, we conducted a workshop at the ETH Samba hackathon in Rio de Janeiro. The workshop showcased major ENS features and provided a step-by-step guide on how to set up a domain.

More to come on that in the following months.

Governance security

As mentioned in our proposal, we are reviewing the call data for each executable proposal. EP 5.12 was the only one that wasn’t possible due to its size and details. We will create a more official report platform through a forum thread to make sure this work is accountable.

Other contributions not related to service provider scope

Being closer to ENS as an organization allowed our research team to also analyze the governance in depth (which is our primary expertise as blockful), which led to research that resulted in the creation of the Security Council. We’re finishing a blog post that will outline more of this work for securing the DAO.

Looking Ahead

As we continue our journey, we remain committed to:

• Refining and formalizing our off-chain standards based on community feedback.
• Working on the adoption of these standards with major players, ENS app and ENSjs.
• Expanding partnerships and integrations to increase ENS adoption.
• Understand what brings the most value for ENS and the community, adapting our protocol research and scope of work for optimal value generation.

We’re grateful for the support of the ENS DAO and community throughout this journey. We look forward to further collaboration as we work together to enhance and expand the ENS ecosystem.

[5pence.eth]

Good update. Thanks @blockful.

@blockful

Governance security

As mentioned in our proposal, we are reviewing the call data for each executable proposal. EP 5.12 was the only one that wasn’t possible due to its size and details. We will create a more official report platform through a forum thread to make sure this work is accountable.

This is a great service to the DAO.

Meta-governance is encouraging proposals to be clear, predictable, and have a uniform matching post in the forum that can be read and commented on before the proposal goes live.

It would be great if we could establish an expectation that on all executable proposals, Blockful will comment on the respective forum post with your review of the call data.

[blockful]

Thanks for the feedback, Spence! It’s a great suggestion, and we’ll do that or a delegation platform where we post reviews of EPs and reasoning for votes.

[blockful]

Q3 Report

Summary

Building on our previous achievements, we’ve made significant progress in implementing and standardizing off-chain and L2 resolvers. We continue to prioritize creating solutions and standards that enhance the user experience and developer experience across the ENS ecosystem.

Major Updates and Achievements

ENSIP: Wildcard Writing Interface

We’ve drafted an ENSIP that proposes a standardized Wildcard Writing interface for registering and managing offchain domains within the ENS ecosystem.

Key aspects of the ENSIP include:

1. Standardized Methods: The proposal outlines methods for domain registration, transferring, and setting records, ensuring a consistent approach to offchain domain management.
2. L1 Resolver as entrypoint: The specification uses the Resolver deployed on Ethereum as an entry point for offchain calls, redirecting these calls to the respective destination (L2 or database). The same approach was used by the well-established CCIP-Read.
3. Support for Database and L2 Implementations: The ENSIP provides considerations for both database and Layer 2 implementations, allowing for flexible offchain storage solutions.
4. Key Functions:
   • registerParams: For obtaining registration parameters
   • register: For registering subdomains
   • transfer: For transferring domains
   • multicall: For batch operations on ENS records
   • commit: For enabling the commit/reveal strategy for offchain subdomain
5. Integration with existing standards: The proposal leverages EIP-5559 for offchain writing and maintains compatibility with existing ENS components.

This ENSIP represents a significant step forward in standardizing offchain domain management within the ENS ecosystem. It provides a framework that will enable consistent implementation across various offchain storage solutions, improving interoperability and user experience.

We aim for going from a protocol-based client implementatation to a standardized version of it, dramatically reducing the complexity required from the client.

Integration with Major Ecosystem Players

A standard has no value if there is no adoption. Our latest efforts are around validating and building it with the ecosystem:

• Coinbase
• Namespace
• Linea
• ENS Labs

The integration process is ongoing, at various stages, between feedback and testing. We’re focusing on maintaining consistency with existing ENS standards while adapting to the unique features of each platform, exploring potential synergies between different approaches to create a more robust and versatile interface.

Deployment of ENS Contracts on Arbitrum

We’ve successfully deployed the ENS contracts on Arbitrum as a proof of concept for the Wildcard Writing L2 implementation. This interim step marks a significant milestone in our efforts to extend ENS functionality to Layer 2 solutions and serves as a valuable testing ground. The lessons learned from this implementation will be invaluable in ensuring these standards can be used in different use cases, players, and can also be integrated into the upcoming ENS architecture.

Key aspects of this deployment:

• Successful implementation of ENS contracts on Arbitrum
• Validation of EIP-5559 L2 implementation in a real-world scenario
• Establishment of a foundation for future L2 and database integrations

Indexing of ENS Events on Arbitrum

We’ve successfully indexed ENS events on Arbitrum, which are now used for the ENSIP-16 Metadata API for Arbitrum. This development enhances our ability to retrieve off-chain ENS data efficiently. By indexing events on Arbitrum, we’ve extended the functionality of the Metadata API to L2 environments, improving the client’s data fetching of offchain domains.

Implications of this achievement:

• Enhanced data retrieval capabilities for L2 implementations
• Enable the nameful (our dapp) integration with domains stored on Arbitrum

User-Facing Developments

The nameful dapp has seen substantial improvements, now handling both L2 and database registering and management of subdomains. This enhancement provides users with a more comprehensive and flexible tool for managing their ENS domains across different environments.

Key improvements include:

• Support for L2 subdomain registration and management
• Standardization of the database-stored domains with the same interface as the L2
• Enhanced user interface for managing domains across different storage solutions

Community Education

We conducted a meetup and workshop about Web3 and ENS at the Curitiba Blockchain Weekend. This initiative continues our commitment to educating and involving communities in the ENS and Ethereum ecosystems, with a particular focus on expanding our reach in Latin America.

This initiative was made possible thanks to the Gitcoin round funding. The whole summary of the event can be found at the Blockful’s blog.

Key highlights:

• Introduced ENS concepts to a broader audience
• Provided hands-on experience with ENS tools and interfaces
• Debate regarding governance
• Gathered feedback from potential users and developers in the Latin American blockchain community

Looking Ahead

Our current focus is on integrating our developed standards with major players’ implementations and gather feedback from the ENS community. This effort aims to increase adoption of our standardized approaches and further unify the ENS ecosystem.

We remain committed to:

• Refining and promoting the off-chain and L2 standards based on community feedback and real-world implementation experiences.
• Expanding partnerships and integrations to increase ENS adoption.
• Further developing and promoting the ENSIP for Wildcard Writing interface.
• Enhancing our user-facing tools, like the nameful dapp, to provide seamless management of ENS domains across different storage solutions.

We’re grateful for the ongoing support of the ENS DAO and community. We look forward to further collaboration as we work together to enhance and expand the ENS ecosystem.

[blockful]

Q4 Report

Summary

In this development cycle, we’ve focused on making ENS domains more powerful and easier for everyone to use. Here’s what’s new:

As highlighted during frENSday by Jeff Lau, most ENS domains today operate through off-chain systems, showing how crucial this technology is for ENS’s success. Building on this foundation, we’re introducing new standards to make domain management more seamless and user-friendly.

First, we’ve created a simpler way for doing transactions between different chains by establishing a behavior that the contracts should implement, making it easier for dapps to integrate regardless of the use case. We named it Operation Router because it acts as an actual router, redirecting the request to the given contract or API.

Second, we’ve applied this router strategy to the ENS use case. With the standard, any dapp can support domain management by following the proposed flow, features that currently require users to access multiple dapps to manage their offchain domain. The standard adoption means that the ENS dapp would be able to manage any kind of domains with the same interface it handles Ethereum ones.

We’ve also launched ens.rent, allowing domain owners to rent out their unused domains easily and securely. This opens up new opportunities for both domain owners to earn from their domains and for others to use ENS domains temporarily without having to buy them outright.

These improvements make ENS more accessible and valuable for everyone, helping it grow from a simple naming system into a more powerful and flexible platform for the future of the internet.

Operation Router EIP Release

The Operation Router EIP represents a significant advancement in offchain data management standards. This implementation is the result of multiple iterations with the ENS community and Nick Johnson (@arachnid) aiming to improve the existing strategies for offchain transactions by transforming the traditional two-transaction flow proposed by the ERC-5559 into a streamlined view call and transaction system.

The standard centers around the getOperationHandler view function, effectively turning the any contract into a router that redirects operations to either onchain or offchain handlers. This standalone solution extends beyond ENS protocol applications, prompting its development as an EIP to serve as the foundation for the proposed ENSIP. In the ENS ecosystem, the resolver deployed to Ethereum would serve as the entrypoint for all the transactions related to offchain domains.

Wildcard Writing ENSIP Update

The Wildcard Writing ENSIP has been enhanced to leverage the Operation Router infrastructure. The latest version in the ENSIPs GitHub repository introduces optimized write operations across the ENS ecosystem.

The specification has been enhanced to support two distinct operational flows. The onchain flow facilitates direct interaction with smart contracts deployed across different layers, while the offchain flow manages database operations through a secure gateway system. This dual approach ensures efficient data management while maintaining strong security guarantees through typed signatures.

There are multiple interfaces that can be inherited by any contract creating a opt-in architecture where each domain provider is able to provide features as intended, e.g. enabling the commit/reveal strategy for registration or providing ways for domains to be transferred.

struct RegisterRequest {
    bytes name;
    address owner;
    uint256 duration;
    bytes32 secret;
    address resolver;
    bytes extraData;
}

interface OffchainRegister {

    struct RegisterParams {
        uint256 price;
        bool available;
        address token;
        uint256 commitTime;
        bytes extraData;
    }

    function registerParams(
        bytes calldata name,
        uint256 duration
    )
        external
        view
        returns (RegisterParams memory);

    function register(RegisterRequest calldata request) external payable;

}

interface OffchainTransferrable {

    function transferFrom(
        bytes calldata name,
        address owner,
        address newOwner
    )
        external;
}

interface OffchainCommitable {

    function makeCommitment(RegisterRequest calldata request)
        external
        pure
        returns (bytes32 commitHash);

    function commit(bytes32 commitment) external;
    
}

ENS Rent Platform Release

ens.rent introduces a comprehensive rental system supporting both wrapped (ERC1155) and unwrapped (ERC721) ENS names. Built on BaseRegistrar, NameWrapper, and ENSRegistry components, the platform features per-second pricing, customizable duration parameters, and automated custody management.

Implementation Progress

ENSjs Updates

Although the Wildcard Writing standard still under review process, the team has implemented Wildcard Writing functionality in the ENSjs fork repository, expanding the JavaScript library’s capabilities an making it easier for the community adoption. This implementation provides developers with enhanced tools for managing write operations across different layers of the ENS ecosystem, ensuring backward compatibility.

The end goal is to have the standard being handled on every call that reverts with the specified error, redirecting the request to the given source, the same way the clients do for the CCIP-Read.

Throughout the research of the ENSjs implementation, the team has found an opportunity to contribute to the library by implementing a subdomain registration functionality.

DAO Proposals

The ENS DAO proposals calldata validation implementation strengthens governance process security and reliability through comprehensive validation procedures.

Future Development

Current development priorities include:

1. Operation Router protocol optimization based on Ethereum community feedback
2. Provide a clear path for the domain providers to adopt the Wildcard Writing standard
3. Enhanced rental platform

These developments mark significant progress in enhancing the ENS ecosystem’s capabilities and user experience.

[blockful]

2025 Q1 / Q2 Report

Disclaimer: The SPP1 year started in February, and the SPP2 year started in May. From now on, we will report based on calendar quarters rather than the program’s start dates. This makes it easier to track progress over time and keeps our communication consistent with ENS DAO’s broader activity cycles.

Summary

Following our renewal as a Service Provider for ENS DAO, blockful continues its work across key areas of governance security and protocol improvement.

During Q1 and Q2, we delivered timely calldata reviews, notification system is live (beta version), and shipped significant improvements to Anticapture, including a feature called data tables that increase transparency around voting power, participation, and delegation flow.

While ENSIP-related work is in progress with clear next step to move forward on the road to production and adoption.

---

ENSIP-20

The ENSIP published but might have some small updates to be finished. A PR on ENSjs is open and in the coming month we’ll coordinate with Labs to advance the implementation on ENS manager app and ENSv2, unlocking a better and unified experience for managing domain and records.

Quarter	KPIs	Status
Q1	ENSIP specification documentation completed - Initial ENSjs integration live

---

Calldata Review

Between Q1 and Q2, blockful reviewed all proposal calldatas submitted to ENS governance, completing each review within the expected timeframes.

Proposal	Github	Notes
[EP 6.1] [Executable] Convert 6,000 ETH to USDC for DAO Operating Expenses	Review	4 days
[EP 6.2] [Executable] Endowment expansion (3rd tranche)	Review	1 week
[EP 6.7] [Executable] Transfer .ceo TLD to the DNSSEC registrar	Review	5 days
[EP 6.8] [Executable] Endowment permissions to karpatkey - Update #5	Review	2 weeks
[EP 6.8] [Executable] Revoke root controller role from legacy ENS multisig	Review	1 day - It was 6.8 on the forum, marked as 6.7 on Tally, but it was supposed to be 6.9.
[EP 6.11] [Executable] Collective Working Group Funding Request (April 2025)	Review	1 day - A mistake happened on our side, you can find the postmortem here.
[EP6.12] [Executable] Set resolver for .ceo TLD	Review	1 day
[EP 6.13] [Executable] - Service Provider Program Season 2 Implementation	Review	2 days
[Executable] Enable L2 Reverse Registrars and new .eth registrar controller	Review	2 weeks - The submitted proposal, 6 of them use parameters that differs from the tests and calldata published, check it here.
[Executable] Transfer .locker TLD to Orange Domains LLC	Review	1 week
[Executable] Reactivate SPP2 streams	Review	4 days
[Executable] Adopt The SEAL Safe Harbor Agreement	Review	1 day

Two reviews are worth highlighting:

1. EP 6.11 forum review mistake

We made a mistake in properly validating the calldata as posted. Instead of reviewing the calldata attached to the forum post, we mistakenly generated and tested a new version internally. Although the onchain submission was correct and safely verified before execution, the purpose of the forum-stage validation was missed. If the discrepancy had gone unnoticed, the proposal would have requested less capital than intended and required resubmission.

We shared a detailed explanation of this event on the ENS forum and took immediate steps to improve our internal process, including the introduction of pair reviews and clearer documentation between stages. More suggestions to come on the governance process as well.*

2. EP 6.16 error prevention

We identified a problem on a live proposal. The transaction simulation on Tenderly passed, but if executed, the proposal would not have achieved its intended goal. We recommended that the DAO vote against the live proposal and encouraged the author to resubmit with corrected calldata. And that’s exactly how these reviews add value to the DAO.

You can read more details here.
Tweet from @ENS_DAO

Quarter	KPIs	Status
Q1*	Response to 100% of tagged proposals within SLA

---

Anticapture

We continue to improve the dashboard, bringing more reliable and deep data about security, token holders and delegates. A major feature released was data tables, bringing accessibility to important information.

It offers a clear view of governance by combining token holder and delegate information with metrics like average vote timing, percentage of “for” votes, token balance variation, delegation changes, delegator balance increase and decrease, voting power, proposals voted on, and many more.

Having this context next to risk indicators allows us to better understand not just where voting power sits, but how it behaves. It also gives a stronger sense of when and how different actors are participating, something that’s hard to grasp when security data, token holder stats, and delegate actions are viewed separately.

Here you can see the token holders, to who they are delegating, their token balance variation which is extremely insightful in the context of security.

Quarter	KPIs	Status
Q1*	Deploy ENS DAO prototype with core governance risk metrics and actionable security insights.
Q2	Deliver the final DAO Security Staging Framework – Like L2beat – in the ENS dashboard, publicly assessing governance maturity across risk	We are advanced in this milestone

---

Governor Upgrade

As we are first focusing to present and discuss the delegation incentives system with the community. We have this research at an advanced stage internally but will wait until the end of September to post. Contributors who are interested in give early feedback or ideas are more than welcome to reach out and refine it together.

Quarter	KPIs	Status
Q1	Report on recommendations for governor changes

---

Delegation Incentives System

During the last Metagov call we have been presenting this research and discussing a solution to incentivize and increase the active voting power. The report will be published in the next weeks, we’re refining as we wanna make sure to come with a well-thought mechanism to execute and test. It involves a lot of simulation and data work.

Quarter	KPIs	Status
Q1	Report about research on effective delegation incentive models

---

Notification System

The ENS Notification System has launched! Start receiving ENS governance alerts → anticapture telegram bot

Impact on the long-term

• Increases governance participation and average turnout.
• Helps delegates act on time and stay informed about important changes (delegations, relevant DAO metrics).
• Reliable channel of communication with delegates and token holders.

Current features

• Notify about new onchain proposals
• Notify when a proposal has finished and it’s results
• Add wallets to track and get relevant
  • Notify voting power changed for tracked wallets
  • Remind delegate about a new vote if he didn’t voted
  • Notify if your delegate becomes inactive and doesn’t votes on the last 3 proposals
• ENS resolution

A clear over delivery compared to the Q1 goal .

Quarter	KPIs	Status
Q1	Telegram integration for onchain voting reminder and token holder to warn about inactivity of their delegate

---

[5pence.eth]

Just a bump here @blockful - it looks like we’ve only had the one update since the start of SPP2. It might be time for another, unless I missed it somewhere.

[blockful]

Hi @5pence.eth, thanks for the reminder! Yes, you’re right, and we have an internal draft that will be published within the next 2 weeks. We’re finalizing some deliverables and revisions.

[blockful]

2025 Q3 / Q4 Report

---

Summary

Following our scope of work as a Service Provider for ENS DAO, Q3 and Q4 focused security:

• Continuous calldata review across all governance proposals, preventing 2 proposals from executing incorrectly.
• Risk assessment report and governor upgrade research, to be published next week, after months of research.
• Delivery and iteration of the Delegation Incentives System proposal, currently the most material lever to increase active voting power and reduce long-term capture risk.
• Incremental expansion of Anticapture as a governance risk observability layer. Progress from v0.6.0 to v1.5.5. More reliable data, infrastructure and features to detect uncommon behavior and threats.
• Deployment of a fully functional governance frontend as an over delivery (outside of initial scope), with an experiece focused on security, better understanding of sudden voting power changes.
• Improvement on notification system reliability, relevant information and slack integration.

---

ENSIP

With the objective of maintaining operational transparency, we note that ENSIP-related deliverables are delayed relative to the original roadmap.

This delay reflects an explicit prioritization: governance-layer risk reduction (delegation dynamics, governor upgrades, and Calldata reviews) as higher urgency for ENS DAO than application-layer integrations.

Entering Q1 2026, blockful’s internal metrics explicitly target:

• Completion of ENSIP-related deliverables
• Fulfillment of ENSIP KPIs as outlined in the Service Provider proposal, under a revised and realistic timeline

ENSIP — KPI Status

Quarter	KPIs	Status
Q2*	Complete implementation with ENSjs + integrate ENSjs into our frontend for usability testing	Delayed
Q3*	Integration with at least 2 major subdomain providers (e.g. base.eth, uni.eth) + developer documentation	Delayed
Q4*	Full integration with ENS Manager App and ENSv2 + 3+ production implementations	Delayed

---

Calldata Review

Continuing our calldata review mandate, which ensures alignment between proposal intent, onchain execution, and governance security, blockful reviewed all proposals submitted during Q3 and Q4.

All reviews were completed within the expected SLA.

Calldata reviews from Q1 and Q2 can be found in the previous report:
blockful - service provider reports - #6 by blockful

Reviewed Proposals (Q3 / Q4)

Proposal	Github
[EP 6.20] [Executable] Reimbursement for eth.limo’s Legal Fees	Review
[EP 6.21] [Executable] Set Primary Names for Core DAO Addresses	Review
[EP 6.22] [Executable] ENS Contract Naming Season	Review
[EP 6.23] [Executable] Endowment permissions to karpatkey - Update #6	Review
[EP 6.27] [Executable] Endowment permissions to karpatkey - Update #7	Review
[EP 6.28] [Executable] Assign Ownership of the .kred TLD to Verified Multisig Controller	Review
[EP 6.29] [Executable] Collective Working Group Funding Request (Oct 2025)	Review
[EP 6.30] ENS Retro: Executable Proposal	Review
[EP 6.32] [Executable] Transfer $2.5M USDC from Endowment to wallet.ensdao.eth	Review

Calldata Review — KPI Status

Quarter	KPIs	Status
Q3	Response to 100% of tagged proposals within SLA	Done
Q4	Response to 100% of tagged proposals within SLA	Done

---

Anticapture

Product Updates — Data & UX

During Q3 and Q4, we focused on strengthening how governance data is surfaced, navigated, and interpreted. They are designed to quickly identify threats and uncommon behaviors.

---

Holders and Delegates

• Increased flexibility on filters
• Filterable tables and interactive charts to explore token holders, delegates, and voting power.
• Detailed drawer views for individual actors, enabling deep inspection without leaving context.
• Balance history charts and tables to track token holder balance changes over time.
• Delegation history tracking with voting power variation graphs.
• Voting power analytics to visualize distribution and temporal changes.
• Top Interactions view highlighting frequent delegation relationships.
• ENS name and avatar resolution using Viem to replace raw addresses.

Impact:
Delegates and token holders can better assess concentration, participation patterns, and coordination behavior, reducing information asymmetry and improving the quality of governance decisions.

---

Panel v2

Panel v2, expanding the DAO panel table to include additional governance-relevant context and a more structured presentation of DAO-level data.

Impact:
Users can more easily extract meaningful differences across DAOs instead of relying on incomplete or non-standardized views.

---

Custom Charts

Users now can select and visualize the metrics most relevant to their analysis, rather than relying on a fixed, one-size-fits-all set of charts.

Impact:
This prevents important signals (e.g., lending supply) from being visually or numerically drowned out by larger unrelated metrics (e.g., CEX supply). It also enables users to explore relationships between metrics over time such as trends between lending supply and governance proposal activity—supporting more explanatory analysis and better-informed discussion.

---

Cost Comparison Currency Switcher

We added a currency switcher for cost comparisons.

Impact:
This makes costs easier to contextualize and compare without requiring external conversion. As a result, users can evaluate proposal spend and treasury-related figures with reduced ambiguity and less manual overhead.

---

Export as CSV

Users can extract structured datasets directly from the interface.

Impact:
This enables downstream analysis, reporting, and integration into existing workflows. It also improves reproducibility and auditability by allowing users to work from the same underlying data outside the UI.

---

Overview Redesign

We redesigned the DAO detail overview to reduce information density by reorganizing content into clearer sections and separating content into dedicated pages where appropriate.

Impact:
This reduces user overwhelm and improves readability, making it faster to locate relevant information and interpret governance data.

Quarter	KPIs	Status
Q3	Increased visibility into treasury movements and token markets for security metrics	Done
Q4	Surface risk-relevant transactions and integrate offchain voting data	Partially Delayed (offchain vote integration is currently under development. Risk relevant transaction visualization is under review, and soon to be released)

---

Governor Upgrade

After months if iteration from the research squad a Governor Upgrade proposal will be posted this week, outlining:

• Explicit mitigation of known governance vulnerabilities
• A redesigned governor architecture

Governor Upgrade — KPI Status

Quarter	KPIs	Status
Q3	Report on recommendations for governor changes	Done
Q4	Reach community consensus on changes	In Progress

---

Delegation Incentives System

This is the highlight as a delivery outlined in this report.

We propose a 90-day pilot that distributes incentives to:

• Active delegates
• Their delegators

Guardrails

1. Time-held factor for delegators (capped at 180 days) to reduce sybil risk
2. 1 ENS minimum payout per address to avoid inefficient micro-transfers
3. Per-delegate and per-delegator payout caps to prevent concentration and increase long-term capture cost

Reward Split

[!IMPORTANT]
The discussion is ongoing here
Community participation is critical for the future of ENS DAO governance.

Delegation Incentives — KPI Status

Quarter	KPIs	Status
Q3*	Community iteration and scope definition	Done
Q4*	Deliver scoped system	In Progress

---

Notification System

Following delivery of a functional risk and governance notification system, we now provide a dedicated, shareable access point: HERE

Updates:

• Slack integration
• Message improvements to add more insight
• Message with links to see more details, transaction
• Bug fixes and tests

Quarter	KPIs	Status
Q3	Integrate email, Discord, and Slack notifications	Done (email pending/ongoing; Discord integration is under development as an out-of-scope enhancement not originally included in the proposal.)
Q4	Support offchain votes, 99% uptime	Delayed
Q1	Notify governance security threads via Anticapture, 99% uptime	Already done (instant notifications)

---

Governance Frontend

We also shipped the governance section as a over-delivery. Client diversity is important for security, and besides that, each detail is designed to be useful in adversial scenarios (eg.: like being able to easily see voting power variation and understand if there was sudden moviments to manipulate a vote).

Key current featurea:

• View all proposals, states, and calldata
• Voting
• Access security data one click away, enabling more data-driven decision-making. By clicking on delegates or votes.

For the roadmap we have planned a deeper integration with our calldata process, UX and security improvements.

---

Feedback

Please let us know any feedback you have, we’re here to make sure ENS is secure and has the best data better for decision-making.

Here is a short anonymous feedback form. Please fill it, makes a huge difference.

[blockful]

2026 Q1 Report (SPP2 Q3)

Summary

In Q3 of the SPP2 mandate (Jan-Mar 2026), blockful continued to prioritize governance security and risk reduction, while also adding a few new scopes that were identified as necessary to support the DAO governance. Highlights include the full delivery of all Calldata Reviews within SLA, completion of the Notification System Q3 KPIs (offchain vote support and 99% uptime), and Anticapture delivering its Q4 KPIs ahead of schedule (risk-relevant transaction monitoring and offchain voting data integration), a deliberate trade-off against the Q3 treasury/market visibility KPI, which is delayed while we rework the backend infrastructure.

The Governance Frontend (an unfunded over-delivery, since the Extended Scope was not approved) is live and being prioritized as a potential E2E governance participation interface for ENS DAO in light of Tally’s sunset. The Delegation Incentives System is in its final adjustments. The Governor Upgrade has substantively reached its Q2 milestone but is being intentionally held for an additional round of community engagement before next steps. ENSIP-20 work is delayed and currently blocked on architectural alignment with ENS Labs and the in-flight ENSv2 work; we will surface the blocker to the community for resolution in Q4.

---

Calldata Review

All proposals tagged for review during the period were processed within the SLA committed in the original proposal. Six executable proposals were reviewed covering treasury transfers, security controllers, ENS DAO registrations, DNSSEC oracle replacement, and endowment permissions.

EP	Description	Turnaround
EP 6.32	Transfer $2.5M USDC from Endowment	1 day
EP 6.33	Enable Root and Registrar Security Controllers	8 days
EP 6.34	Register on.eth to ENS DAO wallet	2 days
EP 6.35	Replace DNSSEC oracle algorithms	1 day
EP 6.37	Transfer 900K USDC from Endowment	2 days
EP 6.38	Endowment permissions to karpatkey Update #8	3 days

Quarter	KPI	Status
Q1	100% response to tagged proposals within SLA	Done
Q2	100% response to tagged proposals within SLA	Done
Q3	100% response to tagged proposals within SLA	Done
Q4	100% response to tagged proposals within SLA	Pending

---

ENSIP-20

As previously reported, we have implemented and submitted PR #226 to ensdomains/ensjs, “ENSIP-20 Implementation”, authored by Lucas Picollo (blockful). The PR adds EIP-7884 ABIs and an ENSIP-20 handler, covering subname creation and record/text/address/ABI/contenthash setting via both onchain and offchain operation routes (with EIP-712 signing for offchain mutations through a gateway).

The PR is open and unmerged, and has not received review activity since July 2025. The workstream is currently blocked on architectural alignment rather than implementation effort.

We’re waiting for a formal document from the ENS Labs team, to understand what needs to change in the standard in order for us to move forward with the implementation.

Quarter	KPI	Status
Q1	ENSIP specification + initial ENSjs integration	Done (PR #226 submitted; awaiting review since Jul 2025)
Q2	Complete ENSjs implementation + integrate into frontend for usability testing	Blocked (pending ENS Labs / ENSv2 alignment)
Q3	Integration with 2+ major subdomain providers + developer documentation	Blocked (pending ENS Labs / ENSv2 alignment)
Q4	Full ENS Manager App + ENSv2 integration; 3+ production implementations	Blocked (pending ENS Labs / ENSv2 alignment)

---

Anticapture

Anticapture’s Q4 KPIs were delivered ahead of schedule — risk-relevant transaction monitoring and offchain voting data integration are both live on the dashboard. We made a deliberate trade-off this quarter: prioritizing offchain voting data integration over the Q3 treasury and token market visibility KPI, which is now delayed.

ENS DAO visitors on Anticapture have grown considerably, especially around new features. ENS pages access were responsible for 35% of all platform activity, with over 200 individual visits this quarter. Holders and Delegates, Proposals and Service Providers are the most visited pages inside ENS DAO.

The treasury/market visibility work has been paused while we rework the backend infrastructure behind Anticapture with a new indexing and API request system. This investment will streamline future dashboard evolution and is expected to land the Q3 KPI in Q4.

Over-deliveries this period:

• Activity Feed with organized transaction risks: risk-relevant transactions are now surfaced in a dedicated activity feed view, making it easier for delegates and the community to track and contextualize governance-impacting onchain activity at a glance.
• Service Provider Reports on Anticapture: the new Service Provider Reports feature is now hosted on Anticapture, giving the DAO a centralized, structured place to track service provider deliverables and accountability alongside the rest of its governance health data.

Quarter	KPI	Status
Q1	ENS DAO prototype with core governance risk metrics	Done
Q2	Final DAO Security Staging Framework in ENS dashboard	Done
Q3	Treasury and token market visibility	Delayed (backend rework in progress)
Q4	Risk-relevant transactions monitoring	Done (ahead of schedule)
Q4	Offchain voting data integration	Done (ahead of schedule)
—	Activity Feed with organized transaction risks	Over-delivery
—	Service Provider Reports hosted on Anticapture	Over-delivery

---

Governor Upgrade

The Q1 recommendations report was delivered in the prior period, and the proposed changes have been live for community engagement. Community feedback has been limited, and we believe the Q2 KPI (“community consensus on proposed changes”) could substantively be marked as ready. However, given the magnitude of a Governor upgrade, we are deliberately delaying next steps to allow for one more round of community engagement before moving toward audit and deployment. With the work on the Security Council and the Incentives System taking more of our time than expected, we would rather absorb a timeline slip than push such a foundational change forward without proper attention and time, as well as a strong, broad-based input from the DAO.

Quarter	KPI	Status
Q1	Governor change recommendations report	Done
Q2	Community consensus on proposed changes	Partially ready
Q3	Governor ready for audit	Pending
Q4	Onchain deployment	Pending

---

Delegation Incentives System

The Delegation Incentives System is feature-complete and currently under stress testing. The technical development took more time than expected, due to the complexity of the algorithm and management of edge cases, as well as refinement of the UI to aim at a campaign as broad and effective as possible. With the system ready, we are now working on the marketing and communications campaign to drive participation, and the next steps are an onchain proposal and activation of the 90-day pilot. The Q4 KPI (a 30% increase in delegated supply) depends on activation landing and the pilot running its course.

Quarter	KPI	Status
Q1	Research report on effective delegation models	Done
Q2	Community iteration; scope definition	Done
Q3	Scope delivery	Feature-complete (under test; marketing + onchain activation next)
Q4	30% increase in delegated supply (excluding veto council)	Pending (gated by activation)

---

Notification System

The Notification System hit its Q3 KPIs on schedule: offchain vote support is live and the system maintained 99% uptime over the quarter.

We also over-delivered on this workstream by expanding the range of functionality available within each notification channel, so different types of users, from passive token holders to active delegates, can shape their notification chat to fit how they engage with governance. The goal is to make sure no user profile is left out of the loop simply because the default notification format doesn’t suit them.

Email and Discord integrations have been de-prioritized based on conversations with delegates, where we have not observed concrete demand for either channel. The underlying system is built to enable new distribution channels (email, Discord, or others) on demand, we are ready to ship those routes the moment delegates surface a need, but will not invest in building them speculatively.

Quarter	KPI	Status
Q1	Telegram integration (voting reminders, delegate inactivity)	Done
Q2	Slack integration	Done
Q2	Email, Discord integration	De-prioritized (no delegate demand; ready to enable on request)
Q3	Offchain vote support	Done
Q3	99% uptime	Done
—	Expanded per-user notification functionality across channels	Over-delivery
Q4	Anticapture security thread notifications	Pending
Q4	99% uptime (sustained)	Pending

---

Governance Frontend (Over-delivery)

Note: The Governance Frontend was originally part of the Extended Scope ($100k) of our SPP2 proposal, which was not approved by the DAO. We are nevertheless delivering this workstream as a true over-delivery on top of our basic scope commitments, at no additional cost to the DAO.

The Governance Frontend is live at ens.gov.blockful.io and operating in production. Given Tally’s sunset, we are reprioritizing this workstream to ensure the interface can provide end-to-end governance participation for ENS DAO, covering proposal viewing, drafting, voting from EOAs and multisigs, and delegate insights, so the DAO has a reliable, ENS-native governance interface.

This is a strategic resilience investment for the DAO’s governance infrastructure, delivered outside the funded scope.

Quarter	KPI (from original Extended Scope)	Status
Q1	V1 voting; mobile-responsive design; user feedback collection	Done
Q2	Multisig integration; gasless voting; proposal wizard	In progress (reprioritized for E2E coverage)
Q3	Draft collaboration features; delegate insights; infrastructure integration	In progress (reprioritized for E2E coverage)
Q4	Advanced analytics; 99.9% uptime; 20% of votes via this frontend	Pending

---

Feedback

We welcome community input on the direction and prioritization of our workstreams, particularly around the ENSIP-20 blocker, the additional engagement round on the Governor Upgrade (we’d love more delegate voices weighing in before we move toward audit), and the expanded scope of the Governance Frontend as a Tally fallback.

[blockful]

2026 Q2 Report (SPP2 Q4)

Summary

This is the final report of Year 1 of our SPP2 scope of work, covering Apr–Jun 2026. In Calldata & Proposal Review, we answered every tagged proposal on time, all four quarters. Anticapture delivered the treasury and token market visibility KPI that had been delayed since Q3. The Delegation Incentives System was built, and the campaign opened in July. We implemented Governor Nexus, the governor upgrade we proposed as an RFC, and published the code and the implementation report in August. ENSIP-20 remains blocked on ENS Labs and ENSv2.

On Security Council Renewal, we built the new SecurityCouncil contract, had it audited by Nethermind (NM-0945), and submitted EP 6.45, which passed on Snapshot. The onchain executable, EP 6.48, was defeated. The DAO has since enacted a council running the same audited contract code (details in the Security Council Renewal section).

Outside the funded scope, we also over-delivered. We continued the end-to-end build of the Governance Interface, authored governance posts beyond our funded workstreams, and built a Copeland visualizer the DAO used to follow ranked-choice votes in real time.

Year 1 results

Workstream	Where Year 1 ended	Status
Calldata & Proposal Review	We reviewed all 24 executable proposals of Year 1 on time	Done
Anticapture	All four quarterly KPIs were met. The delayed Q3 treasury and token market KPI was delivered this quarter	Done
Notification System	The system is live with Telegram, Slack and offchain vote support	Done
Delegation Incentives	The campaign opened in July. The KPI is met at +71.2% (see the disclosure below)	Done
Governor Nexus	The implementation is done and the code went public in August. Feedback window open, external audit next	In progress
Security Council Renewal	Our renewal was defeated onchain. In July the DAO adopted the same audited contract code	Defeated → Adopted
ENSIP-20	The work is waiting on a formal document from ENS Labs for ENSv2	Blocked

---

Calldata & Proposal Review

We reviewed all 24 executable proposals submitted onchain during Year 1 within the committed response time. That closes the year at 100% across all four quarters. The reviews are public in blockful/dao-proposals. We also improved the review tooling with test helpers, pre-state assertions, and CI formatting checks.

EP	Description	Review published
EP 6.39	Treasury Flow Automation	2026-04-08
EP 6.40	Update DNSSEC Algorithm 7	2026-04-20
EP 6.41	Endowment permissions to KPK - Update #9	2026-05-01 (draft review), 2026-05-09 (live proposal)
EP 6.47	Delegation Incentives Program (funding transfer)	2026-07-01
EP 6.48	Renewal of the Security Council (our own proposal)	2026-07-01

Over-delivery: We started building calldata-registry-protocol, which turns our proposal reviews into onchain records. It publishes each review as an EAS attestation, routes URLs by executor nonce with an indexer that needs no RPC calls, and includes a review app that maps how proposals depend on each other.

Quarter	KPI	Status
Q1–Q4	100% response to tagged proposals within SLA	Done, all four quarters
—	calldata-registry-protocol review infrastructure	Over-delivery

---

ENSIP-20

The workstream is blocked on alignment with ENS Labs and the ENSv2 work rather than implementation effort. We did no ENSIP-20 dev work this quarter. As previously reported, PR #226 to ensdomains/ensjs remains open and unmerged, with no review activity since July 2025.

That pause is deliberate. Building the integration while the ENSv2 resolution model is still being finalized could mean building the wrong thing, so we are waiting for a formal document from ENS Labs describing what needs to change in the standard.

Getting that document from Labs has been difficult. In Year 2 we will keep pressing them for that answer, and we are ready to rebuild the standard if ENSv2 requires it. We identified this problem and took responsibility for solving it, but we cannot take it to production without Labs.

Quarter	KPI	Status
Q1	ENSIP specification + initial ENSjs integration	Done (PR #226 submitted, awaiting review since Jul 2025)
Q2	Complete ENSjs implementation + integrate into frontend for usability testing	Blocked
Q3	Integration with 2+ major subdomain providers + developer documentation	Blocked
Q4	Full ENS Manager App + ENSv2 integration and 3+ production implementations	Blocked

---

Anticapture

We delivered the treasury and token market visibility KPI that was delayed from Q3. The token markets side was already live through the token distribution and attack profitability pages. The treasury side was missing, and we closed it with the new revenue page, which breaks ENS revenue down by quarter. The methodology and data are open in ens-revenue-analysis.

The KPI was waiting on the backend rework we reported last quarter, and we finished that rework this quarter. The dashboard now also shows votes, choices and non-voters for Snapshot proposals, including Copeland ranked-choice votes.

Over-delivery: We shipped an Anticapture MCP server, giving AI agents access to the same governance and security data the dashboard shows.

Quarter	KPI	Status
Q1	ENS DAO prototype with core governance risk metrics	Done
Q2	Final DAO Security Staging Framework in ENS dashboard	Done
Q3	Treasury and token market visibility	Done
Q4	Risk-relevant transactions monitoring	Done (ahead of schedule)
Q4	Offchain voting data integration	Done (ahead of schedule)
—	Anticapture MCP server	Over-delivery

---

Governor Upgrade (Governor Nexus)

We spent the quarter implementing Governor Nexus, the modular governor with three interchangeable rulesets (Standard, Optimistic, Bond) that we had proposed to the DAO as an RFC.

The code is complete and public at blockful/nexus. In August, after the quarter closed, we posted the implementation report to the DAO, which opens a two-week feedback window before the external audit. The next steps are the audit and then deployment.

Quarter	KPI	Status
Q1	Governor change recommendations report	Done
Q2	Community consensus on proposed changes	Done
Q3	Governor ready for audit	In progress (code public in August, feedback window before the audit)
Q4	Onchain deployment	Pending

---

Delegation Incentives System

We finished building the Delegation Incentives System this quarter and made it ready to launch. Since last quarter, when it was feature-complete and under test, we added matchmaking between delegates and delegators, referral and sharing features, a rewards engine that records where each wallet’s rewards come from, gasless delegation through a relayer, and the public launch pages.

The campaign opened in July and runs through September 2026 at incentives.ens.blockful.io. The Q4 KPI is met. Delegated supply grew from ≈4.14M ENS to ≈7.09M ENS over the SPP2 year, measured as delegated voting power on 28 Jul 2025 and 29 Jun 2026 using Anticapture. That is +71.2% against the 30% target.

A single delegation accounts for the whole increase. nick.eth’s delegated voting power went from ≈155.6k to ≈3.26M ENS, a rise of 3.11M ENS, which is 105% of the DAO’s 2.95M net increase. Excluding that address, delegated supply fell from ≈3.99M to ≈3.83M ENS, a 3.9% decrease.

Measure	28 Jul 2025	29 Jun 2026	Change	vs. 30% target
Total delegated supply (the KPI)	≈4.14M ENS	≈7.09M ENS	+71.2%	Met
Excluding nick.eth’s delegation	≈3.99M ENS	≈3.83M ENS	−3.9%	Below target

We report the KPI as met because it is met as written. We do not attribute the increase to our work. The campaign was not running at any point in the window this KPI measures, so the −3.9% reflects a year with no incentives program in place.

Engaging the community around the campaign has been harder than expected. Delegates offered strong support for spreading the word early on, but after the discussions and enactment of the ENS Foundation proposal, that support faded and fewer tokenholders heard about the program.

Quarter	KPI	Status
Q1	Research report on effective delegation models	Done
Q2	Community iteration and scope definition	Done
Q3	Scope delivery	Done (system built and ready to launch)
Q4	30% increase in delegated supply (excluding veto council)	Met at +71.2% (see the disclosure above)

---

Notification System

This quarter’s Notification System work went into reliability. We rebuilt the Snapshot reminders, improved their delivery consistency and monitoring, and restored the offchain and security-thread notifications after the Anticapture backend rework, using the public @anticapture/client package. Our uptime monitoring showed no downtime during the quarter.

Quarter	KPI	Status
Q1	Telegram integration (voting reminders, delegate inactivity)	Done
Q2	Slack integration	Done
Q2	Email, Discord integration	De-prioritized (no delegate demand, ready to enable on request)
Q3	Offchain vote support	Done
Q3	99% uptime	Done
Q4	Anticapture security thread notifications	Done (restored after the Anticapture backend rework)
Q4	99% uptime (sustained)	Done (no downtime this quarter)

---

Security Council Renewal

The DAO’s Security Council was set to expire, so we took on renewing it. We built a new contract where only the DAO timelock can extend the expiration and the council multisig owns it from day one. We had it audited by Nethermind, deployed it to mainnet on 20 June 2026, and submitted EP 6.45.

EP 6.45 passed on Snapshot. The onchain executable that would have enacted it, EP 6.48, Renewal of the Security Council (Term 2), was defeated with 1,137,702 ENS for and 3,859,981 ENS against, 3,260,721 of them cast by nick.eth. Our proposal kept the current council membership, and that membership, not the contract or the audit, was the objection. nick.eth wrote onchain that the current members had made clear they intended to use the veto against proposals they personally disagree with.

On 13 July 2026 nick.eth submitted Establishing a new Security Council (Executable), which passed with 4,228,716 ENS for and 94,526 ENS against and was executed. The new council runs the contract we developed and had audited, and we helped architect the proposal and its deployment. We also reviewed the calldata and verified onchain that the deployed bytecode exactly matches the code Nethermind audited. The council is now owned by the elected members’ 5-of-8 Safe and expires on 16 July 2028.

---

Over-deliveries

Everything in this section sits outside our funded scope. The Extended Scope ($100k) that would have covered part of it was not approved, so we delivered it at no additional cost to the DAO.

Governance Interface

The Governance Interface is in production. With Tally sunsetting, we are building it to become the DAO’s main governance tool, under the ENS brand. We introduced it to the DAO in an RFC on 31 May. The main features deployed this quarter:

• Proposal creation, with a multi-action calldata builder and queue and execute steps
• Shareable proposal drafts, so an author can circulate and refine a proposal before submitting it onchain
• Gasless voting and delegation through a relayer
• A unified list of onchain and Snapshot proposals
• A revenue dashboard covering ENS revenue, registrations, renewals, retention and expirations

ENS governance work

We were active in ENS governance throughout the quarter, authoring proposals, temp checks and public positions, and holding a Meta-Governance Working Group steward seat. Most of that participation was already committed to the DAO, through the stewardship or through funded workstreams like the Security Council renewal. Setting those aside, two posts were still over-delivery.

• 2 Apr: ENS Service Provider Accountability
• 31 May: Governance Interface for ENS DAO

Copeland visualizer

ENS ranks candidates with the Copeland method in SPP and working group votes, and the raw Snapshot results are hard to read. We built a visualizer that shows the standings in real time and shared it with the DAO during the Term 7 working groups vote. The code is open at blockful/copeland-visualizer.

---

Carried into Year 2

Three items carry into Year 2, none of them abandoned. The table shows where each one stopped and what it is waiting on.

Item	Where it stopped	What it is waiting on
Governor Nexus	The implementation is complete and the code went public in August, in a two-week community feedback window before the audit.	The feedback window closes, then the external audit, then deployment (see the Governor Upgrade section). Two Year 1 KPIs carry over: “ready for audit” ( In progress) and “onchain deployment” ( Pending).
ENSIP-20	PR #226 is open and unmerged.	A formal ENS Labs document describing what must change in the standard for ENSv2.
Delegation Incentives campaign	The system was built during the quarter and the campaign opened in July 2026.	Nothing blocks it. The campaign is running, and we will report its effect when we re-measure delegated supply in the Year 2 reports.

We will post a Year 2 roadmap soon, with more detail on these items and the new scopes for the year.

[blockful]

Blockful SPP2 Year 2 Roadmap

TL;DR: Year 1 built the infrastructure ENS governance runs on. Year 2 keeps it running and makes it more robust and reliable, with measurable guarantees. It takes Governor Nexus through external audit to a deployment proposal, starts two new work-streams on the registrar (a protocol-paid referral program and 1-2 character .eth names), and carries ENSIP-20 as blocked until ENS Labs takes an official position on it. We’re publishing the plan up front so you can check each quarterly report against it, and there’s an open questions section at the end for delegate input.

---

Context

Our 2026 Q2 report closed Year 1 of the two-year SPP2 stream the DAO approved. The infrastructure we committed to build is now live. Anticapture and the Governance Interface at ens.gov.blockful.io, the notification system, the calldata review SLA, the Delegation incentives campaign, and the Security Council contract now running until 2028 are all in production. We spend Year 2 operating that stack and tightening its guarantees rather than expanding it, with two exceptions.

The scope conversations with NameHash Labs added two items, a protocol-paid referral program and 1-2 character names. We’ll do the design work on both in Year 2 and bring each to the DAO as a proposal.

---

Year 2 scope

What we will strengthen

Most of this plan is continuity. These six services are already live, and Year 2 puts each of them under a guarantee you can measure us against.

Anticapture: The ENS dashboards and data stay in production with two operational guarantees. On-chain data freshness stays under 10 minutes. Prometheus measures uptime and we publish the number each quarter.

Governance Interface (ens.gov.blockful.io): We keep maintaining and improving proposal viewing, creation and voting. Each quarter we’ll report how the interface is being used, starting with the number of votes submitted through it. The analytics are anonymous and collect nothing that identifies who voted.

Notification system: The service keeps running with uptime measured the same way, and every governance event covered by a subscription produces its own notification. Telegram and Slack are the live channels, and whether email and Discord stay in scope is question 2 at the end.

Calldata review: The SLA continues. 100% of tagged proposals reviewed before they go on-chain, and we publish every review’s turnaround each quarter.

Delegation incentives: The campaign has been live since July, still aimed at the application’s +30% goal, and its funded rounds close in September. We’ll report what it attributed. Whether delegation work continues after the campaign closes is a decision for the DAO, and question 1 at the end asks it.

Security Council: The council the DAO seated in July runs until 2028 on our contract, audited by Nethermind (NM-0945). We provide operational support for that council through the term.

What we will finish

One work-stream has a single job in Year 2, to ship.

Governor Nexus: The implementation report’s two-week feedback window has closed. We’re folding the feedback in, finalizing the audit scope, and collecting quotes from audit firms. We’ll bring those options to the community so the choice of firm is discussed in the open, then post the audit proposal for the DAO’s approval. When the audit runs, we address everything it finds. Then a deployment proposal takes the contracts on-chain. Every step is a public forum post, so at any moment you can tell which stage we’re in.

What we will start

Two work-streams are new, and both live on the registrar.

ENS Referral Program: ENS pays no referral fees today. The current controller records a bytes32 referrer on every registration and renewal, but the parameter is only emitted in events, nothing on-chain pays out, and providers pay any referral rewards off-chain from their own budget. We proposed the first referral implementation to ens-contracts in September 2022 (PR #128), including a DAO-settable fee split. A referrer parameter shipped with the new controller in 2025, without a fee split. We’ll continue from what NameHash Labs proposed and learned in their experiments, and bring the DAO a policy that takes referral payments into production and grows ENS registrations.

1-2 character .eth names: Short names have been a standing community ask since 2023 and nobody has ever owned the work. The entire restriction is one function in the current controller, valid(), which requires three characters or more and has no admin switch. Releasing them would be one transaction, the DAO authorizing an additional controller on the registrar it owns, with no migration and nothing to unwind. The live price oracle also carries zero prices for 1 and 2 character names today, so pricing needs a decision of its own. Year 2 is the pricing research and coordination work.

What is blocked

One Year 1 work-stream is blocked.

ENSIP-20: It is the wildcard writing standard we authored in SPP1, so any ENS client can register and update names whose records live off-chain or on an L2. The spec is published, the reference implementation is open source, and the ENSjs integration has been open and unmerged since March 2025. Taking it to production depends on ENS Labs adopting it in the manager app and ENSv2, and they haven’t taken a position. In Year 2 the spec and implementation stay published, we keep asking ENS Labs for a formal position, and the moment it’s unblocked we pick it back up, in this form or a revised one.

---

Timeline

Five services run on standing guarantees that hold every quarter:

Service	Standing guarantee
Anticapture	Data freshness under 10 minutes, uptime reported quarterly
Governance Interface	Usage reported quarterly, starting with votes submitted through the interface
Notification system	Uptime measured, every covered event produces a notification
Calldata review	100% of tagged proposals reviewed, every review’s turnaround published quarterly
Security Council	Operational support through the 2028 term

The staged work moves like this:

---

Open questions

Everything above is what we’ll do in Year 2. Two points along the way are open, either because they need a DAO decision or because we want to hear how you see them before we commit. We’ve written our recommendation under each one.

1. Delegation target. Year 1 carried a +30% active delegation target and we built the incentives campaign to chase it. This roadmap carries no delegation target for Year 2. Should it? Our recommendation: not yet. The campaign closes in September and its results, with attribution separated from market movement, reach the forum next quarter. That’s the first real data on what moves delegation in ENS, and we’d rather propose the next step from it than commit a number before seeing it. That next step can be a second round, a different mechanism, or no further delegation work at all, if the campaign shows incentives don’t move the number.

2. Notification channels. The notification system delivers on Telegram and Slack. Email and Discord were in the Year 1 plan, and we de-prioritized them in our last report because no delegate had asked for them. Since then the subscriber base has held flat and no request for either channel has come in. Should email and Discord stay in Year 2 scope in case demand appears, or come off the roadmap so the effort goes to the commitments above? Our recommendation: take them off. A new channel is one more adapter on the same pipeline. If a delegate asks, we add it then. A channel nobody asked for is cost without users.

---

Point out what you’d reshape. Happy to keep contributing to ENS in Year 2.