Approved Grant Factom Asset Token Protocol

What do you score this grant?


Have not voted

Guides Julianft Niels SamuelVanderwaal

Authority Nodes Multicoin Capital Multicoin Capital Prestige IT Prestige IT RewardChain RewardChain Syncroblock Syncroblock

  • Total voters
    24
  • Poll closed .
Status
Not open for further replies.

Julianft

Guide
DBGrow
Secured
#1
GRANT PROPOSAL EDITED 2018-11-08:

Reduced grant compensation by 40% as follows:

DBGrow: 31,250 to 18,750 FCT
Canoninical Ledgers: 12,500 to 7,750 FCT
Luciap: 6,250 to 4,250 FCT
Layertech: 6,250 to 3,750 FCT


Reduced scope as follows:

Reduced work to strictly the following 3 months
Removed FATIP 201 completion
Removed tutorial creation (Our specifications are very detailed though, and we will look to work with others to make things like tutorials when applicable)
Reduced scope of Wallet to a simple wallet and clarified what the wallet would be
Removed the GO RPC and CLI, keeping the JS RPC

We also moved fatd deliverable from an Alpha to a Beta version in all sections, as we believe we can deliver a fairly robust fat-deamon this grant round.

Thank you everyone for bearing with us during this tense and trying grant round. We truly appreciate all the feedback we have received, and we look forward to forging ahead with all of you to bring tokenization and smart contracts to the Factom Protocol.

****


This grant represents the work of DBGrow, Layertech, Canonical Ledgers, and Luciap in creating the Factom Asset Token Protocol and the FAT ecosystem. Thank you.

As required by document 152 that governs Factom grant round 2: This is the thread for grant proposal FACTOM-GRANT-DBGrow-002.
The review process starts at 2018-10-29 00:00, so please refrain from starting public review or questions before that time to give everybody an equal chance. If you notice clear errors in the proposal you can contact the author of the grant proposal directly.
 

Attachments

Last edited:
Secured
#2
Hello guys!
I like your project and we are going to support it.

Could you please clarify, how 23,750 FCT for Protocol Specifications part will be spent?
Or this work is done and you're going to compensate the time you already spent on this work?
 

Julianft

Guide
DBGrow
Secured
#3
Hi @ilzheev,

As we state in the grant some of the budget is for work already completed. I firmly believe that we should encourage parties to take on ambitious projects like this even if there isn't a grant round at the moment and start early. I believe the factom ecosystem is better for the fact that we jumped into this months early. We have to be agile and take on opportunities that present themselves rather than wait for months to see if we can get paid for them first. In doing so we also can be paid for work we have already shown the community we can do. In all I strongly believe in both models of paying for delivered work as well as paying for work to be delivered, and we do both in this grant.

The budget for specifications more than any other piece of the budget is for past work. That covers the past few months of creating specs, creating js implementations that we had to scrap entirely and learn from, re-writing specs, etc, etc. Most of this goes to specs for the building blocks 100 series, work on 300 and work on 0 and 1, the foundational token types.

Let me know if you have any more questions. Thanks!
 
Secured
#4
Hi @ilzheev,

As we state in the grant some of the budget is for work already completed. I firmly believe that we should encourage parties to take on ambitious projects like this even if there isn't a grant round at the moment and start early. I believe the factom ecosystem is better for the fact that we jumped into this months early. We have to be agile and take on opportunities that present themselves rather than wait for months to see if we can get paid for them first. In doing so we also can be paid for work we have already shown the community we can do. In all I strongly believe in both models of paying for delivered work as well as paying for work to be delivered, and we do both in this grant.

The budget for specifications more than any other piece of the budget is for past work. That covers the past few months of creating specs, creating js implementations that we had to scrap entirely and learn from, re-writing specs, etc, etc. Most of this goes to specs for the building blocks 100 series, work on 300 and work on 0 and 1, the foundational token types.

Let me know if you have any more questions. Thanks!
I agree that this work should be paid.
As this work is already done with internal resources & (what important) in this grant round we have 2x requests against grant pool size, I have the following suggestion:

1) Approve $ amount of work already done in this grant round
2) Postpone the payment for this part to the 3rd grant round to allow other projects get a chance to be developed / done

What do you think about it?
 

BennyJ

BuildingIM
Secured
#5
This looks like a very impressive grant with lots of parties collaborating (which is great). My concern is that most of the dev experience from the protocol is already within the FAT team and therefore it will be hard for those of us outside the FAT team to create an unbiased evaluation.

That said, with the skillset of those involved, I think we are in safe hands.
 

Niels

Guide
BI Foundation
Secured
#6
Disclaimer: these questions are from my role as guide

I really like FAT as it will bring nice opportunities and Sphereon will even use it for the ecitizenship app, however it is clearly stated in current grant round that is should only cover 3 months and back pay violates that. The reason the provision is there is because resources are very very limited. I urge you to split it out and ask for future compensation spread out over more rounds for work already being done.

Currently you are asking for more than 40 percent of total pool and as a guide and an much as I like it from my CTO of Sphereon role, I cannot support that sorry.
 

Julianft

Guide
DBGrow
Secured
#7
I agree that this work should be paid.
As this work is already done with internal resources & (what important) in this grant round we have 2x requests against grant pool size, I have the following suggestion:

1) Approve $ amount of work already done in this grant round
2) Postpone the payment for this part to the 3rd grant round to allow other projects get a chance to be developed / done

What do you think about it?
Hi ilzheev. The issue with that is 1. we will just always be behind in payment. We have already taken on the huge risk this time of working hard to possibly not be compensated, and that is always hard to make happen on the end of those putting in the work. If we do as you suggest we will simply always be in that position while all others are paid for work they have not begun yet.

From a practical standpoint, we will not be able to achieve what we are setting out to achieve with more internal funding.

That being said, we did already have to push some of our work we envisioned out to next grant round.
 

mig

Stamp-IT
Secured
#8
Hi Julian,

I like the FAT initiative but I'd like to have a discussion about the back pay? I don't really have an opinion but I'd like to have yours regarding this.

1. What would happen to the back pay if the community doesn't/didn't support the project going forward ?
2. Do you think introducing back pay could open us up to problems going forward ?
 
Last edited:

Julianft

Guide
DBGrow
Secured
#9
Disclaimer: these questions are from my role as guide

I really like FAT as it will bring nice opportunities and Sphereon will even use it for the ecitizenship app, however it is clearly stated in current grant round that is should only cover 3 months and back pay violates that. The reason the provision is there is because resources are very very limited. I urge you to split it out and ask for future compensation spread out over more rounds for work already being done.

Currently you are asking for more than 40 percent of total pool and as a guide and an much as I like it from my CTO of Sphereon role, I cannot support that sorry.
Hi Niels,
This is a complex one and we knew it going in. That is why we have structured this as 1. one-off costs for delivering an item at the opening of the grant round (a few days ago), and 2. ongoing budgets starting at the opening of the grant round and going through the round. In the one off deliverables to kick off our grant we only ask for the value of the deliverable to be judged. We do not care much for any effort of work put in to be considered as we are not asking so much for payment for work we want to do, we are exchanging an item of value with the community and asking for payment for that item.

Trying to determine the span of work under which these were created is not simple, and it will never be for a project of this magnitude. We originally started envisioning and sketching this out 5, maybe 6 months ago. We've had many rounds of creation, testing, and destroying our designs. For some projects you can understand the scope and set up a self contained timeline, easily judging the start and end date of the development. It is not easy to identify start and end dates of development when creating something like the Factom Asset Token Protocol, as these projects grow over time. That is why we have opted to provide this work in a package, starting a few days ago, as extremely well defined deliverables.

Where the limit that the grant should not exceed the span of 3 months following the close of the grant round comes in for us is for ongoing budgets (similar to guide pay, anchor, core dev, etc), ie FATIP editorship, ecosystem management, etc costs. While we have already been doing them, we will only start being paid for such work starting at the conclusion of the grant round. We would be fine considering a few days ago as the start instead of a couple weeks from now, and we could understand doing so as that was the date of the delivery of the specific items to kick this grant off, but that is strictly worse for the community as that includes less free work from us.

As always I am opting to be as straightforward and transparent as possible with the community to try and navigate a system that is imperfect, and with a desire to adequately fund a project for which it is difficult to define in scope, but that I believe can have profound ramifications for this protocol. We are willing to talk about ways to structure this grant that may be more palatable. This holds true even if we have to be flexible and receive slightly less money this round as it is important to us that the Factom community can feel like they are funding projects they really want to be funding, and in the manner they want to be doing so. We also desire that other impactful projects are able to be funded, we are always willing to work with the community to find what we all want to spend our grant funds on, and ultimately as this is a grant it needs to fulfill the will of the community. As I've said before, I believe that all applicants this round may need to be flexible in working with the community to slim down and reduce the scope of grants.

We also need to stay within the bounds of funding that actually lets us accomplish what we are setting out to do though. As for the comment on this being 40% of the grant pool and that invalidating the grant to you in and of itself, remember this is a grant representing the combined efforts and nearly sole focus of 4 very dedicated ANOs, for which a minimum of 9 people will be employed in this project (4 from DBGrow, 3 from Layertech, 1 from CL and 1 from Luciap), of which almost all are devoted entirely to building out Factom. However you want to approach this, whether from impact to the protocol, or number of hours being devoted to this project across these 4 companies even reduced only to the hours spent working over a 3 month period, the total ask for this grant is well within reason.

The question now is whether this grant is the most impactful use of the communities resources. If the above helped ease your concerns in that, I am glad. If not, please feel free to discuss some specific changes you would like to see. We are here to work with the community to make sure all grants fairly represent the work being accomplished, and represent what the community wants to be accomplished. Thank you for your comments.
 

Julianft

Guide
DBGrow
Secured
#10
Hi Julian,

I like the FAT initiative but I'd like to have a discussion about the back pay? I don't really have an opinion but I'd like to have yours regarding this.

1. What would happen to the back pay if the community doesn't/didn't support the project going forward ?
2. Do you think introducing back pay could open us up to problems going forward ?
Thanks for your comments, and I'm happy to have that conversation. I will not pretend to you that these are simple answers.

1. I believe you are asking what we would do with that money if the community stops financing forward progress? If that is the question then the answer is simple, I will continue to do everything I can to provide our software and ecosystem development resources to further FAT and the entire Factom protocol. I would be able to use the backpay to extend our runway developing these solutions at least at DBGrow as long as I could. We are very devoted to pushing the entire protocol forward as much as we can.

2. I will talk about back-pay generally. Absolutely it could cause problems. And I also think that it solves massive problems as well. I personally think it solves more problems than it causes.

As I see it, the main problem it could cause is that parties that take the enormous risk and initiative to put thousands of hours into developing out a project like this that ends up not being funded by the protocol, there could be enormous frustration by those parties.

The huge benefits I see are that 1. The community can see the work already done, you can examine the github, and read through the thousands of messages on the FAT discord and understand the project much better than you could otherwise. The community doesnt have to fund a set of promises, they get to determine the value of something sitting right in front of them. If the project fails or is not as useful as originally thought, then it will never be funded. Thats a great filter for the community to have. 2. We all need to be in startup mode. Imagine if a startup could only start pieces of development once every 3-4 months. It would kill that startup. If we are not willing to jump headfirst into projects and seize opportunities, knowing if the community believes it was worth it they will fund us in the end, we lose so much as a community. If an ANO spends 100k developing something before a grant round, that ANO just frontloaded 100k in development for the "startup" that is the factom protocol. That is enormously important, and I believe we need to encourage that as much as possible.
 

Julianft

Guide
DBGrow
Secured
#11
This looks like a very impressive grant with lots of parties collaborating (which is great). My concern is that most of the dev experience from the protocol is already within the FAT team and therefore it will be hard for those of us outside the FAT team to create an unbiased evaluation.

That said, with the skillset of those involved, I think we are in safe hands.
Hi, thanks for your comment. That is understandable. If you would like more information on FAT from an unaffiliated party, I believe Steven masely recently reviews FAT, Matt york has reviewed at least some of it, and and niels has as well. Thanks!
 
Last edited:

Niels

Guide
BI Foundation
Secured
#12
Disclaimer I am writing this as a guide


@Julianft thank you for all the words, but this opens up all kinds of back pay tbh and quite frankly you should have thought about it before. Just like the grants of BIF and Sphereon aren't about back pay or even full pay for the work. If we simply start to rely on back pay for large projects and include that in Grants for future work we are going to end up with an unmanageable grantpool that gets souped up by these types of projects. That leaves other parties without a pool as a lot of money is already allocated.

The rules are quite clear for this round, so without changes I am not in support of this proposal as much as I like FAT and as much value it could bring.

I am not fully against back pay, but that needs seperate grants and is not applicable in the form you chose for this round for which the rules are quite clear in terms of timeline. Back pay posing as creating value is trying to get around it IMHO. There need to be discussions before these types of applications, because before we know it companies like Inc and Sphereon will come with back pays in several hundreds of thousands or even millions.

Again I support any current and future work in this proposal, but also believe it is too big of a proposal for the pool to handle, which would definitely be remedied by removing the back pay part, having seperate discussions about that and figuring out a way to recoup some of that in the future. But adding to that I also would like to say that with current prices I think it would be unwise to fund these types of development completely from the grantpool. The fact you guys started it, is the risk you take as with any software development. It isn't for free and the costs goes before the benefits
 
Secured
#13
Hi Julian. Thanks for the reply but I think I have to rephrase question 1.

1. If the community doesn't want the project, do you expect the community to pay the investment you made before hand ?

2. Do you think it's wise to allow ANOs to back channel the system of check and balances we have put in place? (System that was put in place to avoid exactly these type of things)

3. Supposing we go down the "back pay" rabbit hole, resources are not infinite, how do we as a community allow some projects to get paid back and not the others ?

I will echo Niels comments here in my own words.

Resources are scarce. ANO can either finance themselves through their monthly allowance or using the grant system. Back channeling these systems and expecting to be paid in full or at all is asking for huge problems down the road. I think we just cannot go down that rabbit hole. I like this proposal but lumping something as controversial as I think this is with it will get quite a few of us to simply vote no because of the implication this would bring.
 

Julianft

Guide
DBGrow
Secured
#14
@Niels

Doc 152 states that the next grant round is in 3 months, and that if your grant spans longer than that you must break it up and apply for the next segment during the next grant round. Stating that the next phase Must be submitted in the subsequent grant round, the round for which that segment applies, implies that this is directed at grants stretching into the future. The spirit of that is to avoid grants stretching into the future, and the risk associated with funding activities far out in the future. So let's not pretend that it is a 100% clear cut and perfect system, and instead work together to discuss the best way to manage these clearly important situations.

We can also work together to discuss the best way to structure and compensate this grant. We are pricing this grant in a way the 4 ANOs involved felt was fair for the work being completed, and are coming to the table entirely flexible to assess what the community thinks is fair. We have a re-submission period for a reason. We internally even discussed voluntarily lowering the scope of this grant during this period once we had seen the other fantastic grants put forward by the community over the final day of the grant application round. We want to make sure we can fit in other grants that will be impactful for the protocol, and maximize this protocols use of resources.

To summarize a final time: We are coming to the table transparently about what work was completed, and when the work was completed. We opened work early because we wanted to get our work into the communities hands as quickly as possible instead of sitting on completed work and only releasing during the period of the grant. We now will work with the community to decide how they want to judge the work we have laid out that we have done and that we are planning to do. We understand that a big project like this is complex to issue a grant for, and we desire to give the community a voice in it. As such, we planned from the start to listen to what the community wants, and resubmit during this grant period a grant tailored to the wishes of the community. DBGrow, Layertech, Canonical Ledgers, and Luciap believe deeply in representing the wishes of the entire Factom community during the grant round. Thank you.
 

Julianft

Guide
DBGrow
Secured
#15
Hi @mig

1. Absolutely not. If the project fails, or if the community doesnt want it, the community absolutely should vote no. Thats the great thing about delivering at grant round. The community gets to see what they are voting for and decide if they want it, what its worth to them, and this can be communicated to the grantee to create a grant better tailored to the value they actually brought to the table.

Even more than that, if the community loves the project and starts using it in abundance, they still can decide not to pay the developers back. Theres no recourse that the grantee can take, all they can do is learn a harsh lesson and the community gets, in this case, most of a tokenization and smart contract protocol for free.

2. I’m not exactly sure what this question means. I’m not sure what check or balance payment for already completed work gets around. It’s a very fair way to judge a project, has been suggested multiple times by community members in the past as a way of more transparent grants as the voters know exactly what the deliverables are already (actually already suggested in this thread), and payment for completed work has already been done. Check out the current guide payment grant, or the previous one. The current guide grant out for vote, for example, pays for 2 months of already completed work, and 1 month of work in the future.

In fact, if the community consensus is that 152 shall be interpreted to dissalow payment for the value of a deliverable at the beggining of the grant round along with 3 months of payment for work being done in the future, we could likely restructure this grant to be around the same timeline as the guide grant. Thats about when DBGrow began work with Layertech, CL, and Luciap, so that could be a nice window to shrink the grant down to, limit its scope, and reduce the payment amount. Again, it’s the community voting and distributing the funds, going toward a project built for the entire community, so I want as much of the communities input on whether thats a good way to shape the grant for the Factom Asset Token project.

If the community disagrees about payment for completed items in the case of the Factom Asset Token project, or more generally if the grant came off as overly ambitous given the size of the pool (we had a hard time with breaking up this grant. Are the specs worth anything without an rpc client? Is that worth anything without a fatd, or documentation?) , I do apologize. The teams on this grant did not sense that when writing it or running it by some initial people, and had no intentions of seeming to force out other deserving projects. I hope that our clear eagerness from the beginning to engage the community and to be flexible to find what a structure for the grant that we can all get behind can help demonstrate that. All 4 of our ANO’s positive relationship to the community are very important to us.

3. Unfortunately I doubt we will see many grants for already completed work. Its kind of crazy to develop a big project like the Factom Asset Token Protocol thats 100% for the community, and pay for it yourself without certainty you will even recoup any costs. Its a huge risk to take, and I dont foresee it happening that often. When it does, the community may vote how they please. I personally will be encouraging such development. If we force people to wait for months to even begin their development, I believe we are a more stagnant ecosystem. If we can get the community to frontload the costs for some amount of open source development and know that if they succeed they will have the chance to compete to be paid back, we can ease some of our massive resource deficit. That is only a good thing for the ecosystem.
 
Secured
#16
@Julianft can you confirm 5-6 months of work? Any factomized documents of FAT or specifications with date?

I looked into FAT Discord and #standarts-discussion channel started on 28 Sep.
#smart-contracts discussion started in October.

Discord server itself created on 08/17 (#general channel).

1540887347527.png
 

Julianft

Guide
DBGrow
Secured
#19
@ilzheev

We started work in private. Then moved to bitbucket. Then moved to Github. Activity is not carried across those mediums, so the first pull requests on github will start only a couple months ago.

Work with Layertech, CL, and Luciap started in private discord chats, and moved to the FAT Discord 1-2 months ago. This aligns well with the timing I stated of working with adam and luap of around 2 months ago a few posts up actually (we moved to those mediums, FAT and Github, to setup a nice trail of all collaborative work in the FATIP system).


can you confirm 5-6 months of work? Any factomized documents of FAT or specifications with date?
I sincerely hope this is a joke. If we are that quick to jump to such extreme levels of distrust, when there are answers as simple as moving from bitbucket to github, I believe we have some serious issues within our ecosystem.
 
Secured
#20
@Julianft please don't take it personally, I understand that it's impossible to create this idea & white-paper within few months. I'm just trying to understand what type of work you ask for backpay. If it's a couple of months of discussion of Protocol Specification and White-paper preparing for this grant application — I have a question why it should be backpaid?

It's a minimum required things to convince the community to "invest" grant pool funds into your project.
Once anyone develops an idea to get funding, he usually asks funding for realisation of the idea, not for the preparing it's presentation.
 

Julianft

Guide
DBGrow
Secured
#21
@ilzheev

I'm honestly confused here. If in fact we hadn't really been putting in work before very recently, we wouldnt have a problem at all would we, because all of FAT except for "preperation" would have been made within a couple months? I sense the problem here is that we were open and released early, and are 100% transparent about when we did what work. Would we have been better off not having that level of transparency, and saying all work started when we created that new github and did our first pull request? I guess yes. That would have nicely put all our work in a short time frame. We didn't do that because we insist on being transparent in all things that we can.
 
Secured
#22
@Julianft You are changing the direction of this discussion. My main question is what type of work you ask to backpay, and not amount of work you have already done.

I still don’t understand it.
Please explain.

White-paper writing? Specs discussion and formalizing it on GitHub? Anything else?
 

Julianft

Guide
DBGrow
Secured
#24
@ilzheev

I don't mean to ignore your question, only missed it, my apologies.

Ya so the work as you can imagine was a feedback cycle of tons of research, specification creation, implementing clients to test, seeing what worked and what didnt, back to more research, folding that into new rounds of specs, etc. Some of that whitepaper, and dont hold me to this because I dont have the exact date, I believe was actually done right around our ANO election, so its been a lot of thinking and a long time coming before this that we have been interested in this project.

When we added the whitepaper to deliverables, we have not sat down and budgeted what that specifically is worth for example. We just add it there to inform the broader grant, to show our commitment coming in. As it was such a large grant and project, we believed that the 2 week discussion period would be the best place to get a sense of what the community itself wanted from our grant, and so we left some things vaguer than we could have it seems.

We also added all of that because, honestly, we are very very excited about out work. We wanted people to be able to view this grant and see the entirety of the FAT ecosystem and project, and all it can do. I see now that this was confusing, and that is on me.
 

Julianft

Guide
DBGrow
Secured
#25
After reading through this thread in entirety, I want to summarize where we stand so there is no confusion,

- We tried to lay out our contributions coming in, when we did them, and what we plan to do moving forward in a 100% transparent way.

- We put a price to them that we believed is in line with other such efforts awarded in this ecosystem, whether you take this as pay for completed work, or pay for work over 3 months and only take work outside of that as contributions of good will.

- We know that we may have a different perspective than the community in how this work should be structured, priced, and interpreted. We also knew at the time of writing that we were likely to get many other fantastic grants coming in near the end of the grant period.

- We decided early that we would state a fair representation of the costs, and then could work with the community to decide what we should take out of the grant to slim it down to what the community thought would fit well within this grant round.

- While this was meant to give the rest of the community as much of a voice as possible in steering our grant, it clearly was the wrong approach, and I apologize for any repercussions that has had.

- This discussion has been rife with misunderstandings, and I hope we can move forward from it in a way that best represents the wishes of the community, and maximizes the impact of this grant round for our ecosystem.

- Maybe we all got along too well at the ANO retreat. Now we've balanced that with some fighting. Hopefully now middle ground prevails. ;)
 
Secured
#26
Okay, we need to calm down.
Sorry for my tone @Julianft.

Thanks for explanation.
There are a series of questions appeared with your grant proposal, and we need to responsibly discuss it as community and decide, cause it may significantly affect next grant rounds by creating a precedent.

1. Should the already done work (not yours, but in general) be backpaid by grants or dropping efficiency? (except the work that already approved with concrete budget to be backpaid, e.g. Guide payments)

2. If 1) is no, should there be any exceptions of this? Who decides this?

It's very important questions and the precedent, because off we can receive the avalanche of backpay grants in the next round. Naturally each work which not pointed as ANO pledge may be asked to backpay: any products & libraries development, any type of Committee works & compensations and etc.

--
It's not the grant discussion, so it's better to discuss in separate thread.
 
Secured
#27
Regarding your grant @Julianft

1) You made a work with own resources & you ask for compensation for it
2) It's an internal work and you don't need to pay $XXX,XXX to the third-party
3) You're asking for almost 50% of GP amount, the most part of this funds is for backpay

Even if we decide to backpay, why this backpay won't be divided into few next grant rounds as @Niels & I suggested?

The issue with that is 1. we will just always be behind in payment. We have already taken on the huge risk this time of working hard to possibly not be compensated, and that is always hard to make happen on the end of those putting in the work. If we do as you suggest we will simply always be in that position while all others are paid for work they have not begun yet.
If you are going to apply for back-payment on each next grant round — it will be as you describe.
But why to do it?

If you're not going — so what's the problem with postponing backpay?
 

DChapman

Staff member
Factomize
Secured
#28
This is a fantastic initiative and I applaud all involved. The reality is, this initiative risks not being funded this round because of the highly competitive nature of the current grant submissions which would be unfortunate.

I ask that those working on this grant please communicate internally to see if there's a lower number you can come back to the community with to increase the chance of this grant being funded.

If you can't reduce, I understand, but please let us know that. If you can and others do the same, it creates the opportunity for other projects to be funded as well.

Thank you.
 
Status
Not open for further replies.