Approved Grant Factom Asset Token Protocol

What do you score this grant?


Have not voted

Guides Nic R Niels Klomp

Authority Nodes Consensus Networks Factable Solutions Factable Solutions HashQuark Kompendium Kompendium Multicoin Capital Multicoin Capital Prestige IT Prestige IT RewardChain RewardChain

  • Total voters
    24
  • Poll closed .
Status
Not open for further replies.
Secured
#31
@MattO

Yes! We are putting the specifications into the public domain, and the entire codebase is open source. Our hope is that all ANOs build on top of it. We are already working on a specification with Sphereon to build a graph-based network for use in their application in the netherlands.

We truly believe that this puts us on par with Ethereum for so many use cases, and in many cases makes us better.
 
Secured
#34
Hi @sanchopansa , my apologies, lots of messages flying around.

The FAT protocol is of course something that I would like to build on eventually, Its awesome ;) I do not know Luciap or CL's plans long term for the protocol so I wont speak to that.

Xavier and I have discussed what could eventually be built on the platform. We also referenced in our original release document: https://factomize.com/forums/threads/the-factom-asset-token-protocol.1029/ . With the community moving at such a fast speed, the summit, etc things get lost in the shuffle and are easy to miss. In hindsight, I should have reposted this in this thread earlier as it is part of the FAT discussion. This references a client that we have been negotiating with that is interested in integrating with FAT. They love the technology, but this is a very, very long term project as you can imagine, and depends on the speed of development of FAT. We are still ironing out things with the client, so I cannot make any promises. There is no reason to believe we will be funded from that situation in the foreseable future.

Right now the core people working on this protocol are focused on building out the technology, as well as helping others build out applications on the technology. It seems likely that other entities will be building products on FAT for profit before any of the people listed on this grant have the opportunity to do so.

I hope this answers your question fully. If you have any more please let me know. Thanks :)
 
Secured
#35
I think the backpay issue has cast a shadow over this proposal somewhat. I know that shadow does not reflect my overall feelings about the proposal, which is likely the case for many others too. So I want to make those feelings explicit.

I think this is a fantastic initiative and amongst the most important grant proposals we have received. The calibre of the work being completed and the vision for the project is outstanding. I think it is the most exciting second layer innovation we have seen in the protocol to date. The teams involved are an invaluable asset to the ecosystem.

Factoshi will be voting in favour of this grant regardless of how the backpay issue is resolved. That is not to say that I would not prefer to see a reduction in the quoted value - the protocol is resource-poor right now, so belt tightening is necessary if we are to fund as many initiatives as possible. Nevertheless, I do not believe that the initial sum requested reflects negatively on the teams involved, whom I believe to be fundamentally trustworthy and sincere.
 
Secured
#36
TFA commends you for all your work on FAT to date, we’re really impressed with your work ethic and achievements and we’re excited about the potential it has for the protocol.

We would like to support this grant in its entirety, unfortunately given the competitive nature of this grant round, it’s just not feasible in our opinion. We also echo some of the concerns from others regarding backpay and potential implications that come from that.

However, TFA would like to voice our strong support for any forward-looking work detailed in your grant proposal, and we’ll consider minor additions as long as backpay is excluded. We believe this project to be extremely important for Factom and we wholeheartedly trust you as a team for your integrity and transparency; if you continue to prove to us your capabilities, you’ll have our continued support also in future grant applications.
 
Secured
#37
Thank you for your answer, @Julianft. I think we all agree that this is a great initiative, led by some of the best development ANOs in the community. I have had the pleasure of working with some of the people involved and I know that the project is in good hands.

However, as others have pointed out previously, I find it very hard to convince myself to support this grant as it currently stands. I believe that 40% of the grant pool is a disproportionate amount to ask for and I urge you to revise your offering. For comparison, in the last wave of Ethereum grants, a little over $3M were distributed with the (two) largest grants being $500K, around 17% of the grant pool. You should also consider that the Ethereum Foundation is also not at all limited in resources, in stark difference to our grant pool. I also believe that at current levels the market and FCT have more or less reached a bottom, which makes the potential upside of 57.5K FCT quite big. 57.5K FCT was worth over $1.7M when we were elected as ANOs in April. IMO, centralizing this amount of FCT resources into a handful of ANOs (and predominantly in a single ANO) is not good for the ecosystem at this early stage.

With the grant pool oversubscribed, approving this grant would mean that I believe there is no other subset of projects with combined asking price of less than 57.5K FCT, which would bring the same or more combined value to the protocol. Here's a sample list, which in no way represents any endorsement or advertisement:
  • Guide pay: 9K
  • Marketing committee: 5K
  • Exchange committee: 5K
  • Factom protocol website: 2K
  • Bug bounty: 1K
  • Hyperledger Fabric integration: 2K
  • Alfresco integration: 0.75K
  • Verifiable claims: 1.5K

    Plus any three of the following:
  • FactomMask (12K)
  • Ledger ID (7K)
  • Citizenship App (8.5K)
  • Decentralized Identifiers (8.5K)
Do you honestly believe that the value of FAT is higher than the combined value of all of the above proposals bar one?

If all of the above project bar one are approved instead of the Factom Asset Tokens Protocol, there would still be 2K FCT left in the grant pool. Approving all of those projects instead of a single one, would also benefit the ecosystem as a whole by distributing resources to more ANOs (and committees) and helping them "grow". It is also much wiser from an investment perspective: "betting" all these money on a single project at this early stage of ecosystem decentralization is not a wise idea IMO.

Based on the above, I hope you understand where I am coming from when I say that the grant is disproportionate. I, personally, could not support the grant as it currently stands. If the back-pay is removed from the grant, I will happily consider your updated application.
 
Secured
#38
Approval of this grant would set a nasty precedent where sound financial planning is thrown out the window because any business development is not contingent on revenue and asset growth, but rather all (past) costs are absorbed by the safety net that is the grant pool.

That's something to avoid. As a general statement, if you're setting out to develop a major, cost-heavy project where you are unwilling to absorb any costs yourself, then please reconsider. You're a startup. Assume the risk, and have confidence that your solutions grow the environment in such a way that your current ANO payments create a lot more breathing room to more safely undertake these ventures, while leaving enough room for other grants to get accepted.
 
Secured
#39
We believe there seems to be something akin to a consensus so far in this discussion:

- Almost everyone loves the project in itself
- People are very much opposed to backpay, e.g. having the grant pay for both work that has been done and future work (exceeding more than 3 months in total)
- The sheer size of the grant request is off-putting to many people as it together with the Factom Inc. protocol development grant would deplete the pool.

These last two issues can be rectified by amending the proposal, and our understanding is that this is already in progress ref. Luaps comment over at Discord earlier today.

The above list reflects our own view of this matter, and we would be very keen to support this grant if the grant was reduced to not include previous work done.

And for the record: We are very very big fans of FAT, your teams and the work you have been doing so far, and will support the grant if you alleviate the scope-issues identified in this thread. These are the kinds of projects we want our ANO-efficiency to support!
 
Secured
#40
Nice post @CryptoVikings

INTRO
I'm always a proponent of hard questions being asked. With that being said though, I'd like to take step back and look at this grant from a high level:

DOC 152
Let's put aside arguing about the interpretation or "spirit" of section 4.2.3 in Doc 152. People disagree, so be it. Arguing gets us nowhere on this one. I see both sides. A strict interpretation of the clause means this grant needs to be reconfigured. Therefore, I would like to request that this grant be reconfigured.

TOKENIZATION
This will arguably be blockchain's biggest use case. There are many people that make the case that all assets will eventually be tokenized. There is an estimated $700 trillion in assets world-wide. Can we really afford not to implement tokenization? Do we want to miss out on arguably the top use case in blockchain technology?

Here is a good article from Multicoin Capital. They argue that the blockchain that secures the world's assets will be worth $1 trillion to $10 trillion. Let that sink in for a second.
https://multicoin.capital/2018/10/09/100-trillion/

Here is another:
"As explained in this essay, the chain that secures all of the world’s assets must be valuable."
https://tokeneconomy.co/ether-as-a-store-of-national-security-4746297fbb54


SMART CONTRACTS
While these smart contracts operate differently than a protocol like Ethereum's, smart contract functionality is absolutely essential if we want to be a top 10 project. Right now, I think the blockchain community views Factom (incorrectly) as a dApp. If we incorporate smart contract functionality, we can legitimately make the case that the Factom protocol is just as powerful, if not more so, than the all the other smart contract platforms in existence. Combine that with all the new use cases for end-users this opens up, and smart contract functionality becomes integral.

OPEN SOURCE
This is awesome. As we know, not all development project grants are open source. This one is. Not only that, but they have been proactive in finding clients. Ideally, every single development grant would be open source as well as be able to say they have interested clients.

COST
Yes, 57,500 FCT is a ton. Yes, I hope they revise the number. Fortunately, all indications are that they will revise the number.

In order to get an accurate picture of just what the community is purchasing via this grant, I'd like to see a breakdown of:
*Estimated total hours of work for the next 3 months
*What that equates to as far as developer pay-per-hour

CONCLUSION
I sincerely hope DBGrow, Layer Tech, Canonical Ledgers, and Luciap retool this grant and resubmit, as this project lays the foundation to spring-boarding us into a multi-billion dollar protocol. I think we can all agree that $1,000 FCT would be nice.

Thanks for your consideration,
Matt
 
Secured
#42
@sanchopansa, can't you approve both the FAT grant proposal AND the list of grants you outlined? The total value would be well under the total grant pool size. The reason that is not possible is because you didn't list two other big grant proposals (Factom Inc and BIF). Factom Inc asked for 70k (~50%) and BIF asked for 40k (~28%).

Yet because BIF splits up their grants into different pieces, they don't get hit with the same argument that their proposals are asking for too much. If FAT team splits our proposal into 4 pieces, does that mean we're all good? Similarly Inc grant is way out of wack and have way more backpay padded into their proposal. They're just not transparent about it. But we don't have the same debate in that direction.

If Inc, BIF, and FAT revise their figures, we can fit all three big grants and many smaller grants into this grant round. It is not all on FAT. Lastly, let's not pretend that all grant proposals are equally beneficial to the community. No matter what, we have to make hard choices on which projects will give the best return on investment for the community.

I am not saying anyone is in the right, but the argument used against FAT grant proposal is equally if not more applicable with other grant proposals. For the record, I ranked BIF grants on the top of my list and plan to vote on my rank accordingly. If there are no changes to the Inc grant, I will be voting against it. But I have to point out the inconsistency used in many people's arguments.


@Alex, you have no idea how much your words of support means to us. Not because you said you will vote for this grant regardless of the underlying issues, but because you understand FAT team is not coming from place of bad intention.

Prior to submitting the grant proposal, we worked very hard to put down what is needed to fully execute on our vision. The initial amount was smaller than what was submitted. It was I who asked Julian to increase the number because I feel we are too conservative and leave ourselves with no margin for error. And more importantly I feel that the community will understand where we are coming from consider how important this project is to the community. At times, I feel that I am wrong with that assessment. So your word of support is very much appreciated.
 
Last edited:
Secured
#43
@xavierwjc, I appreciate your reply.

can't you approve both the FAT grant proposal AND the list of grants you outlined? The total value would be well under the total grant pool size. The reason that is not possible is because you didn't list two other big grant proposals (Factom Inc and BIF). Factom Inc asked for 70k (~50%) and BIF asked for 40k (~28%).
I cannot approve both because the grant pool is currently oversubscribed and I view core protocol development and its decentralization as the highest priority for our ecosystem at this stage.

Yet because BIF splits up their grants into different pieces, they don't get hit with the same argument that their proposals are asking for too much. If FAT team splits our proposal into 4 pieces, does that mean we're all good? Similarly Inc grant is way out of wack and have way more backpay padded into their proposal. They're just not transparent about it. But we don't have the same debate in that direction.

If Inc, BIF, and FAT revise their figures, we can fit all three big grants and many smaller grants into this grant round. It is not all on FAT.
I'm neither BIF's, nor Factom's advocate, but as far as I know, BIF is not asking for any back-pay in their grant applications and this seems to be the major pain point for people with the FAT one. I know BIF, as well as Factomatic, will be internalizing some of the costs for our DID application should it be approved, which is in contrast with your current proposal. I also haven't reviewed Factom Inc's application yet, so I can't speak too much about it, but given the amount they are asking for (backpay or not), I assure you that I will raise the same concerns with them.

Lastly, let's not pretend that all grant proposals are equally beneficial to the community
I think this is some misunderstanding, as I haven't said that. The point I was making was that weighted against 11 other proposals, it's difficult to argue that FAT brings more value to the protocol over all of them combined.
 
Last edited:
Secured
#44
Backpay overshadowed this entire thread, but it is also one of the easiest to solve. Once FAT team updates the grant proposal, I think that will become a non-issue. To be honest, when we wrote the grant proposal, the topic of backpay didn't even come up. We spent all of our mental energy projecting future costs. If we (Layertech) do include all of our past costs as part of the application, I can assure you the grant size would have been much bigger. Adam, Paul, and DBGrow team spent even more time on the project than LayerTech so I know for a fact this grant proposal does not include all of the blood and sweat they put into the project past six months.

The bigger issue is that the backpay argument evolved into large grant size where 40% is an arbitrary redline. Everyone knows the grant pool will be oversubscribed. Everyone knows core development is needed from Inc. Everyone knows we need more core developers. And everyone knows that not all grants are equal in its value to the community and we can't approve all grants. FAT team put forth what we think will be one of the best ROI for the community and asked the community to decide. Instead, it feels like we are to blame for the fact that grant pool is oversubscribed and that we are taking money away from other teams. Isn't that the nature of the grant pool application process?? (This response is specific to the 40% arbitrary redline argument and I am speaking on my own mind, not on behalf of FAT team)

I apologize if I sound tense. But after reading and processing everything last couple days, I can't help but point out some of the inconsistencies. And more importantly explain why FAT team feels hurt by this entire proceeding. Again, I'm speaking for my own, not on behalf of FAT team.
 
Secured
#45
I personally like your project a lot and I think it's going to give a great return. I think you have been way more transparent than some and I really really appreciate that.

In voting for this grant it is clear to me the value we get. Beside the two following points I have only kind words for how you handled it so far.

1. Allowing back pay would in my opinion allow for a bad precedent.
2. I am not sure why you didn't come forward with an exploratory grant 3 months ago. Your project is open source and I have a hard time seeing the logic behind keeping everyone out of the loop as it is going to be open source? Are you open sourcing it because you failed to find a good way to monetize it with private money ? Working 6 months in the shadows for something that you planned to open source is very risky considering someone could already have been working on it for private purpose.

Anyway, I think it is going to be a great tech nonetheless and that given the chance could give the protocol a nice boost and would happily support it.
 
Secured
#46
BIF asked for 40k (~28%).

Yet because BIF splits up their grants into different pieces, they don't get hit with the same argument that their proposals are asking for too much.
Just to put this in perspective, the grants from BIF and Sphereon are all different in nature and not related. It’s not an ‘all or nothing’ choice. The community decides.
 
Secured
#47
And to add to that.

BIF and Sphereon are separate entities, that quite frankly do not expect to get "awarded" every single grant. Most if not all of these grants are also being funded by the parties itself and have clients interest in it (except for the core-dev). Sphereon has 2 projects running they didn't ask grants for, because of the sheer size of these projects. We have gone out of our way to make the proposals manageable and give the standing parties full control on what and how to allocate the grants. We have done this because of all the comments on the previous Inc proposal

40% of pool by a single grant is of course possible, but is does set a precedent of sorts. It makes it harder for new talent to join the grantpool with their proposals. We are seeing several "outside" proposals and I really hope we keep seeing that. That in no way gives a negative qualitative valuation to your proposal btw. I have said and will repeat it again. I really like FAT. There is a reason we decided to do the Dutch citizenship app with FAT. Some parts of the Inc development are needed very badly as well. If both grants would be awarded as it stands now the pool would be empty. I do believe that is something to consider when doing that large of a proposal.

My recommendations are (and nothing more than that):
- Split it up in seperate parts, so people can choose.
- See how you can fund part of the development of that size somehow outside of the pool as well
- Get a separate discussion going about any potential backpay. You could even include measurable goals like usage in there if you want

I find it a tad worrying if some ANOs are depending on ANO and grant income mostly. That means a lot of resources will be dedicated to a few parties/developers. That is not healthy for the total ecosystem in my opinion. If prices would drop even further, what would be next? Asking 80%? Again without questioning the quality and how nice the solution is. It means other parties that do split it up and also back the grants with other funds might not get any grants. In the end it is the standing parties that decide of course, but since you also know that it is allowed to vote on your own proposals, it also means for instance in this case that you would have 6/32 parties pro anyway. If one or 2 sponsors would be chosen from ANOs that could even be upped to 8/32. I am not saying that people aren't objective in anyway, but I do not believe people wouldn't vote in favor with rather high numbers for their own grants. I believe that is something we need to discuss anyway (not for this round). Large multi ANO projects already have a strong backing by that same ANOs. One of the reasons why I don't like our current standing only by ANOs and Guides, which are all ANOs as well (except for 2, but that is more of a technical formality).

So to conclude: Yes I would back this proposal from all my roles (Guide, Sphereon, BIF) with some adjustments in the proposal.
 
Secured
#48
@xavierwjc Could you run the below numbers by me btw?
The reason that is not possible is because you didn't list two other big grant proposals (Factom Inc and BIF). Factom Inc asked for 70k (~50%) and BIF asked for 40k (~28%).
I come to a total of 7750 split over 4 projects for BIF with an additional 18500 if you include core development, which of course is direct personel for hire. Every single one of that is either funded by other parties as well or other parties take on risk.
 
Last edited:
Secured
#50
@KiwiWithLazerEyes

Thank you for your guidance here. I agree, there are lots of great grants that I would be sad to see not be funded. In accordance with that, and a variety of suggestions from the community on updating this grant, we will get back to you soon with an updated budget that we feel we can still work with. Thanks again.
 
Secured
#51
@sanchopansa

Thank you for your thoughts, I really appreciate the feedback.

If I’m hearing you right, I think the biggest concern you are raising with this grant comes from a feeling like we are attempting to crowd out smaller grants, is that right?

I’d like to hear your perspective on how you think we should go about incentivizing and funding these bigger projects in the ecosystem. I believe being able to create such projects is very important, do you agree with that? If grants are punished only for being larger and more ambitious in their scope, I feel worried I cannot extend my developer resources and maximize my impact on the protocol. From a more personal standpoint, I feel like if I can’t even ask to do so, and it hurts me and the people I’m working with’s standing in the community to even ask, that we will see a lot less of pushing this protocol forward as people will be scared to push the boundaries. What are your thoughts on this?.

You asked me to evaluate the value of FAT compared to a selection of smaller grants, though I have a hard time comparing the value of a variety of great and very different projects to one big project like the creation of a tokenization and smart contract layer for the Factom Protocol. I want to work fit in as many grants as possible while funding them enough to function so we can create the greatest impact we can for the factom protocol.

Quick question, the math you listed here assumes that the governance ratified grants as well as the full 18.5k BIF core dev and full 70k Factom Inc grant are passed, right?

Thank you.
 
Secured
#52
I also want to reiterate that we don’t think what you put fourth was an unfair valuation of your work. In fact, we know it’s very reasonable. It’s just that we can’t support the back-payment in principle. If you were to add some more future-looking stuff, we would certainly entertain that.

And another note, we don’t consider any one’s standing effected by putting fourth any proposal, especially one as monumental as this. From our perspective, all teams involved have only gained more of our respect and support since FAT was announced.
 
Secured
#53
@Julianft

Thank you for the reply, I appreciate the discussion.

If I’m hearing you right, I think the biggest concern you are raising with this grant comes from a feeling like we are attempting to crowd out smaller grants, is that right?
Similarly to Ben above, I want to start by saying that I do not think you are asking for an unfair amount of money in the application. It's just that at this stage: a/ funds in the grant pool are very limited and b/ IMO we should not make the precedent of back-payment. I don't feel like you are trying to crowd out smaller grants and I definitely don't think your thought process was "Yeah, let's submit a very large grant, such that others can't get in (evil smile)". If this was the impression you were left with when reading my comments, it was not intentional.

My biggest concern really is that there seems to be a big discrepancy between the approach of applicants: some of the operators & committees are submitting proposals where they will be working on shoestring budgets, absorbing a lot of the costs, taking on additional risks, etc. With the grant pool being a zero-sum game, I don't think it makes sense that some entities are internalizing costs in order to submit lower valued proposals while others are asking for a much larger remuneration. I am curious to read how you view this situation from your perspective.

I’d like to hear your perspective on how you think we should go about incentivizing and funding these bigger projects in the ecosystem. I believe being able to create such projects is very important, do you agree with that? If grants are punished only for being larger and more ambitious in their scope, I feel worried I cannot extend my developer resources and maximize my impact on the protocol. From a more personal standpoint, I feel like if I can’t even ask to do so, and it hurts me and the people I’m working with’s standing in the community to even ask, that we will see a lot less of pushing this protocol forward as people will be scared to push the boundaries. What are your thoughts on this?.
I don't think DBGrow's standing (or the standings of other participants part of this proposal) has been hurt from this discussion. At least for me personally, I can confirm that. Why do you feel that way?

I agree with you that creating such projects is very important for the ecosystem. However, I think that the size of the projects that we are funding should grow together with the size of the grant pool, especially in cases where the projects are relying on the grant pool as it's primary source of funding. At this stage, I would rather plant a dozen of small seeds rather than a couple of big ones, as I think that is much healthier for our community in the long run. My suggestions for some possible ways to incentivize such bigger projects:
  • get a research grant as a first step
  • share the plans with the wider community early on in the project
  • look for outside funding
I want to emphasize the second point above: I think if more people were involved in this from the start, some of the costs incurred by DBGrow could have been spread out to multiple entities. I also think that for a project of such magnitude garnering more opinions about the overall design of the protocol can be very valuable. I am interested to hear why you decided not to share it with the community earlier. As it stands, the project is developed as open source -- for which I admire you -- but on the other hand a lot of the major design decisions have already been taken.

I feel worried I cannot extend my developer resources and maximize my impact on the protocol.
I believe this is one point on which our views differ quite a bit. I have nothing but respect for the ambitions of DBGrow and the other teams involved, however, if you want to extend your developer resources, I don't think the grant pool is the place to look for such funding at this point. None of the other development ANOs are doing it and some are paying out of their pockets for development to 3rd parties.

Quick question, the math you listed here assumes that the governance ratified grants as well as the full 18.5k BIF core dev and full 70k Factom Inc grant are passed, right?
Not necessarily if they are approved in full. What I would consider currently as "highest" priority items for the ecosystem would be core development, its decentralization and liquidity. I believe -- at this point in time -- more resources should be spend on those 3 combined than on the development of a tokenization platform. So, even if we allocate "only" 70K to these combined, I am getting to a situation where I have to weigh the FAT proposal versus 15-16 other grants. Considering the current combined asking price of 70K (Inc) + 18.5K (BIF) + 5K (Exchange committee) + 9K (Guide pay) = 102.5K, I think that the 70K I use as a reference here is not unrealistic.
 
Secured
#54
With the grant pool being a zero-sum game, I don't think it makes sense that some entities are internalizing costs in order to submit lower valued proposals while others are asking for a much larger remuneration.
Yes. Precisely.

I'll put it in a way that maybe will point out the contradiction:

We are all working towards the future. We are all working assuming the price of FCT recovers.

The problem I have with very large grants such as this and Incs is that it isn't valued at working towards the future. It is also not covering any real costs, only your time. You don't actually NEED this money. Whereas some projects do NEED the funding to progress.

Now as proven by the fact you aren't liquidating the grant - this is indeed a FCT grab at low prices. Because we are all working under the assumption that FCT rises, including these parties. So we need to convert your $ requested at a reasonable future looking value of FCT. As said above - if this was at the time we were elected - this grant is worth $1.7m - a completely ridiculous amount.

It's ok to value your time at $10k a month - but when you don't need to liquidate and it's just going into your FCT stash - you should all be working off a min assumption of $20 FCT. This both keeps incentives in line and fairly rewards you in the future without harming the grant pool and shutting out other projects who do need to liquidate.

For example - Xavier comparing to BIF's core dev grant is misleading. Because BIF have a real cost to cover, they need to liquidate at todays prices! You are just putting it into your FCT stash for a future price environment. So as thats the case, lets assume a higher FCT price for your conversion?

Particularly asking for money at $4 FCT out a strained grant pool - for a time you were sat around in April conceptualising an idea is absurd and has raised a few eyebrows.

The FCT price is much more likely to recover if we are all working on our projects from a wide array of disciplines to make Factom a global utility. Not just one project.

Approving this grant would mean giving up Marketing, Exchanges, Core Dev amongst others. That's the real cost of this grant to the community - and its simply too much.

The community is pissed off because we all like FAT - we all wanted to support it - but this grant was unacceptable and now we're forced into a corner where we have to vote against.
 
Likes: WB
Secured
#55
I'm just an informed spectator here, but I agree 100% with BobbyEK. I don't know where some people get the idea that being an ANO is somehow an actual bill-paying job by default and that it means their time is always worth FCT. Especially when it negatively impacts the space around them.
 
Secured
#56
@MattO

Thank you for this detailed and thoughtful post.

It occurs to me that the zero-sum nature of the grant process can be very frustrating for all of us. That can lead to competitiveness and resentment at a time when we are all working on shoestring budgets, absorbing costs, and taking risks. We are all doing this in the name of bettering the protocol, but when resources are low, tensions are high. It doesn't have to be like that, but coming together to figure out where the line between what we each need to succeed, and what we want to be able to thrive is a stressful process. I just want to acknowledge that and thank everyone for their patience, input, and discussion so far.

Estimating hours and pay is difficult on a project this big to say the least. Additionally, this isn’t a 9-5 5 days a week. This is a day and night obsession to make the factom protocol everything it can be, and I think many of us can relate to that.

I will try to summarize here though. This reflects the update to our grant that will be presented soon that 1. limits scope 2. Sorts out completed items 3. Limits outside costs 4. Forgoes pursuing additional developers to hire which we were originally seeking to do.

DBGrow
DBGrow will continue to act as the main architect of the FAT protocol. We will work to develop out the ecosystem, developer base, documentation, protocol specifications, and software.

Over the next 3 months, we expect around 47 FTE weeks at just under $40 per hour (probably around $30 an hr actual pay).

DBGrow will be internalizing the difference between that and Market Rate, as well as all costs for the past few months of intensive work on this project. I will be personally covering some of these costs, as I cannot in good conscience pay out less than SF minimum wage for this work.

Canonical Ledgers
Canonical Ledgers will build specifications, and play a large role in building out implementations. They will provide 13 FTE over the next 3 months, and at current estimation that will be $60 an hour so around $50 an hour pay for Adam.

CL will internalize the difference between this and market rate, as well as the work over the past month.

Luciap
Luciap will be working on specifications, building the javascript client, and possibly working on an MVP wallet. They will provide 8.5 FTE, and at current estimation that will be $70 an hour so around $60 an hour pay for Paul.

Luciap will internalize the difference between this and market rate, as well as the work over the past month.

Layertech
Layertech will be building out the ecosystem, documentation, and some regulatory knowledge for us. After travel and legal costs, wages will be negligible.

Layertech will internalize costs over the past few months, and the next few months.


We are now going to be looking for additional outside funding sources that we can fold into the open source development of FAT technologies and expand the developer base for FAT. Thank you for your thoughts.
 
Secured
#57
@mig


Thank you very much. This team greatly values transparency, and I appreciate this being acknowledged.

It seems like many people may feel excluded from the early process we went through to get FAT to this point. I can see now how from the outside, it looks like we have been coveting this project, working in the shadows, not involving more of the community earlier on, not seeking input and approval as we went, and then dropping a huge proposal expecting it to be well received by the community. It's amazing how easy it is to start to lose some perspective when you have been working on something you are passionate about long enough. Perhaps that's where some of my disconnect has come from.

  1. This seems to be the consensus and we will table this conversation for now, though I believe as a general conversation it is one we should have eventually.

  2. Thank you, these are good questions that absolutely should be asked.
    1. It may seem like 3 months ago, but last grant round was actually 5 months ago! Time has absolutely flown by in this community!

    2. As you all may know, the realities of incubating and developing an idea in its very early stages are delicate, and it can often suffer from too much outside input early on. Additionally, given the high caliber of this community, we didn't want to release details prematurely when 1. We didn't even know if it would work and 2. Long before we could test the system I was already getting “why does it not have clients using it” statements (the crypto space can be so impatient). I have been bringing anyone at all who seemed to need such a solution into the fold instantly over the past couple months though, as I really wanted people to start getting to know the system so they could plan to build on it. I also did this to do my best to make sure no one else was working on a similar solution, which was also the reason we announced 6 months ago that we were going to be working on tokenization and smart contracts.

    3. Our motivation for open sourcing this is definitely not because we failed to monetize it with private money. This I promise you. We have always been absolutely dedicated and insistent on building an open source platform for the entire factom ecosystem to use. That's part of what makes it so powerful. Every time I talk to people about using this I pitch it just how I did at the Texas Bitcoin Conference talk where I presented FAT. I push the fact that coming into the FAT ecosystem means coming into the wider Factom ecosystem, with all its the other advantages like Decentralized Identities that can be integrated with FAT and their projects. Everyone I’ve talked to loves this. Our goals in creating this is to push the Factom Protocol to becoming a powerhouse of an ecosystem; we cannot do this in private and we cannot do it without each other.

The great thing is that since this is all completely open source, and with an open development process (FATIP) we can all still have input, while taking the knowledge (and failures) of DBGrows work on it so far :) Do you feel that most of your concern is around us trying to exclude others in this process? I hope the above can help with those concerns. Thank you very much.
 
Status
Not open for further replies.