Validation Teams: A proposal for a new variety of team

Why do we need validation teams?

In my view, the main reason we would want validation teams is that there are significant disadvantages to having MKR Holders validate everything produced by the other teams (risk, oracle and governance) on an ad-hoc basis.

What are these disadvantages?

  • It potentially leads to a large duplication of effort far beyond past the point of useful returns. There are currently over 14,000 unique addresses holding MKR, do we expect all of these to validate team output?

  • There is no structure or organisation to MKR Holders. They don’t know each other, they don’t communicate outside of these forums. There is no way to know how many MKR Holders have validated any one thing.

  • There is a large diffusion of responsibility due to the number of MKR Holders. ‘Why should I do it when there are so many others that could?’

  • Related to the last point, there is a large abdication of responsibility due to the uneven token distribution. ‘Why should I do it when JohnnyWhale10K can do it?’

  • The incentive alignment behind validation is sub-optimal. The costs are paid by those who are providing a valuable service (validation) and the benefits are reaped by all MKR Holders, most of whom have paid no cost.

I also believe that there would be other fringe benefits to implementing Validation Teams as described below. Namely:

  • It is a good entry point into the DAO for interested actors or stakeholders. A validation team shouldn’t require specialist skills. However, because of the teams responsibilities, they will be required to interact with all other parts of the DAO (to a greater or lesser extent.) This makes them a source of talent for other teams.

  • It gives us a set of teams who has the responsibility of considering the system-wide implications of any proposal from the other teams. These teams would take a more strategic view of how any individual change could impact the wider system.

  • It would allow MKR Holders to be ‘hands-off’ if they wished to be. There is clearly a desire for this, as we’ve seen from the limited voter engagement. This allows for the separation of interested parties/stakeholders (join/create a validation team) from the passive stakeholders looking for a good investment (vote for any proposal which has multiple validation teams backing it.)


So what are Validation Teams?

Personnel

Validation Teams should have between 2-4 members, with the ideal number being 3. Three members allows for multiple points of view and useful discussion within the team. It also allows for a separation of responsibilities and gives fallback personnel in case of illness or holiday. A validation team might induct a new member in anticipation of replacing an old, making 4 members. In the case of an unexpected departure, it would still be able to fulfil its duties with two members.

Members of each validation team should be willing and encouraged to learn from the other teams (Oracle, Risk, Governance and Dev.) This results in both more effective validation, and a greater pool of generalist personnel that can move from validation teams to one of the other more specialised teams. Between them, the 3 members should have enough knowledge to validate the other teams work (be able to understand and validate, but not to generate.)

Should be made up of engaged actors in the MakerDAO community. Specifically, if at all possible members of validation teams should have an interest in the DCS and MakerDAO beyond solely a monetary incentive.

How many teams should there be?

There should be more than three, but less than ten validation teams. As the system expands, there may be a requirement for this number to grow. The exact number at any one time would be voted on by MKR Token Holders.

What are their duties?

  • To produce short non-technical validation reports (similar to technical audit reports in format and scope) for consumption by voting MKR Holders. Each Validation Team would create one of these reports for each proposal from the other teams (Mainly Risk and Oracle, but also Governance and eventually Dev.) They could also produce reports on applications that come from outside the DAO, namely collateral on-boarding applications, and oracle applications.

  • To act as a pool of generalists that can be drawn upon for the other active teams. This can come into play both on a temporary and a permanent basis. If there is a large amount of Risk work to be done, potentially Risk Validators can pick up any slack.

  • To operate independently from the other Validation Teams. Validation Teams should not confer under any circumstance. Each report should be sourced separately, and each proposal be judged without conformity bias.

  • To keep a wide view of the entirety of the MakerDAO ecosystem and to alert other teams to cross-domain problems that may have fallen outside of their notice.

  • To communicate openly with other (non-validation) teams, concerns do not have to be raised solely within validation reports, they can also be raised with the appropriate teams directly during the process of creating proposals.

  • To educate themselves as to the state of the DCS and the MakerDAO community in general. Validation Teams will require a good understanding of both in order to fulfil their other duties.

Remuneration

Validation Teams should be paid from stability fees once that system is available to the DCS. The rate of pay should be below that of the other teams that require domain specific skills. Validation Teams are a generalist position that should be accessible to any interested party with the will to learn, no special skills should be required, and they should be paid appropriately.


When should we setup validation teams?

  • As soon as possible. We already have things to validate, and to some extent we’re already seeing the variability in the output from MKR Holders. There was a large amount of response to the recent collateral onboarding application (COA) for TUSD, but there has been virtually no response on the COA created by Status (admittedly it is early days.) Likewise, the Interim Governance Proposals received a much larger amount of scrutiny than the recent Oracle Proposals.

  • Of course the major downside is that Validation Teams can’t be paid yet. That said, I think it is worth organising teams now rather than later if MKR Token Holders agree that this should be a paid position in the future. Back pay would also be a consideration.

Who should be part of these teams?

  • Anyone with an active interest in the MakerDAO system.

  • Anyone with a large amount of MKR Tokens (or someone they’re employing)

  • Many of you were planning to do this sort of validation anyway on a less-structured basis. This would be a more formalised and more useful version of that same activity, with the potential to be paid in the future.

  • If at some point you’ve considered becoming part of another team (risk, oracle, governance, dev, etc) then joining or creating a Validation Team would be a good place to start getting to know the duties and learning what is required of the more technical roles.


Some Arguments Against

Naturally it’s only reasonable to try to outline some of the reasons we shouldn’t implement this variety of team.

  • Validation Teams would need to be paid, this money would come out of the stability fee, reducing the income of the system and the individual MKR Holder.

  • It may be difficult to judge the quality of output from Validation Teams. It could be easy to get away with doing very little actual work, and writing a false Validation Report saying ‘everything is fine.’

  • Is this covered in the risk team brief? Would the risk team(s) be doing this as a matter of course?

As always, if anyone has more arguments against, please make them in the comments and I’ll add them in here.


Last thoughts

If this write up attracts a decent level of discussion then we can potentially start signalling on it, but I’m reluctant to throw up a poll this early. If you like this idea, or have concerns, please share them as a written comment.

5 Likes

Interesting, need to think more will edit in some thoughts as they marinate.

I think an obvious next step would be a more formal rubric (assuming there is little opposition, mainly refinements on scope/expectations). One that defines some degree of accountability. In general however I really think we need more robust personnel management agreements and set specific times to review personnel contracts for performance, consistency, ect.

Another concern is budgeting. “Paying from the stability fee” is used here alot. Obviously thats the revenue stream, but soon the organization needed to pay everyone will become a ton of governance overhead. What about reserves to ensure cash flow to contractors? How does the DAO manage all of this personnel safely and transparently. Should there be a proposed budget?

And I also don’t have a great word to describe people employed by the DAO, should we call them employees? contractors? legally are their implications?

1 Like

Good initiative. Imo engaging, growing and managing the community/governance is really becoming one of my biggest concerns.

I share the concerns Mitote mentions. Maybe it would be an idea to tryout the concept of validation teams with a single team first and then reevaluate?

In general I think an approach that also supports a more ad hoc participation would be great but not sure if/how this is possible. For the long term I think we should look into if/how rewarding voting is possible and then validating through voting also. Obviously there are a lot of problems related to this that needs to be solved and incentives that needs to be aligned. From my initial readings at daotalk it seems like reputation, token-locking and futarchy (or maybe a combination) are interesting concepts. However implementing these concepts seems like very big projects. Decentralized governance is not easy :slight_smile: so a validation team seems like a good beginning.

1 Like

Here are you looking for redundancy in reports to get a more thorough viewpoint of one topic? Personally I don’t quite see the need yet for separate, independent reports on the same topic.

Is report and proposal synonymous here? I was viewing reports more as updates (taking the load off risk, gov, or oracle team) rather than proposals ready for mkr signaling.

Also how do you see the interplay between validation teams and the governance facilitator(s)?

1 Like

All good questions, I can’t claim to have the answers. Maybe we should have a topic specifically discussing these sorts of things.

Personally I’m hoping that there is not a huge amount of governance overhead for managing personnel. If necessary we can nominate someone to do it… I guess an admin team… It never ends really does it?

Employees would be my chosen terminology.

This is a sensible idea. Starting with one would make sense. Ultimately it might depend on how many volunteers we have to do it. It would be good to have two teams at some point though, in order to see how consistent or inconsistent the output is between the two.

Yes. I’m of the opinion that this is always beneficial. Obviously there are diminishing returns, especially above 3-5 groups. But in general the more separate sets of eyes and brains examining proposals, the more likely we are to catch something dangerous before it hits the system.

Nope, that’s probably my fault for being unclear.

Reports: A short document created by a validation team commenting on the validity/quality of a proposal created by another team. Is used to inform MKR Token holders prior to voting on the proposal in question.

Proposals: Anything created by a (non-validation) team that requires voting on by MKR Token Holders.

The interplay between the governance and validation teams would probably be the most limited. In general governance probably won’t be producing technical proposals. That said, there are governance proposals that come out of signalling polls. Validation teams could fulfil their duty here by ensuring that the process of governance isn’t subverted and that we have consistent standards for the governance process.

I agree it’s nice in theory but even leaving aside the difficulties you mentioned, I’m not convinced it’s desired for this sort of validation, there needs to be some sort of formalised system for saying that ‘yes I’ve looked at this, and I think it’s good.’ Otherwise you have no measure of how much scrutiny any individual proposal has had.


If anyone else has thoughts it would be great to hear them. Equally good would be if anyone that fancies attempting this sort of work could make themselves known.

This is going to require a fair bit of community buy-in for this to become a thing, I’m not convinced it should even be signalled on until it’s been discussed pretty thoroughly. So yeah, if you want to see Validation Teams, speak up.

1 Like