Factom Asset Token (FAT) Protocol Interview

I sat down with Julian Fletcher-Taylor, the CEO of DBGrow Inc, the company that created the Factom Asset Token (FAT) Protocol for a Q and A. They, in conjunction with the Factom Protocol Authority Node Operators Luciap and Canonical Ledgers are building the protocol which is currently in early beta testing.

What is FAT?

The Factom Asset Token (FAT) Protocol is an open source tokenization protocol built on the Factom blockchain that is efficient, modular, composable, and extensible allowing developers to utilize broad functionality to meet their specific use case. FAT is built around a set of open source standards that establish a pure-data tokenization implementation directly within the efficient entry chain structure of the Factom Blockchain.

FAT tokens are exceedingly efficient, with a cost of $0.012 to issue tokens, and a fixed price of $0.001 to transfer tokens. FAT thrives in data intensive applications, such as non-fungible tokens. This efficiency is further amplified by the ability to integrate them into FAT Smart Contracts that will be able to write arbitrarily large amounts of data into the blockchain for a static $0.001 per kb of data, a feat other protocols cannot match.

The members developing on FAT come from a variety of companies: DBGrow Inc., Canonical Ledgers LLC, Luciap Technology Inc., LayerTech LLC, Factomize LLC, and even includes general community members.

What gave you the idea for FAT?

The cool thing about a pure data protocol is that you have near limitless freedom to build systems and infrastructure on top of that data. Everything comes down to data, and the Factom blockchain is the best protocol for blockchain secured data.

Even though, unlike prevailing blockchains, Factom was not built around token transactions, we realized that we can still express arbitrarily complex systems like tokens and smart contracts on the Factom blockchain if we continue with the Factom design pattern of divorcing data processing and validation from the data itself stored on the blockchain. In doing so, the intensive validation rules for tokenization do not have to be scaled within the protocol itself, leading to huge efficiency and scalability gains.

Why is the Factom Protocol an ideal blockchain for FAT to run on top of?

As of this time, every application of tokenization that exists is in its infancy because the most powerful blockchains out there are running at 10 transactions per second (TPS). However, if the thesis behind “tokenizing everything” is valid, then we haven’t even begun to see what tokenization can be.

The thesis of tokenizing everything can be understood as:

Distributed global platforms that allow you to efficiently prove and transfer ownership of tokens that represent ownership, of anything from currencies, to stocks, to gift certificates, to real estate. In tokenizing these assets, the barrier to entry is lowered, ownership of these assets becomes globalized, and the liquidity of assets around the world greatly increases.

If this thesis is correct, we will need a tokenization protocol that is ready to go to a global scale which will require hundreds or thousands of TPS. We believe that FAT and the Factom Protocol has a strong viability for the sort of decentralization, data security, and throughput needed. The Factom Protocol has an optimal balance of decentralization on both the technological and social layer, data integrity, ability to prove data integrity, and scalability. Other blockchains address some of these needs to varying degrees, but Factom is a strong balance between all of these. In the future, if we have a blockchain that fulfills these needs in terms of decentralization and data security, and is running at hundreds of thousands of TPS, which is what we will need if the thesis on tokenization is correct, then that Protocol is going to be Factom.

What is the breadth of application or use cases with FAT?

Tokenization as a concept is something that was invented thousands of years ago, and has been used throughout history. Tokenization at its most basic level is representing something in a form that is hopefully easier to transfer, easier to prove ownership of, and easier to validate.

Take the progression of currencies. We started by trading items of utility, items with a base value. We then moved to represent value more abstractly with things like shells and gold that didn’t necessarily have a base utility. These are in essence tokenized value, each one representing a piece of value, value that could be traded for items of utility, but it does not expire and was much easier to own and transfer. Coins were another move in this direction. When Athens stamped Athena’s face on a silver coin, it enabled someone to quickly validate the weight and purity of the metal held within the coin.

Blockchain allows for the next evolution of Tokenization because it excels at these 3 most important cornerstones of Tokenization: proof of ownership is built into blockchain tokenization through ownership of the address associated with the token, validation is naturally baked into blockchains through data integrity and whatever validation rules the tokenization protocol is using, and transfers are nearly feeless, instant, and can be transferred across the world to any party.

FAT can represent real world assets or fractions thereof, stocks, bonds, commodities, a digital asset, an ID, something abstract like permission to do something, standing in a governance system, a vote that can be transferred multiple times, currencies, programmable currencies, etc. Fundamentally, anything that you can represent as a piece of data that needs to be owned, able to be validated, and able to be transfered, is a prime use case for tokenization and the FAT Protocol.

FAT allows us to represent these things in a form where I can prove to the whole world instantly that I am the owner of this piece of data and thus whatever it represents as a token. All that I need is a string of numbers, and through some crypto magic, I can instantly and cheaply prove that this piece of data is owned by me to the whole world.

FAT also enables you to program remarkable functionality within your tokenized assets. For example in the Netherlands, FAT will be used with a graph-like structure that allows token holders to be paid along certain vertices on the graph. So, a government aid issuer could specify that only food (as opposed to bets) can be purchased using the financial aid tokens they issue.

We are only a few years into determining what all of this really means for the world, and what will be built with these systems. If the tokenize everything thesis is correct, we are entering a paradigm shift in how assets are held and transferred. When a technological paradigm shift occurs, it’s very rarely the original creators of the technology that change the world with its applications — instead, usually it is future generations that do so. So as excited as I am imagining up all of the use cases for the FAT protocol, it’s the applications that I can’t envision that I am most excited for.

What has decentralized development been like, and does decentralized development present any challenges or benefits when compared to development that is centralized and in person?

One of the nicest things about development in person is that at any point in time when you have a question for another team member, you can lean over and bug them. One of biggest benefits of decentralized development though is you don’t have to worry about other people bugging you.

The FAT developers focus on components of the FAT system that are tailored to our skill-sets. This makes things easier, as there isn’t much risk of stepping on each other in terms of the code. One challenge, though, is the FAT developers are not necessarily available at the same time, so coordination can be more difficult at times.

Working in a decentralized environment requires a team with good communication, and good discipline to not step on each other’s work. The developers come from different backgrounds and bring different perspectives to the problems that are encountered. We have managed to coordinate and collaborate smoothly, and it has been a joy to work together as a team.

Will FAT be targeted at public chain usage?

Absolutely. Every organization that we present FAT to, we explain that FAT is about being able to prove ownership. On private chains, you’re only proving ownership to other people on that specific network, and can only transfer ownership to other people on that network. On public chains, you can prove ownership and transfer ownership to the entire world. Blockchain and tokenization are about opening systems and data to the entire world, and that’s the game changer, not the fact that data simply sits in blockchain data-structures.

Will we see any public chain usage in 2019 from FAT?

Yes. 🙂

What excites you most about FAT?

If the thesis behind tokenization is valid, this means that there are going to be tokenization protocols that truly achieve mass and global adoption and will play a BIG role in the decades to come. We think that the winning protocol is going to be scalable, flexible, programmable, and able to express complex behavior and functionality.

The FAT Protocol is a data only protocol that separates validation from data to achieve higher degrees of efficiency. FAT is language independent and allows you to program arbitrarily complex behavior efficiently and with ease. FAT is built on the Factom blockchain, which we believe is the most scalable public protocol that exists, and it’s built on top of a 2-token system that can be used by entities that don’t want to hold volatile cryptos. We believe FAT is in a strong position to fulfill the global needs of tokenization in the coming decades.

Can you comment on what you envision as the first foreseeable, public-facing implementation of FAT that the community can digest?

For Sphereon’s partner’s project, Triall, they will execute an Initial Token Offering on top of the FAT protocol, and this will be the earliest that people will see a public application running on top of FAT. We are very excited to work with Sphereon to bring this application live.

Can you comment about how organizations view working with FAT?

We have talked with multiple organizations that have expressed interest in doing an ICO on top of FAT. The most attractive thing to these organizations is the 2-token system of Factom, the scalability that Factom can provide, the efficiency of the FAT Protocol, and the ability to so easily encode behavior into the FAT tokens. Additionally, the prospect of having their tokens reside in a blockchain ecosystem like Factom, that is so promising for a myriad of technologies, is very attractive because developers will be able to leverage the Factom Protocol’s technology across their systems.

When we are talking to organizations that want to use FAT, as we describe other benefits that the Factom Protocol can provide to them, we find they get excited about using Factom Protocol technology throughout their technology stack. There are so many technologies that the Factom Protocol is so well suited to such as digital identities, authenticating documents, audit trails, signing, and hashing documents to prove they haven’t been tampered with. These organizations don’t just want tokenization – they want everything the Factom Protocol can provide.

Do you have any concerns or comments about network limitations and how those may be addressed?

As we build out these technologies (not just FAT but everything that everyone is building on the Protocol), our goal is to build things that people will want to use. We are making the investment that these systems we are working hard to build will actually be utilized. While we build out these technologies in signing, authentication, digital identities, voting, tokenization, and smart contracts, we need to put just as much focus into ensuring the bedrock all of these technologies are built on is solid and can handle the usage load that we look to achieve. We look forward to seeing the Factom blockchain, itself, grow alongside these technologies we are building.

What are other possible limitations or potential points of failure for FAT? How can these be navigated?

When building a complex system like the FAT Protocol, you experience limitations and difficulties and failure points at every turn, but we have a phenomenal team working through these issues every day.

Any more thoughts?

We are extremely excited and proud to see the FAT Protocol, which we created and began developing some 9 months ago, begin to extend its reach into the world and be embraced by the community like it has been. We have Factom community members now creating their own FAT standards and specifications. We have community members inputting pull requests and taking up bug testing, and this is why we’ve built the FAT Protocol fully open source and why we are developing a proper FATIP (FAT Improvement Proposal) system around the FAT Protocol. We look forward to continually pushing forward the development of the FAT Protocol to where it has true real world usage and becomes a protocol that the entire Factom community is proud to call its own.

How can people learn more or get involved?

Join our FAT Protocol Discord and check out our Github. We hope to see you there!