Distributed User Interfaces
Interoperability is a core ethos of web3, both in terms of engineering and usage. On the contract engineering end, contracts are seen as the epitome of interoperability; however, the app layer is equally, if not more critical because that’s how the user interacts with the protocol.
The app layer is a particularly interesting concept because it serves as the entry point for introducing the protocol's functionality to an end user. It bridges the gap between the technical intricacies of smart contracts and the user’s ability to interact seamlessly with decentralised systems. By focusing on intuitive design and accessibility, the app layer ensures that the usefulness of web3 is not limited to developers but extends to actual users.
Contracts are inherently permissionless and can be integrated by any third-party app or client-side, making it easy to circumvent extra transaction fees on major apps and wallets. Third-party apps can help protect users, especially from a security angle. For instance, users can still withdraw funds in cases where the main protocol app gets hacked or attacked.
For example, Safe went through a Bybit exploit earlier in 2025 and recommended alternative interfaces for Safe wallet users to access their funds while the main app was restricted.
https://x.com/safe/status/1893012725602885911
The goal of distributed UIs is to simply ensure that we have multiple frontends that allows users access the functionality of the same protocol. This has to be done in a way that’s censorship-resistance by builders’ that are incentivised to create apps on top of the existing protocol.
In June, the EF released a new treasury policy that prioritises core defipunk characteristics, particularly extending decentralisation to the applications. The idea is to ensure permissionless access to smart contract interactions and functionality without KYC.
https://blog.ethereum.org/2025/06/04/ef-treasury-policy
This article would touch on the Distributed UIs section above and how protocols can realistically work on making this possible.
How can Protocols Enable their own Distributed UIs
For the most part, protocols have been enabling distributed interfaces by funding startups and projects leveraging their protocols through the following methods:
Running accelerator/incubators for startups:
A sustainable way for protocols or networks to support external applications is to set up a proper accelerator system where selected startups build on the protocol.
Usually, this arrangement takes the form of VC investments where the protocol takes equity from the startups in exchange for funding. A good example of this is the Blizzard Fund by Avalanche.
Giving grants to specifically build the UI and deploy on IPFS
Offering one-off grants to small engineering teams to just rebuild the existing protocol application and host it on IPFS. The engineering team simply applies with a proposal covering milestones, cost, and deliverables. Then, the selection team evaluates their proposal, team experience, capability, etc, and chooses the best teams to execute the project.
Giving grants to third-party startups
Grants to third-party startups are the combination of (1) and (2) above. The protocol creates a grant program that targets existing startups that are leveraging their contracts and offers them one-off grants without equity requirements. Both parties agree on the deliverables, and the funds are paid based on milestones. This acts as one-off support to the startups.
Building and maintaining it yourself as part of your CI/CD pipeline
This is the least reliable method. The internal engineering team of the protocol simply includes IPFS deployment for their apps. So, once the actual app deployment is done, there’s a backup IPFS deployment that’s added to the pipeline by default. The downside to this is that if there’s an exploitable bug on the main protocol app, it’ll also reflect on the IPFS version. Although it’ll still protect you in terms of centralised hosting services taking down your app for whatever reason.
Centralised vs Decentralised Hosting
Application deployment in web3 today is usually done on centralised services like Digital Ocean, Vercel, AWS, Netlify, etc. Protocols rely on them even though they aren’t censorship-resistant because there’s the ease of use, established ecosystems, support, and less setup required to make it work.
As we continue to grow the web3 ecosystem, we need to grow reliable tooling and advocacy for decentralized hosting of applications. IPFS offers a way to set up hosting as shown below, but it’s still wonky and requires multiple moving parts to make it work. We still need an out-of-the-box tooling like Vercel to enable the adoption of decentralised hosting. We believe this will need to be funded by the ecosystem due to the complexity required to set up such a service for a niche market.
Tutorial on IPFS hosting: https://youtu.be/ZRrPBqqFKFU
IPFS hosting docs: https://docs.ipfs.tech/how-to/websites-on-ipfs/custom-domains/#cid-signaling-with-dnslink
Transparent Contract Interaction
Bare bones contract interaction not only creates a form distributed UI but enables transparency in a way that the user can not only interact with the contract but can see the live frontend code and contract ABI that they’re interacting with. There’s the point of interacting with contracts on a trusted platform like Etherscan, but that’s not practical for real-life actions done by users. A better option would be to use a smart playground like Bonadocs.
It allows developers to import their contracts and set up interactions for each contract method and user actions using ethers and viem. This means users can read and see the ABI, view/edit the frontend code, before interacting with it.
Sample playground: https://playground.bonadocs.com/contracts?public=49-101
Try it out here: http://docs.bonadocs.com/
Conclusion
Distributed UIs are still a niche phenomenon even for the established protocols in the space. To make it the default process, protocols need to ensure that we have the right tooling that abstracts complexities and mirrors the ease and reliability of centralised hosting services.
