FlapperDistributor: A Way to Distribute System Surplus while Minimizing Governance



The current Flapper is responsible for auctioning and burning MKR when the system surplus exceeds the hump parameter.

Once hump is met, any additional DAI entering the surplus is diverted to the Flapper and auctioned for MKR (currently in chunks of 10,000)

FlapperDistributor is a proposed new contract that would have the following functionality:

  • It replaces the current Flapper in the Maker contracts.
  • Governance can vote to add multiple destination addresses each with their own weights.
  • Once the surplus buffer exceeds the hump parameter, DAI enters FlapperDistributor and is divided among the governance approved targets according to their weights.
  • The current Flapper contract would become one of these destination addresses, allowing us to spend a certain percentage of incoming fees on MKR burn.
  • Governance can also remove destination addresses and modify their weights using an executive vote.
  • Other potential destinations are myriad, but could include:
    • Operating Funds (potentially divided between domains)
    • Strategic Reserves (automatically exchange DAI for ETH and accumulate)
    • Core infrastructure development (money to help fund ETH development.)
    • Charitable giving

Diagram courtesy of @juanjuan


This system has a number of advantages over using executive votes to distribute funds.

Reduces Governance Overhead

  • Governance can vote on high-level priorities:
    • How much to allocate to growth, to burn, and to reserves.
  • Governance doesn’t need to approve distribution of lumps of funds using an executive vote.
  • Allows us to have infrequent votes determining distribution.

Puts the ‘autonomous’ in DAO

  • Leverages the advantages of the blockchain, distribution of funds doesn’t require human action (beyond calling smart contract methods.)
  • Very flexible and extensible system.

Soft-Guarantees of a certain level of MKR burn

  • There is an issue when allocating directly from the surplus buffer that means that it is hard to guarantee that the buffer will ever overflow into burn. If the buffer is full, people will want to use it for things that aren’t MKR burn.
  • Would be easy for governance to agree to a certain level of burn, but this would be difficult to manage in practice.

Supports budgeting and distribution of funds

  • We are at a point where we are trying to determine how money is distributed to domains to ensure growth.
  • This would provide a system to do that, allowing money to flow automatically to domain multi-sigs that could then be used to pay contributors.

Supports recent governance initiatives (Strategic Reserves)

  • Provides a great way of accumulating strategic reserves over time, either in DAI or in other assets (when combined with an on-chain dex)
  • It’s generally thought that frequent small purchases to build a position works out better than trying to time the market and buy at the optimal point, additionally, timing purchases with decentralized governance is going to be tricky.
  • Allows accumulation of reserves without minting and selling MKR to raise funds.
  • Could relatively easily be expanded to include additional functionality.

How feasible is this?

I think this is quite feasible. The Maker contracts were built to be modular and replaceable. The Flapper is a ‘leaf’ contract, in that it sits on the edge of the cluster and doesn’t have too many interactions with other contracts (I believe only the vat.)

That said, I’m not a smart contract developer, and there may be interactions with other contracts that I haven’t been able to recognise. I’d love some high-level input from @Smart-Contracts as to how this could work in practice, and the caveats that we’d need to be aware of.


I like this, definitely adds extensibility. As eager as I am to resume burning, seems like allocating a small portion of profit for the domains team is useful.

Would also be neat to use this to test alternative burning mechanisms, i.e. allocate 1% to DEX swap DAI-MKR for burning rather than auctions. If it works, great, if not it’s only a 1% loss.

In the proposed diagram should FlapperDistributor have ‘(auctions for MKR)’? Seems like it should be changed to (excess DAI distribution) or similar.


Was this added at the end–because I don’t see it on Juan’s diagram? Also, I would want to believe that core infrastructure development to also includes but it is not limited to marketing, onboarding of DAI users, and community development of DAI?

1 Like

Most important part of the diagram:

It’s really only meant to communicate the concept of how this works, rather than push for any particular allocation.

I more meant core infrastructure to refer to the Ethereum Network and/or any L2’s we end up using. I totally agree that there are a whole bunch of things we could allocate incoming DAI towards though.

1 Like

My diagram is just for illustration purposes. There’s a (*) claiming that addresses and weights are for illustration purposes only.

But it is a good point. Having the Distributor would allow us to choose different wallets + weights.

1 Like

Can you imagine a world where part of the DAI gets set aside to be put into an active fund-type system that invests in other protocols/tokens/etc.? The strategic reserves you mentioned appear to be more passive (which makes sense!), but I’m wondering if the community and voters would want a more active approach and if there are any limitations that you can think of there.

Why is this better than having MKR governance deciding on what projects they want to fund and then agreeing to mint MKR and running a FLOP auction to raise the funds? I feel like we need to separate the idea that project funding needs to come from current income- as this could end up taking much longer to get to the levels that we need to get a project started. Also- its not any easier to manage and needs to be shut off when the required funding is reached. Furthermore, its no better for MKR holders to divert funds from burning than to keep burn untouched and mint MKR to fund projects that people agree to.


This is great. It’s much better than the rough measure of just raising the System surplus. There’s much more granularity, we can still burn MKR while keeping a portion for operations and reserves.

1 Like

I tend to agree. Similar to having staff do expense reports with the expectation (but not certainty) for reimbursement.

If each of the staff has a company credit card, it will inevitably end up spending more than with expense reports…

As such, I recommend the model of MKR buy and burn. For specific projects (or even a budget) then any shortfall should mint MKR to fund it.

1 Like

Because with this system governance don’t necessarily have to decide which projects to fund. Instead they can make a higher level decisions on the order of ‘spend 10% of income on projects of type x’ and then domain teams or other mandated actors can distribute grants in that area from that pool of funds.

Also, it’s fairly hard to get MKR Holders to agree to mint MKR, for obvious reasons.

Also, having this system doesn’t prevent you from also having MKR Governance decide which projects they want to fund manually if they want to, that’s what makes it flexible. Even if we just used this system to set the incoming percentage to (purely example numbers) 30% burn, 70% operational funds, and then Maker Governance voted on all expenditures from the operational funds, I’d still view that as a win.

No, it doesn’t really. You can distribute the income into a intermediate treasury, it doesn’t need to go directly to a specific project. It could go direct to project, but I agree that then you would need to turn it off, which makes it more of a pain than just transferring directly from a treasury address or the surplus buffer.

It actually is better. When you mint MKR you need to exchange it for DAI, which means paying slippage on auctions or trading fees on uniswap or another on-chain DEX. If you use the DAI income from the stability fee, you don’t need to pay those costs.


THIS is an excellent point…

1 Like

When projects are funded from ongoing revenue, as per above proposal, you maintain the pledge that MKR will only be printed when the system is undercollateralized. If, however, the community decides to fund projects from MKR printing, it means MKR can now be printed for multiple good causes not just undercollaterialization. Big factor that will weigh down on MKR value.


If this ever gets used to distribute dividends then MKR will be deemed a security which will not be good

@Akiva What about ‘sufficiently decentralized’?

1 Like

I guess I’m skeptical though that its efficient or desirable to allocate e.g. “20% to operations” - it would be more appropriate IMO to have a working group first define what operations consists of, what are the most critical activities that need support, and what budget they would require to execute over e.g. a 1-year period. If MKR governance agrees to this budget and list of activities, we should then figure out how to fund it and it may deserve immediate funding so that the work can start. In this case, a FLOP auction to raise the required money would be more effective than waiting until enough money accrued through surplus to fund. Although its a good point that FLOP auction may result in 1-2% loss due to auction fees, its still likely a small price to pay for being able to launch mission critical activities without waiting for stability fees to accrue over time.


I think it will be more like MIPXX requiring DAI 12000, MIPYY requiring 8000 etc etc. No need for coordination or bureaucracy. Maker governance approve the MIP -> it gets funded.

Thats not what is proposed in the OP

1 Like

Myself and a few others been working on a proposal around this, including a budget MIP that might make it easier for teams to request funds. Hoping to have something to share in the next few weeks.


@LongForWisdom, as the diagram of the FlapperDistributor does not conform either to MIPs - rightly pointed out by @latetot - or the current Domain Teams, what do they indicate?

This is a good suggestion, which provides more options for future remaining buffer allocation and expansion. However, now I support MKR burning. In the future, if financial transparency can be achieved, I will support the implementation of this plan.