Discussion of collateral onboarding process

I want to discuss the collateral onboarding process, what we can do to get better estimates for when collateral will be greenlit/rejected by all necessary parties, and how we can speed up this process. I originally considered adding this as a post on an existing topic, but thought it warranted a brand new topic instead.

We all seem to be in consensus that collateral onboarding is the best tool we have to improve the peg and that we want as much new collateral as possible. Despite this, the process for bringing new collateral into the protocol is extremely slow. Dare I say the slowest piece of the maker governance process. It would be one thing if this was due to the slowness of development work, but lots of it seems to be more due to bureaucracy and lots of dependencies on individual people who are overloaded on work and have limited time. We have had several instances of domain teams being unable to meet expected deadlines for collateral analyses, presumably due to a shortage of bandwidth.

I do not want to show any ill will toward the domain teams, @LongForWisdom, or anyone else who plays an important role in the collateral onboarding process. But I have some suggestions to improve this process. I think we need to break down these bottlenecks, make it possible for members of the community to do the the work that the domain teams such as the risk and oracle team are doing.

Maybe we can have a meeting between interested community members and domain teams to onboard new people who can write up these risk and oracle analyses. Maybe we can build a specification meta-doc for these write-ups (This actually may already exist on the forum somewhere). By distributing the work of creating these docs, existing domain team members would simply have to read them and approve them rather than write them up themselves. There could also be domain team leads recruited/trained from the community to further distribute this approval process.

I think it would be nice if we could get the entire process from collateral proposal to working on smart contracts for that collateral to be under a month. We do not lack demand, interested and able community members, or collateral types available to grow much more rapidly, we only lack good efficient processes.

I would love to hear more discussion on this if anyone has any thoughts/ideas.


Agree 100%. Great initiative. I look forward to hearing from @cyrus and the Domain team.

To get from forum application to DAI collateral in under a month would need a big overhaul to the current MIPs process plus who knows what in terms of domain team staffing.

The collateral app is supposed to sit on the forum for 1 month before it even moves into community greenlight for 2 weeks. That’s 6 weeks BEFORE any of the domain teams are supposed to take a look in the best case.

If you could just get the community greenlight process down to 4 weeks that would be a huge win IMO.

1 Like

Well, I think we should speed up that process, maybe make an update to MIP 6. Maybe we do 1-2 weeks feedback before the domain team looks at it, or even just try to do domain work in parallel. As far as I see it, unless there’s clearly a rejection of a collateral… which typically doesn’t take more than a week or two, there’s no reason to wait around.

The risk of wasted effort on a collateral type that will be rejected by the community is lower than the risk of taking too long to get a collateral into the protocol. We should treat the community greenlight as if it were a domain team, and thus do all of our domain greenlights at the same time. Community members should be on those domain teams as well, so technical or risk issues start as part of the discussion from the first day the collateral is proposed.

Are there other risks here besides wasted effort on the part of domain teams?

I agree that a month is too long for the applications to sit on the forum. Most of the discussion around tokens occurs for the first few days, and then the application is mostly buried until it resurfaces as a polling vote.

Here are some examples:

USDT: [USDT] - MCD Collateral Onboarding Application (discussion lasted for 5 days)

COMP: [COMP] MIP6 Collateral Onboarding - Compound (discussion lasted for 1 day)

KNC: [KNC] MIP6 MCD Application: Kyber Network KNC (discussion lasted 10 days)

We can do an analysis on all existing collateral apps to see the average amount of days discussion lasts. Or, for starters shall we try to reduce the time it sits on the forum to 2 weeks?

1 Like

The MIP6 + MIP9 process should currently be 2-6 weeks, because we do the greenlight polls at a fixed time each month. The application has to have been on the forum for at least 2 weeks before the poll.

So in theory it does average out to 4 weeks + 2 weeks for the actual greenlight poll to finish. It’s worth noting that this doesn’t constrain the domain teams, though. It’s not a limiting factor. An example of this is LRC, which the domain teams are actively working on, even though the MIP9 poll is still in progress.

One of the things I’d like to highlight is that though the end-to-end process is fairly long, in theory the throughput should be enough that we get at least 1 collateral type per month (with the current set of domain teams.)


I work on the smart contracts domain team, and wrote the initial MIP12 technical assessments for LEND and MANA.

I really like this idea and am interested in helping coordinate better knowledge sharing between the SC domain team and the community.

With a basic understanding of Solidity and the ERC20 token standard, anyone could work through the MIP12 checklist and gather enough information to complete the technical assessment for a new collateral type. And getting interested community members familiarized with the code patterns will certainly generate more robust discussion.

So far we’ve just put the write-ups together as we start onboarding, but as the list of greenlit collateral types increases, so too will the backlog.

If this sounds interesting to anyone, please let me know and I can start putting some resources together and coordinate. We’ve done something similar with the “How to audit executive code?” reply by @cmooney also from the SC domain team.


Happy to see excitement from the community! I work at Paxos and we’re happy to help however we can to help onboard PAX / PAXG. Also don’t mind spending some time on my off hours assisting on some other work that would help other projects as well!