Grant Discussion Factom, Inc. Inter-Grant Continuity Plan. Dec -> Feb

Secured
#1
The Factom, Inc protocol development grant for maintenance and improvement ended on December 9, but we have been progressing forward with the maintenance efforts so far. We would like to continue until the next grant activates. This document floats some ideas to test community buy-in for upcoming grants. We would like to get back on track to future-looking grants, which means two development grants in the upcoming grant round.

One would be a continuation grant reimbursing us for the maintenance and improvement work currently being done at risk, but which we feel is important, so we are continuing our efforts for now. We would like to use this time to get a jumpstart on the long process of refactoring for scalability, among other things. We would like to operate with anticipation of submitting a grant requesting about $56,800 in FCT per month in the next round.

This will be paired with a second grant, for a future time period, scaled by the appetite for core development at the time. This will get back to the position where the community determines in advance how much development is needed which is how we suggest proceeding going forward. If urgent maintenance is not needed, then time will go into improved scaling/stability.

For the round 2 grant, it turned out that Factom, Inc overestimated community appetite for core development. This interim continuation grant process would be operating at a reduced capacity from the development effort that we have been operating at. The next grant round would have 6 instead of the normal 3 Factom, Inc. grants. More details are in the attached PDF.

The goal at this point is to get some community buy-in to the Inter-grant continuity plan. If it seems like there is sufficient consensus that this plan for the 6 grants to get caught up with the grant cycle is acceptable, then Factom, Inc will feel comfortable dedicating resources towards improving the protocol until then.

If this plan seems like something that is acceptable to the community, please make it known here.
 

Attachments

Secured
#2
I strongly support this general solution.

Filling in the gap between grants for the oracle and anchor master grants to me is basically as clear as doing the same for the guide grant. These should be at the same rate, only truncated to whatever the timespan is.

For the development grant, from what I have seen I believe the work being done on the protocol by Factom inc justifies this given price point. I also believe that continuing to stabilize and scale the protocol is the most critical task right now. We actually have a protocol here that can scale while maintaining a high degree of decentralization of consensus, and can do it now, so lets show that.

The one thing I still need in order to support this and future inc development grants is for inc to provide more public details on how to integrate outside developers into the development process, and to provide a roadmap (we can even start with a non-time based roadmap just to understand how we are going to progress forward) that we can unify as a community around, and that we can reference when talking to investors, clients, partners, etc. This is absolutely critical and will maximize our ability to push this protocol forward, and I do not believe it will even take that considerable of an effort. I believe these items should be requirements over the next couple of months to receive this grant.

Does this seem reasonable @Brian Deery ?
 
Secured
#3
I'm happy to provisionally support all 6 of these grants. Confirmation depends on the content of the final grant proposals.

For the round 2 grant, it turned out that Factom, Inc overestimated community appetite for core development. This interim continuation grant process would be operating at a reduced capacity from the development effort that we have been operating at. The next grant round would have 6 instead of the normal 3 Factom, Inc. grants. More details are in the attached PDF.
I think there has been a serious misunderstanding here. Factom Inc did not overestimate the appetite for core development. I'd be happy to give the whole grant pool to core dev if that is what is needed. The primary issue with your last grant was that no one understood why you had asked for the figure specified in your grant proposal.

In your attached PDF you state that the community has reached a new level of fiscal responsibility. I agree. Asking for some insight into why you need the amount specified is a facet of that fiscal responsibility. It is also an issue of decentralisation. If Inc is awarded money without specifying what you need it for, then I seriously question whether Inc is "just another ANO". In my eyes, it would indicate a privileged position in the protocol.

As many ANOs stated in the previous Q&A for your grant, this would simply be a case of saying "we have x FTE developers being paid y". This is from the budget section of the BIF core development grant:

15,000 FCT for salary and overhead for 2 developers (2 FTE) for 3 months
3,500 FCT for recruitment and US education/trip
TOTAL: 18,500 FCT (74K dollar at current price of 4$/FCT, with 60K dollar subsequent proposals)
That's all I wanted. It's not a large or onerous task. It is information that you should already have readily available. This is what we got in the budget section of your previous grant:

Due to the complexities of managing currency risk and balancing the priorities over such a wide range of tasks, we believe the grant should cover 3 months for a total payout of 70,000 fct.
It tells us absolutely nothing other than how much you want. Do you understand my complaint? The problem is not the amount of money or what that money is being spent on, the problem is the the proposal itself.
 
Secured
#5
Factom was awarded 50k FCT based on $4/FCT. At time of payout this was $15, and spent the week between $14-18 in monstrous volume that could have easily been sold into several times over. Even today at $9, it is still over double the amount requested for the work.

As the largest grant recipient, I’m interested in your comments regarding using the extra value of your award ($500k) to transition into the aforementioned forward-looking grants, rather than writing it off as a lucky break.

To me, requiring an interim to cover this gap, especially talking about the risks of continuing to develop, seems a bit misplaced when your previous grant has always and continues to remain at least 2x valuation.

To put it another way - Would you really down tools and stop working on core development without a further injection of cash, whilst sat on a $300k-$500k windfall from a .... core development grant?
 
Secured
#6
I show the current price of FCT as $9.13. Would you be willing to lock in the price of $9.13 now so that we know how much FCT will be
I agree this could be very good. That means 6,221 FCT per month no matter what price we are looking at in a couple months. If Inc would accept that solution I think I would support that, it let's everyone plan better which is very important.
 
Secured
#7
Echoing Julian's sentiments, I would also like to see a roadmap or some sort of plan that would show a path towards integrating more developers into the ecosystem. Right now, from my perspective, we have a bit of a bottleneck as the Community's/ANO's plans to move forward with planning, sales pitching, and marketing are somewhat (or perhaps, totally) reliant on Inc.'s development progress. Adding more specialized labor, from outside of Inc., with the intent to develop, would further decentralize the protocol, would probably reduce legal risk, reduce our likelihood of having FCT classified as a security, and would provide our ANO's with a stronger case to make when planning ahead with prospective clients.

I think that the Inter-Grant Continuity Plan, as it is written and presently contemplated by me (as a Sponsor for Inc.'s Development Grant), is sound and fair -- assuming Inc. is willing to lock in the present FCT rate as mentioned by David Chapman, above, for the equivalent amount of $56,800 USD per month. The second development grant (that would be a forward-thinking and forward-acting grant), will also be important, and I support the idea. Information as to how many FCT's are to be requested at that time and the "appetite" for development can be discussed at that time, but in general, I am in full support of these grants along with the Oracle and Anchor catch-up grants and forward grants.

Tl;dr - I would love to see a roadmap or some sort of plan to bring in outside developers into the Factom ecosystem, I would prefer Inc. to lock in the present FCT rate (roughly $9.13 per FCT), and am in support of all 6 Grants as I currently interpret them.
 
Secured
#8
Speaking as a guide I am for supporting this interim development grant, as well as the anchoring- and oracle ones. This support stems from the fact that these grants are now offset from the rest of the grant schedule.

I also believe we should go along with David's idea and have the price locked in now to provide predictability for the next formal grant round. This is also in line with how the rest of the grants are calculated; i.e before the work starts.
 
Secured
#9
Grant #1 Factom inc locked their FCT value at the grant payout. Your grant went from something like 1.4 Million to about 400k because of currency fluctuation.

Grant #2 Factom inc locked their FCT value at the grant proposal. You locked in 4$ and could have received anywhere from 14-18$.

With this grant proposal I am somewhat understanding that the position of Factom inc is that is fine to under deliver when the price crash and to bank the windfall when the price pumps ? And then ask the community for more money in the mean time ?

Why can't you use the 500k windfall to support that developing effort until the grant round?
 
Secured
#10
There seems to be a huge disconnect. At no time did the community not have "an appetite for core development." We all wanted this as evidenced by the BIF core developer grant passing with flying colors. Let's also not forget the $1.5 million grant that was given to Inc also.

Here are the issues:
1. The first grant was for $1.5 million in FCT and had all sorts of deliverables in there. We came nowhere close to achieving these. So, the community obviously thinks to itself, "What the hell did we just pay for? This has all the hallmarks of an FCT grab."
2. So, the next grant round rolls around and the community asks Inc for a clear set of deliverables and resources that will be provided. Basically, the community wanted to know what we were buying. Totally reasonable. We never truly received a sufficient answer.
3. Additionally, the community feels the sponsors were unable to provide clear reports

So, to sum it up: Deliverables were not delivered, we had no idea what we were buying, and there was a lack of transparency.

The solution is really simple:
Give us true deliverables/an accurate amount of man hours dedicated to the project and be transparent so we can measure the success. This is completely reasonable. It's disheartening we even need to have a conversation like this.

If Inc can do the above, then we are 100% in support of a continuity plan. If not, then we will not be supporting this endeavor. We really hope Inc chooses the former.
 
Secured
#11
You locked in 4$ and could have received anywhere from 14-18$.
I sincerely think we need to move away from that thinking. Using that kind of thinking forces grant recipients to cash out their fct positions if fct price rises, else risk the community believing they are failing their grant because they are not achieving at the level of the inflated value of the pop in fct price. I'm not sure if we want to set up a system that forces recipients to feel like they have to cash out if there happens to be a pop in price at the wrong time. If a recipient can deliver their grant work no matter what, I want to incentivize holding onto the fct, both for market effects, as well as long term funding for ANOs activities if the protocol grows in value.
 
Secured
#12
I sincerely think we need to move away from that thinking. Using that kind of thinking forces grant recipients to cash out their fct positions if fct price rises, else risk the community believing they are failing their grant because they are not achieving at the level of the inflated value of the pop in fct price. I'm not sure if we want to set up a system that forces recipients to feel like they have to cash out if there happens to be a pop in price at the wrong time. If a recipient can deliver their grant work no matter what, I want to incentivize holding onto the fct, both for market effects, as well as long term funding for ANOs activities if the protocol grows in value.
Agreed. We need to stop trying to apply conventional models to a new technology in its infancy. The reality is, when the price of FCT craters after a grant round, under current circumstances, some grant recipients are not going to be able to produce as much. And sometimes grant recipients will receive a windfall which two weeks later may turn into less of one. We need to stop focusing so much energy trying to apply models we're used to to this situation and realize it's imperfect but it's going to improve over time, so let's move forward. Quickly and with agility or we're going to find ourselves beaten and beaten badly.

And this doesn't just apply to grant payouts but everything in this ecosystem. We need to continually move forward, improve, refine, rinse and repeat. AND FUCKING FAST.
 
Secured
#13
@Matt Osborne

Absolutely agree. I think saying that we dont have an "appetite" for core development is really missing the point. We just have an appetite for well planned, administered, and reported core development.

I do believe thats getting better over time though. This document does have some more specific things they want to accomplish laid out in it, but ya it should be more.

Ultimately, and I'm sure its the same for you and most others, I don't understand why this process is as hard as is has been. I want a set of deliverable that can be accomplished, and then a report of what was accomplished to compare against. I would be much more happy and understanding of that even if not all the deliverables were accomplished than I am to continue with the level of clarity we've had.

That being said, I do truly believe that incs work right now on the protocol is worth that 56,000, so @Brian Deery can you give any greater clarity, or tell us where we're missing it if we are, and bring the sponsors into this thread to discuss what their perception of this fill-in grant is?
 
Secured
#15
@Matt Osborne , for Inc.'s Grant, with relation to your #3 listed above, we (Sponsors) felt that Inc. should communicate their technical reports and updates to the community, and that our role would be to verify that information by acting as witnesses to Inc.'s work via weekly meetings with Inc. I can say that it is sometimes hard to report on Inc.'s work because the majority of it has been maintenance-based (as Brian mentions in his Inter-Grant Proposal). We also are not privy to any confidential or NDA-level information, so our knowledge is no better than anyone else's; the difference here is, as Sponsors, we do get first glances at community updates, maintenance/technical logs to be posted publicly, and personal insight/context by speaking to and with Inc.

The funds awarded in the the original (first) Factom, Inc. Grant were sent to Inc. because the greater community and ANO's had faith that Inc.'s development work would be largely accomplished -- or, if not accomplished, the assumption was that Inc. would still work to meet the expectations of that Grant. I agree with you that it is totally reasonable to have originally expected Inc. to accomplish what they set out to do with the initial funds (1.5M in FCT doled out) requested, and that their progress (regardless of fault or intent), relative to the payout, is not in accord with the spirit of the original (first) Grant proposal.

However, it may also be true that Inc. simply didn't realize how arduous and time-consuming the Development work would be. Inc. hit a lot of snags on the way with maintenance issues, stalls, and bugs, and these were unanticipated problems. Inc. has also mentioned, in our conversations with them, that over the years, they have contributed over 10M in protocol development --- while I cannot independently verify this, I can give them the benefit of the doubt...I also realize this prior point (about the 10M) is not relevant to the actual Grant and payout from an apples to apples POV, but the info, itself, holds some historical weight.

@Brian Deery Still, the frustration here from the community towards Inc. seems warranted to me, and I think that this is a tough situation, because Inc. wants to be properly compensated and incentivized, and the community feels somewhat duped. I think that something akin to what @Alex mentioned with a simple (here are the man hours, specific people, costs, and duration) would be a reasonable step in the right direction.

Theoretically, another issue from a lack of transparency, that could arise, is that Inc. could intentionally slow their protocol work down in order to secure more and more grant funding over time. While I am in no way insinuating Inc. is or would do this, the possibility, with lower levels of transparency, becomes more possible. By having a simple, hard-detailed explanation about hours and pay relative to labor performed, we would all feel much more comfortable.

I want Inc. to be incentivized and paid for their work, and I want the community to feel at peace with the information and transparency provided. As Sponsors, we work for the community, and I want to find a constructive, mutual, and fair solution to end the ambiguity and confusion on both sides of the table.
 
Secured
#16
@Niels Klomp , when you have a moment, could you please provide an update on the recruitment of the two (2) core developers to be hired, per BIF's "Factom Core Development" Grant? The developers to be hired were alluded to above, and I'd really like to hear any information you may have about the hiring and on-boarding process.

Could you also please comment as to whether there has been any contact or collaboration with Factom, Inc. about the on-boarding or education of these core developers? I am hopeful that BIF and Inc. are working together towards bringing these new guys up to speed. Thank you!
 
Secured
#17
I strongly support the plan for six grants at the next grant round. I will vote for both continuity and extension grants for Anchor Master and Oracle Grants at the next grant round as those are no-brainers in my opinion. I will additionally support a continuity grant to cover Factom Inc's current development efforts at the stated price of $56,800 per month, as long as we define what FCT price we are locking that at. I'm in favor of using the current FCT price as others have suggested.

Regarding protocol development, I can't speak for the community, but I think Factom Inc has actually underestimated my appetite for core development. I don't have any priorities that rank higher in my ordinal preference scale for the Factom (R) protocol than maintaining a stable network, refactoring the codebase for performance and to set us up for scaling, and the actual implementation of scaling. I would be willing to vote for Factom Inc and other core developers to receive the majority of the Grant pool for the next year providing the community actually gets what we need out of it. If we can take the Factom (R) protocol to the next level in scalability and stability and truly make us ready to begin onboarding numerous enterprise clients then that's a bargain that is well worth it.

However, this can't just be a blank check to a single ANO. The grants need to have a metric for evaluation and determining that the money is being well-spent and the efforts need to begin to include other Core Developers such as the two from BIF and others who are willing and available. I appreciate the efforts Inc has made over the last few months to increase the visibility of the work its been doing and I also understand that maintenance works such as bug-fixing is hard to predict and can end up taking far more time and resources than anticipated. As such, it may be harder to provide solid metrics for this kind of work. Therefore, I propose Factom Inc further split it's future development grant at the next grant round into two different grants covering the two items listed in the Inter-grant Continuity Plan: Urgent Maintenance and Refactoring for Stability and Scale.

The Urgent Maintenance grant can have a more simple metric, for example by simply specifying an expected FTE and a rate and remain at that fixed amount monthly to cover the anticipated development time. The Refactoring for Stability and Scale grant can have a more involved timeline and whatever metrics Inc and the community feel are required to verify the money is being put to good use.
 
Secured
#18
Sam was more eloquent but I, too, have a very large appetite for Core development work. I personally don't need a lot of detail for Core dev beyond the 5-9 people at 56k per month, especially when I put profit in the equation which I think people tend to forget about at times. I also don't need the grants split up as Sam proposed as I suspect the developers will usually be the same.

All I need is a FCT price to lock the grants in at and Factomize will support these grants.

The reality is, a lot of really good things are happening in this ecosystem. If we're able to refactor and scale in 2019, we're going to be a very serious force to be reckoned with. So let's make it happen!
 
Secured
#19
I agree with most of what’s been said above—I support the plan for six grants at the next grant round, as well as the request for greater transparency in how exactly funds were spent.

My only suggestion is that, in situations like this where a dollar value needs to be assigned to FCT for future reference, something like a 50-day SMA (basically the average token price over the past 50 days) be noted at the time a proposal is submitted. Given the sometimes-extreme price fluctuations of a token, this would create a “smoothing” effect and would allow for more stable benchmarking of token value.
 
Secured
#20
My only suggestion is that, in situations like this where a dollar value needs to be assigned to FCT for future reference, something like a 50-day SMA (basically the average token price over the past 50 days) be noted at the time a proposal is submitted. Given the sometimes-extreme price fluctuations of a token, this would create a “smoothing” effect and would allow for more stable benchmarking of token value.
I'd prefer we locked in the price of $9.13 as discussed above. If the community wants to use a moving average, it should be a 100-day SMA so that some historical prices, rather than just January and February, are taken into account.
 
Secured
#23
Why not let the month conclude and then take the average daily closing price for the month and then divide it by the grant amount? Why does this need to be paid upfront, forcing us to guess? This is a more accurate approach:

EXAMPLE

Month: January
Pay: 50k
The average daily closing price for all days in January is $10.00.

$50,000 / $10.00 = 5,000 FCT

That ensures Inc is not overpaid or underpaid.
 
Secured
#24
Thank you all for being patient during the holidays. I had been composing a single big post over the past week or so, but it now seems better to address the points with individual posts. People's vacations over the holidays was one of the factors that went into the reduced effort over these few months, mine included. Let me see if I can answer the questions adequately.


The one thing I still need in order to support this and future inc development grants is for inc to provide more public details on how to integrate outside developers into the development process
Sure, outside developers are already contributing to factomd. The process is pretty straightforward. https://factomize.com/forums/thread...e-to-github-factomproject-glad-you-asked.992/ Three people have already contributed, and we are anticipating the BIF team showing up and learning/contributing as well.

If you are asking about being educated about how the code works, that has already begun as well.
As far as getting competent on the codebase, that is going to be a long process for any developer that comes along. I have been in that position before on previous projects. It takes about a year to know how the code interacts with itself on large codebases, and factomd is one of those large codebases. This is actually what one of the things the refactor is trying to address. It is fairly convoluted how the different messages interact with the system. By simplifying and compartmentalizing the code it makes it not only easier for the computer to handle it should hopefully make it easier to understand from a human perspective. On the bright side though, is that some sections of the code are fairly compartmentalized, so for a newcomer to just concentrate on a specific feature or subsection is fairly straightforward. The contributions that have come in so far haven't delved too deep into the code, but developers need to get started somewhere.

https://github.com/FactomProject/factomd/pull/620
https://github.com/FactomProject/factomd/pull/626
https://github.com/FactomProject/factomd/pull/616
https://github.com/FactomProject/factomd/pull/598


The contributions that we have seen so far have mostly been for things not on the radar of Factom, inc., thus would not be predicted on a road map. Open source developers will work on things that interest them, in my experience, and that is what we have seen so far. Extrapolating this, it would be hard to predict what interests new developers will have and what they want to work on. It is hard to define a roadmap for people who aren't around and have no idea what their strengths/ interests will be.

There are several different subsections of the factomd code. The code section that interacts with the p2p network is pretty separated from the rest of the code. That can be worked on without having too much interaction with other sections that are being refactored. One of the high level goals is to give the code a little more knowledge of the peers so that the p2p code can have a better handle on identifying abusive peers, and ones that have more bandwidth. Also give the code the ability to have better peer finding, etc.

Another thing that is limiting is the excessive abstractions in the database layer. This was probably something that can be shaved down a little bit. Additionally, the current database subsystem currently handles the entire blockchain, which is fine for now. It can all fit on a single hard drive. Once we start to scale, and the database requires a few terabytes, it needs to be totally reconfigured to handle partial storage (separating out entries and the entry blocks for example).

There are some non-reversible upgrades that are coming up. Things like multisig, and lightning compatibility. There is a change to the entry/chain commit messages which is needed to have better control flows in a sharded environment. The commits were originally designed to optimize privacy for a short period of time to increase censorship resistance, but the effect on a multi-machine environment was not considered. At this point, more thought needs to go into exposing more info in the commits to allow them to be routed better between machines to reduce cross-talk in a multi-machine (sharded) environment.

So, while I can't give a road map for people who have their own interests, I can talk about the mid term updates that factom, Inc wants to work on. This was in the doc that was in the first post in the thread. This is a road map of sorts that is a high level of the current/upcoming effort.

https://docs.google.com/document/d/1MdZCna0ZQZj7LxAU9bgTP1Gf4p8K7AknG9Obsbf3liI/edit?ts=5c19370c

- Create a setup that runs a simulation of a network (5 nodes) and allow our new code to run against this simulation in a separate simulation.
- Remove all code implementing Leader behavior (our code will run as a follower only)\
- Tear down the Follower behavior to implement only the application of dbstates
- Simplify dbstate processing behavior
- Add back message processing
- Create each VM as a separate process
- Route messages to the VMs.
- Move VM related state to VMs
- Create VM states that can be combined to create a DBState


Long term, what needs to be worked on... everything? Whatever is proving to be the closest bottleneck is the thing that needs to be worked on. Right now, message control flow is the bottleneck, and the software getting confused due to that is what we are asking about. This has to do with scale as much as it does about being able to reason about what the code does. It has been a very painful process getting this next release out. A big part of the pain is that the code has so many moving pieces that it cannot be accurately understood where the interactions can go wrong during edge cases and different modes of operation.

You are asking about what will be then next weakness after we fix this one. That depends on how the network will be used and stretched in the future.

Like I am so fond of saying, this is a multi-decade project. It is going to be reconfigured many times over as we progress through the decades. Talking about a roadmap implies a finality, and I don't think that is something we can talk intelligently about.

just to understand how we are going to progress forward ... that we can unify as a community around ... that we can reference when talking to investors, clients, partners, etc
It seems like you are asking for something more in infographic form. (perhaps one literally with a road on it https://bitcointalk.org/index.php?topic=1349965.0) I hope I conveyed properly how non-linear the development is going to be and how much of it depends on specialties/interests of developers that come along, but mostly what the next bottleneck will become. The current bottleneck is that the code control flow is hard to reason about, and hard to adapt to fix things. We have visions of datacenter sized ANOs being devoted to building the blockchain. There are advancements where if a single ANO drops offline (due to natural network delays, which are a fact of life on the internet) that it would only be a small subset of the ChainIDs that would be stopped, and the rest of the blockchain (the remaining ChainIDs) will continue on and the faulting process wouldn't stall out the entire blockchain, just one of the VMs. If this is doable and what tradeoffs it takes hasn't been fully explored. Framing a marketing effort around this would be weird.

From what I have seen in other projects, there are headline banner efforts that people rally around "Segwit, Casper, MAST, lightning", etc but in reality these are not single things, but instead are massive shifts in how people use the system. It's more of a thing for users to say "Oh, I need to change what I am doing because <word developers are saying a lot>. At this point, the thing is refactoring, because that is the current/next effort. A lot of what will be going on in the future will be about reducing the attack surface of the network. That doesn't really seem like something good for a marketing level effort.

The current developery sounding thing being worked on is "Refactoring". There is probably a better developery term for that which is better for marketing, but that is how we have been referring to the effort so far.
 
Secured
#25
The Holidays (unexpectedly) really became some much needed time off from the Factom "storm" of work. I appreciate everyone's support and patience.

We have a huge problem of currency risk that just has no good solution.

To clarify the problem, we have the following issues:
  1. At the time of a grant proposal, the price at the time the tokens will be issued is unknown.
  2. At the time of the payments being scheduled, the price when the tokens will be issued (a week later) is unknown.
  3. The income reported and the taxes due is determined at issuance, and is unknown until tokens are issued.
  4. The value of the tokens when liquidated will be unknown.
We at Factom Inc. (and any other party working for grants) need to justify working for grants to investors. With investors, income matters. The "treasury" (tokens held) value also matters. For regulatory reasons, Factom Inc. is not liquidating tokens until some clarity from a legal perspective forms. Many grantees (and certainly Factom Inc.) are in a long term holding pattern before we can liquidate or even hedge the tokens we are holding. This results in long term risk and reward tradeoffs.

Certainly a stable coin feature in the protocol could resolve almost all of these issues, but we don't have that as part of the protocol at this time.

Many of the other solutions proposed have their pros and cons, and they really amount to betting on what will happen in the future. We have to figure out where we put the risk, and how we ensure that we continue and even grow the development process going forward.

In the end, we need to look at quantifying the risk/reward for Factom Inc. and the community with each proposal. This is done pretty frequently in the market, and might look at futures contracts or insurance for guidance. The point being that we are not the only business or ecosystem that faces these issues.

Some mechanisms that are possible but not discussed (to my knowledge) so far:
  • Carry overs -- Applying previous grant payments to new grants to split the reward of price rises between development and the grant pool
  • Risk payments -- Additional payments to split the risk of price falls between development and the grant pool
  • Long term lockdowns where tokens issued are not liquidated for longer periods (Create long term incentives)
  • Risk margins, increasing grant amounts by some percentage as a payment to take on risk
 
Last edited:
Secured
#26
@PaulSnow -- You ask for $56,800 per month in FCT for these grants. I proposed early in the thread that we lock the price in at $9.13 and later in the thread countered a 50-day SMA with a 100-day SMA for price. If the price was $9.13 and you had exactly two months then you'd receive 12442.497 FCT whether the price was $2.00, $20.00, or $200.00 at issuance (hopefully one of the last two :) ). Would you prefer locking in $9.13, use a 100-day SMA, or some other method?
 
Secured
#30
Thanks @Brian Deery and @PaulSnow for helping clarify things on your side. I agree there's no easy, risk-free solution at this point.

I'm assuming futures contracts are a ways out, and would require overcoming regulatory hurdles? Nothing offered to date from OTC desks or others?

For the SMA option, are there oracles we could use?

It seems there are two sides to this: 1) What carries the least risk? 2) What is the easiest to implement? At the moment I'm trying to get a sense of the second question ...