Home » Our Vision (part 3)

Our Vision part 3

This is the third post in a series by our CTO Niels Klomp about our vision for Blockchain in general and the Factom Protocol specifically.

In my previous posts I started our vision for the Factom Protocol and where I believe the protocol should be headed. This is the 2nd part of multiple posts, as I would like to take the time for the less technical inclined people to get the full vision.

Please note that parts of the vision will be mentioned during every single post, but the last story will be about the complete vision.

In the first post I already talked about Identities, Decentralized Identifiers (DIDs), Privacy, Decentralized Key Management Systems and authentication. In my second post about Verifiable Claims and Zero Knowledge Proofs.

Now I will be talking about Tokenization and, again, I will include some identities in the mix. I guess you noticed a pattern by now 😉

Factom tokenization is FAT

Read more

FAT Whitepaper

FAT, short for Factom Asset Tokens are decentralized, tokenized assets; Pure and simple. A collection of open source, data-only, blockchain tokenization standards. FAT currently features several types:

FAT-0, A fungible asset token standard.

  • Most alike an ERC-20 token (TRON, Golem, Ziliqa):
  • Tradable in fractions of a token

FAT-1, A non-fungible asset token standard.

  • Most alike an ERC-721 token (CryptoKitties)
  • Tradable in whole number token increments
  • Every token is unique, and can have unique properties

Factom Asset Tokens

As said, anyone can send, receive, and create their own tokens for a low and even more important fixed cost.

FAT offers the security of Bitcoin, Ethereum and Factom combined, simply because the Factom blockchain anchors a proof every 10 minutes into the Bitcoin and Ethereum blockchains for additional security.

FAT also has the flexibility of Ethereum, all for a fixed price that is roughly 1/100th of the price of Ethereum. FAT tokens are fixed at $0.001 USD per transaction and $0.012 USD per new token issuance.

The latter of course is only needed to bring tokens into existence. Imagine bringing tokens into existence representing millions of dollars for the price of $0.012 and then transacting these tokens for only $0.001 USD per transaction! Fixed! Forever!

Fungible FAT-0 tokens

The FAT-0 specification describes a fungible token. Fungible tokens are tokens that are interchangeable and indistinguishable, like for instance currencies. To hold 20 dollars it doesn’t matter which 20 dollar bill I hold. It even doesn’t have to be one bill at all. Only the number on the bills and coins matter as it denotes the value and that should add up to 20.

FAT-0 is much like Ethereum ERC20 tokens. ERC20 tokens became wildly popular for Initial Coin Offerings because of their simplicity and interoperability (easily supported by exchanges for instance). Among the most successful ERC20 token sales were EOS, TON and Filecoin, raising more than $200 million dollar each. A quick scan on Etherscan.io these days shows there are over 200.000 ERC20 token contracts and thus that many different types of ERC20 tokens. The largest one, BNB created by the Binance Exchange, representing a Market Cap of $4,718,612,571, individual coin price of $30.3376 and 314,298 holders at time of writing.

Non-Fungible FAT-1 tokens

The FAT-1 specification describes a non-fungible asset token standard. A non-fungible token represents something unique that is not interchangeable. A nice little comparison for non-fungible tokens is a baseball card collection. These cards contain unique information and have different levels of rarity. The card itself is the same piece of paper obviously with the same manufacturing cost, but if we blindly swap 2 cards, one person probably is very happy whilst the other one is not. Simply because the cards represent different information and have value in the eyes of the holders. Just like a non-fungible token you also cannot split the baseball card in two or more pieces.

Non-Fungible FAT-1 tokens, just like baseball cards are non divisible. This is in sharp contrast to the Fungible FAT-0 tokens. Whenever you talk about collectables quite often the provenance also comes into play. Which person(s) held your cards in the past for instance. Non-Fungible tokens incorporate the same concept.

FAT-1 tokens are much like Ethereum ERC721 tokens, which probably are best known by the CryptoKitties rage. A quick look at Etherscan.io shows there are currently 2,006 ERC721 Token Contracts. Non-fungible tokens by their nature are harder than fungible token. Non-Fungible tokens are being used on Factom for instance by DBGrow (the creators of FAT) and other parties with an Asset Holding company to tokenize options contracts with an interest to tokenize more of their portfolio as the technology matures.

Doing an ITO on FAT

A first ITO on FAT using FAT-0 tokens has already been announced to take place at a later stage by Triall.

A blockchain ecosystem for clinical trials, that recently announced the World’s first live clinical trial in production on the Factom blockchain.

A first ITO on FAT using FAT-0 tokens has already been announced to take place at a later stage by Triall.

A blockchain ecosystem for clinical trials, that recently announced the World’s first live clinical trial in production on the Factom blockchain.

Identity based transactions and addresses

Every public blockchain uses addresses and transactions to transact coins. Factom is no different. What is different however is that Factom has separated storage of information away from these transactions, by virtue of its data structures and a secondary usage token, the Entry Credit (EC).

The EC pays for the data storage at a fixed price, using a commit and reveal scheme to be censorship resistant.

This article will become even longer if I have to explain that in detail I am afraid, so I will leave it at that. The key takeaway is that Factom doesn’t have the limitation to have to store everything within a transaction context, like most other blockchains.

These public addresses are the public parts somebody can hand out to the other party. The private part is basically your wallet.
A common misconception is that tokens are physically stored in your wallet. No, only the private key(s) are stored in your wallet! The private key is what allows you to control the tokens that reside on their public key counterparts, the public address(es).
You sign the transaction using your private key, which in turn makes it a valid transaction as the transaction always has the context of the sending address (you), to verify your signature against.

If you have read my previous articles you should probably by now have made the connection that the identities (DIDs) I talked about earlier where basically also a combination of an address (DID), public key(s), management and attributes. A DID is a common cross ledger standard for identities using much of the same concepts of native addresses on a blockchain. An address is typically not used to identify somebody or something in the wider world. Most of the time they are only used in peer 2 peer transactions only.

Wouldn’t it be nice if I could transact to a person, organization or smart contract that has been verified using a Know Your Customer (KYC) process in some cases? If an address is associated with a DID that has been verified by for instance a bank or the government, you know you are transacting with that party without a doubt. Or a use case where you need to be sure somebody is at least 18 years old (Verifiable Credentials) to perform the transaction. Not sure? Well hopefully you get it after reading the next example.

Nikki Beach Dubai

Booking a hotel in the future?

How would booking a hotel room look like in a future where you combine DIDs, Verifiable Credentials, tokenization (and smart contracts, IoT)? Smart contracts and IoT will be explained in the next story. That story will also expand the example started here.

A hotel typically doesn’t allow you to book a room if you are not at least 18 years of age. The hotel needs your address, contact info, credit card information, passport/id-card and the names of the other guests.
Typically a photocopy of your passport is being made, which in a lot of EU countries is officially not allowed. You are not allowed to handover your passport unsupervised to non-authorities let alone let them make photocopies, as these are restricted to only a few use cases and booking a hotel room certainly isn’t one of them.
How are you sure it does not fall into the wrong hands?

Wouldn’t it be much nicer if the hotel already knows it is you right from the start, so whilst registering using the hotel or booking site? You use your DID to login to the hotel or booking site and book the hotel room of your choice. You selectively disclose that you are at least 18 years old (instead of your exact birthdate), which has been verified by a trusted 3rd party. You disclose contact information and the DIDs of your fellow guests. Next you pay for it using tokens which are held in reserve for the hotel.
(more on that last part in the next story about smart contracts)

Now you show up at the accommodation. Although being greeted in the lobby is nice, for sake of showcasing the possibilities let’s skip that. You already got confirmation about the rooms you have booked. You can just walk up to the door and either use the hotel app or your fingerprint to open the doors. Same for your fellow guests.

How is that possible? Well you and your guests simply prove that you are in control of the DIDs that have been used to book the hotel rooms in the first place. Remember that DIDs allow for authentication (including biometrics)

Want to use the minibar? Well I am guessing by now you see you could use the similar process as opening the door. Booked access to some additional amenities? Just prove you are in control of the DID(s). Bartender wanting to pour you a drink containing alcohol? Same concept together with verifying the claim that you are at least 18/21 years old.
Does he need to know your room number? Of course not, that is already tied to your DID in their system.
Want to hear your favorite music or netflix movies in the room? Well the room can know it is you in the first place and just ask for permission to authenticate and load your music/video account on the device for 24 hours.

Although just a little example of what would be possible using Factom, it showcases the immense impact technologies like Factom can have in our daily lives. We might not be completely ready for it yet, but the concept of identities, verifiable credentials, tokenization, smart contracts and IoT combined promise some very interesting opportunities for the future.

Example: our eCitizen app

At Sphereon we use FAT for instance for a type of welfare benefits in The Netherlands. Much like your typical food stamps, Dutch local governments often have their own fund for citizens in social or economical need.

Besides a basic welfare income, these group of citizens are entitled to additional Social benefits for activities, services or products, like sports- and hobby-clubs, the library, museums, clothing etc.

Instead of doing that all administratively, which is really cumbersome and intensive, we have designed a graph like token economy, where there are 3 parties. The local government issuing tokens to the recipients (inhabitants).
If desired, the citizens can remain anonymous in the whole process (even to the local government).

The citizens can pay for these services or products by only using those tokens they received and as registered.
The suppliers, (known parties, KYC), like theaters or shops, can charge and accept these tokens.

Cashless, Trusted

Tokens can only flow from the local government to the inhabitant to the shop and back to the government where the tokens can be burned.
based on the transaction history recorded on the public Factom blockchain, the local government sends out an invoice to the shop owner (using self billing, a negative invoice method) and pay the shop owner his money, in Fiat.

This means that a process that took several weeks and sometimes months in the past could be done in real time if they like. In reality to keep the administration department happy the Fiat payout is done in batches.
There is more to this use case than meets the eye, but this story is already becoming too long 😉

Cashless, Trusted

Tokens can only flow from the local government to the inhabitant to the shop and back to the government where the tokens can be burned.
based on the transaction history recorded on the public Factom blockchain, the local government sends out an invoice to the shop owner (using self billing, a negative invoice method) and pay the shop owner his money, in Fiat.

This means that a process that took several weeks and sometimes months in the past could be done in real time if they like. In reality to keep the administration department happy the Fiat payout is done in batches.
There is more to this use case than meets the eye, but this story is already becoming too long 😉

PegNet — Decentralized autonomous stable coin network

On of the very exiting things being build on top of Factom and on top of FAT is a completely new stable coin network that is unlike anything I have seen to date.

Pegnet is a decentralized network of tokens pegged (stabilized) to different currencies and assets that allows for trading and conversion of value without the need for counter-parties. It is a fully auditable, open source stable coin network using the competition of PoW and external oracles to converge on the prices of currencies and assets.

Consensus algorithms

To know how Factom works, where the protocol governance is heading and how tokenization fits in, first some explanation about consensus algorithms.

Proof of Work

Proof of Work is the resource incentive consensus algorithm used by Bitcoin and Ethereum for instance.

Basically it is a competition between parties to solve a really hard computational puzzle in a limited amount of time to complete a transaction. The winner gets a reward in the native currency.

People see a lot of drawbacks, especially the amount of resources (power) that have to be “wasted”. But it is basically the only consensus algorithm that has proven itself in the course of a decade.

Proof of Stake

Proof of Stake is quite different from Proof of Work. With Proof of Stake you set aside a certain amount of coins/wealth for a period of time to show your interest in the network.

The more you “lockup” the more power you have.

Proof of Authority

Proof of Authority is quite similar to Proof of Stake, but different from Proof of Work.

Proof of Authority is a modified version of Proof of Stake. Instead of coins, parties put their identity at stake. This means your identity has to be (and remain) squeaky clean.

Both consensus algorithms don’t “waste” the amount of resources that a Proof of Work consensus algorithm uses.

Proof of Burn

With Proof of Burn you basically are removing tokens from circulation by burning them on purpose, making the tokens more scarce and increasing the price for others. Typically employed by miners.

It is not a perfect fit for us, but quite similar in nature. I’d like to coin our future Proof of Burn more like Proof of Usage.

Consensus in Factom

Factom uses Proof of Authority primarily for its Authority Set, which then is secured by additional Proof of Work blockchains, because every 10 minutes proofs (Merkletree roots) are anchored into the Bitcoin and Ethereum blockchains.

However our governance has had the foresight that only Proof of Authority anchoring into Proof of Work will not be enough. Our governance has been designed as a slow process for a reason. To make sure we get a nicely balanced ecosystem with regards to distributing power. Meaning that we are working towards giving all FCT token-holders a voice using Delegated Proof of Stake up to a certain percentage of the total voting power.

The same holds true for the users of the protocol. The ones putting in the data, by burning Factoid (FCT) tokens into Entry Credits (EC) and spending those when anchoring data. This resembles the Proof of Burn mentioned above. It is not quite similar and I rather call it Proof of Usage.

Combine all of this and you get the Authority Set running the nodes having a certain percentage of voting power, together with token holders having a certain percentage of power as well as users of the protocol having a percentage, all using different algorithms.

One might notice we miss developers in this equation. Well developers typically can be put in one or more of these categories, given we have a grant pool that pays outs grants in the form of FCT every 3 months.

Using tokenization and DIDs in Factom governance?

So 4 algorithms all playing nicely together? Yeah, that is a bit of a technical problem we are working hard on to resolve.

A really nice voting specification and implementation that is fully decentralized and censorship resistant has already been created. It works based on identities (not DIDs at the moment unfortunately).

DIDs will be the future solution for the Authority Node Operators (Proof of Authority). We need identities attached to FCT addresses (Proof of Stake) and Entry Credit Transactions (Proof of Usage) to finish the final pieces of the puzzle.

When that puzzle is complete, we have a balanced system using Proof of Stake, Proof of Authority and Proof of Usage to make decentralized decisions and secure the network.
The latter is again reinforced by the Proof of Work of Bitcoin and Ethereum network.

A pretty neat and balanced combination if you ask me.

Let us know what you think.

Contact us
Logo Sphereon

Sorry

De versie van de browser die je gebruikt is verouderd en wordt niet ondersteund.
Upgrade je browser om de website optimaal te gebruiken.