0xbac8…13b3

All memos sent from and to 0xbac8…13b3.

Voting against this proposal. While the temporary MinMaxConstantPriceFeed was introduced as an emergency measure, removing it at this stage may be premature. Given the recent history surrounding the rsETH bridge exploit, maintaining additional safeguards for a longer observation period could provide stronger protection against unexpected market or oracle-related risks. I would prefer to see more extended stability data and further risk assessment before reverting to the previous oracle configuration across both the Mainnet WETH and wstETH Comets.
I’m voting For this proposal. The initial fee rollout on mainnet has been live for a while now, and we haven’t seen the kind of liquidity flight that some people were worried about. TVL has held up, volume is strong, and the burn mechanism is working as intended. Expanding fees to L2s where more activity is happening just feels like the logical next step. I also support moving to the tier-based v3 fee model. Managing fees pool-by-pool doesn’t scale, and having a consistent structure across tiers makes governance simpler and more predictable. Governance still retains override power, which is an important safeguard. At this stage, Uniswap isn’t an experiment anymore — it’s core infrastructure. Turning on protocol fees across chains aligns incentives, strengthens UNI, and doesn’t fundamentally change how LPs or traders use the protocol. This feels like a measured evolution, not an aggressive shift. Happy to support it.
voting for – Love seeing real-world infrastructure like this come into ENS. Bridging Web2 and Web3 through familiar tools is exactly the kind of growth we need. Looking forward to seeing how .locker evolves in the ecosystem.
Abstaining on this proposal — I appreciate the thoughtful direction toward L2 support and enhanced reverse resolution. While I’m still evaluating the broader implications of introducing multiple reverse namespaces and a new controller, I truly value the work put into expanding ENS functionality. Looking forward to seeing how these changes empower more seamless multi-chain experiences! 💫
I’m voting YES on this proposal as it significantly enhances ENS functionality across L2s by implementing chain-specific reverse resolution as defined in ENSIP-19. This aligns ENS with the growing reality of multi-chain deployments and smart contract accounts that do not share the same address across chains. Enabling L2 primary names will help developers build seamless ENS-integrated dApps without forcing mainnet interactions. I also support the introduction of a new registrar controller with optional reverse record setting and a referrer field, which opens up exciting possibilities for referral-based ecosystem incentives in the future.
I’m voting FOR this proposal. The corrections to the description provide much-needed clarity, and the transition to a $4.5M budget with a streamlined group of 8 service providers is a solid step forward. I'm especially supportive of the balance struck between continuity (with 6 existing providers) and innovation (with JustaName and ZK Email joining). The technical implementation details—including secure fund handling via the Stream Management Pod, limited exposure through Superfluid, and transparent allocation—give me confidence in the execution. Thanks to the team for including verification tools and a well-defined transition plan. Let’s move forward with SPP2.
Voting yea on this proposal. The transition to SPP2 is well-structured and builds on the proven SPP1 framework. The increased budget allows for greater impact while maintaining strong security and compliance standards. I'm especially glad to see the inclusion of new providers like JustaName and ZK Email—diversification will strengthen the ecosystem. Looking forward to smooth implementation.