Archived on 15/05/2025

Verbs szn 3 ideas brainstorm

verb-e

Hi there,

We’re coming to you again asking for help in planning another season of execution.

We’d love your help with:

  • Feedback (for / against) on ideas we have below in the backlog section
  • Suggestions for additional ideas you find exciting

To provide you with a complete picture, we’re also sharing what’s already in progress as well.
As always, we’re looking to work on what’s most valuable to the DAO - your inputs are meaningful!

Thanks!
verbs team

in progress

title description
streamer allows the DAO to create USDC streams funded by Token Buyer.

currently being audited.
Noracle: auction house price history on-chain upgrades to Auction House that stores auction prices on-chain; also introduces some gas optimizations.

will be audited right after streamer.
ragequit allows DAO members to exit by burning their tokens in exchange for a proportional share of the treasury. Ragequit offers a defense mechanism in addition to the vetoer against 51% attacks, and opens a path to removing/reducing the vetoer power in the future.

this is an active research project. read more here.
change proposal vote snapshot timing currently proposal vote snapshots occur on their creation block, meaning voters can’t organize their votes once a proposal is live.

we’re moving the snapshot to when voting starts, thus allowing voters the voting delay period to move their tokens or delegations around.

we have a working proof of concept, and a more detailed spec here.
conditional objection period a conditional voting period that gets activated upon a last-minute proposal swing from defeated to successful, affording against voters more reaction time.

we have a working proof of concept, and a more detailed spec here.

backlog

title description conviction
refund gas on proposal execution a successful proposal is something the DAO wants to execute, it should happily pay for gas as well; especially useful for high-gas proposals like contract deployments. requires further research to defend against grieving. high
milestone-based proposal payments requires additional speccing.
probably m/n signers to release the next milestone.
milestone order, amount and recipient all specified in advance on proposal creation.
probably require a text description of why funds are being released.
probably recipient can request on chain with a progress update as well.		 high
increase on-chain transparency for multisig / pod spending this feature adds a minimal extra step for multisigs when they spend their allocated funds: they need to provide a reason string.

when the DAO funds a pod / other multisig, the funds can go to a middleman contract that lets the multisig spend their funds at any time, just requiring the reason string be documented on chain first. furthermore, the DAO can withdraw any outstanding funds at any time.

then we would add a simple ledger UI on top, and the DAO should get a significant spending transparency boost.		 high
increase friction for contract upgrade and high spend proposals it seems intuitive to many that the more a proposal wants to spend, it should require more of a “hell yes” from the DAO.
this can be generalized to more risk → greater majority requirement, and so can include sensitive contract upgrades.

potential ways to increase friction:
* require a super majority, e.g. 67% of active votes on a prop must be For (excluding abstains)
* lengthen the voting period
* higher quorum requirement		 medium
autonomous proposals: empower the community to propose similar to what Compound has.

it would be a new smart contract that has sufficient votes to submit proposals (through ownership or delegation), e.g. a Proposer contract.

Proposer holds a list of candidate proposals, and can accept new candidate proposals from:
* anyone
* accounts that hold a certain token; could be a single Noun, could also be anyone holding a Lil, a toad, etc.

candidate proposals (CPs) then need to get additional voter support, and that threshold could be proposal threshold or have its own threshold.

CPs that get sufficient support can be proposed to the DAO (sequentially due to the DAO’s constraint of one active proposal per proposing account).

The desired effect is builders having an easier time getting proposals on chain, without compromising on proposal quality.		 medium
allow vote editing shortly after voting there have been several instances of voting mistakes (meaning to vote one way, accidentally voting the opposite). we’d like to offer a short timeframe to correct such mistakes.

vote editing otherwise will remain prohibited to prevent gaming.

requires further thought to prevent potential abuse.		 medium
private voting this is a research project, where we would explore different approaches and their pros and cons, in different dimensions such as technical complexity, cultural impact, etc.

certain outputs would be detailed design alternatives and proofs of concept; optional output would be deploying a solution to mainnet pending DAO approval.		 medium
vote on sub-proposals (support passing parts of proposals) some proposals have a general consensus, but disagreement on part of the budget allocation.
example:
A builder wants to create a nounish song for $10K and then spend $5K on marketing.
It’s possible that the DAO thinks it good to spend $10K on the song, but not $5K on marketing.

a solution for this problem could be in allowing proposals to have optional elements to them.
in the example above, the song budget is a required line item, but the marketing is an optional one.
a voter would have the following voting options:
1. against
2. for the $10k, against the additional $5k
3. for the $10k and the $5k

the optional elements would also need to reach quorum and have majority to pass.

this example above is the most simple one. our current assessment is that this feature has sizable complexity to it.		 low
allow proposal description amendments until voting starts oftentimes proposals receive valuable feedback once on-chain. allowing proposers to edit their proposal description before voting starts can contribute to higher quality and clarity for voters.

requires further thought to make sure we don’t create voter confusion.		 low
descriptor trait retirement currently all traits (heads, bodies, etc.) are additive, without an option to remove.
trait retirement would allow the DAO to disable any specific image; a disabled trait would still exist in already-minted Nouns, but would not be part of the randomized traits for new Nouns.

the main motivation in introducing this feature would be if the DAO wanted to be less strict about what gets added, to leave more room for trial and error.		 low
delegate override this feature would allow token owners to override votes cast by their delegates.
the motivation is security, as owners have more skin in the game, and therefore more likely to vote in good faith and be less susceptible to bribes.

our initial design work showed us this feature is far from trivial, with the downside of allowing Nouners to abuse the system by delegating to themselves and preserving the right to edit their vote.

we might come up with a design without this flaw with further research.		 low
granular delegation this feature would allow a holder of multiple Nouns in the same wallet to split their delegation to multiple destinations. today this requires transferring Nouns to different wallets.

not pursuing this feature since Agora is actively working on new delegation designs (e.g. liquid delegation).		 nope
CHEFFO

Spectacular. Always great to know that Verbs are on it. Knowing that these updates can be added to sub-dao stacks is truly inspiring and humbling. These are the robust building blocks that make NounsDAO eco system so special and hard to understand for most project leaders, “DAOS” and NFT “maxi”.

It is hard to overstate the innovation that is happening in these updates and contracts. Most other NFT projects have zero tech…a simple “get lucky” dapp, and that’s it…the remaining holder experience is a Token Proofed event…a few times a year. That is 99% of NFT projects.

Thru Verbs, we are going to see automation, filtration, customization, modulation; as well as audits and on-going proper maintenance. Thank you for all the hard work and big brain. These features, voted on and baked into the CCO code stack, are the foundational tech elements that all other tech builders in the eco system rely on to grow and innovate.

9999

This is a great list of upgrades. Thanks for compiling it.

I think standardizing a multisig and milestone system for the DAO (milestone-based proposal payments) and increase on-chain transparency for multisig / pod spending are both important longer term goals. The adhoc systems that are in place right now more or less work: an assessment of trust is made when the proposal is being voted on, folks like maty keep an eye on spending, and we haven’t had any major issues.

However, we do have a gap in technical capabilities for proposal creation for holders and delegates with 1 vote. Currently there is high friction for single vote holders to coordinate and get a proposal on-chain. For single vote delegates, it is currently impossible to coordinate because they do not have the ability to re-delegate to another address. I believe the tools developed for autonomous proposals would empower a larger number of voters than any of the other ideas in the backlog and so would advocate for bumping it to HIGH.

jacob

Airdrops

The DAO has had a long standing issue where it cannot easily pay for proposals in Nouns directly. In the past, we’ve had to instantiate a trusted acquisition committee to acquire nouns, which had the effect of dissuading and blocking new entrants: it was also a cumbersome process generally.

I would love to see Aidrops implemented as a direct and scalable solution to this problem: the DAO can issue new Nouns outside of the daily auction via proposal.

This would allow the DAO to easily include Nouns as compensation in proposals, which may reduce the amount of ETH that needs to be spent as well as align incentives for the long term.

By ensuring this can only happen by proposal, the DAO will only issue these Nouns if it thinks the proposal will create more value than the dilution.

Link to NFT that timestamps this idea.

AndrewLaddusaw

Would love your thoughts on this as a low tech solution to the milestone based prop payments: The Nouns Trust

As far as @verb-e, this list looks great. Keep up the awesome work. :raised_hands:

0xDigitalOil

Great GDoc on Ragequit. Good coverage and very well thought out.

To make sure I got it right –

  1. Ragequit serves as a mechanism against 51% attack assuming that the quits can be executed on demand faster than the prop voting delays.
  2. Does not serve against a different attack vector where the attacker finds vulnerability in the contracts and circumvents transacting through the regular prop flow.

More than mitigating the 51% attack vector, seems more likely to be implemented due to:

  1. Great mechanism to justify getting rid of the veto.
  2. Nouners that bought in cheap wanting to arbitrage for bv, or at least have exit liquidity at bv which is 96% above secondary floor price.
AndrewLaddusaw

Can you help me understand why we would want a ragequit mechanism versus unhappy people just selling their nouns on secondary? I don’t think I’m understanding the purpose of it or how it protects against a 51% attack at all.

0xDigitalOil

Secondary exit liquidity is low because you can always just buy the next Noun.

Ragequit enables exit liquidity to near or at book value on demand.

It protects against a 51% attack assuming that everyone gets a chance to quit the DAO and get ETH back before the 51% attack can take place, assuming that the attack takes place through a DAO prop which will have an inherent delay before it is executed and the attack actually takes place.

Hope that helps.

davidbrai

Thanks @0xDigitalOil

  1. Ragequit serves as a mechanism against 51% attack assuming that the quits can be executed on demand faster than the prop voting delays.

Correct. Ragequit would either be possible to call immediately, or during a proposal’s timelock delay.

It also serves as a protection in case the veto gets captured. One would be able to ragequit in case a proposal is vetoed.

  1. Does not serve against a different attack vector where the attacker finds vulnerability in the contracts and circumvents transacting through the regular prop flow.

Correct. Hard to protect against smart contract vulnerabilities with smart contracts.

  1. Great mechanism to justify getting rid of the veto.

It has pros & cons compared to the veto, but it opens up the possibility to change/remove how veto works.

  1. Nouners that bought in cheap wanting to arbitrage for bv, or at least have exit liquidity at bv which is 96% above secondary floor price

The financial/price impacts of ragequit can’t be ignored and would need to be taken into account. In the gdoc we tried to outline the different possibilities there.

0xDigitalOil

Had a bit more time to read through the list after I initially just commented on the ragequit research doc.

Regarding priorities, I would love to chime in:

  1. Gas refund on prop execution is a nice-have, but I would probably move to medium given other titles that would have higher impact and limited dev bandwidth.
  2. Same for increase on-chain transp for multisig spending – nice have but its audit use would probably not be that high, so medium.
  3. Vote editing would make higher priority as a heavy voting block could accidentally sway a prop the wrong way. I’ve already voted the wrong way on some props, so I know what it feels like.
  4. Private voting is probably the highest impact of them all imho and should be moved to high, as I have a hunch that various props are passing that wouldn’t if it weren’t for social consequences. I would be interested in lending a hand in finding and producing a ZK voting solution for the DAO.
  5. Proposal description amendments and even prop transaction amendments before voting I would move to medium.

The rest looks great to me.

As far as ragequit research, where do we stand on running testing and eventual deployment of such? Any timelines in mind?

Thanks for all verbs.

Cheers

yitong

Hello! very excited to see you guys thinking about what’s next! Some ideas:

  1. Wanna support some way to get builders paid with Nouns. Maybe can be done without new issuance by simply running a prop to fund an autobidder contract.
  2. Would love to see something around a dynamic voting period, where the larger the funding request, the longer the voting time. (I see you already have this in your idea list)
  3. General QOL improvements like vote editing and proposal amendment before voting start would be great too.

Other items on your list are exciting too! just highlighting some that stood out to me.

davidbrai

Thanks for the feedback @0xDigitalOil !

As far as ragequit research, where do we stand on running testing and eventual deployment of such? Any timelines in mind?

We’re currently getting inputs from the foundation lawyers regarding risks involved with the different ragequit design options we outlined in the document shared above.
Following that, we plan to bring the different design options to a more public debate, potentially with some token weighted voting to understand which version of ragequit the DAO is in favor of implementing.
Next after that would be implementation, audit & on-chain prop.

Hard to give a timeline right now. This can be a very big change to the DAO so we are being careful with decision making here.

verb-e

Thank you @AndrewLaddusaw! I think the idea of electing a small group of people to hold props accountable is definitely worth trying!

Haven’t done enough deep thinking on how we’d like to solve this challenge; I suspect we might want to join forces with your idea, perhaps set up the on-chain milestone-based funds release such that it listens for votes of this trusted group.

verb-e

Thank you @0xDigitalOil for reviving the idea of making sure proposal execution doesn’t interact with any malicious code.

Adding this problem to our backlog. I think it could be great if we had an automatic system like what @solimander has been doing here.

davidbrai

Another potential idea for the backlog:

When creating a proposal, allow to optionally set a longer voting dela and/or voting period.
The rational is to already put a proposal on chain, but not force a decision to made very quickly. Give room for discussion.

enti

I’m a bit late to this brainstorm, but on milestone-based proposal payments, I’d suggest you guys read on the research by BlockScience and PrimeDAO on DAO2DAO collaboration (which ends up with what they call a proposal inverter).

I won’t go deep into it here, and I’m not involved with the end product (happy to make the connection), but I believe learning from their research, or making use of the Inverter Network would unlock better accountability for proposals as well as more collaboration potential within all Nouns forks and other DAOs in the broader Ethereum ecosystem.