Grant Update Factom Asset Token Protocol Grant Update Thread

Was Factom Asset Token Protocol Grant Round 2, 2019 Successful?

  • 0

    Votes: 0 0.0%
  • 1

    Votes: 0 0.0%
  • 2

    Votes: 0 0.0%
  • 3

    Votes: 0 0.0%
  • 4

    Votes: 0 0.0%
  • 9

    Votes: 0 0.0%
  • 10

    Votes: 0 0.0%
  • Abstain

    Votes: 0 0.0%

Have not voted

Authority Nodes Blockchain Innovation Foundation Blockchain Innovation Foundation BlockVenture Cube3 Cube3 Factom Inc Factom Inc Factomatic Factomatic Federate This Federate This HashQuark Luciap Luciap

  • Total voters
  • Poll closed .
1 Month Update

Hi everyone,

We are 1 month into the current grant round, and we want to give an update on the Factom Asset Token Grant. This update represents the work of DBGrow, Luciap, Layertech, and Canonical Ledgers.

Global progress:
  • Worked through design discussions for the FAT Wallet
  • Rebuilt the foundation of the FAT Wallet with Vue.js inspired by the early proof of concept developed by DBGrow. All the development is now on the development branch of the wallet repo
  • Decided to rely on factom-walletd to store EC, FCT and identity keys (similar to what the Enterprise Wallet do) Gives us the possibility to leverage all the good things already done there, including the upcoming wallet encryption.
  • Did the integration of factom-walletd. It will require a code change to allow CORS (currently using a tweaked version)
  • Worked on the "Settings" page and the "Token" page (FAT-0 only for now) of the wallet
  • All code required for interacting with the factomd API for parsing the factom blockchain is completed and fully tested.
  • The fat0 entry types and validation rules for issuance, transactions and signing of those implemented and fully tested. We have iterated a fair amount on the validation signing rules to avoid all possible replay attacks. In the past week or so a new potential edge case was discovered and we've since mitigated that in various ways.
  • Planning out the database, specifically discussing what it is that fatd should be able to guarantee about a database when it starts up and connects to it. Another way to ask that is how much does a user need to trust their fatd database? If the user has to trust the database entirely, with no way to determine validity without simply regenerating it themselves, then bootstrapping a database is a risky proposition. On the other hand, in order to have a database that can be validated in some cheaper fashion than simply rebuilding it from scratch, then fatd will have a greater level of security engineered in, but there is more data that needs to be stored to achieve that. This decision is one that probably all security critical applications that depend on Factom for immutable state will have to deal with, in any case, we have settled on a middle ground for now that will allow for slightly cheaper validation of the db, while still only storing valid fat entries. This can be later easily expanded to a more complete set of factom block data that can be more independently verified by recomputing the keyMR for that latest factom block.
  • Example fatd updates:

What’s In Store for Month 2 of the FAT Grant?

  • Finalize FAT-0
  • Push FAT-1 toward finalization
  • Explore potential new standards
  • Alpha release of fatd
    • Implement FAT-0
    • Implement FAT-1
  • Add identity management UI
  • Add issuance UI
  • Integrate with functional fatd (start using fat-js)
  • Fix any outstanding compatibility issues with fatd (signing, data structures, validation)
  • Implement all available fatd RPC calls and complete integration tests
Update FAT Whitepaper
The teams behind the FAT protocol grant will be adding a set of new deliverables to be completed this grant round. These include a GO RPC, a CLI, a more advanced wallet with identity creation and management as well as some simple token issuance mechanics.

We will also be looking into implementing new standards, further refining current standards, and more to be identified later. We are excited to have the opportunity to further build out the FAT protocol, and the greater Factom ecosystem!
2 Month Grant Update

Hi everyone,

We are now 2 months into the current grant round, and we want to give an update on the Factom Asset Token Grant. This update represents the work of DBGrow, Luciap, Layertech, and Canonical Ledgers.

We are fully on track to have a functioning Alpha/Beta of the full technology stack for the Factom Asset Token Protocol, from the protocol, to the creation and issuance of tokens, to the end user's token management, all by next month.

Global FAT Progress
  • Sphereon has publicly stated that they will be bringing more information forward on 2 seperate projects they and their partners will be bringing online on top of the FAT protocol
  • # users on FAT discord this month: 60 to 78
  • Spread awareness of FAT technology to a variety of enterprise parties
  • Preparation of the first FAT Standard by a community member outside of the ANO’s on this grant: !
  • Interface between wallet’s FAT0 token management with the fat-deamon, allowing FAT token balance display, and both single recipient transactions as well as Multiple Input Multiple Output (MIMO) transactions.
  • Dynamic add/remove of FAT tokens to the UI
  • Integration of FCT to the wallet
  • Fatjs completed
  • Integrated all fatd RPC calls complete with integration tests
  • Created a non-fungible token standard with orders of magnitude higher efficiency than even our previous proposed FAT1 token. We are extremely excited by what can be done with this token.
  • Discussion can be followed here on our non-fungible standard:
  • Various other improvements increasing the security and efficiency of FAT tokens

Deliverables added to this grant post grant round

  • Go RPC built and functioning with fatd
  • Go CLI built and able to issue tokens with it
  • On-chain identity management UI (Displays digital identities and their associated keys, options to import identities or create new on-chain identities)
A view of the Wallets identity creation and management:

  • Initial FAT0 token issuance UI
  • Coinbase emission transaction UI (bringing new tokens into existence) for FAT0

Next month

  • Finalize beta versions of FAT standards 0, 1, 13, 100, 101, 102, 200, 300.
  • Bring all documentation in line with current standard implementations
  • Release updated FAT whitepaper
  • Add FAT1 support to FATd
  • Have a completed Alpha Fat-deamon
  • Beta Go-rpc
  • Beta Go-cli
  • Add FCT -> EC conversion UI
  • Interface the wallet’s FAT0 token issuance and coinbase tx with the fat-deamon
  • Add FAT1 support
  • Finish wallet documentation
  • Have a completed Alpha FAT Wallet
  • Write new test suite for faster updates
Hi everyone,

I am really glad to report the achievement of an important milestone: the first stable beta version of the FAT Wallet is available.

FAT Wallet is a multi-platform (Windows, Mac, Linux) desktop wallet that supports in one place FAT tokens, Factoids & ECs and Factom digital identities. That first public version is tested and stable, but is only a beta because of the feature set: more is to come before the official release! It is strongly not recommended for the general public to start using that version as your main wallet, please wait for the official release that will come in a few months. But if you have any questions I will be happy to answer.

It has been a continuous effort for the last 4 months and that version completes the FAT grant 1 in regards to the FAT Wallet development (which was "only" about developing a barebone wallet) and it already goes well into the FAT grant 2 development.

I am really excited and looking forward of getting the first production ready version in your hands, stay tuned!

PS: I am attaching few screenshots of the wallet as teasing :)


Last edited:
Hello Factom Community,

With the completion of this grant we will now post a final update. We apologize for the delay in closing out the updates for this grant after the completion of deliverables.

Since our last update a majority of the core FAT standards detailed in this grant have been revised, polished, finalized, and implemented in the FAT daemon by the FAT Editors. A few standards have been deprecated as they were either replaced with better functionality in-daemon, or deemed to have low community interest or limited use cases.

Finalized Standards
  • FATIP-0 - Our core fungible token standard has been finalized and implemented. FAT-0 allows issuance and transaction of ERC-20 equivalent tokens for just $0.11 USD and $0.001 USD respectively.
  • FATIP-1 - Our recently revamped non-fungible token standard is finalized and implemented. FAT-1 enables issuance and transaction of ERC-721 equivalent non-fungible tokens. FAT-1 is highly efficient, allowing users to issue and transact ranges of token IDs for unparalleled efficiency in comparison to ERC-721 tokens.
  • FATIP-100 - This standard defines how to derive a FAT Token Chain ID from its Token ID and Issuer Identity Chain ID. This standard has been finalized and implemented.
  • FATIP-300 - This standard defines the standard JSON RPC API structure for the FAT daemon. While it has not been deprecated, it has been moved the the FAT daemon repository under as we decided that it was not appropriate to enforce API level details at the standards level. This document is living and continues to be updated as API changes occur.

Deprecated Standards
  • FATIP-102 - This standard defines a way to create an index/listing chain pointing to collections of FAT tokens. Initially this was intended to improve the discoverability of FAT tokens, however this has since been deprecated and replaced with in-daemon chain scanning to detect new and existing FAT chains.
  • FATIP-13 - A theoretical fungible FAT-0 based token issued through PoW based mining instead of authoritative issuance. This was deprecated due to low interest and few apparent use cases. Pegnet achieves similar functionality with a very clear use case and is integrateable.
  • FATIP-200 - This standard defined a way to impose time dependency on tokens. For example only allowing a non-fungible token to only be transacted between points in time x and y after which it is non transferable. This had little interest from the community and fewer use cases and has been deprecated. Currently this is best achieved with smart contracts which are being developed as part of a grant at the time of this message (DBGrow & Canonical Ledgers - Contract Dev Grant)
  • FATIP-101 - This standard used to define the role of digital identities in the FAT ecosystem. It has since been deprecated in favor of a more generic specification created in our second development grant: FATIP-103 which defines the universal hashing salting and signing protocol used in FAT transactions and issuances.
All standards under the finalized section above are implemented in alpha stage at the completion of the grant, are open source, and available for use by the Factom community and the broader crypto world.

FAT Daemon

We have made available to end users a command line interface binary that allows users to issue and transact both FAT-0 and FAT-1 tokens, query balances, get basic statistics, and more.

With the successful implementation of the above standards in the alpha FAT daemon comes additional documentation for the RPC API and the CLI. These documents are part of the FAT daemon repository and are living documents that will be kept up as the API and CLI changes over time. They can be found under and respectively in the FAT daemon repository.

FAT Wallet

Base functionality including FAT-1 & FAT-0 token issuance and transactions have been added and enabled in the wallet. In addition, functionality to hold, transact, and convert Factoids & EC have been successfully added to the wallet! A simple binary is available for end users that will allow you to nicely send and receive the aforementioned Factom and FAT tokens.

Since the beginning of the grant the wallet UI has been revamped greatly improved thanks to the efforts of Paul Bernier. Thanks for your hard work!


A new test suite has been built that features far greater concurrency than was previously achieved. With the Finalization of the above standards the base datastructures for both transactions and issuances for both FAT-0 and FAT-1 tokens has been completed. Integration tests have been improved and include tests against FATD for compatibility. FAT-JS now also includes a full set of unit tests for all FAT datastructures conforming to the newly finalized specifications.

Overall we are extremely pleased with the progress the Factom Asset Token protocol has made over the 3 months of this grant with the help of our community. In that time we have successfully built an open and collaborative ecosystem, attracted over 100 new discord participants, and finalized a majority of the outlying standards in our project.

We want to thank the Factom community very much for the opportunity to bring this new technology to the Factom ecosystem. We hope that FAT’s unparalleled cost and computational efficiency will support the next generation(s) of crypto tokens, much as Ethereum has so far. We are looking forward to future grants to improve the FAT project and continue to collaborate with the Factom ecosystem at large.
This grant is now complete. Per Document 106 - Grant Success Determination Process I will self-score and allow others to review the grant prior to a poll being created where success or failure can be determined.

Original Grant Proposal

Grant Summary

We were awarded a grant to lay the groundwork for tokenization on the Factom protocol. Over this period of time we developed the architecture and standards behind the FAT protocol, created a basic Alpha FAT Deamon, a secure and functioning FAT wallet, and FAT JS libraries. By the end of this grant, we had basic fungible and non-fungible token capabilities on the Factom Protocol.


The following scoring rubrik will be used for this grant per Doc 106:

Exceptional (9.0 - 10.0) - Successful
Overachieved (7.0 - 8.9) - Successful
Achieved (5.0 - 6.9) - Successful
Underachieved (2.0 - 4.9) - Failure
Total Failure (0.0 - 1.9) - Failure
My Score

I believe this grant fully succeeded in its goals, and built off of preceding months of uncompensated work to make sure this platform was viable, which we gave for free in this grant.

I will thus be rating this grant an 8.
Thank your for the update!

Do I understand correctly that this grant was awarded in Nov 2018 and is only deemed completed now?

What I'm trying to understand is what was the scope of this grant, excluding the subsequent FAT development grants, and what parts of the goals & objectives of this grant were completed within the 3 month time frame of the grant and what parts were completed later?
Last edited:
Hi @Valentin Ganev

No, I should have been more clear. This work was completed long ago. I dont believe anything stretched past 3 months, accept for adding or adjusting features.

Since this was from the second grant round, it was before discussions of grant determination (In fact this thread's grant determination had to be done manually, this thread was before that system was in place). I believe that only 2 other grants from this round have been put up for determination (Open node, and the Factom Identity grant that David was a sponsor on). We just wanted to go through and put every one of our grants up for determination to close them out, including this one from long ago.