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.

The technology to be used depends on the project's needs; for some, more stringent on-chain interactions and immutable storage using IPFS are required. For other use-cases like crypto ramps, they require KYC, contracts to perform the ramping, indexers to retrieve transaction data, and store transaction history offline.

To separate the development environment from production. We have two separate deployments (production and staging) for the different project components: frontend, backend, and smart contracts.

In this article, we’re focusing on smart contracts. Before mainnet (read production) deployment, we require a development chain. We have two options:

• Testnets

• Simulation engines (Forked chains)

Testnets

For as long as I can remember, we’ve had to use testnets to interact with smart contracts in development. This acts as a staging environment that mirrors the mainnet, where we deploy contracts and interact with them on the app. It allows developers to experiment and build stuff in a zero-risk environment without having to pay gas fees and use tokens that have real-life value.

Testing transactions directly on a mainnet is expensive, unrealistic, and irreversible, so developers need an environment where they can reasonably work without these outsized risks. Interactions on a testnet allow you to investigate any error, patch it, monitor edge cases, audit your contracts, as well as educate developers on how the project works, all without mainnet risks.

Testnet setup For Your Project

Selecting the right testnet is usually tied to the mainnet of the chain where you want to deploy. Technically, if your app is going to live on Base, there’s a good chance you want to deploy on Base Sepolia while developing.

You have to go to Chainlist and search for Base Sepolia. There, you can select one of the available RPC URLs.

For the faucets, certain protocols or dev tools like Alchemy create faucet providers that can be used for different testnets. In this case, we’re using Chainlink’s faucet.

We can select different token faucets to use, and each token faucet has different conditions to access the tokens. For instance, this requires that the connected account has at least 1 LINK token on the Ethereum mainnet. Other faucet providers also have different conditions that can make the experience wonky. Once you can get past sourcing your necessary tokens, go ahead and use them with your app.

Simulation engines

Simulation engines simply fork the mainnet chain to a custom chain. This forked chain can either be stuck at a certain block number or continuously sync with the latest block number on the mainnet. The provided custom chain has all the core dev features that you need, including RPC URLs, faucets, explorers, etc.

Simulation Engine Setup For Your Project

To setup your simulation engine, you’d have choose a reliable provider. The ones we’d touch on in this article include:

1. Tenderly Virtual Testnet

2. Buildbear

We’ll focus on exploring both BuildBear and Tenderly virtual testnets individually. After which, we’ll compare both, look at tradeoffs, and how to choose the best platform for your app.

Buildbear

Buildbear provides a sandbox environment that’s synonymous to a chain that’s forked from mainnet. Similarly, it offers features to ease application development and test different edge cases. Developers would create their sandbox and add the network to their wallet. The features includes:

1. Explorer: They provide an explorer for your forked network where you can view transaction details and on-chain interactions.

2. Plugins: This is a repository of external plugins that can be plugged into buildbear. For example, you can use the Blockscout plugin to enable a better block explorer than the native explorer. One thing to note is that it’s a paid feature under Buildbear.

3. RPC URL: They provide a RPC that you’ll use for interactions in our staging app.

// Using ethers to interact with the forked network

const provider = new ethers.JsonRpcProvider(BUILDBEAR_RPC_URL);

const signer = Wallet.fromPhrase(Mnemonic.fromEntropy(ethers.randomBytes(24)).phrase, provider);

3. Faucets: The faucet feature allows you to get both native tokens and other ERC20 tokens. It’s a dedicated faucet for just your forked network. Tokens include stablecoins, BNB, MATIC, LINK, etc.

5. One Click Deploy: This allows you to deploy pre-built and audited OpenZeppelin contracts. This includes different standard contracts such as auction, ERC20 contracts, NFTs, and reward contracts.

6. Verify Contracts: You can deploy and verify contracts on the forked network. You can verify this using foundry, hardhat, sourcify, and etherscan.

7. Time advancement: This allows you to set the time of your forked network and test your protocol under certain time conditions. The only downside is that you can’t reset the advanced time once you’ve set it.

8. CI/CD: The CI/CD feature allows you to connect your GitHub, add Buildbear to your CI/CD pipeline, and enable the necessary workflow.

Tenderly Virtual Testnet

Tenderly offers an extensive array of features to simplify development of simple and complex app features. These includes:

1. Faucets: They provide a dedicated faucet that has no conditions. The faucet works not only for the native currency, but also for different tokens that are mostly used in transactions. Including stablecoins, WBTC, WETH, etc. Plus, you can deploy your own ERC 20 tokens and just fund them using the token’s contract address.

2. Public/Admin RPCs:

They provide two different RPCs: Public and Admin RPCs.

The public RPC functions act like a standard node provider RPC, supporting all standard RPC methods along with custom Tenderly methods for tracing and simulating transactions.

const provider = new ethers.JsonRpcProvider(TENDERLY_PUBLIC_RPC_URL);

const signer = Wallet.fromPhrase(Mnemonic.fromEntropy(ethers.randomBytes(24)).phrase, provider);

const result = await provider.send(

    "tenderly_suggestGasFee",
    Ï
    [] // No parameters needed for this specific method

);This is the RPC you’ll use to integrate into your dapp’s UI or backend when you’re ready to demo your dapp externally.

• Admin RPC URLs even allows you to perform even more complex edge cases. For example, evm_increaseTime is an admin method that allows you to fast-forward time on the blockchain. After which, we can mine a new block with evm_mine, and trigger a time-based operation (like interacting with a vault unlock contract) that should be in the future.

const provider = new ethers.JsonRpcProvider(TENDERLY_ADMIN_RPC_URL);

const signer = Wallet.fromPhrase(
    Mnemonic.fromEntropy(ethers.randomBytes(24)).phrase,
    provider,
);

// 3. Use evm_increaseTime to fast-forward time
const sevenDaysInSeconds = 7 * 24 * 60 * 60;
console.log(
    `\nFast-forwarding time by ${sevenDaysInSeconds} seconds (7 days)...`,
);

await provider.send("evm_increaseTime", [sevenDaysInSeconds]);

// Note: After increasing time, you must mine a new block for the timestamp change to take effect.
await provider.send("evm_mine", []);

// call required method
In this case, one can update time as many times as necessary.

3. Explorer:

   The explorer allows you to view your blockchain transactions and manipulate the blockchain state. Interestingly, they allow you to have public and private explorers. The private explorer allows you to view the different features:

   • Explorer: Overview of all the transactions executed on your Virtual TestNet, similar to any block explorer

   • Contracts: Explorer for contracts you’re monitoring (watched contracts) and contracts deployed on the Virtual TestNet (virtual contracts)

   • JSON-RPC calls: Explorer for all the RPC methods executed on your Virtual TestNet

   • Wallets: Explorer for the wallets you’re monitoring (watched wallet) on your Virtual TestNet

For the public explorer, we can select the level of visibility for smart contracts deployed on our testnet:

• None: No access is provided to any virtual contracts; only publicly verified contracts on the parent network are visible.

• ABI-only: Only the ABI of your contracts is accessible, but not the source code.

• Full: Allows complete visibility of all virtual contracts deployed on your TestNet through the public explorer.

4. State Sync on Virtual TestNets: This is a feature that allows you to sync with the mainnet, meaning the network state syncs live with what’s live on the mainnet.

Zimulatoor

Zimulatoor is a simulation engine from Bonadocs. It creates a SimulationProvider that allows devs to create simulated signers for any address, which is used to initialise the contracts and make queries. This simulated provider works for any account and doesn't require you to bring in the private key. It’s only available and built into actions in the Bonadocs contract playground:

const { Contract, formatUnits, parseUnits, BigNumber, ZeroAddress } = ethers;

const { address: sablierV2LockupLinearAddress, abi: sablierV2LockupLinearAbi } =
    bonadocs.contracts.SablierV2LockupLinear;

const { SimulationProvider } = zimulatoor;

const chainId = 1;

const provider = new SimulationProvider(chainId);

const wealthyAddress = "0x1eED63EfBA5f81D95bfe37d82C8E736b974F477b";

const wealthySigner = await provider.getImpersonatedSigner(wealthyAddress);

const sablier = new Contract(
    sablierV2LockupLinearAddress,

    sablierV2LockupLinearAbi,

    wealthySigner,
);

It doesn’t require a faucet as long as the wallet you’re using to perform is funded on the mainnet. It also does not have an explorer, and the provider can be obtained without the need for an RPC, just SimulationProvider that you destructure from the in-built zimulatoor variable.

Note: This simulation engine is experimental and isn’t ready for prod use.

Comparison Between Our Different Chain Environments

Conclusion

The right development environment to use for your application is dependent on the level of complexity that your app requires. A simple use case with no stress test can be handled with a regular testnet and Zimulatoor. At the same time, a more complex app with many edge cases and stress tests should use advanced simulation engines like Buildbear and Tenderly virtual testnet.