0xffaf…8d99

All memos sent from and to 0xffaf…8d99.

0xffaf6202…8d99sent to0xf790a5f5…13652025-02-14·#21,847,566·0xc884ea00…06e5e3

https://github.com/nounsDAO/nouns-monorepo/pull/877

0xffaf6202…8d99sent to0x6f3e6272…223d2025-02-12·#21,831,278·0x7d799c75…ca3c45

# Data Contract V2: DUNA Admin Communications ## Summary This proposal upgrades the data contract to support onchain communications between DUNA administrators and DAO members. The upgrade adds functionality for admins to signal proposal compliance, post announcements, and receive questions from voters. This change supports Nouns DAO's transition to a Wyoming DUNA by enabling transparent, onchain administrator communications. ## Audit Given the low-stakes nature of the data contract (which only emits events) and the simplicity of the changes, this upgrade was not formally audited. The changes have been reviewed internally by the verbs team. ## Changes in Detail ### Admin Compliance Signaling - Admins can signal whether a proposal is compliant, non-compliant, or undetermined (by using 0, 1, and 2 respectively) - Each signal includes a reason string for context - Helps token holders make informed voting decisions with compliance context ### Admin Communications - Admins can post announcements and updates (e.g., financial reports, legal agreements) - Messages can reference specific proposal IDs for better context - Creates a permanent onchain record of admin communications ### Voter Communications - Voters (addresses with ≥1 vote) can post questions to admins - Questions can reference specific proposals - Enables transparent Q&A between the community and administrators ## Configuration Parameters - dunaAdmin: The administrator's address (modifiable by treasury or current admin) Once both admins are elected, we recommend they set up a multisig account and then create a proposal that sets the dunaAdmin account on this contract, using the function setDunaAdmin. ## Transaction ``` nounsDAODataProxyAdmin.upgradeTo(0x513e9277192767eb4dc044A08da8228862828150) ``` - Upgrades the data contract implementation

0xffaf6202…8d99sent to0xf790a5f5…13652025-01-28·#21,725,692·0x590f0479…d3745b

0xffaf6202…8d99sent to0x6f3e6272…223d2025-01-06·#21,566,051·0xcad443a6…6fedb2

# Auction House V3 Upgrade - Bidder Sanctions Check ## Summary This proposal upgrades the Auction House contract to V3, adding sanctions compliance by checking bidders against the Chainalysis Sanctions List oracle. Bids from sanctioned addresses will be rejected. This upgrade is essential for complying with OFAC sanctions requirements, as recommended by our legal advisors, as part of [becoming a Wyoming DUNA](https://www.nouns.camp/proposals/662). The oracle is a non-upgradeable contract that tracks sanctioned addresses. It is a free public good, and Chainalysis frequently updates the sanctioned accounts list with no change needed on our side. For more information about the oracle, see the [Chainalysis Oracle documentation](https://go.chainalysis.com/chainalysis-oracle-docs.html). ## Audit The changes were reviewed by [hyh](https://audits.sherlock.xyz/watson/hyh), the lead auditor from our previous Sherlock audits. While the review highlighted potential risks related to oracle manipulation affecting auction execution, these risks were deemed acceptable given that the specific oracle we selected (Chainalysis) is non-upgradeable and has a secure implementation. The full audit review can be found [here](https://github.com/nounsDAO/nouns-monorepo/pull/876#pullrequestreview-2525723203). ## Changes in Detail - Added sanctions check to the \`createBid\` function - Bids from addresses flagged by the oracle as sanctioned will revert - Check is performed using Chainalysis' non-upgradeable oracle contract - No changes to auction settlement or other auction mechanics ## Configuration Parameters - Sanctions Oracle Address: [0x40C57923924B5c5c5455c48D93317139ADDaC8fb](https://etherscan.io/address/0x40C57923924B5c5c5455c48D93317139ADDaC8fb) (modifiable via proposal) ## Transactions 1. auctionHouseProxyAdmin.upgrade(auctionHouseProxy, NounsAuctionHouseV3) - Upgrades Auction House implementation to V3 2. auctionHouseProxy.setSanctionsOracle(0x40C57923924B5c5c5455c48D93317139ADDaC8fb) - Sets the Chainalysis Sanctions List oracle address

0xffaf6202…8d99sent to0xf790a5f5…13652025-01-06·#21,565,996·0x814abdf4…62cd5d

0xffaf6202…8d99sent to0x6f3e6272…223d2024-12-12·#21,387,734·0xc71f8491…478eec

# Nouns Auction House V3 Upgrade: Escrowed Streams ## Summary This proposal upgrades the Auction House contract to V3 and introduces stream-based minority protection. Upon auction settlement, 20% of proceeds go directly to the DAO treasury, while 80% are placed in a non-custodial escrow contract that streams funds to the DAO over 973 days (approximately 2.7 years). Noun owners can cancel their stream at any time by returning their Noun to the DAO and receiving their unstreamed funds back. ## Context As part of Nouns DAO's incorporation as a Wyoming Decentralized Autonomous Unincorporated Non-profit Association (DUNA), we are replacing the fork-based minority protection with cancellable streams to comply with DUNA requirements regarding member distributions. This redesign allows Noun holders to exit by returning their Noun to the DAO and receiving their unstreamed funds back. For more information regarding the DUNA incorporation, please read [the Noun Foundation's blog post](https://foundation.nouns.wtf/2024/09/06/duna/) and [the recent proposal that funded the transition](https://www.nouns.camp/proposals/662). ## Audit - Number of high severity issues found: 0 - Number of medium severity issues found: 0 - [See the preliminary report here](https://github.com/nounsDAO/nouns-monorepo/blob/verbs-stream-escrow-nouner-can-create-stream/packages/nouns-contracts/audits/2024-12-12_nouns-dao-auction-streams-preliminary-audit-report-1734007690.pdf) ## Changes in Detail ### Example Flow - Alice wins a Noun auction for 10 ETH - Upon settlement: - 2 ETH (20%) goes directly to the DAO treasury - 8 ETH goes to the StreamEscrow contract - A new stream is created that sends \~0.0082 ETH per day to the DAO over 973 days - If Alice cancels after 243 days (\~25% of stream duration): - Her Noun returns to the DAO treasury - She receives her remaining \~6 ETH back - The DAO keeps the \~2 ETH already streamed ### Auction House Changes - Splits auction proceeds between immediate treasury payment and StreamEscrow - Creates a new stream for each auctioned Noun - Advances all streams' clocks upon each auction settlement ### StreamEscrow Contract - Non-custodial, non-upgradeable contract - Manages all streams in a single contract for gas efficiency - Streams advance with each auction settlement (minimum 24 hours between advances) - Stream owners can: - Cancel their stream and receive unstreamed funds - Fast-forward their stream to send funds to the DAO faster - Stream rights transfer with Noun ownership ### Past Nouns and Nounder Nouns - Nouns auctioned before this upgrade will not have streams - Nounder Nouns will not have streams as they were not purchased ### Voting rights This stream design does not change how voting rights work. A Noun continues to represent one vote. ### Rationale for stream length and initial payment values #### Initial payment - Reasons for setting a higher value - The initial payment helps us deter abusive bidding behavior. If there was no initial payment bidders could win an auction and immediately cancel their stream and get a full refund, and would therefore stunt the growth of our community - It should be high enough to deter abuse of client incentives; specifically the reward on auctions is 5% of the winning bid. If this initial payment parameter is set lower than 5%, clients have an incentive to buy Nouns and cancel to gain the difference - Client incentives total rewards are at 10% of auctions; setting the initial payment above the total rewards rate seems like a good anchor, to avoid paying for incentives more than the DAO keeps in the case of cancelled streams - Reasons to lower the value - More funds still in escrow increase minority protection (a hostile majority can’t use those funds) #### Stream length - Reasons for setting a higher value - Funds vest to the DAO at a slower rate, so the DAO’s treasury accumulates less excess funds, therefore the “honeypot” for potential attackers is minimized - Reasons to lower the value - The DAO might want more funds available sooner to fund certain proposals We recommend targeting a Noun’s exit value at roughly 50% of its auction price after one year. There is no specific logic to this part, it’s mostly an idea to get started with. This anchor helps us think about these two parameters together. Here’s a chart of how these parameters interact to achieve our target exit value: ![](https://i.imgur.com/lpv6YNb.jpeg) The two options we highlighted are: - Option 1: - Initial payment: 10% - Stream length: 821 days (2.2 years) - Option 2: - Initial payment: 20% - Stream length: 973 days (2.7 years) We are recommending option 2, because we think it’s valuable to have a meaningful margin between the initial payment value and the client incentives rate (currently at 10%). ## Configuration Parameters ### Auction House (Upgradeable) - StreamEscrow address (modifiable via proposal) - Initial treasury payment: 20% (modifiable via proposal) - Stream length: 973 ticks ≈ 2.7 years (modifiable via proposal, only affects new streams) ### StreamEscrow (Not Upgradeable) - Minimum tick duration: 24 hours (immutable) - DAO executor address, the address that can modify all other parameters (modifiable by the executor address via proposal) - ETH recipient address (modifiable via proposal) - Nouns recipient address (modifiable via proposal) - Allowed stream creators list (modifiable via proposal) ## Post-Upgrade Changes Noun owners will have access to new functionality through Nouns client applications that choose to support these features: - View their active streams and remaining funds - Cancel streams to exit and receive remaining funds - Fast-forward streams to fund the DAO faster This change is fully backwards-compatible. Auction clients do not need to change anything. ## Transactions 1. auctionHouseProxyAdmin.upgrade(auctionHouseProxyAddress, newAuctionHouseLogicAddress) 2. auctionHouseProxy.setStreamEscrowParams(immediateTreasuryBPs, streamLengthInTicks, streamEscrowContractAddress) - immediateTreasuryBPs = 2000 (20% of each auction's winning bid goes straight to the treasury) - streamLengthInTicks = 973 (roughly 2.7 years)

0xffaf6202…8d99sent to0xf790a5f5…13652024-12-12·#21,387,717·0x8f0199a3…f1c166

0xffaf6202…8d99sent to0xf790a5f5…13652024-10-07·#20,916,845·0x795b45fa…0cc9ce

cancel-stream-for-prop-646-part-1

0xffaf6202…8d99sent to0x6f3e6272…223d2024-10-02·#20,878,087·0x4c5d311a…ed4d8e

# Stream-based minority protection - audit funding In this proposal, we are requesting funding to audit the smart contract changes necessary to introduce the new stream-based minority protection design. We begin by sharing the thought process that led to this design and conclude with the funding request. We are using this proposal to get a clear signal from the DAO: do you want us to code and deploy this design? For an overview of how the suggested mechanism would work, please read this [recent spec](https://mirror.xyz/verbsteam.eth/GYWRLqAC0heMC_2Fhc0ez0Mchxp_MCUIjoyt8UPGwrs). The essence of minority protection is allowing members to leave while taking some funds, thereby minimizing the potential gains of a majority attack on the DAO. We cannot continue with the fork as it is currently designed because DUNAs do not allow distributions to members, especially those that result in profit. We considered several alternatives before settling on the streams design: ### Option 1: No minority protection As long as Nouns has a significant treasury and members can join permissionlessly, it will continue to be a honeypot—meaning there is an incentive to acquire enough voting power to take control of the treasury. A 51% attack is the extreme case, but there are more subtle scenarios, as 4156 wrote in this [post](https://deepfried.horse/2023/03/13/rage-quit/). ### Option 2: Vanilla ragequit Similar to the reasons why the fork mechanism is not allowed, a DUNA cannot make distributions to its members, especially those that result in profit. ### Option 3: Capped ragequit Setting the exit value to the original auction amount is not feasible. Since the DAO primarily spends funds rather than generates them, it cannot guarantee having enough funds to pay back everyone. Taking this into account, we could set the exit value similarly to ragequit but cap it at the original auction price of that noun to eliminate the opportunity for profit. However, there are several issues with this option. Firstly, profit is denominated in USD. If ETH appreciates between the auction and the exit time, it would be considered profit for tax purposes. To address this, we would need to change the auctions to be in USD instead of ETH. Secondly, this approach is still too similar to a distribution to members due to the basic ragequit calculation of dividing the treasury assets by the number of nouns. ### Option 4: Proportional exit This is the mechanism originally suggested by wag, in which the exit value of a noun is determined relative to the contribution it made in its auction, while taking into account all the expenses since it joined. This is similar to capital accounts used in partnerships. While considering this option, we encountered significant technical challenges that were not trivial to solve. Additionally, we were advised that this option would not work well within the constraints of a DUNA. ### The benefits of the escrowed streams In this design, upon auction settlement, the auction proceeds go into an escrow contract that streams the funds from the buyer to the DAO. The buyer can return their noun, cancel the stream, and receive any unstreamed funds. If a stream is canceled, the unstreamed funds never belonged to the DAO in the first place. This means there is no transaction between the DAO and the noun holder, eliminating distributions and, consequently, the possibility of profit. We believe that providing minority protection without the risk of making distributions is an ideal “sweet spot.” ### What are some downsides? The primary downside of this design is limited liquidity for the DAO. Funds are not immediately available, which restricts the DAO. Another downside is the risk of reduced minority protection compared to the fork. If the amount of already streamed funds grows large, it reintroduces the honeypot risk. To mitigate this risk, the DAO is encouraged to spend the funds soon after they are streamed. Additionally, this design involves giving up group exit in favor of individual exit. We do not have a fully developed and advisor-approved design for group exits but remain optimistic that it can be achieved. We chose to focus on individual returns for simplicity, which reduces the risk of unexpected bugs and time delays. We can explore a fork-like group-return design in the future and strongly believe that implementing this simpler version is the right decision given the DAO’s current context. ## Audit funding request We do not have a mainnet-ready version of this code, so we do not have an exact quote from our auditors. Our funding request is based on their estimate plus an uncertainty buffer of 40%. A spec of the change is available [here](https://mirror.xyz/verbsteam.eth/GYWRLqAC0heMC_2Fhc0ez0Mchxp_MCUIjoyt8UPGwrs). - Sherlock estimate: $55K - 40% uncertainty buffer: $22K - Budget for post-audit fix reviews: $5K ($500 x 10 hours) - Total request: $82K This proposal’s single transaction approves the verbs multisig to spend the requested budget, [similar to past audit funding requests](https://www.nouns.camp/proposals/505). Unused funds will remain in the treasury. Thanks! [elad](https://warpcast.com/el4d) & [david](https://warpcast.com/davidbr) verbs team ⌐◨-◨

0xffaf6202…8d99sent to0xa5bf9a9b…33a42024-09-24·#20,820,663·0xaa55f392…486b74

On May 31, 2024, we posted [our previous propdate](https://www.updates.wtf/update/458-2). In that propdate we shared our desire to talk to the community more often about the DAO’s protocol/solidity needs and priorities. Shortly after that post we began working with the Foundation on their exploration of an alternative legal structure, which required discretion until we were ready to share the results of our efforts. Because a core value of ours is to be as transparent and open as possible, this was a frustrating period for us, and we are aware it has had a negative impact on our relationship with the community. Now that more information is public, we’re excited to share more about what we’ve been working on. ## Nouns (NFT) Governor * At the beginning of June we started working on a granular delegation design, in order to get the core benefit of Nouns Governor without the significant security risk we had discovered in May. We wrote some internal specs and [proof of concept code](https://github.com/verbsteam/granola/commits/main/). * On June 10th we posted [the feasibility issue we encountered](https://mirror.xyz/verbsteam.eth/gnTdSqqiZC7OmqL8Dix-hEek5Sim1abC1BsZNm9_h-s). * On the same day we made a first attempt at a [farcaster channel + rounds.wtf round](https://warpcast.com/el4d/0x2a329e83) to have more protocol discussions. * On June 24 we started the DUNA exploration project, which quickly led to the decision to pause work on granular delegation. ## DUNA Exploration * On June 24th we spent the week with the foundation and its advisors kicking off the long and challenging process of exploring and recommending a new legal structure for the DAO. It has been our active project ever since. * A major area of exploration was minority protection. We explored various versions including no exit, proportional exit, and various refund mechanisms. This work included many starts and stops, internal spec documents, proof of concept code, back and forth discussions with advisors, and frequent discussions with foundation members and other DAO members. * Other areas of exploration included past and present compliance, including analysis of past transactions, and speccing how the DAO should operate within the new DUNA structure. This work touches on topics such as tax, AML/OFAC compliance and KYC, and how protocol design can best support DAO/DUNA needs. * While this is an ongoing area of research with some sensitivities, if there’s a particular area of work you would like to get more details on, please reach out to us. ## What’s Next Assuming the DAO votes to transition to a DUNA structure, we will work on relevant protocol changes; some examples: * **Minority protection with Streams**: starting with getting consensus on the mechanism described [here](https://mirror.xyz/verbsteam.eth/jFi5T0aehwZws7Q6jdRn8xZmORu25TiyWz4G5LAHuaU) via proposal. * **Sanctions check** on bidders participating in the auction. * **KYC** **grant recipients** as part of the proposal lifecycle. If the DUNA transition does not occur, we will reevaluate our priorities and communicate with the community promptly.

0xffaf6202…8d99sent to0x6f3e6272…223d2024-08-06·#20,469,962·0x37034c5e…58fe3c

I believe in the team, I believe what they are doing adds beauty to our world in a time when we need it more than ever. LFG nounish!

0xffaf6202…8d99sent to0xa5bf9a9b…33a42024-05-31·#19,992,541·0xe785c3d2…a7fa7e

### Client Incentives - DAO and auction house upgrades executed via prop 532 - Prop 545 approved the first 10 clients! - Prop 550 will hopefully configure and fund the rewards contract - We’re already seeing more clients energized by this change, including [W1NT3R’s nouns.sh](https://warpcast.com/w1nt3r/0x9807d6de) ### $nouns - Implemented a minimal first version, including relevant DAO changes, request audit funding and got a No from the DAO - [The code is available on GitHub](https://github.com/verbsteam/nouns-erc20) and the factory contract deployed to mainnet and sepolia (addresses in the readme file on GitHub) ### Nouns (NFT) Governor - Developed a proof of concept with the scope we had in mind - Recently discovered potential attacks that put the design’s feasibility at risk - Working on blog posts that detail the issues we found and alternatives we’re considering ### Governance on L2 - The motivation we see behind this long-standing idea is to primarily gas cost reduction, both for proposing and voting - Our plan is to think about this problem from first principles, to list multiple approaches and articulate their pros and cons in a blog post, then ask the community for feedback so we might choose a direction that has consensus - Planning to spend more time on this soon after we resolve the Nouns Governor challenges mentioned above ### Meta - Our approach to selecting projects and designs for those projects has always been aimed at serving the DAO - The defeat of prop 536 (fungible token audit) was a flag for us that we should be talking to more people to maintain a more accurate map of “what the DAO wants/needs” - We’re actively working on improving on this front - Recently joined a Nouncil call where wag suggested we use a farcaster channel + [rounds.wtf](http://rounds.wtf) rewards to better incentivize protocol-level ideas and thoughtful feedback. We’re keen on trying this idea out very soon

0xffaf6202…8d99sent to0xf790a5f5…13652024-05-23·#19,935,211·0x28ee9dcb…4322b0

additional-resources-for-rounds.wtf-development

0xffaf6202…8d99sent to0xf790a5f5…13652024-05-23·#19,934,345·0x6e624517…b328fa

fund-retroactive-rounds-via-rounds.wtf

0xffaf6202…8d99sent to0xf790a5f5…13652024-05-23·#19,934,322·0xf74edc54…254bea

fund-retroactive-rounds-via-rounds.wtf

0xffaf6202…8d99sent to0x6f3e6272…223d2024-05-12·#19,855,693·0xe774d5eb…7dcf54

+1 > memes w dreams

0xffaf6202…8d99sent to0x6f3e6272…223d2024-05-08·#19,828,563·0x166eb3dc…1167ca

# Nouns Fungible Token: audit funding ## TLDR Asking for 45,625 USDC to audit the $nouns ERC20 token contract and DAO upgrade with Sherlock. ## Context The $nouns token is designed to be the canonical ERC20 token backed by Nouns. Any Noun could be deposited into the $nouns contract in order to mint e.g. 1M $nouns. Anyone holding 1M $nouns would be able to redeem them for a Noun from the $nouns contract. For deeper context please see: * [The token spec](https://docs.google.com/document/d/1Uz4l8bAPaA2_gsUVZsZo_1dAmggAiYIn5sYba1IK10Q/edit?usp=sharing). * [A discussion thread about the spec](https://warpcast.com/el4d/0xddc72a34). ## Scope We’re deploying a new token factory on mainnet, that lets anyone create a new NFT-backed ERC20 token: * They have a fixed exchange rate, e.g. 1 NFT = 1M ERC20 tokens. * The ERC20 token has an Owner account that can upgrade it, as well as disable future upgrades. We’re upgrading the Nouns DAO logic contract, such that it treats its $nouns akin to how it treats DAO-owned Nouns: * The DAO’s Nouns redeemable balance is excluded from adjusted total supply. * One of the DAO’s fork parameters is the list of ERC20 tokens that get sent to fork DAOs; this upgrade rejects attempts to add the $nouns address to this list (again, similar to how we do not send Nouns to fork DAOs today). For a deeper dive you are welcome to review [the NFT-backed token Github repository](https://github.com/verbsteam/nouns-erc20), and [the DAO upgrade PR](https://github.com/nounsDAO/nouns-monorepo/pull/840). ## Audit Plan We intend to undergo a 6-day audit with Sherlock, led by [hyh](https://audits.sherlock.xyz/watson/hyh), #4 on Sherlock’s, #6 on code4rena, and lead our recent audits for client incentives and DAO V3. The audit will cost 40,625 USDC. We are also allocating 5K USDC for reviewing potential fixes after the audit (500 USDC x 10 hours). Total USDC requests: 45,625 USDC. ## Transactions Similar to the [previous audit proposal](https://www.nouns.camp/proposals/505), this proposal’s single transaction approves the verbs multisig to spend the requested budget. _Note: this approval overrides any previously set approvals, thereby removing any leftover approval balance from the previous audit._ Thanks! [elad](https://warpcast.com/el4d) & [david](https://warpcast.com/davidbr) verbs team ⌐◨-◨

0xffaf6202…8d99sent to0xf790a5f5…13652024-05-08·#19,828,537·0x5598ba59…08f1d6

0xffaf6202…8d99sent to0x6f3e6272…223d2024-05-07·#19,820,800·0xf4fdb707…eb9d0d

# Nouns Fungible Token: audit funding ## TLDR Asking for 45,625 USDC to audit the $nouns ERC20 token contract and DAO upgrade with Sherlock. ## Context The $nouns token is designed to be the canonical ERC20 token backed by Nouns. Any Noun could be deposited into the $nouns contract in order to mint e.g. 1M $nouns. Anyone holding 1M $nouns would be able to redeem them for a Noun from the $nouns contract. For deeper context please see: * [The token spec](https://docs.google.com/document/d/1Uz4l8bAPaA2_gsUVZsZo_1dAmggAiYIn5sYba1IK10Q/edit?usp=sharing). * [A discussion thread about the spec](https://warpcast.com/el4d/0xddc72a34). ## Scope We’re deploying a new token factory on mainnet, that lets anyone create a new NFT-backed ERC20 token: * They have a fixed exchange rate, e.g. 1 NFT = 1M ERC20 tokens. * The ERC20 token has an Owner account that can upgrade it, as well as disable future upgrades. We’re upgrading the Nouns DAO logic contract, such that it treats its $nouns akin to how it treats DAO-owned Nouns: * The DAO’s Nouns redeemable balance is excluded from adjusted total supply. * One of the DAO’s fork parameters is the list of ERC20 tokens that get sent to fork DAOs; this upgrade rejects attempts to add the $nouns address to this list (again, similar to how we do not send Nouns to fork DAOs today). For a deeper dive you are welcome to review [the NFT-backed token Github repository](https://github.com/verbsteam/nouns-erc20), and [the DAO upgrade PR](https://github.com/nounsDAO/nouns-monorepo/pull/840). ## Audit Plan We intend to undergo a 6-day audit with Sherlock, led by [hyh](https://audits.sherlock.xyz/watson/hyh), #4 on Sherlock’s, #6 on code4rena, and lead our recent audits for client incentives and DAO V3. The audit will cost 40,625 USDC. We are also allocating 5K USDC for reviewing potential fixes after the audit (500 USDC x 10 hours). Total USDC requests: 45,625 USDC. ## Transactions Similar to the [previous audit proposal](https://www.nouns.camp/proposals/505), this proposal’s single transaction approves the verbs multisig to spend the requested budget. _Note: this approval overrides any previously set approvals, thereby removing any leftover approval balance from the previous audit._ ## Post-Audit Steps If this audit proposal is approved, we plan on performing the following next steps once the audit is complete: 1. Deploy the token factory 2. Create a proposal to upgrade the DAO 3. Create a proposal that will: 1. Use the token factory to create the $nouns token 2. Set the DAOs’ $nouns token parameter, so the DAO logic can treat it as planned Once this setup is done, any Nouner can deposit their Nouns to mint $nouns, including the DAO by executing a proposal that would deposit DAO-owned Nouns into the $nouns contract. Thanks! [elad](https://warpcast.com/el4d) & [david](https://warpcast.com/davidbr) verbs team ⌐◨-◨

0xffaf6202…8d99sent to0xf790a5f5…13652024-05-07·#19,820,634·0x5a4ae332…8654d4

# Nouns Fungible Token: audit funding ## TLDR Asking for 45,625 USDC to audit the $nouns ERC20 token contract and DAO upgrade with Sherlock. ## Context The $nouns token is designed to be the canonical ERC20 token backed by Nouns. Any Noun could be deposited into the $nouns contract in order to mint e.g. 1M $nouns. Anyone holding 1M $nouns would be able to redeem them for a Noun from the $nouns contract. For deeper context please see: * [The token spec](https://docs.google.com/document/d/1Uz4l8bAPaA2_gsUVZsZo_1dAmggAiYIn5sYba1IK10Q/edit?usp=sharing). * [A discussion thread about the spec](https://warpcast.com/el4d/0xddc72a34). ## Scope We’re deploying a new token factory on mainnet, that lets anyone create a new NFT-backed ERC20 token: * They have a fixed exchange rate, e.g. 1 NFT = 1M ERC20 tokens. * The ERC20 token has an Owner account that can upgrade it, as well as disable future upgrades. We’re upgrading the Nouns DAO logic contract, such that it treats its $nouns akin to how it treats DAO-owned Nouns: * The DAO’s Nouns redeemable balance is excluded from adjusted total supply. * One of the DAO’s fork parameters is the list of ERC20 tokens that get sent to fork DAOs; this upgrade rejects attempts to add the $nouns address to this list (again, similar to how we do not send Nouns to fork DAOs today). For a deeper dive you are welcome to review [the NFT-backed token Github repository](https://github.com/verbsteam/nouns-erc20), and [the DAO upgrade PR](https://github.com/nounsDAO/nouns-monorepo/pull/840). ## Audit Plan We intend to undergo a 6-day audit with Sherlock, led by [hyh](https://audits.sherlock.xyz/watson/hyh), #4 on Sherlock’s, #6 on code4rena, and lead our recent audits for client incentives and DAO V3. The audit will cost 40,625 USDC. We are also allocating 5K USDC for reviewing potential fixes after the audit (500 USDC x 10 hours). Total USDC requests: 45,625 USDC. ## Transactions Similar to the [previous audit proposal](https://www.nouns.camp/proposals/505), this proposal’s single transaction approves the verbs multisig to spend the requested budget. _Note: this approval overrides any previously set approvals, thereby removing any leftover approval balance from the previous audit._ ## Post-Audit Steps If this audit proposal is approved, we plan on performing the following next steps once the audit is complete: 1. Deploy the token factory 2. Create a proposal to upgrade the DAO 3. Create a proposal that will: 1. Use the token factory to create the $nouns token 2. Set the DAOs’ $nouns token parameter, so the DAO logic can treat it as planned Once this setup is done, any Nouner can deposit their Nouns to mint $nouns, including the DAO by executing a proposal that would deposit DAO-owned Nouns into the $nouns contract. Thanks! [elad](https://warpcast.com/el4d) & [david](https://warpcast.com/davidbr) verbs team ⌐◨-◨nouns-fungible-token-audit-funding-update-cjhxqz

0xffaf6202…8d99sent to0x6f3e6272…223d2024-05-07·#19,819,545·0x1fa9214a…a42793

# Nouns Fungible Token: audit funding ## TLDR Asking for 45,625 USDC to audit the $nouns ERC20 token contract and DAO upgrade with Sherlock. ## Context The $nouns token is designed to be the canonical ERC20 token backed by Nouns. It will enable Nouns fans to “stack $nouns” similar to how Bitcoin fans “stack sats”. Any Noun could be deposited into the $nouns contract in order to mint e.g. 1M $nouns. Anyone holding 1M $nouns would be able to redeem them for a Noun from the $nouns contract. For deeper context please see: - [Noun 40’s first cast](https://warpcast.com/noun40/0x9f03a48c) about it, and [his recent podcast with Toady](https://warpcast.com/toadyhawk.eth/0xd233a620) where he discusses the token. - [The token spec](https://docs.google.com/document/d/1Uz4l8bAPaA2_gsUVZsZo_1dAmggAiYIn5sYba1IK10Q/edit?usp=sharing). - [A discussion thread about the spec](https://warpcast.com/el4d/0xddc72a34). ## Scope We’re deploying a new token factory on mainnet, that lets anyone create a new NFT-backed ERC20 token: - They have a fixed exchange rate, e.g. 1 NFT = 1M ERC20 tokens. - The ERC20 token has an Owner account that can upgrade it, as well as disable future upgrades. We’re upgrading the Nouns DAO logic contract, such that it treats its $nouns akin to how it treats DAO-owned Nouns: - The DAO’s Nouns redeemable balance is excluded from adjusted total supply. - One of the DAO’s fork parameters is the list of ERC20 tokens that get sent to fork DAOs; this upgrade rejects attempts to add the $nouns address to this list (again, similar to how we do not send Nouns to fork DAOs today). For a deeper dive you are welcome to review [the NFT-backed token Github repository](https://github.com/verbsteam/nouns-erc20), and [the DAO upgrade PR](https://github.com/nounsDAO/nouns-monorepo/pull/840). ## Audit Plan We intend to undergo a 6-day audit with Sherlock, led by [hyh](https://audits.sherlock.xyz/watson/hyh), #4 on Sherlock’s, #6 on code4rena, and lead our recent audits for client incentives and DAO V3. The audit will cost 40,625 USDC. We are also allocating 5K USDC for reviewing potential fixes after the audit (500 USDC x 10 hours). Total USDC requests: 45,625 USDC. ## Transactions Similar to the [previous audit proposal](https://www.nouns.camp/proposals/505), this proposal’s single transaction approves the verbs multisig to spend the requested budget. *Note: this approval overrides any previously set approvals, thereby removing any leftover approval balance from the previous audit.* ## Post-Audit Steps If this audit proposal is approved, we plan on performing the following next steps once the audit is complete: 1. Deploy the token factory 2. Create a proposal to upgrade the DAO 3. Create a proposal that will: 1. Use the token factory to create the $nouns token 2. Set the DAOs’ $nouns token parameter, so the DAO logic can treat it as planned Once this setup is done, any Nouner can deposit their Nouns to mint $nouns, including the DAO by executing a proposal that would deposit DAO-owned Nouns into the $nouns contract. Thanks! [elad](https://warpcast.com/el4d) & [david ](https://warpcast.com/davidbr)verbs team ⌐◨-◨

0xffaf6202…8d99sent to0xf790a5f5…13652024-05-07·#19,819,433·0xa66fc086…7be4f9

# Nouns Fungible Token: audit funding ## TLDR Asking for 45,625 USDC to audit the $nouns ERC20 token contract and DAO upgrade with Sherlock. ## Context The $nouns token is designed to be the canonical ERC20 token backed by Nouns. It will enable Nouns fans to “stack $nouns” similar to how Bitcoin fans “stack sats”. Any Noun could be deposited into the $nouns contract in order to mint e.g. 1M $nouns. Anyone holding 1M $nouns would be able to redeem them for a Noun from the $nouns contract. For deeper context please see: - [Noun 40’s first cast](https://warpcast.com/noun40/0x9f03a48c) about it, and [his recent podcast with Toady](https://warpcast.com/toadyhawk.eth/0xd233a620) where he discusses the token. - [The token spec](https://docs.google.com/document/d/1Uz4l8bAPaA2_gsUVZsZo_1dAmggAiYIn5sYba1IK10Q/edit?usp=sharing). - [A discussion thread about the spec](https://warpcast.com/el4d/0xddc72a34). ## Scope We’re deploying a new token factory on mainnet, that lets anyone create a new NFT-backed ERC20 token: - They have a fixed exchange rate, e.g. 1 NFT = 1M ERC20 tokens. - The ERC20 token has an Owner account that can upgrade it, as well as disable future upgrades. We’re upgrading the Nouns DAO logic contract, such that it treats its $nouns akin to how it treats DAO-owned Nouns: - The DAO’s Nouns redeemable balance is excluded from adjusted total supply. - One of the DAO’s fork parameters is the list of ERC20 tokens that get sent to fork DAOs; this upgrade rejects attempts to add the $nouns address to this list (again, similar to how we do not send Nouns to fork DAOs today). For a deeper dive you are welcome to review [the NFT-backed token Github repository](https://github.com/verbsteam/nouns-erc20), and [the DAO upgrade PR](https://github.com/nounsDAO/nouns-monorepo/pull/840). ## Audit Plan We intend to undergo a 6-day audit with Sherlock, led by [hyh](https://audits.sherlock.xyz/watson/hyh), #4 on Sherlock’s, #6 on code4rena, and lead our recent audits for client incentives and DAO V3. The audit will cost 40,625 USDC. We are also allocating 5K USDC for reviewing potential fixes after the audit (500 USDC x 10 hours). Total USDC requests: 45,625 USDC. ## Transactions Similar to the [previous audit proposal](https://www.nouns.camp/proposals/505), this proposal’s single transaction approves the verbs multisig to spend the requested budget. *Note: this approval overrides any previously set approvals, thereby removing any leftover approval balance from the previous audit.* ## Post-Audit Steps If this audit proposal is approved, we plan on performing the following next steps once the audit is complete: 1. Deploy the token factory 2. Create a proposal to upgrade the DAO 3. Create a proposal that will: 1. Use the token factory to create the $nouns token 2. Set the DAOs’ $nouns token parameter, so the DAO logic can treat it as planned Once this setup is done, any Nouner can deposit their Nouns to mint $nouns, including the DAO by executing a proposal that would deposit DAO-owned Nouns into the $nouns contract. Thanks! [elad](https://warpcast.com/el4d) & [david ](https://warpcast.com/davidbr)verbs team ⌐◨-◨nouns-fungible-token:-audit-funding

0xffaf6202…8d99sent to0x6f3e6272…223d2024-04-24·#19,728,255·0x88e56bec…ef7742

+1 > Proposing to change important params in this plain and faceless manner should be considered an attack on the dao. Voting against based on that.

0xffaf6202…8d99sent to0x6f3e6272…223d2024-03-05·#19,368,979·0xcc5685b1…9278d3

Love to see an art prop, just not excited about the art.

0xffaf6202…8d99sent to0x6f3e6272…223d2024-03-04·#19,358,420·0x353cd2a2…66c3d1

Easy yes because farcaster is the future, and because I trust seneca 100%.

0xffaf6202…8d99sent to0x6f3e6272…223d2024-02-23·#19,291,321·0xd32d6bdf…ef4155

I completely trust index's intentions in everything he has done and will do. Sad to see a friend taking this hit alone. The main argument against helping index is that it was his mistake to make, the DAO did not ask him to lend those funds, and I think all that is right. At the same time, a community is a stronger community when people have each other's back. It is a more beautiful world to live in when we get this feeling of support, that we are less alone in the world. I hope the DAO decides to help index. It'll be great for index and great for the Nouns community.

0xffaf6202…8d99sent to0x6f3e6272…223d2024-02-22·#19,279,680·0x550e2b2c…11674c

# Client Incentives: audit funding ## TLDR Asking for 88,750 USDC to audit the upgrade with Sherlock. ## Context Several months ago we discussed [the idea of client incentives](https://mirror.xyz/verbsteam.eth/vyhDmS56XvnIBFUQ65n_KgmYzkD88-UHxUitxRGw08o) (temporarily named protocol rewards at some point); the sense we got from the DAO was a hell yeah, so we went and built a V1 of this new protocol piece. We are planning to propose an upgrade that adds [client incentives V1](https://mirror.xyz/verbsteam.eth/28ONBDu7kti7cYBFBnEKgktxzuelvhuxu_jtGw9YrdU) into the Nouns protocol. In the linked V1 blog post we review the goals for this feature, the scope of this version, and some key design decisions. We also link to [the technical spec on our github](https://github.com/verbsteam/specs/blob/main/client-incentives-spec.md). ## Scope Summary We’re upgrading the DAO logic contract to V4: - Propose and vote functions now accept an optional client ID parameter that Nouns frontends can populate with their ID. - The DAO records which client ID contributed which interaction; this data is used in the Rewards contract to allocate financial rewards to clients. We’re upgrading the AuctionHouse logic contract to V2: - The bidding function accepts an optional client ID parameter, and winning bids’ client IDs are captured in the AuctionHouse state, to be used by the Rewards contract. - We’re now capturing settlement history onchain, i.e. who won each auction and the winning bid ETH value. - The above changes serve the Rewards contract with essential information for calculating client rewards, which are all configured as percentages of auction revenue in the relevant timeframe. We’re adding the new Rewards contract: - It serves as an NFT contract, allowing clients to mint their client NFT and use that token ID as their client ID in all Nouns interactions that support rewards (bids, proposals, votes). - It calculates rewards and maintains reward balances per client ID. - It allows the DAO to approve or disapprove client IDs to withdraw their rewards, giving the DAO basic spam control, while allowing clients to permissionlessly accrue potential rewards. - We’re choosing to fund this contract via DAO proposals so that any risk in this contract is capped to its balance and not the DAO’s treasury. All the changes can be seen in [PR#826](https://github.com/nounsDAO/nouns-monorepo/pull/826). ## Audit Plan Solimander has already done a deep review. The next step is a 12-day audit with Sherlock, led by [hyh](https://audits.sherlock.xyz/watson/hyh) (#4 on Sherlock’s leaderboard, #6 on code4rena’s leaderboard), and a lead auditor in the big V3 audit done by Spearbit. The 12-day audit will cost 83,750 USDC: 67,000 (Rewards) + 16,750 (20% Sherlock Fee). We are also allocating 5,000 USDC for reviewing potential fixes after the audit (500 USDC x 10 hours). Total USDC requests: 88,750 USDC. ## Transactions We’re trying something new: instead of transferring the funds to our multisig, we are creating an approval for our multisig to spend the amount of USDC we’re asking directly from the treasury. We think it’s an interesting experiment in how to give the DAO more control over its allocated funds, instead of funding multisigs and later coordinating to get excess funds back. The single transaction in this proposal is approving the verbs multisig to spend up to 88,750 USDC from the treasury. This approach can leave unused approval. To properly close the loop we will transfer the remaining allowance from the treasury back to itself, to zero out our allowance. ## Next Steps We’re hoping this audit funding proposal succeeds. Once it does we will book the audit as soon as possible. Once we’re done fixing any issues and reviewing the fixes, we will put up the upgrade proposal which will: 1. Upgrade AuctionHouse. 2. Upgrade the DAO. 3. Send initial funds to a verbs-controlled wallet, from which we will later fund the rewards contract. Once the upgrade proposal executes we will deploy the rewards contract and fund it. Thanks! [elad](https://warpcast.com/el4d) & [david ](https://warpcast.com/davidbr)verbs team ⌐◨-◨

0xffaf6202…8d99sent to0xf790a5f5…13652024-02-21·#19,277,969·0xfa4cc13a…4082db

0xffaf6202…8d99sent to0xa5bf9a9b…33a42024-01-31·#19,126,845·0x637b1794…d0803f

We've published our planned scope for Client Incentives V1. Please read the [blog post](https://mirror.xyz/verbsteam.eth/28ONBDu7kti7cYBFBnEKgktxzuelvhuxu_jtGw9YrdU) and [spec](https://github.com/verbsteam/specs/blob/main/client-incentives-spec.md). We're hoping to finish the the smart contracts development and schedule an audit soon. Any feedback is appreciated!

0xffaf6202…8d99sent to0x6f3e6272…223d2024-01-10·#18,979,277·0xcd0583c3…22cc08

I think 2024 is our "year of the mints", when we explode into the minting economy and become a significant % of mints on zora, base, etc. I hope and believe wiz will push us in that direction.

0xffaf6202…8d99sent to0x6f3e6272…223d2023-12-21·#18,836,954·0x37c1293f…047db5

Prop House IMO is one of the most exciting projects to come out of Nouns. I'm exciting for seneca and soli to go all in this year, expect it to be the best Prop House year yet! Important to note they are making sure the Nouns brand is always front and center, all their code is open source, and they are serious aspirations to become less reliant on Nouns DAO funding. What else can we ask for? :)

0xffaf6202…8d99sent to0x6f3e6272…223d2023-12-21·#18,836,862·0x54ac3ab3…c07810

# Data Contract Minor Upgrade ## TLDR - In V3 we introduced a data contract where people post candidates onchain (using events). - There’s a minor bug where we charge the candidate creation fee in case of an update to a live proposal. - There’s also a minor UX issue where the data contract allows candidates with more than 10 txs, while the DAO has a hard limit at 10. - This proposal upgrades the data contract with minor fixes for both issues. - This version is not audited; This side contract is not part of the core nouns contract, hence the risk is very low. ## Fix summary In V3 we introduced a data contract where people post candidates onchain (using events). Accounts with zero votes need to pay a small spam-protection fee to create a candidate. We use the create candidate function also as part of the flow of updating an onchain proposal that was created with signatures, as a means of collecting signatures again for the update. The primary bug is that we charge the candidate creation fee in this proposal update flow, when in fact we don’t want to charge it. The fix is not charging the candidate creation fee when the candidate is explicitly created in order to update an existing proposal, and the proposal meets certain conditions: it’s in the Updatable state, the candidate creator and the proposal proposer are the same account, and the proposal has at least one signer. The secondary issue is that candidates can be created with an invalid amount of transactions, leading to bad UX when people try to convert these candidates to proposals. The DAO’s rules for transactions are: (1) there must be at least one transaction, and (2) there must be at most ten transactions. With this fix the data contract enforces the same rules so users get pushback early on. Exact changes can be seen in [this pull request](https://github.com/nounsDAO/nouns-monorepo/pull/816). Because this change is for a side contract, which doesn’t have any access to the core nouns contracts,, we're not going through an official audit process. This change has been reviewed by solimander. ## Transaction The transaction sets the data contract proxy implementation to be the fixed version deployed [here](https://etherscan.io/address/0x624efaba6e7df177ad8ca5bee3bd62f78b304b6e#code). Thanks, the verbs ⌐◨-◨

0xffaf6202…8d99sent to0x6f3e6272…223d2023-12-18·#18,816,062·0x9a5bb306…002cc9

I trust krel 1000% in skill, knowledge and love of Nouns, and overall great intentions. To me this prop is about giving krel and his partners a chance to show us what they've got, and I'm super excited for that. I believe nouns.wtf should stop functioning as a nouns client ASAP, for multiple reasons (e.g. tech debt, wanting to remove dependencies on the foundation, wanting to see client innovation, and more); allowing Camp to go all in is an important step in that direction. As for client incentives, it's too early to assume it'll solve all our client funding needs. Until we see it running in production for a while, the right move IMO is to continue funding clients as if it's not coming. As for financial concerns raised in other votes, they are valid concerns! I think it would be great to have more offchain conversations about it.

0xffaf6202…8d99sent to0x6f3e6272…223d2023-12-08·#18,738,630·0x2899c774…391f96

# Verbs Team Extension **TLDR**: Asking to continue our engagement with nouns for another 12 months. ## Accomplishments Below are some of the things we’re proud of that came into fruition since this term started. ### Nouns Fork The fork mechanism has been used 3 times so far. To the best of our knowledge, it worked smoothly with no hiccups. This is the most significant and risky change to the Nouns protocol to date and we are happy there were no technical issues. ### Proposal candidates A new way to coordinate onchain at the pre-proposal stage. Over 100 [candidates](https://www.nouns.camp/?tab=candidates) have been created so far, and over 40 proposals were created with signers via `proposeBySigs`. We believe this widened the funnel of proposals coming into the DAO and created a space where proposers can get attention, feedback and sponsorship. ### Proposal updates The ability to update a proposal before voting starts is a simple change but seems to have been very useful. ### Blog We’ve been more actively publishing long form content on our [mirror page](https://mirror.xyz/verbsteam.eth) in an effort to increase alignment and context on the work we’re doing. ## Projects we’ve worked on this term Our first few months were dedicated to things related to the ongoing forks and arbitrage problem. This has pushed back our planned projects, but we think it was important for us to be reactive to the DAO’s needs. This work included: 1. Reconsidering the fork upgrade due to a potential attack. The original [V3 update proposal](https://nouns.wtf/vote/354) was canceled at the last minute due to [concerns](https://twitter.com/thenounders/status/1691174999451930624) over a potential attack. Together with other nouners, we were analyzing the risks of this attack in order to decide whether to go forward with the V3 upgrade. \ 2. Driving conversation in the DAO on how to mitigate arb. After the first fork, we were taking a leading role in driving the conversation in the DAO on how to mitigate the arb problem introduced by the forking mechanism. \ 3. Implementing the burn and pausing the effort due to complexity. We [implemented the burn mechanism](https://github.com/nounsDAO/nouns-monorepo/pull/803) and were ready to start a security audit of the code. After additional thought we decided that the introduced complexity was not worth the benefits and recommended that we put this on hold for now. \ 4. Modeling arb in Nouns. In an effort to find alternative ways to mitigate the arb problem, we [wrote a post](https://mirror.xyz/verbsteam.eth/W4gaOrp6NC6jopc6vGsGuhz3o4ej0G_0TFhBlcLed94) modeling the arb and showing which potential levers the DAO has to address the problem. [Proposal 439](https://www.nouns.camp/proposals/439) increased the fork threshold as a followup to our research and seems to have at least broken the status quo where only arb minded buyers were winning the auctions. \ 5. Nouns Governor and Client Incentives initial designs. ## Going forward We are currently focused on two big projects that we want to ship in the next term: 1. [Nouns Governor](https://mirror.xyz/verbsteam.eth/wovYOvDZym79vxBnr01WYH3pjy_r7GNSQQ1Pa9-QM3U): an NFT focused governor contract instead of the current governor bravo based contracts. We’ve outlined our motivation in [this blog post](https://mirror.xyz/verbsteam.eth/tQ64cUYlf9hwdDvY8HLs3uw2vs_XwJelp8cY9leMO6c). \ 2. [Client incentives](https://mirror.xyz/verbsteam.eth/vyhDmS56XvnIBFUQ65n_KgmYzkD88-UHxUitxRGw08o): a payment mechanism in which the nouns protocol rewards clients (frontends) for facilitating interactions with it. Other projects that we will potentially work on: 1. L2 voting: join forces with experienced teams building on L2s to explore and potentially build an L2 voting solution. 2. Private voting: work with one of the teams who participated in the private voting prop house round to build a working private voting solution for nouns. 3. Fork V2: upgrade the forking mechanism to prevent a chasing-after attack in which an attacker can follow the minority into a forked DAO and force them to quit. This becomes possible with Nouns Governor. As we did in this term, we will respond to the DAO critical or time sensitive needs as they come up. ## Compensation & terms In this proposal we are asking for a 12-month stream. We think we’ve established enough trust to try a longer stream so that we can spend less time worrying about the next proposal, and more time shipping. We still think shorter streams are essential to mitigate the DAO’s risk with new builders, and hope the DAO will continue with that standard, while being open to longer stream experiments with trusted community members. In addition, we’re committing to posting propdates every 3 months with a status report of what has been done and what is currently being worked on; your feedback is meaningful and often helps us make better decisions. The rest of the terms are similar to our previous proposals. - 12 months engagement starting February 1, 2024. - Payment done via streams controlled by the DAO, cancelable via proposal. - $37.5k per person (2) per month (12) paid in USDC. - 1.5 ETH per month for 6 months to solimander, for time spent meeting with the team, reviewing designs and code, and supporting audits and rollout. - Total: 900K USDC, 9 ETH. - Additional funding for things like audits, mandated rounds and other experiments will be requested separately as needs arise. [elad](https://warpcast.com/el4d) & [david ](https://warpcast.com/davidbr)verbs team ⌐◨-◨

0xffaf6202…8d99sent to0x6f3e6272…223d2023-12-07·#18,734,838·0xf1554f77…9aa5a4

# Verbs Team Extension **TLDR**: Asking to continue our engagement with nouns for another 12 months. ## Accomplishments Below are some of the things we’re proud of that came into fruition since this term started. ### Nouns Fork The fork mechanism has been used 3 times so far. To the best of our knowledge, it worked smoothly with no hiccups. This is the most significant and risky change to the Nouns protocol to date and we are happy there were no technical issues. ### Proposal candidates A new way to coordinate onchain at the pre-proposal stage. Over 100 [candidates](https://www.nouns.camp/?tab=candidates) have been created so far, and over 40 proposals were created with signers via `proposeBySigs`. We believe this widened the funnel of proposals coming into the DAO and created a space where proposers can get attention, feedback and sponsorship. ### Proposal updates The ability to update a proposal before voting starts is a simple change but seems to have been very useful. ### Blog We’ve been more actively publishing long form content on our [mirror page](https://mirror.xyz/verbsteam.eth) in an effort to increase alignment and context on the work we’re doing. ## Projects we’ve worked on this term Our first few months were dedicated to things related to the ongoing forks and arbitrage problem. This has pushed back our planned projects, but we think it was important for us to be reactive to the DAO’s needs. This work included: 1. Reconsidering the fork upgrade due to a potential attack. The original [V3 update proposal](https://nouns.wtf/vote/354) was canceled at the last minute due to [concerns](https://twitter.com/thenounders/status/1691174999451930624) over a potential attack. Together with other nouners, we were analyzing the risks of this attack in order to decide whether to go forward with the V3 upgrade. \ 2. Driving conversation in the DAO on how to mitigate arb. After the first fork, we were taking a leading role in driving the conversation in the DAO on how to mitigate the arb problem introduced by the forking mechanism. \ 3. Implementing the burn and pausing the effort due to complexity. We [implemented the burn mechanism](https://github.com/nounsDAO/nouns-monorepo/pull/803) and were ready to start a security audit of the code. After additional thought we decided that the introduced complexity was not worth the benefits and recommended that we put this on hold for now. \ 4. Modeling arb in Nouns. In an effort to find alternative ways to mitigate the arb problem, we [wrote a post](https://mirror.xyz/verbsteam.eth/W4gaOrp6NC6jopc6vGsGuhz3o4ej0G_0TFhBlcLed94) modeling the arb and showing which potential levers the DAO has to address the problem. [Proposal 439](https://www.nouns.camp/proposals/439) increased the fork threshold as a followup to our research and seems to have at least broken the status quo where only arb minded buyers were winning the auctions. \ 5. Nouns Governor and Client Incentives initial designs. ## Going forward We are currently focused on two big projects that we want to ship in the next term: 1. [Nouns Governor](https://mirror.xyz/verbsteam.eth/wovYOvDZym79vxBnr01WYH3pjy_r7GNSQQ1Pa9-QM3U): an NFT focused governor contract instead of the current governor bravo based contracts. We’ve outlined our motivation in [this blog post](https://mirror.xyz/verbsteam.eth/tQ64cUYlf9hwdDvY8HLs3uw2vs_XwJelp8cY9leMO6c). \ 2. [Client incentives](https://mirror.xyz/verbsteam.eth/vyhDmS56XvnIBFUQ65n_KgmYzkD88-UHxUitxRGw08o): a payment mechanism in which the nouns protocol rewards clients (frontends) for facilitating interactions with it. Other projects that we will potentially work on: 1. L2 voting: join forces with experienced teams building on L2s to explore and potentially build an L2 voting solution. 2. Private voting: work with one of the teams who participated in the private voting prop house round to build a working private voting solution for nouns. 3. Fork V2: upgrade the forking mechanism to prevent a chasing-after attack in which an attacker can follow the minority into a forked DAO and force them to quit. This becomes possible with Nouns Governor. As we did in this term, we will respond to the DAO critical or time sensitive needs as they come up. ## Compensation & terms In this proposal we are asking for a 12-month stream. We think we’ve established enough trust to try a longer stream so that we can spend less time worrying about the next proposal, and more time shipping. We still think shorter streams are essential to mitigate the DAO’s risk with new builders, and hope the DAO will continue with that standard, while being open to longer stream experiments with trusted community members. In addition, we’re committing to posting propdates every 3 months with a status report of what has been done and what is currently being worked on; your feedback is meaningful and often helps us make better decisions. The rest of the terms are similar to our previous proposals. - 12 months engagement starting February 1, 2024. - Payment done via streams controlled by the DAO, cancelable via proposal. - $37.5k per person (2) per month (6) paid in USDC. - 1.5 ETH per month for 6 months to solimander, for time spent meeting with the team, reviewing designs and code, and supporting audits and rollout. - Total: 900K USDC, 9 ETH. - Additional funding for things like audits, mandated rounds and other experiments will be requested separately as needs arise. [elad](https://warpcast.com/el4d) & [david ](https://warpcast.com/davidbr)verbs team ⌐◨-◨

0xffaf6202…8d99sent to0x6f3e6272…223d2023-11-19·#18,607,611·0x5055a6b5…2a0a78

What Krel said :)

0xffaf6202…8d99sent to0x6f3e6272…223d2023-11-19·#18,607,595·0xf285e84f…1a6d78

Let's get natural demand winning more auctions!

0xffaf6202…8d99sent to0x6f3e6272…223d2023-11-17·#18,595,001·0xb715741d…fd9315

# 🔥 The Burn: pause for now ## TLDR 1. Support dealing with the arb with current protocol nobs. 2. Pull audit funds back to the USDC payer contract. ## Description The original burn design was meant to mitigate the arb in the short term, and it did so by burning BV in excess of recent auction prices immediately, with no delay. The spec changed to give voters more coordination time, and that led to the burn no longer mitigating short term arb. We spent time discussing additional changes to combine with the burn, e.g. require noun age to fork, and decided it’s all too complex and the problem can be solved with existing tools. We wrote [the arb analysis post](https://mirror.xyz/verbsteam.eth/W4gaOrp6NC6jopc6vGsGuhz3o4ej0G_0TFhBlcLed94) after this realization, hoping to provide voters with a framework on how to take action with protocol as it currently is. Since the burn in its current spec doesn’t solve the arb and seems to have lost some consensus and momentum, we suggest dropping it at least until the current arb problem is dramatically mitigated, i.e. BV is equal-ish to natural demand. Once we’re in that reality we can revisit the value of adding the burn and certainly do so if there’s enough energy behind it! ## Transaction Withdraw the audit funds from the Tech Grants multisig back to the Payer contract, which is where the DAO holds USDC to fund proposals. Thanks! the verbs ⌐◨-◨

0xffaf6202…8d99sent to0xf790a5f5…13652023-11-10·#18,542,810·0xc5b18ee4…a20ec2

0xffaf6202…8d99sent to0x94b4fb16…d5f12023-10-23·#18,413,962·0xd65fcbbf…512004

TLDR: we're exploring additional protocol changes to better curb auction arb. The burn code has recently been reviewed by soli, and the fixes won't take long. However, that's not our main focus these days. The burn works in cycles that provide predictability, e.g. we can decide to burn every 100 Nouns. At the same time roughly 30 Nouns are required to initiate a fork given current adjusted supply and fork threshold. Assuming such parameters, arbers can safely perform up to 3 rounds of forking without being impacted by the burn. And after a burn occurs, they can continue to do so until the next burn and so on. A naive reaction to this problem is to configure fork threshold and burn cycle such that we burn before there's a fork, e.g. raise fork threshold to require just over 60 Nouns, and set the burn cycle at 60 Nouns, and there you have it. While this is certainly a possibility, there is a natural tension: * We want to keep for threshold low, for multiple reasons such as wanting the fork to truly serve minority protection * We want the burn cycle to be longer, to give the community sufficient time to coordinate funding We are therefore exploring other designs, such as: * Requiring a minimum age for a Noun to be allowed to escrow towards a fork * Initiating a burn before any fork Since such ideas have the potential to impact the burn design, we think it best to reach a decision before declaring the burn code to be final and submitting it for an audit. It might also be best to expand the audit scope to include whichever idea we land on, as they seem highly entangled, working together with the burn to achieve the arb mitigation we're aiming for. Important to restate: we want to significantly curb arb such that auctions are once again onboarding new long term Nouns players. What's next: * We will publish a blog post detailing our thinking, and share it with the community. * We will ask for feedback and help making a decision. * We will then share an updated scope and timeline. Thanks to everyone contributing to these conversations!

0xffaf6202…8d99sent to0xf790a5f5…13652023-10-20·#18,388,434·0xe59b90a5…6bdb72

issue-dao-token-redeemable-for-a-treasury-nounSeems to me there's a majority interest in iterating on granting Nouns, and reducing friction on something the DAO wants to do is a great idea. And I think using NFTs to keep record of these grants and redeem them feels legible and elegant. Let's do it.

0xffaf6202…8d99sent to0x6f3e6272…223d2023-10-05·#18,284,867·0x28f80a09…e54c1e

# 🔥 The Burn: audit funding We are planning to propose an upgrade that implements [The Burn](https://w.mirror.xyz/AmHOzH-FQZVO3IhGXHSvCRxRSf2MO6VCZdmMwNEIyKE). The goals for the burn are described in the blog post above by wilson. What's in this proposal text? * High level design details * Audit plan and budget request ($36K) The burn code is in an advanced state, and if this proposal succeeds we hope to start the audit soon after. ## Technical spec We plan to deploy a new contract, with a single function that lets burn excess ETH from the timelock. ### How much will be burned? Excess ETH is defined as the difference between the treasury value denominated in ETH, and: adjusted_total_supply * trailing_N_day_mean_auction_price. adjusted_total_supply is the number of minted nouns, excluding nouns held by the treasury or in the escrow contract. In order to calculate the treasury value in ETH, the contract will consider only ETH, stETH, rETH & WETH. All other assets are ignored. The number of auctions looked at when calculating the mean price is a configurable parameter; we suggest starting with 90. Example based on numbers close to actuals: Treasury has 2857 ETH, 10830 stETH, 228 rETH. Adjusted total supply: 394. Mean price of last 90 auctions: 30 ETH. Treasury value in ETH: 2857 + 10830 + 247 (228 worth of rETH) = 13,934 ETH. Excess ETH: 13,934 - 30 * 394 = 2114 ETH. ### What is burned? Only ETH is burned. If the Nouns runs out of ETH, it will need to swap other assets (e.g. stETH) into ETH to allow for more burn. ### When can it be called? The goal is for the burn to happen at predictable times. One parameter will define what will be the first noun id at which the first burn can happen. Another parameter will define how many noun ids need to be minted before the next burn can happen. Example: Suppose the first noun id is set to 1000, and the number of nouns between burns is set to 100. The first burn will be possible once a noun with id 1000 is minted. The next burn would be possible once a noun with id 1100 is minted. Even if the first burn actually occurs when noun 1002 is auctioned, the next burn will still be possible starting id 1100. ### Timelock upgrade The timelock will be upgraded to a new version which will allow the burner contract to call it an burn ETH. The timelock will only allow the burner contract to call it. The address of the burner contract is a configurable param. Setting it to the zero address is effectively turning off the burn mechanism. ## Audit costs Our plan is to undergo a deep code review with solimander, and an audit with [Sherlock](https://www.sherlock.xyz/). In a bit more detail: 1. Soli review (+ verbs fix things) 2. Sherlock audit 3. Verbs fix things + soli reviews fixes 4. Sherlock mitigation review We are asking for 36K USDC to be sent to the Tech Grants Pod multisig to pay for the audit. 30K USDC will go to auditors and 6K USDC will go to Sherlock. ## Next steps Funding the audit will let us know the DAO wants the burn to be deployed. Once funded we will finalize the code, undergo the audit, and follow up with a proposal to upgrade the auction house contract and the treasury contract. The upgrade will leave the burn disabled, since it seems best to separate the deployment of the mechanism from reaching consensus on its parameters. We will of course support any voters who will want to follow up with a proposal to set the burn parameters. It's also worthwhile for voters to consider converting stETH into ETH ahead of the burn, since as mentioned above this simple design only burns native ETH. ## Appendix: pseudocode ExcessETHBurner: ``` // configurable params: uint numPastAuctions; uint nextBurnNounId; uint mintsBetweenBurns; function burnExcessETH() { if (auction().nounId < nextBurnNounId) revert('Not yet'); allowedTreasuryInETH = adjustTotalSupply() * meanAuctionPrice(); excessETH = treasuryValueInETH() - allowedTreasuryInETH; amountToBurn = min(excessETH, timelock.balance); nextBurnNounId += mintsBetweenBurns; timelock.burnETH(amountToBurn); } function treasuryValueInETH() { return timelock.balance + stETH.balanceOf(timelock) + wETH.balanceOf(timelock) + rETH.getEthValue(rETH.balanceOf(timelock)); } function meanAuctionPrice() { return mean(auctionHouse.prices(numPastAuctions)); } ``` ## Appendix: current asset breakdown At the time of writing this text, [according to Etherscan](https://etherscan.io/tokenholdings?a=0xb1a32FC9F9D8b2cf86C068Cae13108809547ef71): * Total treasury value is roughly $23.15M. * Its two main assets are: * ETH at $4.391M (2631.493 ETH). * stETH at $18.061M (10830.768 stETH). * These two assets alone make up over 96.7% of the total treasury value. * USDC is roughly 1.1% of the treasury, and we’re comfortable ignoring it for the sake of code simplicity. * wstETH is roughly 0.11% and is ignored as well.updated the audit budget to 36K due to a misunderstanding with Sherlock, and fixed the intro text

0xffaf6202…8d99sent to0xf790a5f5…13652023-10-05·#18,284,836·0x9a8a64ec…042464

0xffaf6202…8d99sent to0x6f3e6272…223d2023-10-04·#18,278,839·0xa600b16a…fe3fae

# 🔥 The Burn: audit funding We are planning to propose an upgrade that implements [The Burn](https://w.mirror.xyz/AmHOzH-FQZVO3IhGXHSvCRxRSf2MO6VCZdmMwNEIyKE). The goals for the burn are described in the blog post above by wilson. This is a first draft of the proposal candidate through which we will ask the DAO to fund one or two audits of the implementation. We are putting it up even before we have quotes from auditors, in order to raise awareness among voters, stimulate the conversation, and listen to feedback. ## Technical spec We plan to deploy a new contract, with a single function that lets burn excess ETH from the timelock. ### How much will be burned? Excess ETH is defined as the difference between the treasury value denominated in ETH, and: adjusted_total_supply * trailing_N_day_mean_auction_price. adjusted_total_supply is the number of minted nouns, excluding nouns held by the treasury or in the escrow contract. In order to calculate the treasury value in ETH, the contract will consider only ETH, stETH, rETH & WETH. All other assets are ignored. The number of auctions looked at when calculating the mean price is a configurable parameter; we suggest starting with 90. Example based on numbers close to actuals: Treasury has 2857 ETH, 10830 stETH, 228 rETH. Adjusted total supply: 394. Mean price of last 90 auctions: 30 ETH. Treasury value in ETH: 2857 + 10830 + 247 (228 worth of rETH) = 13,934 ETH. Excess ETH: 13,934 - 30 * 394 = 2114 ETH. ### What is burned? Only ETH is burned. If the Nouns runs out of ETH, it will need to swap other assets (e.g. stETH) into ETH to allow for more burn. ### When can it be called? The goal is for the burn to happen at predictable times. One parameter will define what will be the first noun id at which the first burn can happen. Another parameter will define how many noun ids need to be minted before the next burn can happen. Example: Suppose the first noun id is set to 1000, and the number of nouns between burns is set to 100. The first burn will be possible once a noun with id 1000 is minted. The next burn would be possible once a noun with id 1100 is minted. Even if the first burn actually occurs when noun 1002 is auctioned, the next burn will still be possible starting id 1100. ### Timelock upgrade The timelock will be upgraded to a new version which will allow the burner contract to call it an burn ETH. The timelock will only allow the burner contract to call it. The address of the burner contract is a configurable param. Setting it to the zero address is effectively turning off the burn mechanism. ## Audit costs Our plan is to undergo a deep code review with solimander, and an audit with [Sherlock](https://www.sherlock.xyz/). In a bit more detail: 1. Soli review (+ verbs fix things) 2. Sherlock audit 3. Verbs fix things + soli reviews fixes 4. Sherlock mitigation review We are asking for 30K USDC to be sent to the Tech Grants Pod multisig to pay for the audit. ## Next steps Funding the audit will let us know the DAO wants the burn to be deployed. Once funded we will finalize the code, undergo the audit, and follow up with a proposal to upgrade the auction house contract and the treasury contract. The upgrade will leave the burn disabled, since it seems best to separate the deployment of the mechanism from reaching consensus on its parameters. We will of course support any voters who will want to follow up with a proposal to set the burn parameters. It's also worthwhile for voters to consider converting stETH into ETH ahead of the burn, since as mentioned above this simple design only burns native ETH. ## Appendix: pseudocode ExcessETHBurner: ``` // configurable params: uint numPastAuctions; uint nextBurnNounId; uint mintsBetweenBurns; function burnExcessETH() { if (auction().nounId < nextBurnNounId) revert('Not yet'); allowedTreasuryInETH = adjustTotalSupply() * meanAuctionPrice(); excessETH = treasuryValueInETH() - allowedTreasuryInETH; amountToBurn = min(excessETH, timelock.balance); nextBurnNounId += mintsBetweenBurns; timelock.burnETH(amountToBurn); } function treasuryValueInETH() { return timelock.balance + stETH.balanceOf(timelock) + wETH.balanceOf(timelock) + rETH.getEthValue(rETH.balanceOf(timelock)); } function meanAuctionPrice() { return mean(auctionHouse.prices(numPastAuctions)); } ``` ## Appendix: current asset breakdown At the time of writing this text, [according to Etherscan](https://etherscan.io/tokenholdings?a=0xb1a32FC9F9D8b2cf86C068Cae13108809547ef71): * Total treasury value is roughly $23.15M. * Its two main assets are: * ETH at $4.391M (2631.493 ETH). * stETH at $18.061M (10830.768 stETH). * These two assets alone make up over 96.7% of the total treasury value. * USDC is roughly 1.1% of the treasury, and we’re comfortable ignoring it for the sake of code simplicity. * wstETH is roughly 0.11% and is ignored as well.

0xffaf6202…8d99sent to0xf790a5f5…13652023-10-04·#18,278,599·0x9f349df5…7edc56

# 🔥 The Burn: audit funding We are planning to propose an upgrade that implements [The Burn](https://w.mirror.xyz/AmHOzH-FQZVO3IhGXHSvCRxRSf2MO6VCZdmMwNEIyKE). The goals for the burn are described in the blog post above by wilson. This is a first draft of the proposal candidate through which we will ask the DAO to fund one or two audits of the implementation. We are putting it up even before we have quotes from auditors, in order to raise awareness among voters, stimulate the conversation, and listen to feedback. ## Technical spec We plan to deploy a new contract, with a single function that lets burn excess ETH from the timelock. ### How much will be burned? Excess ETH is defined as the difference between the treasury value denominated in ETH, and: adjusted_total_supply * trailing_N_day_mean_auction_price. adjusted_total_supply is the number of minted nouns, excluding nouns held by the treasury or in the escrow contract. In order to calculate the treasury value in ETH, the contract will consider only ETH, stETH, rETH & WETH. All other assets are ignored. The number of auctions looked at when calculating the mean price is a configurable parameter; we suggest starting with 90. Example based on numbers close to actuals: Treasury has 2857 ETH, 10830 stETH, 228 rETH. Adjusted total supply: 394. Mean price of last 90 auctions: 30 ETH. Treasury value in ETH: 2857 + 10830 + 247 (228 worth of rETH) = 13,934 ETH. Excess ETH: 13,934 - 30 * 394 = 2114 ETH. ### What is burned? Only ETH is burned. If the Nouns runs out of ETH, it will need to swap other assets (e.g. stETH) into ETH to allow for more burn. ### When can it be called? The goal is for the burn to happen at predictable times. One parameter will define what will be the first noun id at which the first burn can happen. Another parameter will define how many noun ids need to be minted before the next burn can happen. Example: Suppose the first noun id is set to 1000, and the number of nouns between burns is set to 100. The first burn will be possible once a noun with id 1000 is minted. The next burn would be possible once a noun with id 1100 is minted. Even if the first burn actually occurs when noun 1002 is auctioned, the next burn will still be possible starting id 1100. ### Timelock upgrade The timelock will be upgraded to a new version which will allow the burner contract to call it an burn ETH. The timelock will only allow the burner contract to call it. The address of the burner contract is a configurable param. Setting it to the zero address is effectively turning off the burn mechanism. ## Audit costs Our plan is to undergo a deep code review with solimander, and an audit with [Sherlock](https://www.sherlock.xyz/). In a bit more detail: 1. Soli review (+ verbs fix things) 2. Sherlock audit 3. Verbs fix things + soli reviews fixes 4. Sherlock mitigation review We are asking for 30K USDC to be sent to the Tech Grants Pod multisig to pay for the audit. ## Next steps Funding the audit will let us know the DAO wants the burn to be deployed. Once funded we will finalize the code, undergo the audit, and follow up with a proposal to upgrade the auction house contract and the treasury contract. The upgrade will leave the burn disabled, since it seems best to separate the deployment of the mechanism from reaching consensus on its parameters. We will of course support any voters who will want to follow up with a proposal to set the burn parameters. It's also worthwhile for voters to consider converting stETH into ETH ahead of the burn, since as mentioned above this simple design only burns native ETH. ## Appendix: pseudocode ExcessETHBurner: ``` // configurable params: uint numPastAuctions; uint nextBurnNounId; uint mintsBetweenBurns; function burnExcessETH() { if (auction().nounId < nextBurnNounId) revert('Not yet'); allowedTreasuryInETH = adjustTotalSupply() * meanAuctionPrice(); excessETH = treasuryValueInETH() - allowedTreasuryInETH; amountToBurn = min(excessETH, timelock.balance); nextBurnNounId += mintsBetweenBurns; timelock.burnETH(amountToBurn); } function treasuryValueInETH() { return timelock.balance + stETH.balanceOf(timelock) + wETH.balanceOf(timelock) + rETH.getEthValue(rETH.balanceOf(timelock)); } function meanAuctionPrice() { return mean(auctionHouse.prices(numPastAuctions)); } ``` ## Appendix: current asset breakdown At the time of writing this text, [according to Etherscan](https://etherscan.io/tokenholdings?a=0xb1a32FC9F9D8b2cf86C068Cae13108809547ef71): * Total treasury value is roughly $23.15M. * Its two main assets are: * ETH at $4.391M (2631.493 ETH). * stETH at $18.061M (10830.768 stETH). * These two assets alone make up over 96.7% of the total treasury value. * USDC is roughly 1.1% of the treasury, and we’re comfortable ignoring it for the sake of code simplicity. * wstETH is roughly 0.11% and is ignored as well.-the-burn-heads-up-and-audit-funding-placeholderupdated audit plan and funds request, and next steps summary

0xffaf6202…8d99sent to0xf790a5f5…13652023-10-02·#18,265,344·0x0c5cd9f4…9fa0b7

# 🔥 The Burn: heads up and audit funding placeholder We are planning to propose an upgrade that implements [The Burn](https://w.mirror.xyz/AmHOzH-FQZVO3IhGXHSvCRxRSf2MO6VCZdmMwNEIyKE). The goals for the burn are described in the blog post above by wilson. This is a first draft of the proposal candidate through which we will ask the DAO to fund one or two audits of the implementation. We are putting it up even before we have quotes from auditors, in order to raise awareness among voters, stimulate the conversation, and listen to feedback. ## Technical spec We plan to deploy a new contract, with a single function that lets burn excess ETH from the timelock. ### How much will be burned? Excess ETH is defined as the difference between the treasury value denominated in ETH, and: adjusted_total_supply * trailing_N_day_mean_auction_price. adjusted_total_supply is the number of minted nouns, excluding nouns held by the treasury or in the escrow contract. In order to calculate the treasury value in ETH, the contract will consider only ETH, stETH, rETH & WETH. All other assets are ignored. The number of auctions looked at when calculating the mean price is a configurable parameter; we suggest starting with 90. Example based on numbers close to actuals: Treasury has 2857 ETH, 10830 stETH, 228 rETH. Adjusted total supply: 394. Mean price of last 90 auctions: 30 ETH. Treasury value in ETH: 2857 + 10830 + 247 (228 worth of rETH) = 13,934 ETH. Excess ETH: 13,934 - 30 * 394 = 2114 ETH. ### What is burned? Only ETH is burned. If the Nouns runs out of ETH, it will need to swap other assets (e.g. stETH) into ETH to allow for more burn. ### When can it be called? The goal is for the burn to happen at predictable times. One parameter will define what will be the first noun id at which the first burn can happen. Another parameter will define how many noun ids need to be minted before the next burn can happen. Example: Suppose the first noun id is set to 1000, and the number of nouns between burns is set to 100. The first burn will be possible once a noun with id 1000 is minted. The next burn would be possible once a noun with id 1100 is minted. Even if the first burn actually occurs when noun 1002 is auctioned, the next burn will still be possible starting id 1100. ### Timelock upgrade The timelock will be upgraded to a new version which will allow the burner contract to call it an burn ETH. The timelock will only allow the burner contract to call it. The address of the burner contract is a configurable param. Setting it to the zero address is effectively turning off the burn mechanism. ## Audit costs: TBD We will update this section once we have information from the auditors we’ve reached out to. We are still deciding between a couple of auditing approaches; here they are with some of their advantages: 1. A single audit, with explicit reviews from technical DAO members 1. Costs less. 2. Probably faster shipping time. 2. Two audits 3. Extra safe, which might be prudent given this upgrade is changing the treasury code, however simple we’ve designed the change to be. Your inputs here are welcome! ## Next steps We are engaging auditors to receive quotes and auditor availability, and will update this candidate once we have useful information for a decision. Upon sufficient consensus for the design of the burn, this candidate will become a proposal requesting funding for an audit of this upgrade. ## Appendix: pseudocode ExcessETHBurner: ``` // configurable params: uint numPastAuctions; uint nextBurnNounId; uint mintsBetweenBurns; function burnExcessETH() { if (auction().nounId < nextBurnNounId) revert('Not yet'); allowedTreasuryInETH = adjustTotalSupply() * meanAuctionPrice(); excessETH = treasuryValueInETH() - allowedTreasuryInETH; amountToBurn = min(excessETH, timelock.balance); nextBurnNounId += mintsBetweenBurns; timelock.burnETH(amountToBurn); } function treasuryValueInETH() { return timelock.balance + stETH.balanceOf(timelock) + wETH.balanceOf(timelock) + rETH.getEthValue(rETH.balanceOf(timelock)); } function meanAuctionPrice() { return mean(auctionHouse.prices(numPastAuctions)); } ``` ## Appendix: current asset breakdown At the time of writing this text, [according to Etherscan](https://etherscan.io/tokenholdings?a=0xb1a32FC9F9D8b2cf86C068Cae13108809547ef71): * Total treasury value is roughly $23.15M. * Its two main assets are: * ETH at $4.391M (2631.493 ETH). * stETH at $18.061M (10830.768 stETH). * These two assets alone make up over 96.7% of the total treasury value. * USDC is roughly 1.1% of the treasury, and we’re comfortable ignoring it for the sake of code simplicity. * wstETH is roughly 0.11% and is ignored as well.-the-burn-heads-up-and-audit-funding-placeholder

0xffaf6202…8d99sent to0x6f3e6272…223d2023-06-25·#17,553,367·0xd143553b…fbb839

No votes, just want to say Wilson has been an amazing addition to Nouns and this prop is an easy YES. And I ❤️ vwr. *sent from voter.wtf*

0xffaf6202…8d99sent to0x4976fb03…ba412022-09-29·#15,639,703·0x2434027a…14193e

avatarhttps://pbs.twimg.com/profile_images/1575497795393318913/qMfo958w_400x400.jpg