Non-Fungible Apps (NFAs): Community Hosting

Non-Fungible Apps (NFAs): Community Hosting


A month ago we dropped an announcement that we were working on a new web3 primitive: Non-Fungible Apps (NFAs). If you missed the announcement, go read it, brush up on the core concept of NFAs (at least the TL;DR), and this blog will make much more sense.

Today, we’re back to announce that we’re working on the MVP for NFAs (to be released in April) that will have a large focus on decentralizing one of the most vulnerable yet most used parts of web3 apps – their frontend. In tandem with the platform, community hosted NFAs will enable founders, DAOs, and developers alike to empower their community to run verifiable frontends for them.

We’ll touch on a few different topics in this blog, jump ahead using the links below:

Prefer to dig into code instead of reading? You’re in luck, NFAs have been open source from day one and we’ve got an MVP working branch in development for you to check out.

Decentralizing Web3 App Access Points

Centralized and Decentralized Access points infographic banner

Community hosting will enable NFA owners to store a verifiable on-chain list of approved frontends for their web3 app. Community members who wish to extend the censorship resistance of their favorite web3 app’s frontend will be able to mint their own mirror of the NFA that we’re calling Access Points.

In their simplest form, NFA Access Points will be independently run domains that point to the frontend content (in the form of IPFS / IPNS content hash) of the NFA that they’re mirroring. When an NFA updates their frontend contents, the new content hash will trickle down to all Access Points, ensuring that all Access Points consistently point to NFAs frontend.

With multiple access points to the same frontend content, an app’s resilience to censorship goes up. For example, if Fleek’s frontend was minted as an NFA and (our official frontend) went down, community hosted versions (let’s imagine they’re something like and would still be able to serve our frontend’s content to users.

To keep Access Points trustworthy, NFAs will implement a social moderation component as well. “Watchers” will be able act as community stewards by independently validating that Access Points are redirecting to the proper NFA/Frontend content, and report when an Access Point is misbehaving.

For user safety, we’re creating an extension to MetaMask snap that ensures that the domain you’re accessing points to the exact frontend content set by the NFA. Wallets who surface NFAs will also be able to surface Access Points to increase the amount of trusted access points for web3 app users. Goodbye sketchy phishing domains 🎣.

MVP Development Progress

It’s official, the NFA project now has a small team inside Fleek dedicated towards pushing the project forward! 🥳

First item on the team’s list: figure out what needs to be done to have an NFA MVP done for April, package those stories & features up in a roadmap, and start executing.

NFA's MVP MVP Development Progress Details

The road to NFAs MVP mainnet consists of three main components that are actively being developed in parallel.

App UI

While anyone will be able to interact with the NFA contract directly, we’re building an official frontend for minting NFAs from source, managing access controls to NFAs, and easily minting new NFA Access Points.


Alongside the first NFAs release, we dropped NFA’s V0 which included a POC from which the NFAs contract could be hardened from.

We’re currently working on extending the V0 contracts to include logic for new things such as community hosting, on-chain SVG storage for NFA preview images, and gas optimizations.

Once solidified, we’ll bundle all of this up into an EIP for maximum visibility & composability within the ecosystem, and then deploy the NFA contract to Polygon’s mainnet.

Fleek / Off-Chain

To add some extra magic 🪄 to NFAs we’re spinning up a few off-chain components:

The subgraph will enable easy composition of NFA data (say, for wallets looking to surface NFAs 👀) and the build & DNS verification are key components to keeping NFAs honest.

Build verification will leverage’s build pipeline to verify that the source code of the NFA matches the decentralized storage hash in the NFA’s metadata & give it a verified tag if true.

So, How Does Fit into the Picture?

We are building the NFA contract with the platform in mind. We see the contract as a way for on-chain management of web3 apps and, with the users permission, integrations with outside services (such as build verification through

The team will also be spinning up an official NFA frontend for minting and managing your NFAs, available at in April.

In the future, NFAs will be fully integrated into the platform. For example, you will have the option to mint their site as an NFA during deployment. New pushes to your tracked github repo would get built & could automatically update your NFA’s metadata (& get propagated down to all access points mirroring your NFA) without you having to do a thing.

That’s a wrap! If you’ve got any questions, want to start playing around with NFAs early, or want to contribute some code (we’re open source, ya know) hop over to our Github or our Discord!

Enjoyed brushing up on NFAs? You’ll love our other recent blogs:

For all other socials, docs, contact info, and more, checkout our Linktree ⚡️