Authors: Abdullah (Arana Digital), Juanbug (PGov), Jordan (Event Horizon)
The Uniswap Accountability Committee (UAC) will from hereon, be referred to as the Uniswap Council (UC), to more aptly represent the group’s existing functions.
This proposal outlines the UC’s mandate, structural changes, and budget request for Season 5. For more details around Season 4 operations and financials, please refer to the companion Season 4 Report.
The UC is a DAO-elected entity that supports Uniswap governance by ensuring that DAO-approved initiatives are executed transparently and efficiently. It operates as an independent, community-driven body that coordinates operational tasks, oversees service providers, and maintains governance integrity without setting policy or controlling protocol development. In practice, the UC serves as a lightweight operational layer for the DAO, translating governance decisions into action while remaining fully accountable to tokenholders.
A UC season is a term during which a DAO-elected set of council members is authorized to carry out the UC’s mandate, with funding and scope renewed by governance at the end of the period.
Below are the areas that the UC presided over during Season 4
Cross-chain deployment coordination
ENS record management
Disbursement and accounting of service provider, grantee, and working groups’ compensation
Custody of DAO-approved funds on Ethereum mainnet
Incentive distribution across a multitude of EVM-compatible chains
Governance community calls
Assisting with miscellaneous DAO operations like helping teams sponsor proposals
Managing the Foundation Feedback Group (FFG) to liaise between delegates and the Foundation
Governance logistics improvements
In this proposal, we also introduce new functions to support token holders and delegates in a post-UNIfication world, as well as adjust some previous operations.
Over the past season, the organizational makeup of Uniswap has materially evolved. With Labs taking on a lion’s share of work and funding, and the Foundation winding down over time, the UC becomes the primary independent, community-driven counterweight within the ecosystem.
The UC’s mechanics remain firmly DAO-controlled. Its members are elected through Snapshot votes, and its funding must be approved by governance, which ensures that the team stays accountable. These structural constraints ensure accountability and alignment with tokenholder intent. At the same time, the UC operates as a smaller, more nimble body than the DAO as a whole, capable of responding to operational needs, coordinating service providers, and executing administrative tasks within clearly defined bounds. In practice, this positions the UC as a liaison across several DAO-adjacent functions, which are outlined in greater detail later in this report.
While the committee maintains a deliberately narrow and procedurally defined mandate, the nature of its work has increasingly taken on operational characteristics. This evolution is not unique to Uniswap. Comparable models have emerged across the ecosystem as protocols mature. Arbitrum, for example, established the Arbitrum OpCo, a DAO-elected operational organization tasked with supporting ecosystem programs, vendor oversight, and administrative continuity. ENS operates with a similar pattern through its working groups, which collectively manage grants/service providers and public-facing reporting. In each case, the DAO retains ultimate authority, while the operational unit provides structure and continuity to day-to-day processes that require reliability and professionalization.
Within this landscape, the UC occupies a similar position. While “accountability” has been foundational to the committee’s mandate, the UC now acts more as an administrative and operational body on behalf of the DAO.
As of October, 2025, the UC has been incorporated as a Delaware Nonprofit Nonstock Corporation. As per its initial mandate, the UC entity is not designed to hold profits, issue equity, or accrue economic interests. It is solely meant to support governance integrity and operational accountability within the Uniswap ecosystem. Governance is handled exclusively through a Board of Directors. The composition of the board follows DAO-based elections, as per previous seasons.
This formalization provides the UC with a recognized legal body capable of entering contracts, receiving confidential information, issuing payments, and formally interacting with the DUNI, service providers, and other partners.
Within this evolving framework, the UC functions as an independent, DAO-elected operational body that interfaces with the DUNI but is not an official “service provider” like Uniswap Labs, nor is it assigned a role like “Ministerial Agent” or “Administrator.” In this respect, the UC’s structure aligns with a growing class of DAO-adjacent legal entities akin to BORGs, which are designed to carry out certain mandates on behalf of decentralized systems while remaining constrained by governance.
Unchanged from previous seasons, the UC continues to manage two multisig addresses to conduct its operations:
Primary UC Wallet Address: 0x3B59C6d0034490093460787566dc5D6cE17F2f9C (UAC.eth)
UC Incentives Wallet Address: 0xEBCCf1ce13F63c6B98811F03964F51fC43cef851
Going forward, the UC will not be responsible for disbursing incentives. Legal and tax surface area has expanded post DUNI adoption, and future incentives will be coordinated and executed with the DUNI.
Season 4 consisted of 5 members, representing diverse skillsets and organizational associations:
Alice Corsini
Jordan Karstadt
Doo Wan Nam
Jun Sun
Abdullah Umar
Each member is a signer on the UC multisigs and now a representative on the UC entity Board. Workload is divided among members based on their individual capacities and can vary month-to-month. Multisig duties and security, however, are an evenly assumed responsibility. All members must be ready to sign transactions when needed and uphold multisig integrity without exception.
Previous UC Seasons have lasted for approximately half-a-year each. Season 4 took place between May/June until the end of December 2025. Like prior seasons, 3 members of the UC have stayed active post season 4, planning for adjustments going into Season 5.
The UC has been responsible for disbursing payments to ecosystem vendors whose work has been previously authorized by governance. This includes but is not limited to:
Tally: governance infrastructure and execution support
Forse: incentives impact analytics
Oku: alternative Uniswap front-end, aggregator, and analytics site
Merkl: incentivization infrastructure
DAO programs: structured support for delegate engagement and Uniswap-related research
Going forward, the UC will manage this function differently from how it has been approached in the past. Rather than serving as an intermediary for ad hoc governance-approved funding, future funding will likely be sent to a DUNI-associated address and payments executed by the Ministerial Agent. Payments can also be structured in a more autonomous manner with vesting contracts. We will continue to help coordinate with these teams to ensure milestones, accountability, and transparency metrics are met.
Further, the UC will move to a pre-defined internal budgetary model. Anticipated vendor and operational expenditures will be scoped and requested upfront as part of the seasonal renewal proposal. Pre-defining these budgets simplifies operations by making the UC and its projects direct counterparties. Further, we are still able to help continue our previous seasons’ scope for independent governance approved funds over the season, now leaning on the DUNI for additional support with executing payments in a compliant manner.
The UC will continue to serve as the administrative and coordination layer for cross-chain v3 deployments, working alongside deployers like Oku and Protofire to oversee deployment workflows, maintain the canonical contract registry and ENS subdomains, and support chains through the onboarding process. We will rely on closer coordination with Labs when it comes to newer v4 deployments.
More information on this function can be found here.
Treasury strategy has been a recurring topic within the Uniswap ecosystem for several years, most formally explored through the Uniswap Treasury Working Group (UTWG). While the DAO previously signaled broad interest in developing a structured investment framework, the lack of a legal wrapper and operational infrastructure prevented meaningful progress. With the establishment of DUNI and the maturation of service provider relationships, the conditions now exist to revisit this work responsibly. Recurring budget obligations and large, multi-year engagements further underscore the need for a deliberate treasury management approach.
To start, we want to emphasize that we primarily want to kick off these discussions in a formal and compliant manner post-DUNI adoption. There will be significant tasks to complete before we get to a vendor selection phase, but we believe it is a very important opportunity that should be actively discussed and focused on by the DAO.
As a result, a natural next step may be for the UC to initiate a formal Request for Proposals (RFP) to evaluate qualified treasury managers. Other large DAOs—ENS, Aave, Lido, Gnosis—have successfully partnered with firms such as Karpatkey, Steakhouse, Avantgarde, and others to manage portions of their treasuries under clearly defined Investment Policy Statements (IPS). These IPS frameworks establish risk parameters, liquidity buffers, permissible assets, rebalancing logic, and reporting requirements. Implementing a similar structure under the DUNI would transition Uniswap from reactive treasury decisions toward a durable, mandate-aligned investment framework tailored to the protocol’s long-term needs.
The presence of the DUNI also opens the UC to explore new institutional partnerships with vendors that, for legal and structural reasons, may have been off the table over the past handful of years. At present, the UC is exploring a combination of the following methodologies:
Basis Fund: Deploy UNI as collateral to capture the spread between spot and perpetual futures prices, targeting 10%+ APR; reasonable given that crypto basis spreads have historically averaged 8-20% annualized, and UNI’s moderate liquidity and higher volatility relative to BTC typically place it toward the upper end of that range.
Options: Pledge UNI collateral to systematically sell overpriced volatility via OTC options desks, targeting 15% APR; reasonable because UNI’s realized volatility consistently underperforms its implied volatility by 15-30%, creating a persistent risk premium harvestable through structured short vol strategies.
Market Making: Provide continuous two-sided liquidity across UNI spot pairs on CEXs and DEXs, earning the bid-ask spread and rebates while targeting 20% APR; reasonable given UNI’s $260M daily trading volume creates consistent flow to capture, and the persistent CEX/DEX price dislocations in mid-cap DeFi tokens offer structural arbitrage that wider spreads on UNI (relative to BTC/ETH) translate into higher per-trade margins.
Statistical Arb: Exploit mean-reversion and momentum signals across correlated pairs like UNI/ETH, UNI/AAVE, and UNI/broader DeFi indices, targeting 20% APR; reasonable because UNI’s high beta to the DeFi sector creates frequent mispricings that revert on short timeframes, and the token’s strong correlation structure (0.7-0.85 with ETH) provides reliable pairs trading relationships.
Collateralized Lending: Pledge UNI as collateral through OTC lending desks to borrow USDC at conservative LTVs, then deploy the stablecoins into high-grade yield opportunities such as T-bills, money market funds, or institutional DeFi vaults, targeting 5-10% net APR after borrowing costs; reasonable given that OTC lending desks typically offer more favorable borrowing rates and liquidation terms than onchain venues, eliminating smart contract risk and avoiding the reflexive liquidation cascades common in transparent lending markets.
Token Swaps: Execute bilateral token swaps with strategically aligned DAOs, exchanging UNI for their native governance tokens at negotiated terms, targeting long-term portfolio diversification and ecosystem alignment rather than short-term yield; reasonable given that protocol-to-protocol swaps have become an established mechanism for DAOs to diversify concentrated native-token treasuries while simultaneously deepening governance and economic relationships with key ecosystem partners. The surface area for this, however, has narrowed due to the lack of value-oriented tokens. Swap structures can include vesting schedules and lockup periods to ensure mutual long-term commitment between blue-chip protocols.
To those ends, a focus for the UC during Season 5 will be initiating a comprehensive treasury management program, in concert with continuous feedback from governance and DUNI-related administrative entities. The core goal eventually will be to administer an RFP process to deliver a structured proposal in collaboration with an asset manager(s). Sizing the amount of allocated capital, specific strategies, and timelines will be key points that the UC seeks to delve into.
The UC would like to further concretize its value with additional hard metric objectives. In line with the consolidation of ecosystem emphasis around burn, expansion of UNI burn is one natural avenue. At present, we have aligned around Treasury Management and Burn Bounties as two initial, but not only, ways to achieve this objective.
Treasury Management:
Treasury yield could be applied in any ratio to either UNI burn or Treasury Diversification as the UC and DUNI see most fit. To ensure sufficient capital to meaningfully drive either or both objectives, the UC has outlined the following benchmarks as approximate program targets:
The above is a potential result if treasury management-derived yield is used for burning UNI. But it will be up to governance to decide whether or not—or how much—treasury yield is used for compounding DUNI capital versus driving burn.
Burn Bounties:
Traditional grant programs teeter towards opaque net benefits to the DAO. In principle, most grants are intended to support builders. These builders create products. These products drive volume. This volume drives fees. And, as a final, most elemental value, these fees drive burn. However, attempting to incentivize developers building to deliver UNI burn, without making the objective an explicit KPI (burn), often involves value leakage for token holders. Burn bounties resolve this by incentivizing the end state desired value, burns, directly. The UC proposes paying builders a fixed amount, for example, 2%, of every dollar of UNI that their products burn, creating an incentive layer where the protocol captures 98% of the deflationary value while developers get paid to make Uniswap their default routing destination.
In this rebate model, and unlike conventional grant programs, the cost-to-value of every dollar emitted is deterministic. For example, if the rewards rate is 2% and the program is budgeted $200,000, then full capital deployment would mean that $10,000,000 in UNI was burned. If the program capital is partially allocated, let’s say $100,000 is claimed, then only $5,000,000 UNI has been burned, but the DAO has “spent” proportionally the same amount.
Cumulatively, we believe Treasury Management and Burn Bounties can augment the work already being done by Uniswap Labs. Today, the DAO is on track to burn ~$30M worth of UNI annually. We anticipate that together, Treasury Management and Burn Bounties could achieve as much as $16m in added burn, increasing the ecosystem’s projected annual burn by >50% with minimal cost to the DAO.
Accordingly, we are requesting a total of $200k UNI to set up and manage a UNI Burn Bounty Program.
In previous seasons, the UC operated the Foundation Feedback Group (FFG), serving as an information bridge between the DAO and the Uniswap Foundation. This structure balanced the DAO's expectation of visibility with the Foundation's need to protect sensitive operational details.
Labs has since entered into a service provider relationship with governance, which introduces expectations around transparent reporting and mandate alignment that go beyond ad hoc public announcements.
With the Foundation and Labs actively exploring how responsibilities and reporting practices will be consolidated, it would be premature to prescribe a fixed successor to the FFG. The UC intends to work closely with the relevant teams as this transition unfolds to identify an appropriate mechanism for ongoing information exchange, including cadence, scope, and how sensitive operational information can be responsibly distilled into public updates for delegates and tokenholders. However, ascribing this function as a definite UC mandate would be jumping the gun.
In addition to its liaison functions, the UC has hosted monthly governance community calls throughout its tenure, providing a regular forum for delegates and ecosystem participants to discuss active proposals, surface concerns, and engage directly with teams working on DAO-funded initiatives. These calls have served as an important complement to asynchronous forum activity, ensuring that governance discussions are accessible beyond the forum. The UC intends to continue facilitating these calls throughout Season 5, along with broader community management efforts aimed at keeping governance participants informed and engaged.
During Season 4, the UC conducted an analysis on the overall state of governance (Governance Logistics Improvements), instigated by the sudden loss of significant voting power among a cohort of well-known delegates. This initiative analyzed major structural pain points in Uniswap DAO governance, opening community dialogue about potential paths forward.
Since then, the adoption of the DUNI has quelled many of the concerns larger token holders and delegates held regarding active participation in votes and forum discussions, meaningfully shifting the delegation landscape.
As Uniswap governance enters this new stage, the UC intends to continue and deepen this line of work throughout Season 5, with a focus on:
Surfacing and supporting community-created proposal ideas
Helping design models for novel governance architectures suitable for Uniswap, like optimistic governance
Monitoring quorum dynamics as token price, circulating supply, and delegation patterns continue to evolve
Providing neutral, data-informed visibility into emerging governance risks and power-concentration dynamics
High-quality infrastructure that has already been funded and developed through the Foundation’s grant programs should be sustained. A healthy governance ecosystem benefits from a clear “grant graduation pipeline,” in which successful grantees transition from one-time funded projects into long-term, DAO-supported service providers when their work proves beneficial.
Oku represents the clearest precedent for this model. The team received an initial grant from the Foundation, built and proved their product in the market, onboarding numerous clients and driving volume to EVM environments outside of Labs’ purview.
Another potential example is Blockful’s Anticapture product. Anticapture has been adopted by multiple DAOs across the Ethereum ecosystem. Uniswap was the first DAO integrated into Anticapture, funded by a $110k grant provided by the Foundation. That grant has now concluded. Blockful has continued to maintain indexers, analytics pipelines, and monitoring infrastructure without additional funding. The platform surfaces governance-critical indicators such as delegation concentration, token distribution across custody venues, proposal thresholds, quorum dynamics, and execution mechanics, contextualized within a broader risk-assessment framework.
Bringing such providers under the DAO’s funding umbrella ensures that critical tooling is not lost due to the expiration of grant funding. The UC intends to play a constructive role in identifying these high-impact grantees and, correspondingly, work with them to best provide value to the DAO. For example, Anticapture can supplement much of the UC’s governance logistics reporting.
We will continue exploring how to best serve this function going forward in concert with the Foundation. Accordingly, we are requesting a total $200k UNI budget for Grant Graduation purposes, with allocations made as candidates are assessed on an ad hoc basis. All of this will be continuously communicated publicly to the DAO.
Throughout its tenure, the UC has maintained transparent accounting practices, tracking inflows, outflows, and program-specific account balances across all DAO-approved initiatives. The UC served as an escrow intermediary, receiving funds from the treasury upon onchain vote execution and disbursing them to vendors and programs upon verification of completed work. As of the end of Season 4, the majority of program accounts have been fully allocated and closed out, with remaining balances for active programs transferred to the DUNI. An accounting breakdown is available in the Season 4 report. Going forward, as outlined earlier, the UC will shift away from this intermediary model in favor of a pre-defined budgetary approach.
Composition of the total UC team will remain at 5 members, with two new members elected in for Season 5 via a Snapshot vote. The staggered board system exists to prevent junctions between ongoing projects and training entirely new teams. The Snapshot election will occur after the onchain vote for renewing the UC passes. Abdullah, Jun, and Jordan will remain on the UC for Season 5, joined by the two newly elected candidates. The newly elected members will start as multisig signers and be onboarded over the season.
We are also proposing extending future seasons, starting with Season 5, to 12 months, as opposed to 6-8 months. This will help with personnel continuity and less administrative overhead, especially with the presence of the newly established UC nonstock corporation.
The operational budget requested for Season 4 was $370k over 8 months, which included staffing, legal operations, accounting tools, etc. For similar line-items, we are requesting a total of $555k for Season 5 over 12 months, the exact same monthly budget.
We are making an additional budget request for Grant Graduation, totaling to $200k, along with a $200k proposed allocation towards the Burn Bounty Program. Grant Graduation allocations ensure that capital already allocated to promising prospects via the Foundation is effectively complemented. Some projects require follow-on funding. And the Burn Bounty allows the UC to support token holders by propelling further UNI burn using rebates.
Season 5 Request:
Duration: 12 months
UC Operating Budget: $555k
Grant Graduation Pipeline: $200k
Burn Bounty Program: $200k*
TOTAL: $955,000 in UNI for 12 months
*Note that the budget associated with burn bounty will only be released as explicit burn metrics are achieved. Hence, the total $200k will be expended if, and only if, $10M UNI is burned—given a 2% rebate.
All Accounts from previous seasons have been closed and returned to the DUNI, so the above funding is all that the UC will have under its purview going into Season 5. The discretionary budget has also been terminated.
Authors: Abdullah (Arana Digital), Juanbug (PGov), Jordan (Event Horizon)
The Uniswap Accountability Committee (UAC) will from hereon, be referred to as the Uniswap Council (UC), to more aptly represent the group’s existing functions.
This proposal outlines the UC’s mandate, structural changes, and budget request for Season 5. For more details around Season 4 operations and financials, please refer to the companion Season 4 Report.
The UC is a DAO-elected entity that supports Uniswap governance by ensuring that DAO-approved initiatives are executed transparently and efficiently. It operates as an independent, community-driven body that coordinates operational tasks, oversees service providers, and maintains governance integrity without setting policy or controlling protocol development. In practice, the UC serves as a lightweight operational layer for the DAO, translating governance decisions into action while remaining fully accountable to tokenholders.
A UC season is a term during which a DAO-elected set of council members is authorized to carry out the UC’s mandate, with funding and scope renewed by governance at the end of the period.
Below are the areas that the UC presided over during Season 4
Cross-chain deployment coordination
ENS record management
Disbursement and accounting of service provider, grantee, and working groups’ compensation
Custody of DAO-approved funds on Ethereum mainnet
Incentive distribution across a multitude of EVM-compatible chains
Governance community calls
Assisting with miscellaneous DAO operations like helping teams sponsor proposals
Managing the Foundation Feedback Group (FFG) to liaise between delegates and the Foundation
Governance logistics improvements
In this proposal, we also introduce new functions to support token holders and delegates in a post-UNIfication world, as well as adjust some previous operations.
Over the past season, the organizational makeup of Uniswap has materially evolved. With Labs taking on a lion’s share of work and funding, and the Foundation winding down over time, the UC becomes the primary independent, community-driven counterweight within the ecosystem.
The UC’s mechanics remain firmly DAO-controlled. Its members are elected through Snapshot votes, and its funding must be approved by governance, which ensures that the team stays accountable. These structural constraints ensure accountability and alignment with tokenholder intent. At the same time, the UC operates as a smaller, more nimble body than the DAO as a whole, capable of responding to operational needs, coordinating service providers, and executing administrative tasks within clearly defined bounds. In practice, this positions the UC as a liaison across several DAO-adjacent functions, which are outlined in greater detail later in this report.
While the committee maintains a deliberately narrow and procedurally defined mandate, the nature of its work has increasingly taken on operational characteristics. This evolution is not unique to Uniswap. Comparable models have emerged across the ecosystem as protocols mature. Arbitrum, for example, established the Arbitrum OpCo, a DAO-elected operational organization tasked with supporting ecosystem programs, vendor oversight, and administrative continuity. ENS operates with a similar pattern through its working groups, which collectively manage grants/service providers and public-facing reporting. In each case, the DAO retains ultimate authority, while the operational unit provides structure and continuity to day-to-day processes that require reliability and professionalization.
Within this landscape, the UC occupies a similar position. While “accountability” has been foundational to the committee’s mandate, the UC now acts more as an administrative and operational body on behalf of the DAO.
As of October, 2025, the UC has been incorporated as a Delaware Nonprofit Nonstock Corporation. As per its initial mandate, the UC entity is not designed to hold profits, issue equity, or accrue economic interests. It is solely meant to support governance integrity and operational accountability within the Uniswap ecosystem. Governance is handled exclusively through a Board of Directors. The composition of the board follows DAO-based elections, as per previous seasons.
This formalization provides the UC with a recognized legal body capable of entering contracts, receiving confidential information, issuing payments, and formally interacting with the DUNI, service providers, and other partners.
Within this evolving framework, the UC functions as an independent, DAO-elected operational body that interfaces with the DUNI but is not an official “service provider” like Uniswap Labs, nor is it assigned a role like “Ministerial Agent” or “Administrator.” In this respect, the UC’s structure aligns with a growing class of DAO-adjacent legal entities akin to BORGs, which are designed to carry out certain mandates on behalf of decentralized systems while remaining constrained by governance.
Unchanged from previous seasons, the UC continues to manage two multisig addresses to conduct its operations:
Primary UC Wallet Address: 0x3B59C6d0034490093460787566dc5D6cE17F2f9C (UAC.eth)
UC Incentives Wallet Address: 0xEBCCf1ce13F63c6B98811F03964F51fC43cef851
Going forward, the UC will not be responsible for disbursing incentives. Legal and tax surface area has expanded post DUNI adoption, and future incentives will be coordinated and executed with the DUNI.
Season 4 consisted of 5 members, representing diverse skillsets and organizational associations:
Alice Corsini
Jordan Karstadt
Doo Wan Nam
Jun Sun
Abdullah Umar
Each member is a signer on the UC multisigs and now a representative on the UC entity Board. Workload is divided among members based on their individual capacities and can vary month-to-month. Multisig duties and security, however, are an evenly assumed responsibility. All members must be ready to sign transactions when needed and uphold multisig integrity without exception.
Previous UC Seasons have lasted for approximately half-a-year each. Season 4 took place between May/June until the end of December 2025. Like prior seasons, 3 members of the UC have stayed active post season 4, planning for adjustments going into Season 5.
The UC has been responsible for disbursing payments to ecosystem vendors whose work has been previously authorized by governance. This includes but is not limited to:
Tally: governance infrastructure and execution support
Forse: incentives impact analytics
Oku: alternative Uniswap front-end, aggregator, and analytics site
Merkl: incentivization infrastructure
DAO programs: structured support for delegate engagement and Uniswap-related research
Going forward, the UC will manage this function differently from how it has been approached in the past. Rather than serving as an intermediary for ad hoc governance-approved funding, future funding will likely be sent to a DUNI-associated address and payments executed by the Ministerial Agent. Payments can also be structured in a more autonomous manner with vesting contracts. We will continue to help coordinate with these teams to ensure milestones, accountability, and transparency metrics are met.
Further, the UC will move to a pre-defined internal budgetary model. Anticipated vendor and operational expenditures will be scoped and requested upfront as part of the seasonal renewal proposal. Pre-defining these budgets simplifies operations by making the UC and its projects direct counterparties. Further, we are still able to help continue our previous seasons’ scope for independent governance approved funds over the season, now leaning on the DUNI for additional support with executing payments in a compliant manner.
The UC will continue to serve as the administrative and coordination layer for cross-chain v3 deployments, working alongside deployers like Oku and Protofire to oversee deployment workflows, maintain the canonical contract registry and ENS subdomains, and support chains through the onboarding process. We will rely on closer coordination with Labs when it comes to newer v4 deployments.
More information on this function can be found here.
Treasury strategy has been a recurring topic within the Uniswap ecosystem for several years, most formally explored through the Uniswap Treasury Working Group (UTWG). While the DAO previously signaled broad interest in developing a structured investment framework, the lack of a legal wrapper and operational infrastructure prevented meaningful progress. With the establishment of DUNI and the maturation of service provider relationships, the conditions now exist to revisit this work responsibly. Recurring budget obligations and large, multi-year engagements further underscore the need for a deliberate treasury management approach.
To start, we want to emphasize that we primarily want to kick off these discussions in a formal and compliant manner post-DUNI adoption. There will be significant tasks to complete before we get to a vendor selection phase, but we believe it is a very important opportunity that should be actively discussed and focused on by the DAO.
As a result, a natural next step may be for the UC to initiate a formal Request for Proposals (RFP) to evaluate qualified treasury managers. Other large DAOs—ENS, Aave, Lido, Gnosis—have successfully partnered with firms such as Karpatkey, Steakhouse, Avantgarde, and others to manage portions of their treasuries under clearly defined Investment Policy Statements (IPS). These IPS frameworks establish risk parameters, liquidity buffers, permissible assets, rebalancing logic, and reporting requirements. Implementing a similar structure under the DUNI would transition Uniswap from reactive treasury decisions toward a durable, mandate-aligned investment framework tailored to the protocol’s long-term needs.
The presence of the DUNI also opens the UC to explore new institutional partnerships with vendors that, for legal and structural reasons, may have been off the table over the past handful of years. At present, the UC is exploring a combination of the following methodologies:
Basis Fund: Deploy UNI as collateral to capture the spread between spot and perpetual futures prices, targeting 10%+ APR; reasonable given that crypto basis spreads have historically averaged 8-20% annualized, and UNI’s moderate liquidity and higher volatility relative to BTC typically place it toward the upper end of that range.
Options: Pledge UNI collateral to systematically sell overpriced volatility via OTC options desks, targeting 15% APR; reasonable because UNI’s realized volatility consistently underperforms its implied volatility by 15-30%, creating a persistent risk premium harvestable through structured short vol strategies.
Market Making: Provide continuous two-sided liquidity across UNI spot pairs on CEXs and DEXs, earning the bid-ask spread and rebates while targeting 20% APR; reasonable given UNI’s $260M daily trading volume creates consistent flow to capture, and the persistent CEX/DEX price dislocations in mid-cap DeFi tokens offer structural arbitrage that wider spreads on UNI (relative to BTC/ETH) translate into higher per-trade margins.
Statistical Arb: Exploit mean-reversion and momentum signals across correlated pairs like UNI/ETH, UNI/AAVE, and UNI/broader DeFi indices, targeting 20% APR; reasonable because UNI’s high beta to the DeFi sector creates frequent mispricings that revert on short timeframes, and the token’s strong correlation structure (0.7-0.85 with ETH) provides reliable pairs trading relationships.
Collateralized Lending: Pledge UNI as collateral through OTC lending desks to borrow USDC at conservative LTVs, then deploy the stablecoins into high-grade yield opportunities such as T-bills, money market funds, or institutional DeFi vaults, targeting 5-10% net APR after borrowing costs; reasonable given that OTC lending desks typically offer more favorable borrowing rates and liquidation terms than onchain venues, eliminating smart contract risk and avoiding the reflexive liquidation cascades common in transparent lending markets.
Token Swaps: Execute bilateral token swaps with strategically aligned DAOs, exchanging UNI for their native governance tokens at negotiated terms, targeting long-term portfolio diversification and ecosystem alignment rather than short-term yield; reasonable given that protocol-to-protocol swaps have become an established mechanism for DAOs to diversify concentrated native-token treasuries while simultaneously deepening governance and economic relationships with key ecosystem partners. The surface area for this, however, has narrowed due to the lack of value-oriented tokens. Swap structures can include vesting schedules and lockup periods to ensure mutual long-term commitment between blue-chip protocols.
To those ends, a focus for the UC during Season 5 will be initiating a comprehensive treasury management program, in concert with continuous feedback from governance and DUNI-related administrative entities. The core goal eventually will be to administer an RFP process to deliver a structured proposal in collaboration with an asset manager(s). Sizing the amount of allocated capital, specific strategies, and timelines will be key points that the UC seeks to delve into.
The UC would like to further concretize its value with additional hard metric objectives. In line with the consolidation of ecosystem emphasis around burn, expansion of UNI burn is one natural avenue. At present, we have aligned around Treasury Management and Burn Bounties as two initial, but not only, ways to achieve this objective.
Treasury Management:
Treasury yield could be applied in any ratio to either UNI burn or Treasury Diversification as the UC and DUNI see most fit. To ensure sufficient capital to meaningfully drive either or both objectives, the UC has outlined the following benchmarks as approximate program targets:
The above is a potential result if treasury management-derived yield is used for burning UNI. But it will be up to governance to decide whether or not—or how much—treasury yield is used for compounding DUNI capital versus driving burn.
Burn Bounties:
Traditional grant programs teeter towards opaque net benefits to the DAO. In principle, most grants are intended to support builders. These builders create products. These products drive volume. This volume drives fees. And, as a final, most elemental value, these fees drive burn. However, attempting to incentivize developers building to deliver UNI burn, without making the objective an explicit KPI (burn), often involves value leakage for token holders. Burn bounties resolve this by incentivizing the end state desired value, burns, directly. The UC proposes paying builders a fixed amount, for example, 2%, of every dollar of UNI that their products burn, creating an incentive layer where the protocol captures 98% of the deflationary value while developers get paid to make Uniswap their default routing destination.
In this rebate model, and unlike conventional grant programs, the cost-to-value of every dollar emitted is deterministic. For example, if the rewards rate is 2% and the program is budgeted $200,000, then full capital deployment would mean that $10,000,000 in UNI was burned. If the program capital is partially allocated, let’s say $100,000 is claimed, then only $5,000,000 UNI has been burned, but the DAO has “spent” proportionally the same amount.
Cumulatively, we believe Treasury Management and Burn Bounties can augment the work already being done by Uniswap Labs. Today, the DAO is on track to burn ~$30M worth of UNI annually. We anticipate that together, Treasury Management and Burn Bounties could achieve as much as $16m in added burn, increasing the ecosystem’s projected annual burn by >50% with minimal cost to the DAO.
Accordingly, we are requesting a total of $200k UNI to set up and manage a UNI Burn Bounty Program.
In previous seasons, the UC operated the Foundation Feedback Group (FFG), serving as an information bridge between the DAO and the Uniswap Foundation. This structure balanced the DAO's expectation of visibility with the Foundation's need to protect sensitive operational details.
Labs has since entered into a service provider relationship with governance, which introduces expectations around transparent reporting and mandate alignment that go beyond ad hoc public announcements.
With the Foundation and Labs actively exploring how responsibilities and reporting practices will be consolidated, it would be premature to prescribe a fixed successor to the FFG. The UC intends to work closely with the relevant teams as this transition unfolds to identify an appropriate mechanism for ongoing information exchange, including cadence, scope, and how sensitive operational information can be responsibly distilled into public updates for delegates and tokenholders. However, ascribing this function as a definite UC mandate would be jumping the gun.
In addition to its liaison functions, the UC has hosted monthly governance community calls throughout its tenure, providing a regular forum for delegates and ecosystem participants to discuss active proposals, surface concerns, and engage directly with teams working on DAO-funded initiatives. These calls have served as an important complement to asynchronous forum activity, ensuring that governance discussions are accessible beyond the forum. The UC intends to continue facilitating these calls throughout Season 5, along with broader community management efforts aimed at keeping governance participants informed and engaged.
During Season 4, the UC conducted an analysis on the overall state of governance (Governance Logistics Improvements), instigated by the sudden loss of significant voting power among a cohort of well-known delegates. This initiative analyzed major structural pain points in Uniswap DAO governance, opening community dialogue about potential paths forward.
Since then, the adoption of the DUNI has quelled many of the concerns larger token holders and delegates held regarding active participation in votes and forum discussions, meaningfully shifting the delegation landscape.
As Uniswap governance enters this new stage, the UC intends to continue and deepen this line of work throughout Season 5, with a focus on:
Surfacing and supporting community-created proposal ideas
Helping design models for novel governance architectures suitable for Uniswap, like optimistic governance
Monitoring quorum dynamics as token price, circulating supply, and delegation patterns continue to evolve
Providing neutral, data-informed visibility into emerging governance risks and power-concentration dynamics
High-quality infrastructure that has already been funded and developed through the Foundation’s grant programs should be sustained. A healthy governance ecosystem benefits from a clear “grant graduation pipeline,” in which successful grantees transition from one-time funded projects into long-term, DAO-supported service providers when their work proves beneficial.
Oku represents the clearest precedent for this model. The team received an initial grant from the Foundation, built and proved their product in the market, onboarding numerous clients and driving volume to EVM environments outside of Labs’ purview.
Another potential example is Blockful’s Anticapture product. Anticapture has been adopted by multiple DAOs across the Ethereum ecosystem. Uniswap was the first DAO integrated into Anticapture, funded by a $110k grant provided by the Foundation. That grant has now concluded. Blockful has continued to maintain indexers, analytics pipelines, and monitoring infrastructure without additional funding. The platform surfaces governance-critical indicators such as delegation concentration, token distribution across custody venues, proposal thresholds, quorum dynamics, and execution mechanics, contextualized within a broader risk-assessment framework.
Bringing such providers under the DAO’s funding umbrella ensures that critical tooling is not lost due to the expiration of grant funding. The UC intends to play a constructive role in identifying these high-impact grantees and, correspondingly, work with them to best provide value to the DAO. For example, Anticapture can supplement much of the UC’s governance logistics reporting.
We will continue exploring how to best serve this function going forward in concert with the Foundation. Accordingly, we are requesting a total $200k UNI budget for Grant Graduation purposes, with allocations made as candidates are assessed on an ad hoc basis. All of this will be continuously communicated publicly to the DAO.
Throughout its tenure, the UC has maintained transparent accounting practices, tracking inflows, outflows, and program-specific account balances across all DAO-approved initiatives. The UC served as an escrow intermediary, receiving funds from the treasury upon onchain vote execution and disbursing them to vendors and programs upon verification of completed work. As of the end of Season 4, the majority of program accounts have been fully allocated and closed out, with remaining balances for active programs transferred to the DUNI. An accounting breakdown is available in the Season 4 report. Going forward, as outlined earlier, the UC will shift away from this intermediary model in favor of a pre-defined budgetary approach.
Composition of the total UC team will remain at 5 members, with two new members elected in for Season 5 via a Snapshot vote. The staggered board system exists to prevent junctions between ongoing projects and training entirely new teams. The Snapshot election will occur after the onchain vote for renewing the UC passes. Abdullah, Jun, and Jordan will remain on the UC for Season 5, joined by the two newly elected candidates. The newly elected members will start as multisig signers and be onboarded over the season.
We are also proposing extending future seasons, starting with Season 5, to 12 months, as opposed to 6-8 months. This will help with personnel continuity and less administrative overhead, especially with the presence of the newly established UC nonstock corporation.
The operational budget requested for Season 4 was $370k over 8 months, which included staffing, legal operations, accounting tools, etc. For similar line-items, we are requesting a total of $555k for Season 5 over 12 months, the exact same monthly budget.
We are making an additional budget request for Grant Graduation, totaling to $200k, along with a $200k proposed allocation towards the Burn Bounty Program. Grant Graduation allocations ensure that capital already allocated to promising prospects via the Foundation is effectively complemented. Some projects require follow-on funding. And the Burn Bounty allows the UC to support token holders by propelling further UNI burn using rebates.
Season 5 Request:
Duration: 12 months
UC Operating Budget: $555k
Grant Graduation Pipeline: $200k
Burn Bounty Program: $200k*
TOTAL: $955,000 in UNI for 12 months
*Note that the budget associated with burn bounty will only be released as explicit burn metrics are achieved. Hence, the total $200k will be expended if, and only if, $10M UNI is burned—given a 2% rebate.
All Accounts from previous seasons have been closed and returned to the DUNI, so the above funding is all that the UC will have under its purview going into Season 5. The discretionary budget has also been terminated.
Thanks to the UC team for putting together such a thorough Season 5 proposal. A lot of thought clearly went into it, and we are supportive of the direction. However, a few things are worth talking through before we move to a vote.
Burn Bounty Program
The incentive logic makes sense in principle; however, additional detail is required before we can offer our full support.
Thanks to the UC team for putting together such a thorough Season 5 proposal. A lot of thought clearly went into it, and we are supportive of the direction. However, a few things are worth talking through before we move to a vote.
Burn Bounty Program
The incentive logic makes sense in principle; however, additional detail is required before we can offer our full support.
The delayed compensation piece could quietly disadvantage smaller teams and solo devs who don't have the runway to wait for burn to materialize. Has the UC looked at what that lag typically looks like in practice, from product launch to meaningful burn accrual?
I'm also worried the 2% rebate creates blind spots. If compensation is directly tied to burn, developers have a real reason to deprioritize infrastructure work and public-good tooling — stuff that creates genuine value but doesn't sit neatly in the fee path. Is there a carve-out for that kind of contribution, or a parallel track being considered?
A clearer eligibility framework and application process would also go a long way in helping delegates feel confident about the $200k ask. Furthermore, a clearer end-to-end overview of how the program operates would also strengthen voter confidence.
Proposal Structure
The proposal comprises several elements: treasury management, burn bounties, grant graduation, governance logistics, community calls, and deployments. The proposal would land better with a cleaner sense of hierarchy: what's core to the UC's mandate versus what's more exploratory? Even a short executive summary at the top would make a real difference for delegates getting up to speed ahead of the on-chain vote.
Treasury Section
We’re supportive of getting the RFP process started, but the specific strategy breakdowns (basis funds, statistical arb, options, projected APR targets) may be too ambitious. We suggest trimming this down to the RFP mandate and high-level rationale to reduce back-and-forth over specifics that may change anyway.
Looking forward to the team's thoughts.
Could you confirm whether the final treasury management plan (strategy selection, sizing, risk parameters, manager appointment) will require a separate governance vote before any capital is deployed, or whether the UC considers this proposal sufficient authorization to proceed through to deployment?
Thanks for the thoughtful feedback, @SEEDGov.
A couple of points:
Washtrading in our eyes is less-so an issue. When you wash trade, you're paying swap fees on every loop. Those swap fees are what fill the TokenJar. So you're spending your own money to fill a pot, and your bounty is only 2% (or whatever rebate rate) of what a searcher eventually burns from that pot.
Thanks for the thoughtful feedback, @SEEDGov.
A couple of points:
Washtrading in our eyes is less-so an issue. When you wash trade, you're paying swap fees on every loop. Those swap fees are what fill the TokenJar. So you're spending your own money to fill a pot, and your bounty is only 2% (or whatever rebate rate) of what a searcher eventually burns from that pot.
You'd spend $50 in swap fees to earn $1 back. There's no way to make that math work in your favor since the wash trading costs more than the bounty pays.
That said, your point about the need for a clear verification and attribution framework is well taken. Attribution takes some effort and isn’t a perfect exercise.
The TokenJar is completely agnostic about what caused the fees. It just accumulates fee tokens. When a searcher triggers the burn, the chain records which pools generated fees, that the searcher paid some amount of UNI and got back the TockenJar’s contents, and that UNI was burned/sent to 0xdead. The issue is illustrating which FE, for example, routed the user to that pool in the first place.
So you can't perfectly attribute the TokenJar release to a specific builder cause many builders' traffic flows into the same shared TokenJar and the searcher burns it all at once in a single transaction. What we can do is attribute the underlying fees by tracing pool-level events back to the originating transaction and then pro-rate the burn bounty based on each builder's share of fees that entered the TokenJar during the claim period. This is just a structural limitation that we need to work through based on how the burn system is designed. It also increases the need for a program manager because some degree of interpretation/discretion is required. Likely can’t be made autonomous.
Just for more clarity around our thoughts…
Say there are three builders routing swaps through Uniswap on Base over some period:
Builder A (a FE) generates $800k in fees
Builder B (an aggregator) generates $150k in fees
Builder C (a wallet) generates $50k in fees
All of that $1M flows into the same shared TokenJar. At some point, a searcher decides the pot is worth enough, so they take the fee tokens, and the associated UNI gets bridged back to L1 and burned.
The TokenJar release is one txn but doesn't say “800k came from Builder A.”
So a model for tracing would therefore be going upstream to the pool-level fee events.
Every swap on Uniswap emits a swap event from the pool contract. That event includes the amounts, the pool address, and the associated txn hash. From the txn hash you can trace back to the originating call as see who called the router, from what contract/EOA, with what calldata.
So, we’d have to
Index all Swap events on Base during the claim period that had a protocol fee component
For each swap txn, check the calldata for a builder identifier (referral tag, contract address, etc)
Tally each builder's share of total fees that flowed into the TokenJar
When the searcher burn happens, pro-rate the burned UNI against those shares (this accounting can get tricky due to token $-value fluctuations…see more below)
But not every builder will have a clean onchain identifier. If Builder C is a wallet that just calls the Uniswap router directly with no tag and no intermediate contract, their swaps look identical to any random user. That's where the UC's discretion comes in. We’d require builders to demonstrate attribution. Essentially, to participate in the bounty program, you register your identifier upfront, and only tagged volume counts.
So the process is:
Collect all the receipts for swaps during a claim period
Filter by builder seeing which receipts have Builder C's identifier on them
Add up what % of Builder C's swaps generated the total fees in the TokenJar
Apply that % to the burn so when the searcher burns, Builder A gets credit for X% of it, and their bounty is 2% of that
Identifying which receipts belong to which builder is the hard part. That's why pre-registration of an onchain identifier (a contract address, a referral tag in calldata) is a key design requirement.
Another point worth considering is on the potential hierarchy around the fee tokens themselves. This may be needed to filter garbage volume.
USDC, ETH, PEPE, and a brand new memecoin all go into the same TokenJar. If the TokenJar is full of worthless tokens, no searcher will touch it, meaning no burn happens, meaning no bounty is paid.
So if a builder routes a ton of memecoin trading volume, and at the time those swaps happen the memecoin has real value, fees accumulate in the TokenJar and look meaningful. BUT then the coin rugs or goes to 0 before a searcher claims the pot. That’s not a benefit to burn. The builder could argue that they generated a buncha fees during the claim period, but those fees are now worthless so no bounty should be paid.
The design implication here is that we could explicitly whitelist eligible fee tokens for bounty attribution purposes like ETH, WBTC, USDC, USDT, and some others. Only fees denominated in those tokens count toward a builder's rebate share. Memecoin fees still flow into the TokenJar and still get burned if a searcher wants them, but they don't count toward bounty credit/or if they do, they must have >$XM mcap. This makes the bounty program resistant to builders chasing low-quality volume just to inflate their numbers.
Thank you for the detailed breakdown of the Season 4 report and the specifics for Season 5. The rebranding to Uniswap Council feels apt, this is clearly an operational body now, and the name should reflect that.
The Burn Bounty is the standout initiative, it feels like a very thoughtful way to align builder incentives with the protocol's success. Making burn an explicit KPI rather than a hoped-for downstream effect of generalized grants is a meaningful design improvement, and the deterministic cost-to-value ratio ($200k budget = $10M burned if fully deployed) is a compelling framing.
Thanks to the UC team for putting together such a thorough Season 5 proposal. A lot of thought clearly went into it, and we are supportive of the direction. However, a few things are worth talking through before we move to a vote.
Burn Bounty Program
The incentive logic makes sense in principle; however, additional detail is required before we can offer our full support.
Thanks to the UC team for putting together such a thorough Season 5 proposal. A lot of thought clearly went into it, and we are supportive of the direction. However, a few things are worth talking through before we move to a vote.
Burn Bounty Program
The incentive logic makes sense in principle; however, additional detail is required before we can offer our full support.
The delayed compensation piece could quietly disadvantage smaller teams and solo devs who don't have the runway to wait for burn to materialize. Has the UC looked at what that lag typically looks like in practice, from product launch to meaningful burn accrual?
I'm also worried the 2% rebate creates blind spots. If compensation is directly tied to burn, developers have a real reason to deprioritize infrastructure work and public-good tooling — stuff that creates genuine value but doesn't sit neatly in the fee path. Is there a carve-out for that kind of contribution, or a parallel track being considered?
A clearer eligibility framework and application process would also go a long way in helping delegates feel confident about the $200k ask. Furthermore, a clearer end-to-end overview of how the program operates would also strengthen voter confidence.
Proposal Structure
The proposal comprises several elements: treasury management, burn bounties, grant graduation, governance logistics, community calls, and deployments. The proposal would land better with a cleaner sense of hierarchy: what's core to the UC's mandate versus what's more exploratory? Even a short executive summary at the top would make a real difference for delegates getting up to speed ahead of the on-chain vote.
Treasury Section
We’re supportive of getting the RFP process started, but the specific strategy breakdowns (basis funds, statistical arb, options, projected APR targets) may be too ambitious. We suggest trimming this down to the RFP mandate and high-level rationale to reduce back-and-forth over specifics that may change anyway.
Looking forward to the team's thoughts.
Could you confirm whether the final treasury management plan (strategy selection, sizing, risk parameters, manager appointment) will require a separate governance vote before any capital is deployed, or whether the UC considers this proposal sufficient authorization to proceed through to deployment?
Thanks for the thoughtful feedback, @SEEDGov.
A couple of points:
Washtrading in our eyes is less-so an issue. When you wash trade, you're paying swap fees on every loop. Those swap fees are what fill the TokenJar. So you're spending your own money to fill a pot, and your bounty is only 2% (or whatever rebate rate) of what a searcher eventually burns from that pot.
Thanks for the thoughtful feedback, @SEEDGov.
A couple of points:
Washtrading in our eyes is less-so an issue. When you wash trade, you're paying swap fees on every loop. Those swap fees are what fill the TokenJar. So you're spending your own money to fill a pot, and your bounty is only 2% (or whatever rebate rate) of what a searcher eventually burns from that pot.
You'd spend $50 in swap fees to earn $1 back. There's no way to make that math work in your favor since the wash trading costs more than the bounty pays.
That said, your point about the need for a clear verification and attribution framework is well taken. Attribution takes some effort and isn’t a perfect exercise.
The TokenJar is completely agnostic about what caused the fees. It just accumulates fee tokens. When a searcher triggers the burn, the chain records which pools generated fees, that the searcher paid some amount of UNI and got back the TockenJar’s contents, and that UNI was burned/sent to 0xdead. The issue is illustrating which FE, for example, routed the user to that pool in the first place.
So you can't perfectly attribute the TokenJar release to a specific builder cause many builders' traffic flows into the same shared TokenJar and the searcher burns it all at once in a single transaction. What we can do is attribute the underlying fees by tracing pool-level events back to the originating transaction and then pro-rate the burn bounty based on each builder's share of fees that entered the TokenJar during the claim period. This is just a structural limitation that we need to work through based on how the burn system is designed. It also increases the need for a program manager because some degree of interpretation/discretion is required. Likely can’t be made autonomous.
Just for more clarity around our thoughts…
Say there are three builders routing swaps through Uniswap on Base over some period:
Builder A (a FE) generates $800k in fees
Builder B (an aggregator) generates $150k in fees
Builder C (a wallet) generates $50k in fees
All of that $1M flows into the same shared TokenJar. At some point, a searcher decides the pot is worth enough, so they take the fee tokens, and the associated UNI gets bridged back to L1 and burned.
The TokenJar release is one txn but doesn't say “800k came from Builder A.”
So a model for tracing would therefore be going upstream to the pool-level fee events.
Every swap on Uniswap emits a swap event from the pool contract. That event includes the amounts, the pool address, and the associated txn hash. From the txn hash you can trace back to the originating call as see who called the router, from what contract/EOA, with what calldata.
So, we’d have to
Index all Swap events on Base during the claim period that had a protocol fee component
For each swap txn, check the calldata for a builder identifier (referral tag, contract address, etc)
Tally each builder's share of total fees that flowed into the TokenJar
When the searcher burn happens, pro-rate the burned UNI against those shares (this accounting can get tricky due to token $-value fluctuations…see more below)
But not every builder will have a clean onchain identifier. If Builder C is a wallet that just calls the Uniswap router directly with no tag and no intermediate contract, their swaps look identical to any random user. That's where the UC's discretion comes in. We’d require builders to demonstrate attribution. Essentially, to participate in the bounty program, you register your identifier upfront, and only tagged volume counts.
So the process is:
Collect all the receipts for swaps during a claim period
Filter by builder seeing which receipts have Builder C's identifier on them
Add up what % of Builder C's swaps generated the total fees in the TokenJar
Apply that % to the burn so when the searcher burns, Builder A gets credit for X% of it, and their bounty is 2% of that
Identifying which receipts belong to which builder is the hard part. That's why pre-registration of an onchain identifier (a contract address, a referral tag in calldata) is a key design requirement.
Another point worth considering is on the potential hierarchy around the fee tokens themselves. This may be needed to filter garbage volume.
USDC, ETH, PEPE, and a brand new memecoin all go into the same TokenJar. If the TokenJar is full of worthless tokens, no searcher will touch it, meaning no burn happens, meaning no bounty is paid.
So if a builder routes a ton of memecoin trading volume, and at the time those swaps happen the memecoin has real value, fees accumulate in the TokenJar and look meaningful. BUT then the coin rugs or goes to 0 before a searcher claims the pot. That’s not a benefit to burn. The builder could argue that they generated a buncha fees during the claim period, but those fees are now worthless so no bounty should be paid.
The design implication here is that we could explicitly whitelist eligible fee tokens for bounty attribution purposes like ETH, WBTC, USDC, USDT, and some others. Only fees denominated in those tokens count toward a builder's rebate share. Memecoin fees still flow into the TokenJar and still get burned if a searcher wants them, but they don't count toward bounty credit/or if they do, they must have >$XM mcap. This makes the bounty program resistant to builders chasing low-quality volume just to inflate their numbers.
Thank you for the detailed breakdown of the Season 4 report and the specifics for Season 5. The rebranding to Uniswap Council feels apt, this is clearly an operational body now, and the name should reflect that.
The Burn Bounty is the standout initiative, it feels like a very thoughtful way to align builder incentives with the protocol's success. Making burn an explicit KPI rather than a hoped-for downstream effect of generalized grants is a meaningful design improvement, and the deterministic cost-to-value ratio ($200k budget = $10M burned if fully deployed) is a compelling framing.
Could you confirm whether the final treasury management plan (strategy selection, sizing, risk parameters, manager appointment) will require a separate governance vote before any capital is deployed, or whether the UC considers this proposal sufficient authorization to proceed through to deployment?
Thanks for your question—this would be Uniswap's first instance of managing protocol-owned assets, so a series of future votes may be needed from a decision making consensus perspective. Some may just be Snapshot votes due to no associated calldata. Of course, the allocation of funds for specific strategies will require moving UNI from the timelock. Onchain votes may also be needed for signing any formal agreements between vendors and the DUNI. The nature of these votes will be determined as the program unfolds. Needless to say, proper procedure and community input is top of mind. We have to be cognizant of aspects pertaining to legal and tax variables associated with treasury management as well, in particular since the DUNI is now in place.
Thank you for the detailed breakdown of the Season 4 report and the specifics for Season 5. The rebranding to Uniswap Council feels apt, this is clearly an operational body now, and the name should reflect that.
The Burn Bounty is the standout initiative, it feels like a very thoughtful way to align builder incentives with the protocol's success. Making burn an explicit KPI rather than a hoped-for downstream effect of generalized grants is a meaningful design improvement, and the deterministic cost-to-value ratio ($200k budget = $10M burned if fully deployed) is a compelling framing.
I think this approach hits the mark for a few reasons:
On wash trading: @AbdullahUmar's response is largely convincing, swap fees make it economically irrational to game the rebate, creating a naturally Sybil-resistant structure by design.
Scaling potential: I see the 2% rebate as a foundation that we can iterate on. If this goes well, it would be exciting to explore tiered rewards in the future. For instance, offering a 4% rebate for products that cross a major milestone (like $5M in generated burns) could make the program even more compelling for high-impact builders as they grow.
On Attribution: The more substantive challenge is attribution. @AbdullahUmar's discussion of requiring builders to pre-register onchain identifiers and the token whitelist concept (crediting only fees from ETH, WBTC, USDC, USDT) are sensible design directions. It would be good to see the UC publish a formal program spec covering attribution rules and eligibility criteria before the program goes live.
Overall, supportive of this renewal and looking forward to seeing these initiative in action.
Could you confirm whether the final treasury management plan (strategy selection, sizing, risk parameters, manager appointment) will require a separate governance vote before any capital is deployed, or whether the UC considers this proposal sufficient authorization to proceed through to deployment?
Thanks for your question—this would be Uniswap's first instance of managing protocol-owned assets, so a series of future votes may be needed from a decision making consensus perspective. Some may just be Snapshot votes due to no associated calldata. Of course, the allocation of funds for specific strategies will require moving UNI from the timelock. Onchain votes may also be needed for signing any formal agreements between vendors and the DUNI. The nature of these votes will be determined as the program unfolds. Needless to say, proper procedure and community input is top of mind. We have to be cognizant of aspects pertaining to legal and tax variables associated with treasury management as well, in particular since the DUNI is now in place.
Thank you for the detailed breakdown of the Season 4 report and the specifics for Season 5. The rebranding to Uniswap Council feels apt, this is clearly an operational body now, and the name should reflect that.
The Burn Bounty is the standout initiative, it feels like a very thoughtful way to align builder incentives with the protocol's success. Making burn an explicit KPI rather than a hoped-for downstream effect of generalized grants is a meaningful design improvement, and the deterministic cost-to-value ratio ($200k budget = $10M burned if fully deployed) is a compelling framing.
I think this approach hits the mark for a few reasons:
On wash trading: @AbdullahUmar's response is largely convincing, swap fees make it economically irrational to game the rebate, creating a naturally Sybil-resistant structure by design.
Scaling potential: I see the 2% rebate as a foundation that we can iterate on. If this goes well, it would be exciting to explore tiered rewards in the future. For instance, offering a 4% rebate for products that cross a major milestone (like $5M in generated burns) could make the program even more compelling for high-impact builders as they grow.
On Attribution: The more substantive challenge is attribution. @AbdullahUmar's discussion of requiring builders to pre-register onchain identifiers and the token whitelist concept (crediting only fees from ETH, WBTC, USDC, USDT) are sensible design directions. It would be good to see the UC publish a formal program spec covering attribution rules and eligibility criteria before the program goes live.
Overall, supportive of this renewal and looking forward to seeing these initiative in action.
Thanks for the detailed proposal. We are supportive of the UC's renewal and the expanded mandate for Season 5.
The Burn Bounty design is compelling. Paying only for the end-state outcome rather than proxies eliminates the value leakage that makes traditional grant ROI non-deterministic, and the economics make wash trading irrational. We agree with @SEEDGov and @Curia that a formal program spec covering attribution rules and token eligibility should be published before the program goes live, but the core mechanism is sound.
Thanks for the detailed proposal. We are supportive of the UC's renewal and the expanded mandate for Season 5.
The Burn Bounty design is compelling. Paying only for the end-state outcome rather than proxies eliminates the value leakage that makes traditional grant ROI non-deterministic, and the economics make wash trading irrational. We agree with @SEEDGov and @Curia that a formal program spec covering attribution rules and token eligibility should be published before the program goes live, but the core mechanism is sound.
The Grant Graduation Pipeline also makes sense. Ensuring that proven Foundation grantees like Anticapture don't lose funding due to grant expiration is a practical use of UC resources.
One clarification on treasury management. We understand the UC is seeking a mandate to begin the RFP process, not to deploy capital immediately, which is the right sequencing. Could you confirm whether the final treasury management plan (strategy selection, sizing, risk parameters, manager appointment) will require a separate governance vote before any capital is deployed, or whether the UC considers this proposal sufficient authorization to proceed through to deployment?
Thanks for the detailed proposal. We are supportive of the UC's renewal and the expanded mandate for Season 5.
The Burn Bounty design is compelling. Paying only for the end-state outcome rather than proxies eliminates the value leakage that makes traditional grant ROI non-deterministic, and the economics make wash trading irrational. We agree with @SEEDGov and @Curia that a formal program spec covering attribution rules and token eligibility should be published before the program goes live, but the core mechanism is sound.
Thanks for the detailed proposal. We are supportive of the UC's renewal and the expanded mandate for Season 5.
The Burn Bounty design is compelling. Paying only for the end-state outcome rather than proxies eliminates the value leakage that makes traditional grant ROI non-deterministic, and the economics make wash trading irrational. We agree with @SEEDGov and @Curia that a formal program spec covering attribution rules and token eligibility should be published before the program goes live, but the core mechanism is sound.
The Grant Graduation Pipeline also makes sense. Ensuring that proven Foundation grantees like Anticapture don't lose funding due to grant expiration is a practical use of UC resources.
One clarification on treasury management. We understand the UC is seeking a mandate to begin the RFP process, not to deploy capital immediately, which is the right sequencing. Could you confirm whether the final treasury management plan (strategy selection, sizing, risk parameters, manager appointment) will require a separate governance vote before any capital is deployed, or whether the UC considers this proposal sufficient authorization to proceed through to deployment?
Thanks Abdullah for the detailed proposal!
We have some concerns related to the Burn Bounty mechanism that we like to shere.
The core idea is compelling: aligning incentives directly around the end-state value (burn) rather than proxies like activity or volume is a meaningful improvement over traditional grant structures.
Thanks Abdullah for the detailed proposal!
We have some concerns related to the Burn Bounty mechanism that we like to shere.
The core idea is compelling: aligning incentives directly around the end-state value (burn) rather than proxies like activity or volume is a meaningful improvement over traditional grant structures.
There's one thing that concerns us: there is a clear potential vector for abuse, as a malicious actor could create a protocol or mechanism with artificial UNI trading volume (wash trading) to collect the bounty. For example, a team could route wash trades or self-referential volume through a front-end that technically burns UNI, at a cost lower than the 2% bounty they'd collect. The net result would be UNI burned, but at an unfavorable ratio for the DAO compared to organic burn.
We would like these concerns to be addressed before this mechanism is established:
It is necessary to consider and establish a system that prevents participants from generating fictitious trading volume in order to claim a bounty
Establish a validation or audit process before bounties are paid out
Establish a mechanism for the UC to intervene in the event of a potential attempt at abuse during the program
We think a specificity framework would strengthen this initiative.
Thanks Abdullah for the detailed proposal!
We have some concerns related to the Burn Bounty mechanism that we like to shere.
The core idea is compelling: aligning incentives directly around the end-state value (burn) rather than proxies like activity or volume is a meaningful improvement over traditional grant structures.
Thanks Abdullah for the detailed proposal!
We have some concerns related to the Burn Bounty mechanism that we like to shere.
The core idea is compelling: aligning incentives directly around the end-state value (burn) rather than proxies like activity or volume is a meaningful improvement over traditional grant structures.
There's one thing that concerns us: there is a clear potential vector for abuse, as a malicious actor could create a protocol or mechanism with artificial UNI trading volume (wash trading) to collect the bounty. For example, a team could route wash trades or self-referential volume through a front-end that technically burns UNI, at a cost lower than the 2% bounty they'd collect. The net result would be UNI burned, but at an unfavorable ratio for the DAO compared to organic burn.
We would like these concerns to be addressed before this mechanism is established:
It is necessary to consider and establish a system that prevents participants from generating fictitious trading volume in order to claim a bounty
Establish a validation or audit process before bounties are paid out
Establish a mechanism for the UC to intervene in the event of a potential attempt at abuse during the program
We think a specificity framework would strengthen this initiative.
