The problem here is the myth that genius senior devs are infallible, which leads to the thinking that governance has to put all their trust in a small closed group of special genius devs that are the only ones who will ever be good enough to write code for the maker protocol. But this way of thinking doesn’t hold water considering that even Rain and Lev - literally the two greatest geniuses in all of crypto who basically built the entire maker protocol by themselves - made some serious mistakes with the emergency shutdown module.
The solution is to move past branding specific people as special infallible genius devs (which im sure nobody actually wants to be), and instead opening up and branching out by relying on open, scalable processes and external audits by top tier auditing firms (which the genius devs can help identify and vet). For collateral onboarding I think it can be quite simple such as:
At least 1 audit and 2 weeks bug bounty for a small debt ceiling, 2 audits and 1 month live bug bounty for a large debt ceiling and 3 audits + 3 months liveness and bug bounty for unlimited debt ceiling (unlimited here meaning the risk team can set the parameters they want without worrying about technical risk factors related to the adapter, oracle, liquidation setup and other things related to the technical collateral onboarding itself).
That is of course just a basic example, but this kind of hypothetical process can be extremely scalable, and also be supported and improved by simultaneously making sure we have plenty of super geniuses in the ecosystem that also review and take part in the process - but we can’t put all of our trust in specific individuals, we have to put our trust in open processes because otherwise we will never scale, and then as we stretch everyone thin running on single thread mistakes will start to happen.
Yes, I am well aware of the bottlenecks. I’ve been at the Foundation for almost two years and have had my hands all over this, MIP41c4-SP14: Facilitator Onboarding, Collateral Onboarding Core Unit. The past six months, I’ve been facilitating the Foundation’s dissolution. My roles have been 100% internal focused so I haven’t had a lot of community participation…until now.
While there are some technical challenges (there always are), there is another one with our current governance process as it relates to moving collateral through the system. There is a element of autonomy that is needed, with guardrails, in order for us to scale the collateral onboarding process.
To scale, it’s a function of three things: the COB team, the parallel development work (infrastructure), and changes to the governance process that allow for a much quicker, iterative approach when adding collateral.
To me, the biggest challenge is attracting, hiring, and retaining the COB team since solving any problem first starts with the people side of the equation. I’ve been doing that for 30 years so I feel pretty comfortable taking that challenge on.
Thanks for this. You’re aligned with the thinking here. In my conversations with the Foundation members and others, this is the theme that has emerged.
I believe we still need those genius senior devs. It’s just the right tool for the right job. That’s why I’ve also proposed using the COB as a training ground for newer devs into the Maker ecosystem. As an example, working with SES using a feeder system to allow new devs to cut their teeth on the protocol. It’s a perfect opportunity for those folks to work on classes of collateral that have already been figured out and are more mechanical.
For those new collateral types where innovation is required, we’ll need our best people on the job to figure it out then pass the work onto less experienced devs.
I fully support this effort, but I think it will require both skill and timing to get this Core Unit going. What I think you are proposing is a unit composed of approximately 1/3 Engineering, 1/3 Oracles, and 1/3 Risk, which then (hopefully) are able to turn the collateral onboarding process from creating unique pieces of art into something more similar to serial production.
Initial thoughts from my side - mostly just brainstorming
Right now Maker has a collateral onboarding pace of about 2 types per month, but as far as I know, nobody has done any serious attempt to debottleneck the existing process.
So since you propose this CU it must be assumed that either debottlenecking will not happen or that the results will be poor - otherwise this CU makes no sense. Thoughts?
Possibly you will have to wait with growing this CU until the market crashes and more devs will be available
I guess you have probed around for support on this CU, but I think what would convince people would be a description of the process flow of the as-is situation, and then a description of the process flow within your proposed CU. Right now you are just promising to employ more people?
I’ll be speaking more about the plan and process at an upcoming Core Unit presentation scheduled for May 26th.
Overall, what I am proposing is an iterative process. When I managed collateral onboarding within the Foundation, it exposed the almost the same issues we’re having today in the community. Today, it’s more important than ever we figure out how scale the process. There is a low probability our current collateral onboarding system will meet our long-term needs.
The strategy involves three components: building and retaining the team, scaling the infrastructure, and creating autonomy.
I appreciate your thoughts around the team. Right now, we have a number of dependencies within other Core Units and this creates the bottlenecks. The team I am proposing to build will have elements from all three groups in order to streamline the process. I want to be clear this is a collaborative effort between the Oracle, PE, and Risk Core Units. There are always challenges in hiring people in any market. The goal is to focus on what’s best for the protocol.
On the infrastructure, it’s critical to take a holistic approach in developing our products. I think that is one thing missing to date. My background is delivering software with a product orientation. Functional approaches are important and make sense in some situations. In this case, we’re going to need to figure out how to have multiple teams working at the same time on smart contract functionality. My feeling is that the whole project will be in jeopardy if we don’t do this one thing. Plus, it’s really important to diversify responsibilities within the DAO.
When it comes to autonomy, all decisions are structured to go through Governance today. This alone will prevent the entire protocol from scaling. How do we modify our structure to accommodate a higher level of growth, while working under reasonable guardrails, and without introducing unreasonable risk into the system? Collateral onboarding provides a great opportunity for us to figure this out since debt ceilings are an automatic limiter of the system.
Please keep your comments coming as it’s going to be a collective effort to make all of us successful.
Hey @monkey.irish, in general I think having a Core Unit to focus on collateral onboarding is a good idea, will hold my thoughts on that to the end. Initially I’m just going to focus on and hopefully provide some useful comments to the contents of this MIP.
I don’t really understand how some of these principles are directly relevant to collateral onboarding.
Collateral Onboarding isn’t really very related to DAI adoption. The one tenuous connection is that it exposes those wanting to take leverage on that collateral to DAI. The rest: supply, attractiveness and market usage either don’t drive DAI adoption or aren’t really addressed by collateral onboarding.
This doesn’t really have anything to do with scientific governance?
Again, not sure what the statement has to do with gradual decentralization.
Feels a little like you had the principles in front of you and are trying to fit them to the collateral onboarding unit. Imo it would be better to just say: We want to really push and support pillars 4 and 5 in these ways. Rather than trying to connect 2 and 3 to this unit when they are only tangentially related.
Not sure this makes sense back-to-back? ‘If so’ - what are you referring to?
Not sure this really says much? In what way is high-quality collateral connected to a strong incentive system? What does compensation have to do with demand have to do with growth?
This is more of a ‘content’ comment rather than a ‘presentation’ comment. I’m not sure that we want a single core unit that is the guardian of how collateral makes its way into the protocol? This doesn’t sound like a decentralized solution. Like, you mentioned economics, risk and the DAO principles, but are you trying to claim that this unit should have the final say on levels of risk, economics and how the DAO principles apply?
Why is it good to encourage competition in this instance? Competition leads to a race to the bottom, and sacrificing long-term stability for short-term gain. If you turn collateral onboarding into a competition, you misalign the incentives of the risk-evaluation portion of collateral onboarding.
This is problematic, imo, for a number of reasons. First, those principles are old as hell, and very rarely referenced by anyone in the community at this point. Second, that vote took place at a time when MKR was much more centralized than it is now, and had different owners. Third, why exactly is this a part of the collateral onboarding mandate? Being a ‘guardian’ of these principles has nothing to do with collateral onboarding. The part about being ‘true to our community’ rings a bit false to me personally too, as you haven’t exactly been heavily involved in the community up to this point - at least not that I’ve noticed.
Have each of the core units mentioned here explicitly agreed to work with this core unit in this way?
Feels like agreeing this with critical stakeholders should be a prerequisite rather than something you figure out as you go? Like, what if critical stakeholders aren’t cooperative?
To summarize my thoughts after reading this, I would say that this seems like a good idea, but I am less sure of the execution. If I personally wanted to setup this core unit, I would do the following:
Speak to PE, Oracles, Risk and GovAlpha and express my desire to help coordinate the collateral onboarding process and seek to get their buy-in to do this on a trial basis.
Setup a meeting each week that covers collateral onboarding that includes the above stakeholders.
Provide value to those stakeholders and make their jobs around collateral onboarding as easy as possible by providing coordination, setting expectations and handling communication with the community and collateral partners.
Become indispensable to the process.
Start hiring individuals to perform the more mundane duties that the existing stakeholders don’t want to handle.
Expand the team to take over more and more of the process.
I would probably do a core unit proposal around step 3/4, initially budgeting only for my own time on a 3-month budget, then adding to the budget and responsibilities as I was able to hire.
The tl;dr of this is that I would actively provide value, and make myself indispensable to the process, and propose a budget that supported myself doing that, before attempting to onboard additional contributors.
Hi, Long. Thank’s for your feedback and comments. I also appreciated getting additional clarification on our call yesterday.
There is a lot here so I am going to try and address your major points. Let me know if you’d like additional clarification on anything you might have felt I missed.
Most organizations I have worked within have a common goal/purpose/mission/vision. Mapping my work, or in this case, the proposed work is a way for me to show my support for the community and protocol. The five principles I mentioned were voted in by the community some time ago. I get it if they are old or aren’t being referenced or used anymore. That doesn’t make them invalid especially in the case sustainable finance.
My opinion is when there is a lack of vision, there is a lack of direction. I see other posts where this topic is more widely discussed and I’ll place my comments there. As for this MIP, I’ll review it and the feedback to determine the MIP modifications to be made relating to this issue. To be clear, my core unit goal is to focus on providing engineering services around collateral on/offboarding.
I appreciate your suggestion on the steps to setup this core unit. That is an option I’ll consider in addition to waiting until I secure a team then move into a formal submission process.
This ties back into the vision or mission and having a plan and focused goals around collateral onboarding. I think this is best accomplished by having a core unit and collaborating with other stakeholders to build scaleable processes.
While there could be an opportunity for competition in collateral onboarding, I was more referring to overall competition in the ecosystem. I hoping teams and core units will be selected based upon a variety of factors where hard costs are only one of the components. Generally, there is so much work to be done today, it will take a bit of time before we see real competition. Right now, diversification, like having multiple smart contract core units, appears to be our next step. Even then, it’s highly unlikely that will be competitive given the amount of work we have to do.
The question I am playing with is, can we provide a platform for collateral onboarding and an incentive model based upon the value of the collateral? If a third party onboarded a collateral type and it generated a healthy SF, would we be willing to pay a small percentage of the SF back to the external team who did the work to onboard the collateral? If it’s possible to implement a model like this, it could allow us to really scale the system and normalize the hard costs for the core unit.
In my conversations with the core unit facilitators (and proposed), I’ve shared my goal of incrementally taking on responsibilities. All of them were supportive of this concept. It’s a continuous process to determine the specific responsibilities. Your suggestion at the end of your feedback is aligned with some of my thinking here. Btw, I haven’t had a chance to talk with Risk yet.
Hey RoJo! To get an easy explanation of what exactly CES is going to be providing–as an Example–this CU can/will seek to onboard Alternative Collaterals such as wrapped Solana, wrapped DOT, wrapped Atom, etc., collaterals that are NOT EVM compatible(tho Cosmos/Tendermint are comp.), and this CU can also innovate by onboarding DAI into other Layer 1s, such as Terra, Avalanche, Osmosis, etc. Am I getting it right? Looking for the ELI5 on this MIP39 Application.
In other words, CES is going to do the heavy lifting that PE, Rick and others can’t do because they’re too busy with more important/time-sensitive things–am I reading your core mission correctly?
Thanks for your question! It’s an interesting one to address. I’ll try to give you as direct of an answer as possible at this time. I’m taking a little extra space to elaborate for the greater good.
In short, CES is an engineering services core unit which means that we have the technical ability to execute a variety of engineering functions (smart contract) within collateral management. We offload and consolidate the product management of the collateral functions from the other core units. The actual scope of the work is driven by the roadmap and product backlog. The roadmap and backlog is created based upon feedback and input from key stakeholders of the Maker protocol. Right now, the current backlog is listed in the Collateral Framework and will be expanded upon based upon the needs and prioritization of the stakeholders. The key benefits are to allow for better prioritization, communication, and collaboration and to reduce the bottlenecks. To scale this process, we’ll be enabling third parties, with the appropriate incentives, to onboard collateral and expand the supply of Dai. Bottom line, we’re thinking 100’s of billions and trillions since that is the only way we’re going to scale our protocol with the limited resources available to us.
I’m happy to talk with you (or anyone else) directly about the concepts I’m proposing or if there are terms that need further clarification.
The longer version…
The main goal of the core unit is to scale the Dai supply and manage the product collateral lifecycle. Inside of that, there are two areas of focus: crypto native and real world assets. The part I believe you are asking about is the crypto native assets.
Currently, collateral management is distributed amongst several core units. Since collateral is such an important part of the protocol, the PE, Oracles, and Risk team spend a lot of time in this area. So it makes sense to consolidate product management into one core unit to free the other teams to work on more innovative work. That’s the initial CES priority…as well as to build the team.
As far as the innovative work is concerned, you’ve mentioned some of it in your reply. There is also the innovative work in real world assets. Since we are an engineering services group, we’ll have the talent on team and the ability to do the work. I’d love to say, we’ll handle all the innovative work but it’s not that easy.
What needs to be worked out is which team feels best equipped to take on the innovative work that comes forward. This will be balanced based upon the workload, domain knowledge, and priority of the collateral type based upon Dai generation or other strategic factors. This is the second priority.
Ideally, we need to scale our collateral management and that can only be done by enabling and leveraging third parties and partners. And the incentive models need to be there too. If CES tries to do everything, we’ll become a silo of centralization inside of a decentralized system. So, this will lead to a lot of experimentation which allows us to learn and refine the patterns to enable a wider audience than just the core units to onboard new collateral types. This is the third priority.
With all this said, I believe the core of your question deals with the collateral roadmap. Most of what you mention is on the table for consideration although I’m not quite sure about onboarding Dai into other Layer 1s. Roadmaps are driven by product backlogs and this is part of what product management provides. The roadmap will be visible to all and build off of the current collateral onboarding and polling processes.
Roadmaps and backlogs are a highly collaborative process and involve the feedback and input from a variety of stakeholders. It’s also an iterative process where priorities change. What we focus on shifts a little on each iteration and that’s by design. It allows the core unit and protocol to respond to the ever changing aspects of our industry. This is a best practice brings forward the learning each and every time we deliver value in our software.
Now, let’s dig a little deeper. Where are the HUGE pockets of assets we can turn into collateral? Is it with Alternative Collaterals or elsewhere? How do we want to invest our precious time in onboarding and managing collateral? And how/who has access to these reservoirs of assets? We work in millions and talk in 100’s of billions and trillions. Let’s use the saying, “act as if”, and own our destiny. Only by setting the Trillions Intention and having a concrete plan to move forward will we realize the protocol’s future.
I’m enjoying the conversation! Please keep it going and make sure you vote!
Many of the concerns raised above are valid, and we can understand why the community leaned “NO.” However, we worry that there may be unintended implications for social norms and expectations around governance (beyond this individual MIP).
Some high-level observations:
Onboarding ex-foundation teams was relatively easy. Onboarding entirely new teams feels like a more complex problem; the first attempts may be messy & imperfect processes.
This is generally true of all new ventures – things feel way messier on the inside than they may appear externally, and that is okay.
Need to balance a high bar for quality with an encouraging environment for new contributors. Trending too far in either direction is suboptimal: should be prudent without “gatekeeping”.
Maker governance should hold contributors to account. They need to demonstrate they are executing on their mandates and adding value to continue receiving funding.
Specific to this proposal:
Compensation may feel high but the market for engineers is hyper-competitive. Maker should bias towards over vs. under compensating (within reason), both to frame working for the DAO as prestigious, and to compensate for the novelty risk (relative to a traditional startup).
It feels unrealistic to expect that new teams will be able to come in “fully baked,” like the ex-foundation teams were — anchoring to that norm would limit Maker’s ability to onboard new contributors.
Some of the points raised about operational details feel like things for which the DAO should figure out general policies (e.g., multi-sig control & audit responsibilities). They are not existential risks, so bikeshedding them at the level of individual proposals stalls progress and discourages future proposals.
Ultimately, a Collateral Engineering Services team seems like a potentially useful function, this CU proposal feels like a credible attempt to try out new models of contributor onboarding (hiring), and we worry that rejection may discourage potential contributors from making proposals in the future.
As a result, we (Paradigm) voted “YES”, but not in such a way as to determine the outcome. We’d be excited to see the CES team incorporate the feedback in this thread into another iteration of their proposal!
If anyone would like to discuss the issue further, you can reach us here on the forums, on Telegram @csnoyes, or over email ([charlie, dan]@paradigm.xyz).
This is a statement I agree with. Still, as a future delegate, I voted “No” to this proposal. I will now explain why.
It had nothing to do with the proposed compensation, nor that the team would need some time to get up to speed. The reason was the operational overlap created where the proposed CES would take over some activities presently in the domain of three CUs - Risk, Oracles and Protocol Engineering.
OK - so what? Out in the real world companies reorganize the whole time. Well, I feel the world of crypto might be slightly different with the decentralized nature of the teams making loyalties to some degree more centered on the local group people are working with daily. This has the implication of making overlaps, usually avoided in any organization, especially problematic.
If you look at the majority of Maker Core Units, the daily operations have, to the meager extent of my knowledge, been remarkably free of friction when taking into account the high stakes and the dynamic environment. The few cases where I have noticed some sparks have been exactly where there has been some overlap in activities.
The proposed Collateral Engineering Services team would not only have some overlap but in seeking to place itself into substantial parts of the domain of three existing and functional Core Units, the overlap and potential friction would be a minimum 3x, likely quite a bit more. Right now I feel that is not such a good idea. Maybe 12-18 months from now it will be different.
That is why I voted “No” to this specific proposal.
Leaving this specific proposal aside, my abstract concern is that things have been (relatively) smooth so far because most teams transitioned into the DAO out of the foundation. Of course, there are a finite number of those teams and we won’t have that luxury going forward. Onboarding wholly new teams, especially into cross-functional roles, is going to be higher friction. This is something that every organization struggles with – from early-stage companies to 1k+ headcount orgs.
Maker is the first project to run the decentralized organizational model experiment at scale and that will kind of mean figuring it out as we go along. At the highest level, my point above is that Maker should remain open-minded and bias towards action over indecision, even in the absence of perfect solutions (or potential friction).
Again, these are general thoughts, not specific to this or any other individual proposal.