Approved Grant [Matt York-Paul Bernier-DBGrow-Canonical Ledgers-1] FAT Smart Contracts 2 - Development

Final results

Standing Parties are currently voting on the grant proposals. The vote will close on Aug 16, 2019 at 23:59 UTC and results will immediately become available.
Total Grant Pool: 121,449.00 FCT
Grant FCT Requested Cumulative FCT Score Funded
900.00 900.00 1.00 Yes
660.00 1,560.00 2.00 Yes
9,000.00 10,560.00 3.00 Yes
8,747.00 19,307.00 6.00 Yes
8,093.00 27,400.00 7.06 Yes
1,126.00 28,526.00 8.44 Yes
38,940.00 67,466.00 8.83 Yes
13,750.00 81,216.00 9.10 Yes
22,500.00 103,716.00 9.22 Yes
2,950.00 106,666.00 10.09 Yes
10,000.00 116,666.00 10.15 Yes
680.00 117,346.00 11.12 Yes
2,400.00 119,746.00 14.73 Yes
9,000.00 128,746.00 14.75 No
33,333.00 162,079.00 15.37 No
1,939.00 164,018.00 15.45 No
800.00 164,818.00 15.59 No
Not approved
Not approved
Not approved
Not approved
Not open for further replies.
Executive Summary
The Factom Asset Token(FAT) protocol is a pure data tokenization protocol built on top of the Factom Blockchain. FAT allows groundbreakingly cost effective, flexible, and efficient tokenization due to it’s novel paradigm and usage of the Factom data layer.

Our previous grant successfully researched and fleshed out the concept of smart contracts on FAT. As a result of this grant, an extensive research paper that lays out our findings and proposed design of a FAT smart contract ecosystem was produced, including a proof of concept. This grant seeks to take the next step in making FAT smart contracts a reality by:

  • Drafting an official FAT standard for smart contracts from our findings
  • Implementing an experimental release of FAT Smart Contracts in code (FAT Daemon)
  • Creating supporting libraries, software, and infrastructure to make contracts usable (fat-js, fat-cli)

This grant will work to create an experimental implementation of the proposed contract solution from the previous research grant. This will be no easy feat - as our research over the previous round has revealed there are many complexities and implications to designing contract systems, not to mention a system that is 100% backwards compatible with FAT’s existing structure and remains secure.

As a result of our efforts proposed in this grant, FAT will have experimental contract capabilities at unparalleled cost efficiency. We are very excited about the prospect of Factom being able to openly compete with other established contract ecosystems on this front. Factom is typically evaluated only as an enterprise data security solution; achieving this grant will allow Factom to explore near infinite use cases.

DBGrows ongoing core FAT work (aka what would be FAT Development Grant 4) will be 100% subsidized by the venture with layertech and other partners interested in the success of FAT and the Factom protocol for this grant period.

Team Member or Entity Forum Username
User: Matt York
FCT address: FA35Kd1Ac1aQXEHPxYTR6jNDPuwVoh6APQQGKViceQTedyE7J2vV
FCT: 200

User: Paul Bernier
FCT: 200

User: David Chapman
FCT address: FA3nsSjUy5uSkqMEug8t3VcehZn5w2ciSMpgqFEEsMRwMrHoa9k3
FCT: 300

ANO / Committee
Group: DBGrow
FCT address: FA3HSuFo9Soa5ZnG82JHqyKiRi4Pw17LxPTo9AsCaFNLCGkXkgsu
FCT: 7550

Group: Canonical Ledgers
FCT address: FA2xccSAfhGm5k4tPaXF9741xkQ52drWjoJodQhpPxDxepdqasMM
FCT: 5500

Total FCT Requested

Start Date

Completion Date

Project Description
FAT Overview
The Factom® Asset Token protocol (FAT protocol) is an open source tokenization protocol built on the Factom® blockchain that is efficient, modular, composable, and extensible allowing developers to layer token functionality to meet their specific use case. The FAT protocol is built around a set of open source standards that establish a pure-data tokenization implementation directly within the efficient data structure of the Factom® blockchain.

FAT Smart Contracts
This grant adds smart contract functionality to FAT by specifying a protocol allowing a piece of WebAssembly (WASM) code sole control over a Factoid address on a FAT-0 token. The WASM code controlling the address may include any user defined logic desired, allowing unlimited possibilities for implementing contract use cases. Contracts include external functions that can be called by end users of FAT to access functionality.

Once established, contracts are called by sending a FAT transaction to the contract address similarly to Ethereum. The contract can accept a function to call and arguments to call it with. Naturally each transaction to a contract can also carry an amount of FAT tokens that are deposited and given to the contract. A contract can always abort a call in the case of insufficient payment or bad arguments.

The most current design solution & technical can be found in our FAT Smart Contract Research Paper.

The FAT Contract Advantage
FAT uses Factom entries and chains and enjoys the same pricing & scaling advantages as other Factom applications. FAT’s current token functionality supplies some of the most cost efficient and predictable operational pricing of any public blockchain. Adding smart contracts to FAT will create a fixed price smart contract system on a public blockchain - A truly unprecedented offering.

Since FAT contract operation does not require a network, computation is not scaled in the same way as Ethereum. FAT’s contract TPS scales 1:1 with the throughput of Factom’s data ingestion speed. Data storage is much easier to scale than computation, and as a result FAT has a major opportunity to scale as a smart contract platform among competitors.

Problem Statement
While FAT is closing in on being prepared for use in production tokenization use cases, we can do much more to create a highly flexible and powerful system allowing trustless customization and complex logic. Many use cases require functionality beyond the base FAT standards and token types, often customized to their use case.

FAT does an incredible job at competing with existing technologies like Ethereum, Bitcoin, EOS, and Stellar in terms of tokenization cost and security for basic tokenization. However, FAT is still not flexible in the way that smart contract based blockchains are.

Goals and Objectives
We seek to bring a powerful smart contract solution to the FAT token ecosystem. The proposed changes will allow end users to program custom business logic directly into FAT tokens & addresses and execute it trustlessly via the Factom blockchain.

The solution will achieve the following general & philosophical goals:

  • Allow end users to trustlessly create and publish programs to control the functionality of FAT tokens & FAT addresses:
    • Publishing of contracts will not be censorable or require a trusted party
    • Contracts will be public & transparent. Anyone can read them
    • No central control of contracts
  • Backwards compatible with existing FAT tokens
  • Highly accessible:
    • Contracts are programmable in any language that WASM supports (C/C++, Rust, Go, Typescript, more)
    • Requires no proprietary of for-pay software to use
    • Includes creating clear concise documentation for our solution
  • Scalable:
    • Scales closely with Factom’s data costs & TPS
    • Requires no network consensus for contract operation (Data only)
    • Contracts execute at near native speeds (WASM)
  • Secure:
    • Provides a safe bedrock for a contract ecosystem to form
    • Contracts have complete control over their security at the application level
  • Draft a standard or set of standards that completely describe the functionality of FAT’s smart contract system
  • Fitting with FAT’s standard first ethos, the standards will completely and wholly inform the implementation
    • The standard or set of standards we create will be solely sufficient to re-implement the functionality in another language if desired.
  • Conduct any necessary changes to existing standards required to facilitate contract functionality. The standards we create will draw upon and intermingle with our existing token & supporting standards. FAT-0 will need to be modified to accommodate new contract functionality.
    • Allow establishing contracts on an address by signing a 0 input burn transaction
    • Allow establishing an “issuance” contract that can mint (coinbase) tokens by signing a 0 input burn transaction from the issuer
  • Amend our governance document FATIP-X to support a new type of FATIP proposal relating to standard contract interfaces & applications
    • Promote the creation of common interfaces that can be used to form larger ecosystems & synergies between contracts Similarly to Ethereum’s ERC standard series
FAT Daemon
  • Implement changes to existing standards
  • Implement new experimental contract standard functionality
  • Add endpoints to RPC API:
    • Get-contracts - return the contract Factoid addresses for a specified token
    • Get-contract - return the contract at a Factoid address
      • Contract code itself will be hosted on a separate dedicated chain so as to be reusable, so will return that chain ID
    • Get-result - return the result value of a contract call (transaction) by entryhash
FAT Clients
  • Implement changes to transaction validation for zero input/output transactions for FAT-0
  • Implement new transaction fields for establishing contracts (linking to contract chain in transaction body)
  • Implement contract validation & contract chain establishment
  • Implement new fatd RPC API endpoints & changes to endpoints
Update documentation, FATIPs, websites, wikis, etc to reflect new smart contract functionality of FAT. There are many existing and references in documentation to change.

Success Criteria
Standards and documentation clearly define the solution:
Questions from the community are addressed, included in docs, and fixes are made based on feedback

Securely implement a backwards compatible contract solution on FAT:
Existing FAT balances are not affected by implementing contracts. Contracts do not open vulnerabilities

Contract solution is open, decentralized, trustless, censorship resistant:
Anyone can use the contract system and FAT. All designs and code remain open source and free to use

Clients and tooling are made compatible with the new solution:
Fat-js and the fat-cli support the new features relating to contracts

Timelines and Milestones
Create Smart Contract FAT Standard - M1 - Week 3

Implement new validation rules into FAT Daemon in prep for SC support - M1 - Week 4

Support basic contract establishment mechanics in fatd - M2 - Week 6

Expose contracts to calls via signed transactions - M2 - Week 8

Update existing documentation - M3 - Week 10

Enable SC support in fat-js for new FAT Daemon functionality & validation - M3 - Week 11

Final integration testing - 4 - Week 13

Total Project Budget:

13,750 FCT

DBGrow: 7550 FCT

Canonical Ledgers: 5500 FCT

David Chapman (Factomize, Sponsor): 300 FCT

Matt York (Factom Inc, Technical Advisor): 200 FCT

Paul Bernier (Luciap, Technical Advisor): 200 FCT

Assumed Price Per FCT

There are no known direct competitors in the Factom ecosystem related to the grant material presented.

In terms of collaborators, BIF is currently working on allowing FAT transactions being sent from enterprise Smart Contract and ledger solutions such as DAML, Ethereum, Hyperledger etc. While this is is extremely valuable off chain integration, it is not closely related to the direct efforts of this grant. This grant will increase the capabilities of such integrations by allowing those ledgers to operate smart contracts on FAT.

Additional Information
Organization & Person Info:

Canonical Ledgers:
  • Adam Levy - FAT Editor and maintainer of fatd
  • Sam Vanderwaal - Software Developer (will not be directly working on this grant)
  • Devon Katz - FAT Editor and maintainer of fat-js
  • Julian Fletcher-Taylor - FAT Editor
  • Eric Salinger - FAT standards & code collaborator

We are very excited to welcome a new collaborator to the FAT ecosystem on the DBGrow team: Eric S. Eric comes to us with a background in enterprise systems architecture, auditing, and senior development from a Big Four tech company. Eric will be assisting us with making sure our ecosystem is secure and contributing to FAT standards and code. Welcome Eric!

  • Paul Bernier - Technical advisor, FAT Editor and maintainer of the FAT Wallet, collaborator on previous FATdevelopment grants.
Factom Inc:
  • Matt York - Technical Advisor & collaborator on previous SC grant
  • David Chapman - Sponsor & Sponsor of previous SC grant

Additional Information:

Background Work For This Grant:
FAT Smart Contract Research Paper

Our Ecosystem:
FAT Discord
FAT Whitepaper

Previous FAT Grants:
FAT Development 1
FAT Development 2
FAT Development 3
FAT Smart Contracts Research

Indemnification and Waiver
By submitting a grant proposal or participating in the grant proposal process, the submitter hereby agrees to release, waive, discharge the Guides, Authority Set Members, Standing Parties, and their respective employees, contractors, agents, representatives, successors, and assigns (collectively, the “Releasees”) from any and all liabilities, claims, and demands of whatever kind of nature, either in law or in equity, which arise or may hereafter arise from participating in the grant proposal process, except for those caused by the willful misconduct or intentional torts of the Releasees. The submitter further agrees to indemnify and hold harmless the Releasees against all liabilities, obligations, losses, damages, penalties, claims, actions, judgments, costs, or expenses which may be imposed on, asserted against or incurred by any Releasee as a result of, or arising out of, or relating to this grant process contemplated by this document, including without limitation, any judgment, settlement, attorneys’ fees and other costs or expenses incurred in connection with the defense of any actual or threatened action or proceeding, except for the liabilities caused by the willful misconduct or intentional torts of the Releasees.
The submitter warrants and represents that he or she has all necessary power and authority to represent all applicants contained in the grant proposal: (i) to submit the proposal and (ii) to agree to this Indemnification and Waiver.
Note: Please see the Factom governance document (Doc 001) for definitions of Guides, Authority Set Members, and Standing Parties. Grant proposals submitted in another format shall include this indemnification and waiver in its entirety.
Last edited by a moderator:


Factomize Bot
The Forum Q/A process has now started. The community may ask questions until Aug 12, 2019 at 23:59 UTC.

Other important dates:
  • After the question period ends on Aug 12, 2019 at 23:59 UTC, you may continue to answer last minute questions until Aug 13, 2019 at 23:59 UTC
  • Once the answer period ends, voting will start one minute later on Aug 14, 2019 at 00:00 UTC
  • Voting will be closed on Aug 16, 2019 at 23:59 UTC and the final results will immediately become available.
So just to set the record straight: on December 1st I will be able to write a smart contract interacting with FAT-0 tokens (transferring, burning and also holding tokens?) in a WASM compatible language, compile it and publish it to Factom and will then be able to interact with it? Is that an accurate description of the end result?

Also which identity system will you be leveraging?
Last edited:
I am really surprised how this community funds everything with a FAT label. The comment above is a confirmation for this.

My 5 cents:

1. I find DBGrow rate a bit steep, especially regarding the previous smart contract grant

2. Each development grant/sprint, that FAT team applied, has to be done within 3 months interval.

FAT grants are seriously lagging in time.

FAT Dev 2 (March-May 2019): Full update has not provided, lag of 2 months and 7 days.

FAT Dev 3 (June-August 2019): No proper update. 70% of time passed.

3. While some other grantees use “a great windfall” in December 2018 to push additional features or to lower future grant amounts cause this free money, I haven’t seen any additional efforts from DBGrow for a huge windfall they received. Of course, it’s completely up to them, as it’s their money, I just highlighted this moment. Colin mentioned this in December, but it was ignored.

4. FAT had to bring a great EC usage, instead we receive a stretched development for the development. FAT was not properly released and team started working on smart contracts. Previous grants has not finished and team applies for new and new grants.

I urge everyone to look at this and stop funding everything with a FAT label. Seriously, remove FAT prefix and take a look again — should we fund this?

I urge DBGrow to finish all works, that they committed to do and got paid in previous grant rounds.

De Facto won’t support this grant and I encourage people to open their eyes.
Last edited:
I agree with some (but not all) of what Anton is saying. I'm still waiting for closure on a lot of your previous grant work, and I am not 100% clear on what value has been delivered since the last grant round. There are 5 milestones on that grant. We have heard a little bit about your ongoing work on milestone 1 and that you plan to launch work on milestone 2, but nothing else. That grant ends in less than a month, are you going to finish milestone 2, 3, 4 and 5 in that time? Are you going to have to work on it in parallel with this grant?

I'd be much more inclined to support this if I could clearly see you hitting the milestones that you defined and committed to.
Thanks for your opinions on this @Anton Ilzheev

I'll go through your points, but will mostly just be reiterating as you have asked some of these many times.

1. Our rates are not steep. People even mentioned that we had great rates a few times in our last grant round. Feel free to check it out.

2. As I've told you FAT grant 2 wasn't just dbgrow. We must wait for all parties to check off that it's done.

3. I've already responded about FAT grant 3. We have actually now had our new developer working the past week, you can ask Devon or adam. I only haven't posted an introduction thread because I've been non stop travelling and meetings the past week for a factom project.

4. Grant windfall comment simply untrue so I wont go more into that.

5. I've responded to this many times for you re a DBGrow pushed release. There are a couple things left we are waiting on from others for that, and there are some important core updates that have come about from Smart contract / DEX investigation, hence why it is important to be considering smart contracts at the same time. It is all an open source project though, so feel free to release as you'd like. We will wait until we think the time is right, which as I told you and you seemed happy about like 2 weeks ago, will be in the next few months.

Your comment about EC usage is of course nonsense, but I promised to respond to all of these points ;). If our bar for succesful Grant's is the EC usage they have brought, all Grant's would be a fail. I strongly believe that FAT will provide significant usage, and will bring in entities that create significant usage outside of FAT, but would only be here because of FAT.

If you remove FAT label should you still fund this?
- Yes because this is a bargain price for the work being done.
- Yes because FAT is becoming more and more useful, for example its usage in pegnet.
- Yes because the work is awesome and has huge potential
- Yes because the last smart contract grant we are hitting all milestones and making great progress
- Yes because every grant round we have asked for less money than the last. Every grant round more work is subsidized by ourselves and others we are working with. Now we have a venture with other partners 100% subsidizing what would be core dev grant 4. That's the kind of trajectory we should be very happy to see in this protocol. Let's see where that trajectory takes us going forward ;)

I believe your continued public remarks come more from a place of not understanding the project than anything. Please feel free to learn more about it. I was looking forward to demonstrating more of it to you and helping clear up these odd repeated remarks after you asked Dbgrow to sponsor your FAT grant, but I never heard more from you on that after you told me you were writing the grant. Regardless, let me know if you want to learn more about what we are building here, it's pretty cool stuff and I'd love to have you and anyone else contributing.
4. Grant windfall comment simply untrue so I wont go more into that.
Let me up this thread started by one of ANOs (ANOs only access).

4) It's crazy to say ANOs will lose standing by lowering their efficiency and taking home an extra say $2k a month, and then ignore people walking off with a windfall of $550,000 banked for just 3 months of work.
So, FAT team received extra $550K for the first grant (on the day of payout) and what's happened then?
You applied for FAT-2 ($70K requested), FAT-3 ($30K requested) and etc.

I don't see you used the windfall towards FAT development – instead DBGrow requested additional money each new grant round. In addition to operating at 0%.
Last edited:
2. As I've told you FAT grant 2 wasn't just dbgrow. We must wait for all parties to check off that it's done.
From FAT-2:

We are seeking 12,700 FCT across DBGrow, Canonical Ledgers, and Luciap to further development of the Factom Asset Token Protocol
So, right now you ask funds for new development across DBGrow and Canonical Ledgers, without proper finishing the previous work, that should be finished in May 2019.
Not sure what those comments mean anton. The math your pulling out from the comment your publicly showing here from the private ano section is incorrect as well. Beyond that, we've already talked about work we've added, and theres plenty of things we've done with extra money to benefit the protocol. I wont continue to rehash with you. These things also,ind you, include covering losses from Grant's we had where the price dropped significantly before payout... because that's how these Grant's work.

Yes we request additional money each round, because we continue to do more work and add more features outside the original grant. I'm sure you can understand that given you do the same thing...

Lastly, you seem to be avoiding the bulk of my response and points, so continuing long responses seems unfruitful.
Thank you @Matt York and @Niels Klomp . I am immensely excited about this work as well.

I will ask you this outright niels as I think all of us respect your knowledge of budgeting these things, do you believe that the dollar amount of this grant is overpriced for the integration of WASM powered smart contracts into Factom and all the associated FAT work over the next 3 months?
From a dollar perspective certainly not. This grant is comparable to the dollars budget of the mobile wallet, which with all due respect is not that hard to begin with as it just a seed, key-pairs and a few transactions. Sphereon has a product that has 2 mobile apps for this including backend creation and management of tokens.

The smart contract is also is in line with the dollars amount for DAML we requested last round. Ours was also about the research part which you already have done using the previous grant. We are going over budget in ours, mainly because DAML is not as polished yet as we would like to see. So I am guessing for your grant you will not be able to finish this one in budget as well at roughly 50K, since it is a little less than I would expect.

What I do have to say, but that is to all people creating proposals; Is that we are in a tight situation. Sphereon made a really deliberate choice to only list the core dev grant and internalise that one with something like 40%. (the token taxonomy thing is available for the whole ecosystem and only at cost price with risks for us as well if price falls). We have been internalising almost every single grant (if not every single one) to date.

In a time where FCT is at 4 dollars, i would like to see some more parties taking the approach of internalising. If I see some parties trying a shotgun approach with only a few developers at their disposal I am seeing a strategy that I don't really like. Everybody has to rate all the proposals and of course every party will defend their grants and some at the expense of others. I see several entities having something like an ask of 25+% combined of the total pool doesn't make sense to me
So just to set the record straight: on December 1st I will be able to write a smart contract interacting with FAT-0 tokens (transferring, burning and also holding tokens?) in a WASM compatible language, compile it and publish it to Factom and will then be able to interact with it? Is that an accurate description of the end result?

Also which identity system will you be leveraging?
Thanks for the question @Paul Bernier. Yes, that description accurately describes the end goal of this grant.

To add on this, beyond just allowing code to interact with FAT-0 tokens your code can perform any arbitrary logic you desire in response to a FAT-0 transaction event.

The identity system for the contract solution will be identical to FAT, which is currently the Factom serveridentity framework. We are looking forward to supporting DIDs based identity in FAT once the tooling and standards are ready. Once that change occurs all FAT functionality requiring identities, including smart contracts, may use DIDs.

EDIT: Apologies missed the identity aspect of the question, have added that to the response above
Last edited:
We are trading at 50% of the fct price assumed for last grant round.

This round we have set relative to $4 and we are already trading around 3.75, meaning on this grant we will already be taking a loss of over three thousand dollars, unless we adjust our fct ask right now to compensate for that.

We wont do that, because we understand the inherent currency risk, both up and down.

I will point out, though, that if we already are subsidizing other work through the venture mentioned in the other thread, we are probably pretty dedicated toward both using excess funds to continue to develop, as well as filling in the gap if grant payouts have a lower fct value than $4, which seems likely.
This is a final warning that the community has just 24 hours from now to ask any last minute questions.

Other important dates:
  • After the question period ends on Aug 12, 2019 at 23:59 UTC, you may continue to answer last minute questions until Aug 13, 2019 at 23:59 UTC
  • Once the answer period ends, voting will start one minute later on Aug 14, 2019 at 00:00 UTC
  • Voting will be closed on Aug 16, 2019 at 23:59 UTC and the results will immediately become available.
Happy to.

Legal Grant: We have massively overperformed on this grant, and thus still have some funds left (mostly in USD as we were able to preserve capital and find private buyers at a higher fct price). All such funds will be spent on costs in line with the legal grant under the supervision of LRWG. No internal fees or costs for dbgrow being taken. You could say this grant is ongoing, but only because our over performance has allowed us to do a lot more than we originally set out to. Feel free to ask @matt to verify anything you'd like.

Website grant: Successfully completed

FAT Dev 1: Successfully completed

FAT Dev 2: We believe this grant to now be completed. Some items needed to be pushed back or adjusted (See paragraph under these grants), but everything that needed to be done that could be that was in line with our goals of this grant was done, tons of things were worked out, lots of improvements and features added, testing suites created, documentation generated, etc, all in line with FAT Dev 2. We will make an appropriate update in that thread and close that round.

FAT Dev 3: Currently underway. As stated here in response to your question, this work may run slightly (Maybe an extra few weeks) longer than the 3 month period (as many Grant's do). We currently have hired our new developer and he is diligently working through and reviewing FAT. We are also working on the first draft of a FAT Protocol Website with a built in FAT Explorer to make it as easy as possible for people to get started building with FAT. This website will be hosted as a stand alone website for the FAT Protocol, but all of the content is fully free to be brought under the Factom Protocol website (which I think it should be) if/when the Website Committee approves, in whatever way the community would like. (Though this website is more of an add on, as it wasn’t listed under FAT Dev 3 TODOs, but it is being built during this time period). More updates to come on all of this.

Smart Contract Research Grant: As david (our grant sponsor) stated in response to your question in that thread, it is successful and fully on track to be completed by the end of the grant round.

When building something complex such as this, you are often adding things to do, removing things to do, and there are times you discover you need to bring in a new thing to do before you finish an old thing. For example bringing in changes to the base layer for smart contract functionality to happen, merging the Smart Contract research paper into the FAT Whitepaper, or of course changes requiring re-documentation and tutorial reworking. Overall we believe that we have executed well and used the protocols resources efficiently across the Grant's that we have received, starting from the first grant round over a year ago.

This grant follows the work of the FAT Smart Contract Research Grant, which is on track to be completed by the date this grant starts. The first few weeks of this Smart Contract grant, we will be finishing through with the rest of FAT Dev 3. Then for the rest of this grant period, we will be working on this Smart Contract Grant, with the rest of our work on FAT subsidized by DBGrow and our venture. Please see our Smart Contract Research Paper for an in depth look at what we will be doing.

I think the above about sums everything up. Let me know if you need any clarification on any of it. Thanks.
I would just like to chime in here about the state of the code development. And let me start by apologizing for submitting this comment so last minute in the discussion period. But I hope that this is mostly informative, and will aid in people's decision making about how to vote on this grant.

Since the first commit on Oct 8, 2018, the fatd repo has grown to over 17k lines of code and has had 12 early pre-releases. I'm very proud that the daemon and the fat-cli have been a fully functional proof of concept since the end of the first grant round. I learned a lot through that first implementation and identified a number of key security and functionality improvements that I wanted to make in the second grant round.

Unfortunately I will admit that during the 2nd grant round I was not able to make as much progress on some of these issues as I wanted to. I under estimated the time it would take me and the amount of refactor that would be required. By the time the third FAT grant round came around, I had made a lot of progress on the codebase. I had fully replaced all of the FactomProject libraries with my own, adding full cryptographic validation of any data structures entering the daemon, which is also the basis for full database validation. I had completely replaced the fat-cli with a much better documented and complete interface, making it much easier to interact with the daemon from the command line. There also were a number of other smaller API and internal improvements. But the largest outstanding security feature was a way to fully cryptographically validate a database to ensure it had not been tampered with. Without this, the basic security of the daemon was reduced to the users' security of the database file, which is not something to rely on for the average user. Additionally this validation provides a way to ensure that future code changes don't change the protocol. I knew that this refactor would require a new database schema and a nearly full rewrite of the state and engine packages. But the third grant round was upon us. So Sam and I decided to not apply for another development grant until those features were complete.

I am proud to report that at this point the develop branch has full database validation. I completely rewrote the most fundamental internals of the daemon with the lessons learned from the first implementation. I am working with other editors now to get the code ready for an official 1.0 release. In addition to the full database validation, which is very fast by the way, this new refactor contains a number of usability improvements which greatly increase the sync speed, especially if you already know which FAT chains you are interested in. Additionally the code is much better tested and easier to write tests for. It is now possible to reliably add pending transactions, which is the next major feature I will be working on.

I believe that the expectation set from the 2nd FAT grant was to get FAT to a 1.0 release. So regardless of the outcome of this grant Canonical Ledgers is committed to bringing the FAT Daemon to a stable 1.0 release that includes pending transactions. I expect I'll be comfortable making that release very soon. I am putting the polishing touches on it now.

In hindsight I regret not taking the time at the end of the 2nd grant round to communicate this and express our intention in not being included on the 3rd FAT grant. But I am very thankful that DBGrow was able to secure the 3rd FAT grant because while I was working on the codebase, they have laid the groundwork for smart contracts, which is a natural evolution for the FAT protocol. I'm really excited to build the first proof of concept for this into fatd. I'm even more excited to be able to work with DBGrow's new developer directly on the codebase. I truly don't want to be the only lynch pin in the success of the FAT core development, so I am all for expanding the knowledge-base surround the codebase. I invite anyone interested to contact me because I am more than happy to help people get up to speed on the code to allow for more developers.

I think a lot of people see the value in this grant, but have reservations about the execution and communication surrounding previous grants. I'll be the first to admit that my communication could have been better. I am committed to improving that for this grant. However, if you had reservations about the execution, I hope that in light of what I've written above, you will reconsider. To support what I've written, I encourage you to review the conversations that take place on the FAT discord, and if you are technically minded, to review the code and commit history of the fatd repo, and to feel free to reach out to me with any further questions about the state or history of development.
The Forum Question Period has now ended. Teams will have until Aug 13, 2019 at 23:59 UTC to answer any last-minute questions.

Other important dates:
  • Once the answer period ends, voting will start one minute later on Aug 14, 2019 at 00:00 UTC
  • Voting will be closed on Aug 16, 2019 at 23:59 UTC and the results will immediately become available.
The Answer Period has now ended and Standing Parties may now vote.

Voting will be closed on Aug 16, 2019 at 23:59 UTC and the final results will immediately become available.

Instructions for Standing Parties:
  • You may vote in any thread or on this page. The ranks are mirrored once you save.
  • Drag and drop using the three-lined icon at the left of the grant proposal and hit "Save" when done.
  • If you change rankings and leave the page without saving, those changes will be reversed and not count.
  • You may change your vote as many times as you like prior to the vote being closed.
  • If you "Abstain" that means your vote won't be counted no matter what you ranked that proposal.
  • If you deselect "Approve" how you rank the grant matters, but 60% of voters must approve the grant for it to be funded.
Not open for further replies.