Calculating available FCT in grant pool

Unrestricted Public Thread

  • Viewed Guides Nikola Nikolov Shuang Leng Tor Paulsen
  • Not Viewed None
Secured
#31
@Stake Capital adding 50% maybe safe but it still adds risk and complication. When time and resources are stretched thin is it really worth having a pool value that is open to interpretation every grant round? Is 50% still going to be safe in future grant rounds if a number of ANOs decide to change their efficiency or will we end up having future conversations about what the % should be?

At present grant, payments are hard-coded and require server updates. Requiring multiple updates per grant round is going to be time-consuming for everyone involved with a small risk of something going wrong.

It would make more sense to try and squeeze out as much FCT from the pool if grant rounds occurred every 6 or 12 months but 3 months simply isn't long enough for the additional effort required.
 
Secured
#33
@Stake Capital adding 50% maybe safe but it still adds risk and complication. When time and resources are stretched thin is it really worth having a pool value that is open to interpretation every grant round? Is 50% still going to be safe in future grant rounds if a number of ANOs decide to change their efficiency or will we end up having future conversations about what the % should be?

At present grant, payments are hard-coded and require server updates. Requiring multiple updates per grant round is going to be time-consuming for everyone involved with a small risk of something going wrong.

It would make more sense to try and squeeze out as much FCT from the pool if grant rounds occurred every 6 or 12 months but 3 months simply isn't long enough for the additional effort required.
The additional effort is just to make a simple calculation (i.e take the estimate of FCT added the last 22 days and multiply it with a buffer value (for example 0.75). This is how we have done it the previous rounds and it has worked out ok with no added overhead really.

I do however agree that "solution A" might be best for the long run; but taking "a hit" in this grant round of making 30k FCT unavailable is not a good option as the round is quite oversubscribed and we want to get as many good projects up and running as possible - as quickly as possible. Thus moving slowly towards "Solution A" to spread the hit over multiple rounds (3) is the best option in my book.
 
Secured
#34
Again, this is nothing more than a simple accounting issue.

As long as there is a transparent UI showing the accounting (Factomize will likely create this as it's needed, especially to keep track of the non-disbursed grants) then it really doesn't matter if a calculation is off a little because of a pause or ANOs lowering efficiency.

1. Factoshi has API data that tracks the amount of new FCT into the pool per block based upon ANO efficiency.
2. From there's it's pretty simple to tap into that API and perform basic accounting and if you go into the negative due to some unforseen circumstance, it's not the end of the world. Yes, I like the idea of a small buffer so it happens rarely, but it truly isn't a big deal if it does.

Screenshot 2019-05-05 at 9.34.33 AM.png
 
Last edited:
Secured
#35
My thoughts are as follows:

- We know that Option A is less risky from a legal and accounting standpoint.
- We know that unforeseen events can happen (Efficiencies changing; Network issues).
- We know that the 22-day period of time can yield variable FCT amounts available due to the point above.

However, pragmatically speaking, a similar process has happened in the past in prior Grant rounds, where a certain amount of FCT's were withheld and deferred to the future Grant round, and it didn't cause any major issue (as Tor mentioned above). In the end, all Grants that won funding were awarded funding.

I think the sliding scale solution of .75, .50, .25 bridges the possibilities of what could occur very well. It allows for a small "buffer" of 25% not included this round that is deferred to next Grant round, and it preserves 75% of the 22-day generated FCT's as available for this round (yielding more development in a faster timeframe than purely going with Option A). And, it eventually does end up in Option A after a few Grant rounds. Thus, while I see the possible problems that could arise, and have some reservations based on legal/accounting possibilities, largely, I am in favor of the sliding scale solution.

However, I also exercise caution based on Nikola's example provided earlier in this thread. Introducing complexity and potential for variability as it relates to money does create some risk. In the end, I think that the most pragmatic solution is still the sliding scale solution, and I personally believe that we are achieving close-to-consensus at this time.

I would love to read a couple other opinions on this matter, but I think the majority has expressed preference for this solution as it aligns near-term development and progress with risk reduction in providing a sliding scale buffer over the next few Grant rounds.
 
Secured
#36
Again, this is nothing more than a simple accounting issue.

As long as there is a transparent UI showing the accounting (Factomize will likely create this as it's needed, especially to keep track of the non-disbursed grants) then it really doesn't matter if a calculation is off a little because of a pause or ANOs lowering efficiency.

1. Factoshi has API data that tracks the amount of new FCT into the pool per block based upon ANO efficiency.
2. From there's it's pretty simple to tap into that API and perform basic accounting and if you go into the negative due to some unforseen circumstance, it's not the end of the world. Yes, I like the idea of a small buffer so it happens rarely, but it truly isn't a big deal if it does.

View attachment 1443
Yeah, I think this is the right answer. We should be maximizing the amount of funding available instead of leaving ~$200k-$300k on the table because of an overly conservative calculation.
 
Secured
#37
1. Approximately 1397 FCT go into the pool per day at current efficiencies.

2. There will be 24 days in May where FCT continues to be disbursed or 33,528 FCT.

3. A 25% buffer would give us an additional 25,126 for funding grants and 8,382 FCT safety margin.

4. It would take EIGHT ANOs going from 50% efficiency to 0% efficiency to remove that buffer.

5. It would take a 6 day pause of the network to remove that buffer.

And even if something substantial happened and the buffer was fully realized, as my accounting above shows, it's not a big deal.

Buffering for a 6 day pause or eight ANOs going to 0% efficiency is too conservative.

Let's build this ecosystem. I propose a 10% buffer. Pay out 90% of the estimate.
 
Secured
#38
As long as there is a transparent UI showing the accounting (Factomize will likely create this as it's needed, especially to keep track of the non-disbursed grants) then it really doesn't matter if a calculation is off a little because of a pause or ANOs lowering efficiency.
I agree with David. As long as the reference value is not a static value but a calculation method/a dynamic value, in my opinion there is no risk distributing the maximum available FCT in the pool. We could even show the real-time value and the forecast value with a disclaimer ("based on the following assumptions...blabla"). Blockchain is all about accounting actually. So no cheat is possible ; everyone can check the total amount available in the grant pool.
Really do not think there is a risk here as long as you tell people the method you will consider to calculate the available FCT (which is basically the FCT in the grant pool at a certain point of time).
 
Secured
#40
What is the timeline for coming to a final decision on this?

While I'm biased, since Factomatic has submitted a grant application this round, I still want to say that I'm strongly against a large buffer being set aside (and by large I mean 25%). The grant round is oversubscribed, there are a number of essential initiatives such as core development, marketing and 2nd layer applications that we need to be supporting and building out now, so let's not be unnecessarily cautious.

As a few people have said, this is clearly an accounting issue.
 
Secured
#41
The main rule that would break the protocol is if the outstanding coins were more than the inflation schedule. I think everyone agrees on that. I don't really see this as a legal issue but rather how we transition into an automated system, and the risk associated with things going wrong if efficiencies are changed. (network stalls can be compensated for by just keeping the expected activation block height when the total is calculated.)

Eventually the grant stuff will get automated through the blockchain, at which point there won't be any wiggle room. We are bit of a ways from that.

There are a handful of grants awarded that haven't been paid out, like bug bounties, etc. That is being tracked with a spreadsheet now, but hopefully it will be a forum thing.

In order to prepare for automation, I would like to get to the position where right before the voting for grants the amount is locked in. That means getting to the Option A. To me it is a matter of how quickly we get there. I like @Matt Osborne's proposal of 0.66 of the way this round, then 0.33 the round after that.
https://factomize.com/forums/threads/calculating-available-fct-in-grant-pool.1934/#post-14800

but taking it slower like @Tor Paulsen suggested will work too. We likely won't get to automation of this magnitude in the next 6 months, so the .75 then dropping 25% twice proposal will fit the bill.
https://factomize.com/forums/threads/calculating-available-fct-in-grant-pool.1934/#post-15178

This seems like a good plan to get us from here to there without disincentivizing the effort to build the protocol we are seeing.
 
Secured
#42
The main rule that would break the protocol is if the outstanding coins were more than the inflation schedule. I think everyone agrees on that. I don't really see this as a legal issue but rather how we transition into an automated system, and the risk associated with things going wrong if efficiencies are changed. (network stalls can be compensated for by just keeping the expected activation block height when the total is calculated.)

Eventually the grant stuff will get automated through the blockchain, at which point there won't be any wiggle room. We are bit of a ways from that.

There are a handful of grants awarded that haven't been paid out, like bug bounties, etc. That is being tracked with a spreadsheet now, but hopefully it will be a forum thing.

In order to prepare for automation, I would like to get to the position where right before the voting for grants the amount is locked in. That means getting to the Option A. To me it is a matter of how quickly we get there. I like @Matt Osborne's proposal of 0.66 of the way this round, then 0.33 the round after that.
https://factomize.com/forums/threads/calculating-available-fct-in-grant-pool.1934/#post-14800

but taking it slower like @Tor Paulsen suggested will work too. We likely won't get to automation of this magnitude in the next 6 months, so the .75 then dropping 25% twice proposal will fit the bill.
https://factomize.com/forums/threads/calculating-available-fct-in-grant-pool.1934/#post-15178

This seems like a good plan to get us from here to there without disincentivizing the effort to build the protocol we are seeing.
Thanks for the response @Brian Deery. Can you also provide the exact number of FCT in the pool set aside (bug bounty etc)?

I have actually changed my mind slightly and would like to support using a factor of 0.9 to maximize the FCT made available to the community. As you mentioned now, if we lock the payout block a network pause wouldn't matter either, and only, very unlikely, efficiency changes could create an issue - but we have ways to solve such an outcome as well.

---
@Guides we have all (I believe) supported the use of the 0.75-factor so far for this round.
I propose that we go with 0.9 instead ref what I wrote above and the discussion in #governance-chat.

What do you other guides think?


Edit:
Some numbers:

Right now (the day of the FCT-amount announcement) the pool sits at 107 661 FCT.

With the current efficiency 1397 FCT are added to the grant pool daily.

By 1st of June (the payout date) another 30 734 FCT will have been added for a total of 138 395.

This is how using the factors 0.75 and 0.9 compares:
107 661 (todays amount) + (30 734 x 0.75) = 130 771 FCT
107 661 (todays amount) + (30 734 x 0.90) = 135 321 FCT

For the 0.9 alternative there is still a buffer of 3074 FCT (minus FCT set aside for bug bounty etc).
 
Last edited: