DeFi Ethics

Posted on:14 August 2025 at 13:45

Table of Contents

Open Table of Contents

Where We Are Now?

Most DeFi developers care about their users’ outcomes. Their focus is primarily on preventing hacks. This is often achieved by prioritising a few key areas:

Ethical developers understand the implications of “code is law” and consider all potential exploit vectors, whether they’re economic or code-based.

However, historically, we* have not prioritised the following:

I personally like DeFi for that;

Overall, the ethical outcomes of DeFi are net positive. Is there room for improvement? Yes.

Room for Improvement

While the transparency of blockchain is a major advantage over TradFi, there are still areas where we could do better. The completeness of on-chain information is a key differentiator and it reduces the need for extensive disclosures. Users can, and should, make their own decisions based on the publicly available code and transaction data.

However, accessibility and privacy are areas where the industry is increasingly failing.

Accessibility

Accessibility is about ensuring anyone can access a system. The primary failure here is the reliance on traditionally hosted and censorable user interfaces.

Historically, DeFi was the domain of technically proficient users who could interact with applications directly on-chain. But as systems have grown more complex and adopted new technologies like embedded wallets (e.g. EIP-7702) and fee-payers (e.g. ERC-4337), DeFi is becoming invisible to the user. While this “abstraction” is key to onboarding a mainstream audience, it introduces significant ethical challenges related to accessibility.

We can categorise the different levels of inaccessibility importance by their predictability and permanence:

  1. PREDICTABLE & TEMPORARY: A temporary UI outage due to planned maintenance.
  2. PREDICTABLE & PERMANENT: A project’s UI is being deliberately wound down.
  3. SUDDEN & TEMPORARY: An unexpected UI outage, leaving users unable to interact with the protocol.
  4. SUDDEN & PERMANENT: A UI is permanently taken down, perhaps due to a legal issue.

The UI is increasingly the gatekeeper for DeFi. This has been, historically, a Solana-specific cultural problem where the publication of IDLs has not been common practice. But with recently increased systems complexity, UI dependence is much, much greater than ever before also on EVMs.

How should teams think about ethics and their role when facing different levels of inaccessibility importance?

Level 1: predictable & temporary lack of accessibility

In a well managed technical organisation, these events should not happen. However, if you are facing one, consider the day-to-day actions that must be secured and how user losses can be mitigated. One overlooked source of potential user losses might be forced liquidations or inaccessibility to unwinding a higly volatile LP position. Teams should always aim to give users ample and prominent notice, even of temporary inaccessibility.

Level 2: predictable & permanent lack of accessibility

Preparing for level 2 inaccesibility is most often not necessary. When the event comes, teams should take a user-first approach in ensuring users can exit the systems gracefully. In practice, I suggest considering:

Level 3: sudden & temporary lack of accessibility

Sudden inaccessibility (levels 3 & 4) are, by definition, unpredictable. Therefore, teams should prepare for these events beforehand. Preferably before taking in the first user funds, but practically, at the latest when their user base starts to grow too large to manage on a one-by-one basis.

Each protocol is unique but the analysis of how to prevent user losses should be the centre of discussion. User losses can come in many forms: complete loss of principal (e.g. derivatives, leveraged position), partial loss of principal (e.g. liquidity provision, trading applications, liquidations, slashing), and unavailability of funds (e.g. liquidity provision, staking, idle assets). Failure to prevent large user-losses stemming from the team’s inability to adequetly prepare for outages is unethical. There is certainly a balance on what is acceptable, but this should be clearly communicated to the users, whether through documentation or terms of service.

If the inavailability of the system can lead to large principal losses, I believe it would be ethically prudent for the team to make alternative interfaces or systems available for the end-user to access their funds in case of outages. This can be realised either by publishing such interfaces before any event or having them readily available in case of such an event. Where embedded wallets are used, teams should ensure these wallets can be accessed even outside of their primary interfaces.

Teams should also consider that interface vulnerabilities may, in fact, be an attack vector for malicious actors. Consider the following scenario:

  1. User B has deposited a large amount of $SWAN into a lending protocol, against which they have taken a large USDG loan
  2. $SWAN price decreases, putting B into imminent risk of liquidation
  3. Attacker A prevents B from accessing the protocol through its UI (perhaps by sending them Tornado Cash ETH, leading to an automated UI ban)
  4. B is unable to pay back their loan or add collateral because they are reliant on the UI
  5. $SWAN price decreases further, making B’s position liquidatable
  6. A liquidates B’s position, receiving a tip from the lending protocol, covering the cost of the attack in step 3

Was it ethical for the protocol to automatically ban the user? Was it ethical for the protocol to not provide sufficient guidance on how to pay back their loan or add collateral through decentralised systems?

Level 4: sudden & permanent lack of accessibility

While these types of inaccesibilities have historically mostly related to rug-pulls or otherwise unethical teams, they still warrant a thought, even from ethical teams.

Does your protocol survive the bus test? If not, how can it improve?

Who are the key persons and key infrastructure providers in your supply chain? Are they replacable?

Are there single points of failure outside of your team’s control?

Could someone disable the protocol completely?

Privacy

One of the most significant ethical challenges in DeFi is the tension between transparency and privacy. Blockchains, by their nature, are public ledgers. While this provides unprecedented transparency, it also means that every transaction is permanently recorded and visible to everyone.

For new users, who may be coming from a TradFi system where their bank account history is semi-private, this can be a shocking and often unknown reality. When a new user interacts with a DeFi protocol, they most likely do not realise that their entire transaction history is publicly accessible and, with enough effort, potentially linkable to their real-world identity.

This raises important ethical questions:

The answer to these questions isn’t simple. On one hand, the ethos of DeFi is “don’t trust, verify,” which implies that users should be responsible for their own security and privacy. On the other hand, the industry is moving towards user-friendly, abstracted experiences that intentionally hide the underlying complexity. In this context, it’s easy for new users to be lulled into a false sense of security, believing their financial data is equally private to what they are used to.

Footnotes

* We, as in blockchain projects collectively, from my perspective