MIP34: Keg Streaming Payments Module

[hexonaut]

MIP34: Keg Streaming Payments Module

Preamble

MIP#: 34
Title: Keg Streaming Payments Module
Author(s): Sam MacPherson (@hexonaut)
Contributors: None
Type: Technical
Status: Formal Submission (FS)
Date Proposed: 2021-01-11
Date Ratified: <yyyy-mm-dd>
Dependencies: n/a
Replaces: n/a
License: AGPL3+

References

• The proposed keg
• Flapper Distributor - one use-case of the keg

Sentence Summary

This proposal provides a smart contract implementation of a Streaming Payments System for Maker.

Paragraph Summary

The Keg is a tool for streaming ERC20 DAI to a preset group of addresses. These address groups can be targetted by specifying a human-friendly name to the Keg. These address groups are called flights. Anyone can make a payment into the Keg provided they specify the destination flight and have enough DAI. Also included are two contracts Tap and FlapTap to facilitate payments from the Surplus Buffer and Flapper respectively.

Component Summary

MIP34c1: Keg: summary of Keg contract.

MIP34c2: Tap: summary of Tap contract.

MIP34c3: FlapTap: Summary of FlapTap contract.

MIP34c4: Test cases: lists existing test cases, including integration test

MIP34c5: Security considerations: comments on the limited nature of the security implications of adding the PSM.

MIP34c6: Licensing: states the license under which the proposal and code are distributed.

Motivation

A mechanism to fund domain team work is required in order to reduce/eliminate the Maker Foundation as a dependency of the Maker protocol. This could be achieved by one-time governance votes for a lump sum, but this introduces overhead on the governance process. This module aims to reduce this overhead by having governance pre-approve budgets at a fixed rate. Additionally, the FlapTap provides a mechanism to redirect a fixed fraction of the surplus auctions (Flapper) towards another target. This will give governance a way to control protocol profits.

Specification

MIP34c1: Keg

The Keg contract defines flights which are a list of target addresses along with the relative weights of how much each address should get. Governance can create, update or delete flights by calling the seat() and revoke() functions.

Once a flight is registered then anybody can approve DAI to be sent to the Keg via the pour() method. The flight bytes32 descriptor is a human-friendly name for the list of targets which could be for example “operations-smartcontracts”.

The keg also defines a stoppable modifier to allow governance to pause payments.

MIP34c2: Tap

The Tap allows governance to define streaming payments from the Surplus Buffer at a fixed rate. The flight is the target group of addresses in the keg. The rate is the per-second rate of DAI to stream from the Surplus Buffer. Once initiated anyone can call pump() to pull funds from the Surplus Buffer via vat.suck() to the target flight. Tap also supports the stoppable modifier to allow governance to pause payments.

MIP34c3: FlapTap

The FlapTap sits between the vow and the flapper. It is used to redirect a portion of the funds to the Keg. The flow parameter controls what % of the funds go to the keg - the rest go to the flapper as usual. The FlapTap is designed to be as non-invasive as possible by preserving all the assumptions of kick() and cage(). One unavoidable behaviour change is that vow.bump is no longer one to one with the amount sent to auction, but is instead the amount to send to the auction + keg.

MIP34c4: Test cases

see Keg.t.sol

• test_flap_tap_cage
• test_pour_flight
• test_keg_deploy
• test_seat
• testFail_seat_bad_shares
• test_tap_rate_change_with_pump
• testFail_flap_tap_invalid_flow
• testFail_tap_rate_change_without_pump
• test_pour_flight_one_wei
• test_flap_tap_deploy
• testFail_seat_zero_address
• test_tap_pump
• testFail_seat_zero_length
• testFail_pour_flight_invalid
• testFail_seat_unequal_length
• testFail_pour_flight_not_enough_dai
• testFail_pour_flight_zero

MIP34c5: Security considerations

The Keg does not require any permissions into the Maker system and as such does not have any security risks. The Tap is simple and only interacts with vat.suck() in a permissioned way. The attack surface is minimal and easy to audit. The most significant risk comes from FlapTap which requires a modification to the core protocol to sit between the vow and the flapper. The code itself is simple, but the modification to the core protocol should be carefully considered.

MIP34c6: Licensing

• AGPL3+

[MakerMan]

I am confused by the complexity of this payment system:

There is this idea that passing quarterly budgets through governance being considered a problem. Yet once the ‘payment spigot is turned on’ it is then only turned off or changed by governance - which may also act slowly.

My problem is the attack surface via vat.suck() and setting up automated systems.

• Where is the general document that structures in a more general way (and using normal language) how this system is intended to function generally?
• What roles governance plays?
• How often will governance be acting?
• What are the quality assurance checks?
• What are the security issues and security checks?
• Who is going to audit and do accounting?
• How often?

My problem here is I see a lot of complicated mechanics being setup to access the surplus and no real global document describing the problem(s), the solution(s), and then the implementation(s).

I am glad this is being worked on but rather dismayed there is no general MIP document or even a funding document forthcoming that covers a general specification, an org chart, a plan and timeline for implementation, implementing auditing/checks and balances etc.

Since my intention is to vote more I do try to keep up on forum posts so perhaps I missed a more general discussion on this, or is all of this being done behind the scenes with no real information documents being produced for the community of MKR holders that are voting?

[ElProgreso]

@MakerMan

• Where is the general document that structures in a more general way (and using normal language) how this system is intended to function generally?
• What roles governance plays?
• How often will governance be acting?
• What are the quality assurance checks?
• What are the security issues and security checks?
• Who is going to audit and do accounting?
• How often?

From my personal point of view–here’s how I visualize the responses to your questions:

• Where is the general document that structures in a more general way (and using normal language) how this system is intended to function generally?

Check out the write-up by LFW on the FlapperDistributor

• What roles governance plays?

Personally I envision each Team having an annual budget. That budget is presented by the Team and review by the community. It then goes thru the weekly Governance cycle–you know-the frozen period, RFC, Gov Facilitator approval, etc. Then the MKR holders can vote to approve, or reject. Similar to the same process as what your Black Thursday working group is going thru right now. This keg implementation will help your working group and Others, get paid quickly IMO.

• How often will governance be acting?

For Team budgets, I imagine once per annum. Imagine if you worked at ABC Inc.,–and you’re the head of Accounting/Director of Finance. I would imagine you would need to present an annual budget to the CFO. In this scenario, you would present your budget to the Maker Community. Again, this is my opinion/vision.

• What are the quality assurance checks?

I envision it as: Teams present their budgets. The community approves the budget via an Executive vote. Checks and balances are made via on-chain transactions (keg distributes and Team members get paid), and on the Team delivering performance. Budgets equal clear commitments. Transparency. Asking the right questions. I highly doubt we will be dealing with fraudulent Team members. We have good folks building this community.

• What are the security issues and security checks?

Not sure if you’re asking about contract security, or Job security. If Job security–this is priority #1. Hands down. Otherwise–This should be a simple implementation – DAI from SB gets paid out to Team – reuse the same keg for established Teams – we can optimize it for contributors.

• Who is going to audit and do accounting?

Personally I’m not a fan of Audits (inspecting invoices, reviewing receipts, etc.–micromanagement is not my style) but, I am pretty sure an Audit can be done. The operations team can eventually introduce accounting. I know a few folks from the operations team has been investigating all of this.

• How often?

As often as the Maker Community deems necessary IMO.

All in all–IMO: The most important takeaway: Job Security and let’s make sure our Team Members get PAID so they can pay their Life Expense. Priority One.

[MakerMan]

@ElProgreso

Check out the write-up by LFW on the FlapperDistributor

I think I read that and felt the title was such that it was a proposed mechanism for fund distribution. I didn’t comment there. There wasn’t enough community engagement on that to get to a general Maker revenue/DAO payment model.

The question that is going to come up here is what happens if there are no DAI profits? Everyone on board running a negative surplus to drip out budgets automatically and sell MKR to raise DAI, or pull from an investment fund or treasury. I didn’t really see this discussed at all (except as a question) and a point to @mrabino1 that basically just selling MKR to fund after buying to burn it was ‘inefficient’ (which I think most people would agree with).

@ElProgreso

• What roles governance plays?

Personally I envision each Team having an annual budget. That budget is presented by the Team and review by the community. It then goes thru the weekly Governance cycle–you know-the frozen period, RFC, Gov Facilitator approval, etc. Then the MKR holders can vote to approve, or reject. Similar to the same process as what your Black Thursday working group is going thru right now. This keg implementation will help your working group and Others, get paid quickly IMO.

But if governance is going to be involved annually why not then just allocate budgets annually out of a large treasury funded by surplus with a single shot buy MKR and burn with 10K DAI and take 10K to a treasury. Have N being a number that is tunable based on MKR price and/or a governance action. This seems like a much simpler mechanic to interact with the suplus via vat than having vat drip out funds all over the place. Maybe maybe not. I am not a contract developer. Also having all funds in a treasury I think makes accunting easier since then one doesn’t have to go through the myriad of vat transactions to isolate the funds - but I guess if addresses are whitelisted somehow this isn’t too much of an issue.

Even so in both cases governance acts annually in your vision - which is not unreasonable. I just think the mechanics of MIP34 proposed seem sort of overkill to achieve the goal.

@ElProgreso

• What are the quality assurance checks?

I envision it as: Teams present their budgets. The community approves the budget via an Executive vote. Checks and balances are made via on-chain transactions (keg distributes and Team members get paid), and on the Team delivering performance. Budgets equal clear commitments. Transparency. Asking the right questions. I highly doubt we will be dealing with fraudulent Team members. We have good folks building this community.

So you are saying the teams themselves.? So no independent auditing or accounting. Seems like this could be abused in time. There are lots of examples of people skimming company funds. It is why in a lot of companies there are accounting departments that basically monitor and check fund disbursal. Just to make sure money is ending up where it should go, buying what was intended. I just wondered what kinds of checks people thought would go into place on this generally.

@ElProgreso

• Who is going to audit and do accounting?

Personally I’m not a fan of Audits (inspecting invoices, reviewing receipts, etc.–micromanagement is not my style) but, I am pretty sure an Audit can be done. The operations team can eventually introduce accounting. I know a few folks from the operations team has been investigating all of this.

Once upon a time all I did was freelance and send in invoices for payment describing work done, hrs, usually accompanied by a basic work log of some kind (though I quite often kept and keep meticulous logs in case something went legal - time consuming - yep - annoying - yep). But if someone asked with additional effort logs could be produced. It adds overhead cost sure, but given everything DAO wise is basically flying by seat of pants perhaps this is where some focus should be given. I mean if governance has an issue with a budget or they think too much money is being spent on department B, what is the recourse without some accounting? I see this will become a yearly rub - predominantly if MKR is needing to be burned to pay these budgets and no accounting for the lean times in the good times to build a treasury is not accounted for.

@ElProgreso

• What are the security issues and security checks?

Not sure if you’re asking about contract security, or Job security. If Job security–this is priority #1. Hands down. Otherwise–This should be a simple implementation – DAI from SB gets paid out to Team – reuse the same keg for established Teams – we can optimize it for contributors.

I am just asking about fund security. For example in 1Hive there is effectively a multisig and aragon set of contracts. swarms ask for funding which goes into a contract that is accessed via multisig and voting members of the swarm basically allocate funds to projects or individuals for work done that they checked and/or approved. In this way no one person can make off with the funds - though a malicious swarm that gets funding could just pocket but since funding there is monthly that group would only be able to run off with 1 month worth of funds. I don’t think this is ideal but it is just a general stewardship over funds security question. How are funds secured, and how are they disbursed. In the case of 1Hive via a conviction voting proposal passing, funds enter a smart contract that uses multisig mechanism for disbursement. Quality assurance checks are done by the group and accountable to the DAO. Other proposals pay out immediately even if contractual obligations have not been met (prepay or post pay depending on the proposal) In the case of 1Hive there is an intention to put a intermediary (via celeste) between the proposal, and pay out as a quality assurance check on work being done. This is not in place yet.

I guess this proposal is about an implementation and I guess I didn’t really see details of funding mechanics and backing discussed or hashed out.

Will Maker mint MKR to pay bills if there is no income or running at a loss?
How does a treasury fit into this?
What is the general structure proposed regarding use of Maker revenues beyond burning MKR to run the DAO generally?

I guess my point was I never saw a proposal that really lays out just a basic framework for how the Maker revenue model is going to change to fund the DAO away from the Foundation. The Foundation is working out of a warchest of MKR that presumably they sell periodically to raise DAI. I see mechanics popping up but none of the details of the how this works financially other than a hope that the surplus will always have funds.

[hexonaut]

These are all good points and will be addressed in the non-technical Keg MIP which is coming soon. The above is just a technical description of the Keg system without any particular use case specified. Some examples of possible use cases are:

• Streaming Payments to Domain Teams
• Redirecting part of the MKR burn to DssGovRewards

These use cases will be added as proposals under the non-technical Keg MIP when it’s done.

[SebVentures]

MIP34 is mainly a means of moving money outside of the Maker Protocol.

The money might get moved to the mandated actor multisig.

From this multisig some budget can be paid off to teams (like here a proposal for RWA). The mandated actor will act to check that no payment is suspicious (undocumented) and inside the budget limit.

The Keg provides a lot of options that Governance can decide on. It can push a lump sum directly to the multisig or push only a % of revenues. This multisig can act as strategic reserves for the time being (the cool stuff of strategic reserves should be on the protocol anyway).

You are right in saying that some accounting of the multisig will be needed. In my view, this should be fully open, and for the community to check when needed.

In short:

• Governance can transfer cash to mandated actor multisig (using the Keg)
• Governance vote on all budgets.
• Governance can decide if the multisig has only money to cover for 1 month of expenses or enough to survive 18 months (in case there is an ES and to avoid making too much transfers) or anything else
• Mandated actors will check and pay invoices that fall within an approved budget.

[MakerMan]

It just seemed prudent from a implementation and funding security perspective to have a single destination for funds from the surplus into a treasury. The treasury formally would be DAO controlled in the sense that the DAO via governance actions can then authorize funds from the treasury to go into a DAO operating budget fundf (or other funds). Do this annually and warm up the next years department or operation budget requests for governance vote perhaps 3-6 months prior to it being needed.

So I would have this as a diagram look like:

• VAT(surplus) ->
• General Maker Treasury (which is controlled by governance say on a yearly or biannual basis) ->
  1. DAO operating budget -> Domains (via Domain lead multi-sig)
  2. Liquidity reserves (Liquidity team multi-sig + possibly Domain team)
  3. Investment reserves (Investment team multi-sig + possibly Domain team)
  4. Contingency operational reserves (Domain lead muli-sig as well as large MKR governance voting MKR multi-sig sign off)
  5. Other stuff (to be determined multi-sigs)

The DAO budget would just get a lump sum then controlled by a N-2, N-3 Domain lead multisig that includes all the domain team leads and designated assistants. I beleve the whole DAO management team of all the domain team leads. It would be less likely to misappropriate funds, and then the domain teams can wrangle themselves over the DAO operating budget if budgets need to be adjusted on the fly giving them together some flexibility to adjust the DAO operating budget to changing conditions/needs. Some incentives for coming in under budget might be prudent but not required some potential penalties if over budget might be considered as well ( or at least some incentive mechanics in this regard thought about)

I also think it would be prudent to set aside a contingency DAO budget of roughly 10% of the annual funding request (i.e. fund yearly operating budgets at 110%) DAO management group can call on if they need that perhaps has some additional large MKR holders as the multi-sig participants that can sign off on contingent operational funding in a pinch and not have to go directly to governance to wrangle over.

My point here is that I’d rather this DAI distribution to not be so close to the VAT(surplus) and would rather it come through a treasury managed by the DAO governance and dropped into a Maker Operations budget that serves all the domain teams as suggested above.

I realize this is my own view and words/ideas are easier to say and come up than to code up contracts or write MIPS on the matter. I just thought we would first discuss the structure of such budgets and how money flows vs. just drop kicking implementation without discussing a general structure. I saw the well done post from @LongForWisdom but didn’t feel it had enough discussion to be a working financing structure. If everyone wants to go with the whole stream payments form the above MIP34 implementation - ok poll on it - an if everyone agrees let it fly.

While I thought about and present an alternative above. My only concern is that this is very close to the VAT/surplus in terms of smart contracts and I have concerns this opens up an attack surface that could be mitigated by a just going to a treasury which the DAO controls (a two step funding model). This gives even more flexibility. It potentially provides an operational cash buffer and opens up immediately the general treasury to other cash management functions that is controlled by the DAO but then moved into contracts managed by elected management teams.

Anyway I will let this one go to the community at this point. The above is a rough idea for structure and flows of funds as well as a rough idea on how it can be managed that also reduces governance overhead and reporting to annual cycles.

[MakerMan]

I hate to add to an already longish stream but I realized there is a single reason Maker NEEDs a seperate treasury.

The surplus technically is part of the whole DAI backed by collateral. Imagine if you will a event that drains the surplus (Black Thursday comes to mind). You don’t want funds that are designated to run the business be drained to nothing when you most need funding to conduct key operations to get back on your feet. You want these funds well isolated from the system.

[ElProgreso]

I don’t know how to answer your questions MakerMan–but when I see conversations like this one–where a protocol is struggling with their treasury–and they don’t have the options to generate income via their products, or by minting more Tokens–I think to myself, that the most important component is making sure everyone that works for the DAO has Job Security:

[MakerMan]

@ElProgreso

I don’t know how to answer your questions MakerMan–but when I see conversations like this one–where a protocol is struggling with their treasury–and they don’t have the options to generate income via their products, or by minting more Tokens–I think to myself, that the most important component is making sure everyone that works for the DAO has Job Security:

My answer to that is the following:

1. Then you want to see a well funded treasury.
2. And a Operations DAO fund that is ‘over funded’. ( i.e. if Managers can do things underbudget then the DAO budget in principle becomes what the DAO managers - manage. It is my expectation that we should slightly overfund the DAO Operations group. Build at least a 1-3 year operations budget. Would 1-3 year salaries being guaranteed be enough to start?
3. DAO governance that is supportive and given conditions warrant approve commitment to people for 2-3 years or longer employment contract. All of this contingent on the Treasury having funds and, if necessary, MKR being printed to pay them?!

I await the MIPs, and polls, on such matters. If backed with well reasoned arguments (like some of the people here as a MKR voter I could commit to ‘as long as Maker has money, or breath’ we will mint MKR to pay you folks.) I am not going to try to make that list, because that is a governance discussion. imo. Those who have put in since beginning, who are smart contract devs, with high experience doing all the grunt work on the contracts side.
I come to realize talk is cheap, smart contract code that does what talk says - really expensive and hard to come by. It is particularly these PEOPLE protocols NEED to keep around. But a general consideration for finding and retaining people is commitment (btw the whole employment market is now a compete vs. commit environment btw - employers thinking people are replacable to get cheap work, and people struggling to manage careers in the face of employers not giving a shit about them)

You can’t easily replace some of these people, certainly not quickly AFAIK.

I am and have long been a 24/7/365 operations guy who is committed to his crews both from a career perspective (them moving up and on if necessary or up within) understands both the reality (always pretty high turnover in operations group) both from the management side as well as the people side. I am going to be supportive of creating an environment that works both from a management token holder perspective (management, budgets and q/a), as well as the employee doing the work trying to take care of themselves and their families needing certainty perspective.

[alexis]

I wanted to say two point here :
First you are probably alright that gov probably wants to have more control over the founding. I have pushed MIP37 for that, however this case is one use case over many and doesn’t reflect correctly the keg MIP. The ability to divert a percentage or a some from the vow is needed even if we have an account where to move found.

The second point is that it is very unfortunate that when an MIP is on request for feedback we got feedback the day after the end period. The keg has been in this stage for months now and probably never get feedback. I don’t think Sam or the one how did the keg is paid for that and it is not fair to him to delay thing that much. I don’t even sure he is still active here. You are probably alright the code is not that great but in the same time the code is open source and I haven’t seen any pull request so far except Sam one.

Edit : Oups actually it seems that I am confusing MIPs but the statement is still valid.

Edit 2 : thanks for the feedback BTW very appreciated

[hexonaut]

I’ve formally submitted this for the March governance cycle.