A Framework for Real-World Assets


We have lately seen a lot of heat in the forum regarding how Real-World Assets should move forward. While some become uncomfortable with the idea of a DAO having an internal conflict, I see this as an opportunity to surface and fix all the issues pending to ensure that we move sustainably.

Back to the drawing board, then, where we can all zoom out and focus on building!


  • I think RWF is an avenue (if not the avenue) that will bring Maker to the next level. Let’s scale it (in a sustainable way).
  • I am not a Real-World Finance expert. I don’t even play one on TV.
  • My initial attempt at a Framework provides more questions than answers. Ideally, the real experts will join me (or take over).

:brick: Building Blocks


I don’t want to become an expert in real estate. Or farming. Or solar projects. Or invoice factoring. I assume most MKR holders share this feeling. We need the relevant Core Units, the Community, partners, and external experts to take care of the details.

Governance Overload Avoidance

MKR holders want RWF to move forward. That said, it might be unfair to assume that they have thoroughly read the implementation details and want things to proceed precisely as outlined. It is possibly a full-time job to keep up with what is happening in the Real-World Finance area within Maker, and I tend to believe that voters have perhaps other duties.

Code is Law?

Is it if the code is buggy? Or if it can be improved? I would not want our Protocol Engineering team to avoid making improvements on some module “because the MKR holders voted for that specific implementation”. I want to think that any MKR holder will vote for a “better” implementation.

Risk Appetite and Critical Failure

There are different degrees of risk that, ideally, we can price accordingly. That said, anything that could lead to a critical failure should be sandboxed, tested, and improved until it is not critical anymore.

:chart_with_upwards_trend: Another Framework

Code is Law

We need a framework to evaluate, audit, and prioritize all the deals coherently. That should lead to more transparency, less second-thinking intentions, and more trust across the ecosystem.


The framework does not need to be perfect. It needs to be a model for all to agree on how to evaluate a deal. Ideally, anyone can propose ideas to improve it.

Removing Bottlenecks

Much like the risk team has established assessments to evaluate collateral types (and the Community does many), we need to replicate this model to remove bottlenecks and standardize the process as much as possible.

Moving through the Onboarding Funnel

Ideally, we have some checkmarks and checkpoints that each deal or collateral type needs to prove to unlock more debt ceiling, reduce stability fees, etc. We have many parameters to limit and charge for risk. We need our brightest to start working on this.

:skateboard: An Initial RWA Framework: an MVP

We need to define a way of abstracting all the deals and making sure that they are comparable.

Some starting points:


What are they? Are there different groups for them? What are acceptable ranges? Which ones could be changed unilaterally, which ones could not, and which ones might be?


  • How are the parameters defined?
  • How can they be changed?
  • Is an email an acceptable method for communicating anything?
  • Should Maker approve all changes by default?
  • Should there be a different process for changing a parameter from a group to another group?
  • Can or should an Asset Originator be able to change something? If yes, what? If no, how should Maker react?


  • Which documents should be public? In which form
  • Should there be any proxies? Should we have several actors representing different parties to avoid conflicts of interest?
  • Is a proxy (trusted actor by Maker) reviewing the contracts enough? Should they be public? Will the Assets Originators accept that? All of them?


  • What are the incentives for all the actors in the value chain? Is there any type of subsidy that might be skewing the numbers? Would any actor have a reason to apply favouritism? How can this be avoided?


  • Which documents need auditing? At which point?
  • Which firms could provide an audit? How do we measure their reputation?
  • Is there any way to evaluate their independence (agency problem) by anyone interested in doing so?

Bugs and Post-Mortems

  • How are bugs defined? Who defines them?
  • What should we do when a bug is found? What is the procedure?
  • What happens with different types of bugs (based on criticality)?
  • Who is in charge of the Post Mortem?


  • Can this framework be compatible with the one for digital assets?
  • Is it possible to improve that framework based on this one?

@juan this is a good starting point.

Let me add that in order to have any chance of scaling this we need to avoid becoming the crypto equivalent of a fiat bank. On this recent NewSilver deal there were terms like the max percentage that should be invested in a single (US) state and other terms regarding loan-to-value ratios.

Dear people in this community - this.will.not.scale.

There is just no way we can learn the ins and outs of every industry and offer a tailored package like that of a specialized fiat investment firm. Do note that this is in no way criticism of the people doing the deal (cough - I am myself on the rwa commitee) but just something we learn going forward in this ongoing experiment.

Do we really need to know more than these two things?

  1. Is the applying company real?
  2. What would they pay in interest rate if they had to source from fiat?

The first is standard due diligence work. The second is with some deviation to be found using google. That’s it.
What percentage they subsequently invest in what state, their loan-to-value ratios, or if they just blow it on coke and strippers I could not care less about as long as they pay back what they owe us.


“Code is law” has always seemed to me to be said by people who don’t often deal with law. In practice, very rarely does the written contract end up being the arbitrator of actions. It’s really just a baseline that the parties use to negotiate for modification or waiver of future actions going forward. It’s an inherently messy process and pretending you can automate your way out of legal processes is naive if not outright dangerous to an understanding of the real world.

What we call “ethereum” was the result of just this process when the DAO hack was rolled back, while the “code is law” camp stuck with ethereum classic.

We don’t want to have to auction/take possession of the assets. There are both legal and financial costs and hassles of doing so that no one wants to deal with. Thus, we do care about their ability to pay, which means looking at things like historical and future expected cash flows, business plan, reputation in the industry, etc.


We look at historical cash flow that they provide us with.
We look at future expected cash flow that they provide us with.
We look at business plans they provide…need I go on?

If people could make accurate estimates of future cash flows the world would look very different.
If the hassles of providing rwa finance are indeed so great we should rethink how to do it, not dig further into business plans we do not ever have the chance of fundamentally understanding.

Thanks for engaging, @Planet_X. Helpful as always.

While I do believe that a degree of simplification is needed,…

(Can this be a sticker? Or an NFT?)

…I also believe that we might need a more nuanced approach where we set different debt ceilings for different deals, based on the information that they provide, etc.

Happy to hear comments from the experts (please let me know if you’re one and I’ll reach out and pick your brains).


Perhaps the best approach here is to hire a team of experience Loan Officers, head of international credit, Securitized Products, etc.?

Honestly, reading thru the Forum–if I was a RWA company looking to onboard via Maker, I probably would pivot to another lender. Just being honest. Besides, many successful startups have gone from one product idea, and pivot-it to another.

But obviously most community members don’t want potential clients to pivot–so, yea–maybe a new framework with experience characters would work best.

Or, maybe RWA protocols should just borrow from Maker Vaults and do as they please with the borrowed DAI. Why have a community tell you how, when, where, why, how to spend DAI? Kind of what NEXO is doing right now.


I truly believe such framework is so much needed. I’ve deep-dived into many RWA discussions here on the forum lately and a lot of things seems to be so very well prepared when it comes to on-chain, yet what happens in “the real world” is another ball game (I can especially attest to the real estate equity and debt parts).

My major concerns, for the time being, are:

  • no clear map of the risk / reward spectrum (e.g. development projects are so much rewarding, yet so very risky; farmlands, timber, solar are rather alternatives within alternatives and so the question is how liquid are they…, etc.)
  • no clear way to swiftly and objectively assess “is this a good deal?” (e.g. no large datasets with price points, no easy way to check the investment against market sentiment - now Resi in the US seems to be too hot to handle and so what will happen to those dev projects that are to come to market in 6-12 months, would the market still be growing?)
  • how to check the project’s status in an objective manner to see how it performs (both, the dev projects and the standing assets)?

I’m trying to wrap my head around those points currently, whether I have some answers I’ll post them here. Maybe that would be useful.


Are you implying that the Core Units are going to be experts in real estate? What countries will they cover? All of them? Same with farming. Or invoices.
Can you make an estimate of how many RWA-related CUs you are thinking about onboarding next 3 years?

I am aware of the slightly provocative tone of my reply but I am trying to stoke the discussion.


We probably can do both, centrifuge is issuing tokens. Can’t we on top of the drop deal takes a deposit on their token. Let’s say 130% of the max DC. The deposit can cover more than one DROP. And we won’t care about the contract itself.

If they have to liquidate their asset we let them managing the liquidation for a certain period of time. If we don’t get the full amount, we liquidate the centrifuge token and leave them the DROP.

@SebVentures is that possible?

1 Like

I was thinking about the opposite, actually.

If we have an open framework, we would essentially have a recipe that:

  • can be improved by anyone
  • doesn’t discriminate
  • provide any Asset Originator with a clear path to onboard in Maker

We might need the experts you mentioned to:

  • evaluate individual deals
  • audit documents
  • provide feedback to improve the framework
  • accommodate a specificity in a given industry

I don’t think I tell you enough how much I appreciate you being around keeping everyone in check. Thanks for all your work.


As long as we have a clear framework that the MKR-holders understand, we can do whatever makes most sense (even have competing ways of doing things).

I think this is the pain-point. If we solve this we are on the way to scaling.

1 Like

At scale, the idea is to have Asset Managers allocating properly, for instance in real estate.

FortunaFi is one example. FortunaFi is doing the curation of Asset Originators (Corl and Pipe currently). Each deal proposed by Corl is also checked by FortunaFi.

Yale endowment is managing $30B with 30 people. As you can see they are everywhere.


Yale is a great example, yet their size is quite a special thing which I’d associate mainly to late David Swensen and the discipline he imposed. I recommend this episode for some great insight on him and the organization - https://podcasts.apple.com/au/podcast/charley-ellis-the-magic-of-david-swensen/id1223764016?i=1000523625184

In general, Capital Allocators podcast is a superb first-hand resource of high-quality knowledge on the institutional investment space.


My only push back on the endowment comparison is that the core unit should be proposing frameworks and risk analysis to the MKR holders for approval, and then facilitating as outside parties engage with the DAO within those frameworks. I would not want to see any core unit or committee making allocation decisions or having discretion and/or subjectivity (to the maximum extent it can be eliminated) in the onboarding process. I think we need to strive to remove as much of the human element from our processes as is possible - not just in RWF but across the board.


I agree. Frameworks have the advantage of behaving like software. They establish base rules for everyone to see and follow, they can be audited, and improved by anyone that cares.

Any “discretionary” method might be valid, but it requires extra trust and surveillance from the stakeholders.


Good listen–thanks for posting.

So, are you recommending that the Maker Community create a “Yale like Committee”, that meets quarterly, and reviews asset allocation, Real-World Assets performance, and strategies proposed by the RWF Core Units/DAO? Trying to understand the correlation to David Swensen style of management…

1 Like

My Yale reference was to @SebVentures earlier point on their slim structure (roughly 30 people on 30B USD) while e.g. HMC (Harvard’s investment arm) has close to 200 people on some 40B. Swensen as Yale’s CIO was a unique person, sort of super-human who did an extraordinary job which is usually done by many more, therefore his role was central and key to the Yale’s Inv Office success over many years.

Although I believe there’s tons of wisdom in the way Yale run their endowment (e.g. their focus on Risk), I don’t think that it’s easily applicable to a more decentralized organization like MakerDAO.

Honestly, I’d need to deep dive even more into the strategy, roadmap and objectives of MKR to be able to recommend sort of role model, nonetheless - it’s a great idea by Seb to be even looking this direction for guidance as they are a well-run entity with plenty of success over the course of decades.


CFG token is non-traded (the one that provides a price on CoinGecko is an IOU, not the token) and is not on Ethereum. And we are not dealing with Centrifuge.

1 Like

Yeah I agree, the Yale model was quite centralized. But at the same time should we looking for generating alpha? Currently we are investing on what many would call advanced assets mainly because we need people bold enough to finance thru DeFi, and are unable to understand the maturity/duration risk.

Generating alpha in TradFi should probably not be a core competency of MakerDAO.

1 Like