‍

‍

‍

‍

‍

‍

‍

DeFi protocols are increasingly targeted by “frontend hacks”. Unlike traditional attacks that exploit smart contract vulnerabilities, frontend hacks manipulate the protocol’s user interface, leading to malicious transactions and loss of funds for users. These attacks can severely impact both users and the long-term viability of DeFi protocols.

Furthermore, DeFi protocols are navigating a complex regulatory environment. Proposed legislation in the US and EU seeks to categorize them as intermediaries, due to their role in operating public centralized frontends.

Two core issues emerge

Frontend integrity verification: Users need assurance that the frontend they use isn’t compromised. 

Legal liability for protocols: Developers need a secure, compliant, and decentralized method to distribute their frontend.

Despite the decentralized nature of Ethereum, DeFi’s frontends rely on centralized opaque web2 infrastructure. This dependency introduces multiple risks at various levels. Commonly, domain registrars are being socially engineered into handing over control of DNS records to attackers.

Mitigating these issues

An immediate, albeit imperfect, solution is for developers to stop serving public frontends, and instead only publish source code for users to download and run locally. Various projects aim to package this process up into a downloadable executable and browser extension, masking complexities from the user. The limitation of this approach is that it excludes mainstream users and breaks the convenient web2 experience of URL-based access, creating un-linkable URLs such as https://localhost:8080.

Our goal

We aim to achieve trustless frontend access entirely within the browser, while preserving the familiar web2 experience.

What do we mean by trustless?

When you type a URL like google.com into your browser, you hope that the frontend you see is the real google.com frontend, and that it hasn’t been tampered with by a malicious actor. But how could you know for sure?

If Google published their frontend source code, you’d be able to compare the source code they’ve published to the source code you received in your browser, and check that they match. 

In practice, it’s much more nuanced than this, but in short, this enables you to verify that the content you received is what you expected — a.k.a. “Don’t trust, verify”.

When it comes to DeFi protocols, you shouldn’t have to trust any part of the process. Smart contracts are open-source and verifiable, so should the frontend be. However, achieving this entirely in the browser without 3rd party software poses a number of challenges.

Guiding properties of a solution

Any solution we design should aim to achieve the following:

• Verify frontend integrity to protect users
• Remove the need for developers to serve public frontends
• Ensure accessibility for all users, regardless of technical skill or third party software
• Allow developers to seamlessly integrate their open-source frontend code without needing to modify it
• Build on existing browser security mechanisms (SSL, isolated origins, secure context, etc.)
• Reduce the number of trusted touch-points compared to accessing a dapp on public frontend servers
• Make frontends immutable by default — allowing users to upgrade when they want to

Enhancing frontend integrity

Integrity checks using content hashes would allow verification of unaltered code. When a developer publishes source code to Github, they could also publish an integrity hash. If a developer publishes source code to IPFS then it automatically generates the required integrity hash.

DeFi projects could also sign transactions containing hash values to prove authenticity.

Reducing legal risk in frontend distribution

Developers should be able to publish open-source frontend code without hosting a public server. Users could download and run these frontends locally via an automated process, eliminating the need for an intermediary, or any technical knowledge.

Towards decentralized solutions

While initiatives like IPFS and ENS show promise, their lack of native browser support breaks the user experience by requiring additional software (extensions/desktop apps). Additionally, projects aiming to decentralize higher levels of the stack, such as HNS instead of DNS, are not utilized mainstream.

We must make compromises to find a solution that can work with what is available now. Our goal is to achieve trustless frontends, but even a trust-minimized approach would be an improvement over the current landscape.

Others are attempting to solve this problem by decentralizing web hosting itself. We instead propose moving towards a local-first approach, whereby users install frontend source code directly to their device instead of requiring a public frontend host.

By combining current technologies and enhancing browser wallets, we can reduce risks while maintaining mainstream usability. This approach keeps standard browser workflows intact, while allowing for a shift towards more trustless models.

Local app installer model

A transparent, minimal installer payload could facilitate the trustless downloading and running of dapp frontend code. DeFi developers could issue web links that initiate a local installation process, rather than serving a frontend from a public server. This solution would “get out of the way” of developers and users, not aiming to be a “dapp store” or platform, but an invisible, verifiable, layer. This takes away the burden from developers to serve public frontends and enables users to self-host private frontends locally.

Technical details

The local app installer would consist of static HTML/JS/CSS and utilize a service worker to perform integrity checks on installed frontends, ensuring they haven’t been tampered with.

There are two ways users could obtain this installer:

1. Via public infrastructure
2. Via enhanced browser capabilities (e.g. a browser wallet)

If the installer is obtained via public infrastructure, we can minimize the trusted touch point to one single interaction, the first time the installer is accessed, while subsequent visits, and any dapp installation, would be entirely trustless.

If the installer is obtained via enhanced browser capabilities, then it’s obtained trustlessly — removing the single trusted touch point.

Once the installer is on their device, whenever it’s accessed, it will lookup the subdomain it was requested on e.g. “uniswap” in “uniswap.lapp.eth.limo” — and then perform an on-chain RPC call to the ENS registry to retrieve the source code location for the frontend source code e.g. uniswap.eth. It then takes this source code and stores it locally on the user’s device for subsequent access.

By utilizing public infrastructure such as eth.limo, we can issue universal links that have different risk profiles depending on whether the user has enhanced browser capabilities or not. In both cases, we are improving the security and decreasing the risks for users with and without enhanced browsing capabilities.

User experience

Using a dapp through this installer would involve:

1. Clicking a link or typing a URL into a browser
2. First-time visitors would automatically receive and store the installer locally
3. Users are prompted to install the frontend (e.g. Uniswap)
4. On agreement, the frontend is trustlessly downloaded, stored immutably, and rendered in the browser

The service worker ensures that the public gateway issuing the installer (e.g. eth.limo) is never accessed in subsequent requests. Instead all logic occurs client side, like an offline app.

Handling dapp frontend updates

The installer would monitor the project’s ENS source code location to see if new versions are available, and if there are, would prompt the user if they would like to update their local version to the latest..

Preventing scams and phishing

Users would receive prompts and warnings when navigating to installer links, and be guided towards avoiding installation if they already have that dapp installed. Additionally, a known-frontends file could facilitate common dapps with known ENS’s.

Handling installer updates

To keep pace with this evolving space, the installer will periodically check its own source location (e.g. GitHub or IPFS) for updates. While the installer is stored immutably on the user’s device, users will receive a prompt to upgrade when a new version is available, ensuring they always have access to the latest features and security enhancements.

Developer experience

DeFi developers publish their source code to their normal source code storage provider as usual. They only need to register an ENS with a record pointing to their source code location (e.g. a Github URL or IPNS/IPFS hash). This ENS will then be referenced based on the subdomain used when accessing the installer.

Spectrum of trust

Let’s compare how dapps are accessed today vs through a local app installer approach.

Here we can see that using dapps via an installer distributed through an ENS gateway reduces the risks to a one-time interaction vs incurring risks every time you access a dapp via traditional public servers. Furthermore, we hope to remove the risk entirely by updating browser wallets to support ENS gateway integrity verification.

Today, we can achieve the trust minimized approach. With some effort, we hope to achieve the fully trustless approach.

Open challenges and future directions

Verify installer via browser wallets

To enable users with browser wallets (Metamask, Frame, Rabby, etc.) to obtain the installer in a fully trustless way, we need to add support for verifying the integrity of ENS gateway responses (such as eth.limo). The primary challenge here is that the browser extension Manifest V3 API removed access to navigation responses, making it hard to verify the integrity of the response.

Alternative to ENS gateways

We could look to utilize 3DNS to register an apex domain such as lapp.com instead of depending on ENS gateways. We’d gain more transparency into the DNS records/ownership/changes, and reduce domain risks i.e. removing the possibility of the domain registrar getting socially engineered, as ownership is managed entirely on chain. Furthermore, Fleek’s decentralized edge CDN could offer an alternative to relying directly on a single ENS gateway’s infrastructure.

Extendability

This solution will be an open-source public good, owned by a neutral party such as The DeFi Collective. The first version will support Github, IPFS and Ethereum web3: URL schema, as source code locations. Anyone can contribute other source code storage locations.

Common-frontends

The installer could contain a list of common “known frontends”, similar to how DEXs utilize a token-list file for well known tokens. This wouldn’t act as a gatekeeper or blocker, but simply enable legitimate projects to contribute their ENS which references their source code location. This file would exist in the source code for the installer.

Recap

Currently DeFi protocols are limited in how they can securely distribute their frontend to users in a way that doesn’t break the web2 experience. With a browser-based local app approach, they can securely distribute their frontend in a decentralized, compliant, and web2-friendly way.

Over the next months, we’ll be working on a demo Liquity frontend utilizing this approach for testing. Any technical feedback and ideas would be very much appreciated.

Collaboration

If you’re interested in solving these problems, have any suggestions, questions, or feedback, feel free to reach me on X (Twitter): https://twitter.com/edwardmulraney or join the public forums where people are working on this:

• DeFi Collective Discord: #decentralized-frontends
• IPFS Slack: #ipfs-ecosystem‍
• IPFS dapps working group: https://lu.ma/ipfs-dapps