The first question one might ask is why, after all, do we want a decentralised frontend layer? The two main points (among numerous others) to be addressed here are censorship and the concept of a ‘Single-Point-of-Failure’.
Censorship is an important phenomenon to tackle when wanting to move towards full or what I more adequately call, optimal level, of decentralisation. To explain this I shall provide a very recent example. Uniswap is one of the largest DEXs within our industry. The structure is made up of the Uniswap Foundation, Uniswap Labs, and the Protocol (the tech-stack). Now, Uniswap Labs depicts itself as a mere frontend provider of the Protocol (we know that they are also the main active software developers of the Protocol – but that’s a separate argument altogether); however, they developed both the Frontend and the Protocol itself (they have since decentralised many functions).
Uniswap had 3 frontend-related events in 2022. The first related to the Privacy Policy (and this relates to the User Data component of the above diagram). The updated Privacy Policy stated that the DEX collects certain on-chain and even off-chain data connected to users’ wallets.
Our main concern here relates to the off-chain data, i.e., data collected from the frontend. The centralisation of the Uniswap frontend (hosted by Uniswap Labs) led to a high degree of centralisation. Due to the amassed simultaneous on-chain and off-chain data collected by Uniswap Labs, it could theoretically link an IP Address to a real address, to the on-chain data being a wallet and the transactions of that wallet. Some might say, “But IL, their frontend code is open-source, they’re doing all they can!” -> I’ll get to this in a bit.
With regard to on-chain data, we cannot make any arguments. On-chain data is transparent and immutable in nature – this is the beauty of the blockchain. What we can do is provide and cater for mechanisms that ensure off-chain data (User Data) is not merely funneled through one frontend which, if compromised, could lead to a data-leak like no other – leading to IP Addresses being linked to large wallets and god knows what follows.
The second frontend-related matter Uniswap experienced regarded the main frontend (which funnels almost all of the Protocol’s volume) going down in November of 2022. Again, here we have a clear example of a Single-Point-of-Failure. The frontend went down, the token crashed until it was back on, volume went down, and a lot of people publicly stated that they’d move to use other DEXs. This is the result of having a Single-Point-of-Failure. Were Uniswap to promote and incentivise multiple frontends, the aforementioned negative results would not have been an issue or would have been greatly diminished.
The last, and most important, frontend incident dates back to August of 2022 when Uniswap Labs blocked 253 addresses from accessing its Frontend. The 253 blocked crypto addresses could continue to use Uniswap’s smart contracts yet, they were blocked from accessing the popular Uniswap website, which is a frontend managed and maintained by Uniswap Labs, a New York-based company.
These address blocks were the result of US Sanctions (kudos to them as these were some bad people for the most part – sanctions relating to heinous crimes were linked to most wallets). Here’s the issue: circa 30 out of the 253 blocked addresses (12%) merely had associated ENS names to the address holders on the US Sanctions List and were thus, collateral damage. Some of these addresses were NomadWhiteHats.
The fact that Uniswap Labs has the capacity to censor sanctioned users also means that Uniswap Labs also has the capacity to censor (remove access to the frontend) any user based on an arbitrary choice (case in point re. those caught in the crossfire above). Hence, where a frontend is centralised, we have a situation where one may abuse this centralisation or rather, misuse it. Furthermore, this also gives rise to a situation where Uniswap Labs might be ordered to remove frontend access to Person X for an act performed in the United States – but maybe that act is not a crime within the European Union – thus, that person would be able to use an EU-hosted frontend. This is just a high-level example – other examples could relate to the US party-in-power wanting to infringe on an opposition party’s financial liberties and ordering Uniswap Labs to comply with blocking such a person from accessing the Frontend.
Following that example-giving section of the post, we’ll now move on to a potential solution that could be used to avoid any of the three scenarios experienced by Uniswap – I am a big believer that those who do not learn from history are doomed to repeat it – so let’s not repeat it!
I will now enlist a cool concept that could potentially be developed on Cosmos and also a potential solution that could be leveraged to progressively decentralise the frontend layer. The first is not currently live and not available on Cosmos due to its reliance on ENS Domains - Dappnet.
Dappnet is a permissionless application network built on IPFS and ENS Domains. Dappnet addresses the issue of the current predominant access to dApps via DNS and servers (which are centralised in nature) and leverages ENS and IPFS hosting to create a ‘BitTorrent-like P2P Network’. However, unfortunately, this does not solve the issue with most protocols as it functions through ENS Domains. So let’s move on to our next solution.
The Liquity-Model
Previously, I mentioned the following: “Now, some might say, ‘But IL, their frontend code is open-source, they’re doing all they can!’ -> I’ll get to this in a bit.” – let’s get into this. Open-sourcing the frontend code is not enough to decentralise your frontend. Merely open-sourcing the codebase of the frontend is the equivalent of stating that one needs to use electric cars without adequately incentivising electric car usage.
Liquity did just this. Liquity itself does not run its own frontend at all – it actually instructs users intending to use Liquity’s features to choose from a list of Frontend Operators. Hence, to open loans, make deposits, etc., users thus have to use one of the frontends provided by third parties.
Frontend Operators provide a web interface to the end-user enabling them to interact with the Liquity protocol. For that service, they will be rewarded with a share of the LQTY tokens their users generate.
To incentivise users to act as Frontend Operators, Liquity allows these Operators to set a rate between 0 and 100% that determines the fraction of LQTY that will be paid out as a kickback to the Stability Providers using the frontend. If a frontend sets the kickback rate to 60%, their users would receive 60% of their earned rewards while the frontend receives the remaining 40%.
This is a simple yet effective way of making sure that users are adequately incentivised to run frontends. In the case of Uniswap, the lack of incentivisation regarding the operation of alternative frontends has naturally led to a stagnation in alt-frontends, and thus a centralisation and Single-Point-of-Failure in the Uniswap Labs-operated frontend.
The operation of a Frontend could potentially trigger regulatory implications based on where the frontend is being operated from – the operation of a frontend operator within the EU could be deemed to constitute the unregulated/unlicensed solicitation of users to use a protocol (which would breach current provisions in relation to financial services and crypto asset services). Hence, the research conducted should also take into account an assessment of the regulatory implications that could potentially be incurred by virtue of operating a frontend so as to make sure that frontend operators are aware of the risks and pitfalls associated therein.
