Intro
Ever since Enzyme was first conceptualised in 2016 (at the time, known as Melon), we’ve worked towards a mission to bring a secure, trustless, censorship-resistant, transparent and automated asset management system for digital assets. With this, came the promise to lower barriers to entry and democratise access to finance. This vision is what generally became known as DeFi today.
The definition of “DeFi” is largely debated today and it’s no secret as to why. Building a system with all these qualities is substantially harder than building one that compromises on any one of them. Despite what has often felt like tradeoffs (eg. more challenging/time consuming), we have always strived to preserve these values and a great example of this is how much thought and care we took to design a decentralised upgrade process.
Today, we want to talk about how our thinking is evolving on “trust”. Crypto Twitter has recently been increasingly of the opinion that DeFi is not trustless. We disagree. We think it can be trustless. However, since having a completely trustless system is more complicated and comes with certain tradeoffs, we want to shed some light on what those tradeoffs are and make sure they’re understood. We’ll also share with you how we’re tackling the different trust assumptions, trade-offs and what we’re doing to provide solutions for all the different shades of trust that exist today.
But before we begin, let’s start off by defining what “trustless” actually means in the context of Asset Management.
Defining “Trustless” in Asset Management
In DeFi, when we talk about “trustlessness” we are usually talking about an efficient P2P market which doesn’t need financial intermediaries to help enforce standard market protocols which exist so that market participants can trust one another when transacting. In DeFi, market participants should only need code to enforce standard market protocols if the protocol is completely trustless.
For example, in the case of a decentralised exchange, a buyer and seller do not need to rely on intermediaries and opaque processes before transacting with one another. Buyers and sellers can transact P2P and enjoy what is known as a trustless relationship. Similarly, protocols like Compound and AAVE take care of guaranteeing a trustless relationship between borrowers and lenders without intermediaries and so on and so forth.
In Asset Management, the trust relationships between Asset Managers and their stakeholders can be more complex. Since asset management is a vast sector, stakeholders can vary according to use-case.
In the case of for example a DeFi fund; we would be looking at the relationship between a Fund Manager and their investors.
In the case of a Protocol DAO treasury which is run by token-holder governance; we’d be looking at the relationship between the person(s) managing the DAO treasury and the token holders of that protocol.
So a decentralised asset management system which promises to be trustless should enable Asset Managers (eg. fund manager or DAO) and their stakeholders (eg. investors or token holders) to have a trustless relationship without the need for intermediaries. We’ve written more extensively about this topic here if you’re interested in delving deeper into the topic.
Relationship types
As the DeFi sphere grows and matures, we’ve realised it’s possible to give our users all the flexibility they want in terms of features, but in some cases this comes with some necessary compromises to the promise of a fully trustless system. We recognise that every user in our ecosystem has its own set of priorities and assumptions to work with and we can help them through the customer journey by highlighting the various tradeoffs to think about and providing advice and tooling which accommodates those individualised assumptions.
Below we illustrate a flow chart which maps out trust between a vault manager (Eg. Delegated DAO treasury manager, or a fund manager) and their stakeholders (eg. community, token holders or investors). The flow chart starts by asking stakeholders if they trust their manager in the various different areas where things could go wrong. The answer to these questions is rarely 100% yes or 100% no so we’ve gone on to list a range of policies which can help improve trust programmatically when it is weak. These are all policies that are either available today or will be available with Sulu release imminently. The less trust you have on the various aspects, the more policies you want to be requiring from a manager before you invest in them.
We’ve also evaluated trust the other way around. What about whether a manager trusts their investors? There are ways that maliciously intended investors could also cause harm to a vault manager and it’s other investors. Fortunately, we have thought this through too and have proposed additional policies that can help remove the need for trust between the parties when necessary.
The important thing to remember with all of this is that policies are programmable and if you have a great policy in mind which we haven’t implemented already you can program it yourself or email us about it. We will prioritise requests that have a real use case behind them.
Trust Recipes
We realise that all of this is rather complicated and can be a little bit confusing to navigate so together with Sulu we’ll be launching a new concept of pre-baked recipes to assist users in making the right decisions based on their trust assumptions. We’ll start with three simple templates that users can choose from;
Conclusions
In conclusion, we do think it’s possible to run a trustless vault where financial participants can trust one another without the need for intermediation. However, this does come with some compromise. It will mean that accessing the full feature-set in DeFi today will be difficult and certain actions will have to be prohibited. However, in our new design you won’t have to worry about making these trade-offs. You can choose your own. We’re going to be enabling the full spectrum of trust to be catered for and we’ll try to make that as easy as possible for users to navigate with pre-configured templates.
