MVP scope (for mainnet launch)
The focus for our mainnet launch is adoption. We want to incentivize the growth of the world's largest decentralized data pool, and will make sure we have that done well before shifting focus to data consumers (buy side). It follows that what we want for a successful launch is:
  • to have secured some partners like eyeo who have integrated us, and are ready to collect and provide data;
  • to start distributing new tokens as an incentive for data provisioning;
  • to kickstart an adoption flywheel by being able to show the above is working (as measured in user and data growth).
    • attract more partners -> attract more users -> attract more partners

Critical components

In order to meet what's outlined above, we will need to deliver:
  • a standard for data schema;
  • a standard, reference implementation, and partnerships for data hosts and user-facing applications;
  • a blockchain with tokens and mechanics for data provisioning incentivization.

Substrate blockchain

We will be using Substrate to build our blockchain layer.

Account support

Our blockchain will support accounts, with associated addresses, much like Ethereum does.

New FCL token

Our blockchain will host the new FCL token, and mint an additional supply of 400M over 50 years (with yearly emission decreasing every decade: 0.42%, 0.21%, 0.10%, 0.05%, 0.03%).
Minting is likely to be tied to block production. FCL balances will be associated with blockchain accounts.

Data schema standard

To ensure interoperability, it's important to have a standard for cataloguing data. We will define a schema for data providers to follow when collecting data: instructions on how to organize and tag it so that it can be properly read by other systems.
KILT's usage of CTYPEs is a (more complicated) example of what we mean with "schema".

Data hosts

Data provided to the protocol must be stored somewhere. This will be done in a decentralized manner: data will not live on chain, nor in a centralized database, but in one of the following:
  • online servers (in the spirit of Solid Pods)
    • these can be provisioned by the user themselves, but it's more likely they'd be provisioned by the user application providers like Fractal and partners
  • edge computing applications living in user devices (like PolyPoly polyPods)
    • the simplest example is just the local database of a browser extension
These data hosts will store:
  • the account of their owner (an address representing an individual user);
  • the account of their incentive beneficiary account (e.g. the owner account, the data host developer, or the user application developer)
  • the owner's identity credential
  • data about the owner (identity, browsing history, ...) according to the schema standard

Interface definition

We will describe the interface (API) of data hosts to be used by user applications looking to collect and provide data.

Reference implementation and SDK

We will build an implementation of a data host which partners could use, either as is or as inspiration. This will conform to the interface definition specified above. We will probably focus on edge storage for launch, since it's likely simpler to deliver and interoperate with.
We will also ship an SDK which makes it easy for partners to incorporate a data host, and communicate with it, inside their user applications.

User applications

These are the user-facing applications, built by partners like Crumbs, that must interact with the protocol. They use the SDK mentioned above to set up and interact with data hosts.

Reference implementation

We will build a browser extension using the data host SDK to set up a data host, help the user get an identity credential, and store their browsing history. This will serve as a reference implementation, a guide for partners to follow when integrating with us.
This reference implementation might end up being an updated version of the Fractal Wallet, adapted to also work with our Substrate chain.

Data provisioning incentivization

These mechanics are subject to change. See Incentivized data provisioning for more details and alternative options.
New tokens minted will be equally distributed equally among all accounts:
  • with identity credentials signed by a set of permissioned accounts (e.g. Fractal's);
  • AND who are marked as owners of a data host containing data.
Ideally, balances just update automatically every time tokens are minted (or every time incentives are distributed), instead of requiring accounts looking to claiming the incentive to initiate a transaction.

Other needs and open issues

These are some items we haven't fully wrapped our heads around yet, but will need to develop a deeper understanding soon.

Blockchain infrastructure

It's still unclear whether we want to connect to Polkadot/Kusama as a parachain/parathread (see What infrastructure do we use for our Substrate chain? and Development and deployment paths for more information). This is not just because auction prices could be prohibitive (and we may not have the bandwidth to conduct a successful crowdloan), but also because the higher transaction fees and lower bandwidth might not make it a good fit. Additionally, we don't yet see a pressing need for interoperability with other Substrate chains at launch.
I described what could be seen as a default option in this launch scenario:
It's the first week of October and we've successfully launched the protocol on mainnet. Parachain auctions were too expensive, so we decided to go with an independent PoA Substrate chain for now.
In simple terms, this means "at launch, Fractal will run its own nodes, and we'll think about decentralizing that later". The biggest downside here is story value:
  • becoming a parachain may convey a deeper commitment to the ecosystem;
  • winning a parachain auction likely conveys social proof;
  • PoA validation might reduce the legitimacy of the protocol, since it's not as decentralized as it could be.

Data dashboard

In order to show progress in adoption, we probably want a public-facing dashboard, drawing from verifiable data, that shows:
  • the number of data hosts over time
    • how many with identity credentials?
    • how many with data provided?
  • the volume of data provided
    • how much by hosts with identity credentials?
  • the number of different partner integrations

Token migration

We launched the FCL token on Ethereum, but are now building on Polkadot and expecting to mine an additional 400M tokens there. So far, we've regarded old and new FCL to be "One Token", so we need the technical infrastructure to make it so.
I described a possible future in this launch scenario:
Permissionless DeFi protocols in Ethereum have kept their pace and FCL can now be used as collateral in several of them. Because of this utility, we've decided against a forced migration of FCL to our Substrate chain, and instead use a 1:1 token bridge in order for tokens to flow freely between the different chains.
We're yet to do a through analysis of what options and trade-offs we have here.

Integration with Fractal ID and Fractal Wallet

Given the importance of identity credentials above, it's likely that Fractal ID needs to adapt to whatever new credential standard the protocol uses, and Fractal Wallet to be able to interoperate.
Last modified 7mo ago