Why Blumen?
Fragility of classic front-ends
Decentralized web hosting is often an overlooked aspect with dApp infrastructure. While the underlying smart contracts are open, permissionless and verifiable, the front-end itself is usually hosted on some central hosting service, such as Vercel or Netlify.
The crypto industry has faced numerous cases of different front-end attacks resulting in loss of millions of dollars, ranging from DNS hijacks to developer machine compromises.
- PancakeSwap DNS hijack in 2021
- Convex Finance DNS hijack in 2022
- Ribbon Finance DNS hijack in 2022
- QuickSwap front-end attack in 2022
- Binance Labs Velvet Capital website compromise in 2024
- Curve Finance DNS hijack in 2025
- Safe front-end deployment compromise in 2025
Another serious issue is censorship. Governments or platforms may want to censor dApp front-ends for their own reasons (such as sanctions or repressions), making it impossible to use the dApp other than manually sending transactions to a smart contract.
IPFS is not magic
It is a common misconception that uploading files on IPFS makes them distributed across many nodes on the network. This is completely false and is not how IPFS works at all.
Replication is not enforced by IPFS in any way. Uploading a file to the network does not reproduce it across many other nodes. While certain storage providers may pin the same content onto their own cluster of nodes, it is still bound to the same provider. What this means is that you have to replicate content on your own.
IPFS doesn't provide any guarantees on content persistence. Storage providers may unpin or delete content at any point of time, for example if you stop paying a service subscription. The content is available on the network as long as one or more node have it and are discoverable anyhow, for example DHT.
One of the key features of Blumen is automatic re-pinning of content for IPFS on many independent IPFS storage providers. The full list is available here.
Swarm, on the other hand, enforces at least 4 replicas of content by default. It can be used as an alternative to IPFS hosting and is also supported by Blumen.
Decentralized vendor lock-in
Certain platforms advertise themselves as "decentralized web hosting". While the app hosted on such platform itself might be somewhat decentralized (for example by pinning to multiple IPFS providers and utilizing ENS), it does not mean that such a platform can't take the website down or just go in vain (for example because of business not going well). The reliability of the application is bound to the platform.
A few platforms additionally opt in for simpler solutions by sacrificing decentralization. One such example is Fleek. It uses IPNS which is not feasible for replication, and doesn't get pinned the same way IPFS hashes are pinned, even though it is possible.
Blumen does not impose such risks because it is not a platform. It is instead a tool that talks to infrastructure providers and protocols directly without middlemen. There is no "Sign Up" button. The underlying infrastucture is chosen by the user.
Blumen never uses mutable references besides ENS, making sure all the content references are immutable and deterministic (IPFS CIDs and Swarm reference IDs). Such approach additionally provides a transparent and permanent history of website changes for an ENS name.
Dangers of automatic updates
The web is unstable. Any website may be updated at any time by pushing a new version without much notice or any required approval steps, by default. This is mostly how websites and web apps are updated.
While this is indeed very convenient, such approach is terrible for security. In case of developer machine compromise, there are almost no barriers for publishing an exploited version of the web app without anyone being able to stop the attacker before the damage is done. This is exactly what happened during the Safe front-end hack.
Such status quo should not apply to dApps, especially financially sensitive ones where security is of upmost importance. That is the primary reason why Blumen integrates with Safe for ENS update management.
With a multi-sig wallet sitting on top of an ENS name it is possible to add an multi-factor authorization layer for website updates. It is also not required to be one of the wallet owners to propose ENS updates, which significantly minimizes potential damage from an owner account getting compromised.