[Usecase Draft] Validating & curating trustlessness in DeFI

[ Problem ]
As a non-blockchain developer DeFi user I am often confronted with the problem of finding products with the smallest risk for my funds. After doing some research I came to the conclusion that actually the biggest majority of so called DeFi projects are not truly DeFi at all and mostly rely on third parties or even single privatekey holders.
One of the big problems in DeFi today is the intransparency of risks involved in using such services. This leads to the mind-set that the risks are generally minimal and those smart-contracts are trustless by design, which is not only wrong but might also be very damaging for the DeFi movement if something “went” wrong. For that reason there should be a distinction between true trustless DeFi and partial DeFi projects via a public available free rating data, that can be easily read by non-technical service users.
The current intransparency is a huge risk that seems to be often underestimated while having huge impacts on the reputation of the community, simply because the word DeFi is these days used by way to many projects, that do not really deserve this label. This should be put more into the focus of this emerging movement.

[ Examples ]
A lending platform allows users to lend crypto currencies for platformTokens which represent a 1:1 value of the provided token. platformTokens can be added to the exchange and removed by a single person owning the smart contract privatekeys. This requires trust in this person.
For that reason the lending platform is not a trustless DeFi service.

A multi-signature wallet holds bitcoin that can be operated openly and from public nodes to mint a 1:1 token representation on the ethereum blockchain. The minted tokens can be burned to get the initially used bitcoin back.
This DeFi service can be considered trustless.

[ Solution ]
A DeFi product registry that is governed by dxDAO which is similar to the Kleros token registry. But focusing on validating trustlessness in DeFi products. A group of jurors could audit the DeFi product and rate it based on the following aspect:

1.) Identifying the smartcontract(s) of the DeFi product.
2.) Understanding its risks and technical implications in context of trust.
3.) Rate the product by trustlessness: bolean (yes or no. Very strict)

Optionally 1: If no, offering those projects solutions to make their products trustless.
Optionally 2: The product could also be rated in integer values rangeing from 0-4. 1 star = risky, 4 stars = nearly trustless. 5 stars = trustless.
Optionally 3: There could be a detailed report on why the jurors rated the product like this.

[ Goal / Conclusion ]
If a system like this would be used today, there will probably not much truly trustless DeFi products at all. But in a perfect decentralized financial world all of its financial services primitives should at least have one single trustless representative. A curation list like this could be very precious for the end user. A validation list for a proof of trustlessness could also drive transparency and in long-term help to decentralizing finance.


Yeah, we can become a governance layer like we might be for DMM. It’s a cool concept to help decentralization.


This is a great idea that needs to be tested. Could you make a mockup/demo to test it out and see if it would work? Maybe something no code like google forms + sheets.


This could be done without any additional development using curate (general purpose version if the Kleros token registry).
The scope of a dapp would be the initial submission and the stars would be badges.
The dxDAO could set up the requirements for each star level and publish the information in some sort of Defi Rating website.

1 Like

Yes that is true, Kleros also was my thought for a possible solution as well. But I was thinking about this a bit more and came to the conclusion that it is quite ironic and probably un-optimal in the long run, that in order to verify trustlessness, you need to trust an organization at all. Its a bit of an oxymoron. This might be better if it would be possible to fully automate the verification process in a way.

So I was thinking to improve on that idea a bit more. Maybe this might work with the introduction of a new trustless standard for DeFI. That new standard should always met conditions in order to allow trustless DeFi contracts.

Possible conditions could be:

  • The DeFi contract does not move your tokens at any time.
  • The DeFi contract gives a proof-able token refund at anytime if something went wrong.

Liquidity pools like balancer could probably met such conditions. But maybe I am missing a point.


I fear it is a bit to early for that, this is currently barely a proposal. And I started this dicussion more to bring this probably more into focus, and how to design possible solutions for the problem. There are also a couple of obstacle that needs to be resolved first, like for example a dependency of trust towards the DAO for the verification. I really wonder if there is a trustless solution of the problem it selves.

Could you explain more on this part?
Trustless means that we don’t need to trust a specific party (no centralized point of failure) not that we don’t trust anything.

Here it would be composed of 2 decentralized ORGs:

  • dxDAO as the “legislative” setting up the requirements for certs
  • Kleros as the “judiciary” solving disputes on whether or not the rules are satisfied
    and 2 other kind of actors:
  • Submitter (projects or people acting on their behalf), claiming some defi apps satisfy some rules
  • Challenger (basically the investigators reporting that some infos are incorrect)

So that’s harder to do more decentralized.

1 Like

Sure. Humans are the specific party in which we should not trust in a perfectly decentralized world. Since humans are more susceptible to error, can be bribed and cheat. Lets assume we hit 100 curators for the verification. This is still more centralized then: “Everyone can verify this code, because it is classified as trustless in a standard”.

This is of course not given or possible for all DeFi. But I think this is exactly the issue. There should be a classification of true trustlessness that only trust in the code is required and the underlying network reality. Which of course can be false, when the network layer it-selves is changed by hard forking. But lets assume this is not the case. Forking ethereum to change the underlying reality is always a possible risk, but can be ignored for this proposal.

But decentralization is not the same as trustlessness.

In a scenario which uses a human driven curative system as a veryfier the risks would be indeed be more decentralized, but the risks are still there. I am not saying that everything should be trustless.

I think there should be a verifyable way to tell the users.

  • This DeFi product is perfect in design.
  • It will never change. Or can be changed.
  • Its code is law.
  • Even if someone, a government, a DAO or a law dictates, or decides to change the code. It is not possible. Therefore the code is trustless.

And It could indeed be a nice job for dxDAO to define a trustless standard like this.


All of those would require human evaluation. I don’t really see how we could have a system not using humans to do that.

The idea is, that only the standard is defined by humans / dxDAO. As there are token standards like ERC-20, ERC-721, ERC-1155 and so on, there could be a standard for trustless DeFi.

But I agree that the name of this [draft] is now misleading while the discussion has evolved. I currently think a classified standard might work better as a solution then letting people validate trust.

Maybe I will create updated proposal in a couple of days.

Edit: Also I still like the idea of letting people validating trust with a star ranking system. And I believe, there will be some awesome projects like this in the future. But I just think there should be a truly standardized solution for the problem.

Standards as ERC20 are technical standard for interoperability this is quite different from Defi risk evaluation. And we still need human input to verify that tokens fullfil those standards.

Yeah, that’s the idea, make a list of rules that projects must fulfill to be awarded those stars.

1 Like