Spence prepared material to increase the allowance for SPP2.
Waiting to get some input from AvsA
Executable proposal hopefully this or next week
Spence proposes to do 1 year + 3 months (doesn’t cover 2-year streams)
Netto believes it would be “operationally clean” to have the allowance of the whole SPP2 program under the next executable and set the end dates of the streams as specified on EP 6.3.
Thomas adds that the executable code generates a year’s funding plus a 6-month buffer, while the 6.3 proposal accounts for a 3-month buffer but funds the full 2 years upfront. The actual number is around $6.4 million allowance.
Netto is adamant about being strict in implementing what was approved in the 6.3 proposal, which clearly states 3 months of runway. Anything else needs to pass through a proposal again.
Netto’s proposal was discussed briefly about allowing SPs to receive a streaming grant in sUSDS, which is a yield-bearing asset that would yield at least $210k extra with 4.5% APY.
There are blockers regarding IPS from kpk, which exposes the DAO to more risks by holding sUSDS rather than USDC.
The yield from this investment would only go to the streams and not be used for other activities.
There are potential legal issues to consider.
Complexities added around operations, accounting, IPS updates, requiring a vote, risk concerns, etc.
Need to weigh the risk versus opportunity, including the cost of coordination, to determine if “the juice is worth the squeeze.”
Social proposals to create a committee for further privately evaluating this proposal, doing due diligence, etc. expected to come this week.
After that, there will be an executable proposal for the final Yes/No on the proposal.
3. Open Discussion
2.4 Tally Proposals
Clifton from Tally introduces their proposal, noting Tally didn’t receive funds from SPP2 but has been working with Nick on items like supporting Namechain and ENS integration.
The proposal aims to formalize the ENS DAO’s partnership with Tally, which has been a go-to governance platform for many on-chain boards since 2021
Scope of work overview:
Customizable Webhooks – triggers, real-time alerts, etc.
Integration – Namechain support, indexing offchain ENS names, etc.
Terms:
180k first year (split between USD and ENS tokens)
TL;DR – Tally proposes a formal enterprise-level service agreement that elevates ENS governance UX, broadens the distribution of ENS primitives across all governance users on Tally, and furnishes the DAO with battle-tested uptime, reporting, and support guarantees.
Three scopes of work: webhooks, deeper ENS integration/distribution, and enterprise support levels.
Tally’s proposal is complementary and more in-depth than Denison’s post on programmatic tooling rewards.
It was suggested that MetaGov could request funding from the DAO to pay Tally, similar to how they request funding for other needs.
The suggestion of an RFP (Request for Proposal) was brought up.
The DAO could work with Tally for a year or so, similar to the arrangement with Agora, and then potentially collaborate with other providers.
The title of the proposal may be misleading, as “dedicated governance provider” does not imply exclusivity.
Funding should follow clear DAO signals and focus on proven needs, not assumptions or features without demonstrated demand.
Proposals should be motivated, evidence-based, and distinguish genuine community needs from self-promotion, as setting the wrong precedent could invite low-signal ideas.
Hats Protocol enables onchain role management using programmable “hats” to build secure, cost-efficient DAOs and manage dynamic organizational structures.
Integration with Safe allows DAOs to control multisigs via Hats modules, automating onboarding, compliance, and signer status programmatically.
Enforceable Requirements, like ENS token holdings, can be used to automate access and removal of multisig signers, enhancing accountability and flexibility.
DAO Control is emphasized—DAOs can update multisig roles onchain, minimizing risks of stuck multisigs and allowing responsive governance.
Role Reusability across multiple multisigs simplifies transitions; a single “hat” can represent permissions across systems without managing separate addresses.
Additional Permissions through hats (e.g., forum badges, Telegram access) extend utility beyond just multisig signing, enabling trusted coordination.
Risk Mitigation includes concerns over multisig lock-in or collusion when one person holds multiple hats—Hats offers mechanisms to adjust signers.
Fractal Hat Structure allows nested roles and delegated admin control.
Future-Proofing includes immutable smart contracts, decentralized indexing, DAO governance of Hats, and potential for ENS to white-label the UI.
