USD vs FCT denominated grants

Secured
#1
I posted this in the "Grant Expectation" thread, but best I can tell, this generated near zero discussion. So I am putting this here hoping that @MattO , @Niels , @DChapman @quintilian @briandeery @Luap @Legalbadger and others would try and discuss.

What I have tried to do is boil down the pros and cons of either denomination as honestly and completely as I could
  • Arguments for FCT denomination:
    • Easy to code
    • Gives an Incentive to grantees to support the token price with their work
    • Keeps Grants relatively short in duration to manage currency risk
    • Easy to manage (payments are unambiguous)
  • Arguments against FCT denomination:
    • The value of a grant none the less must be understood in dollars or other real world currency no matter what
    • Currency risk to over pay or under pay a grant
    • Keeps Grants relatively short in duration to manage currency risk (yes, this really is both a pro and a con)

  • Arguments for dollar denomination:
    • Easier budgeting for the grantee
    • Can be used to support grants over longer periods (since payments will track the market)
    • Makes more sense to people comfortable with dollars or other real world currency
  • Arguments against dollar denomination:
    • We can't really denominate in dollars to eliminate currency risk:
      • FCT will be scheduled for payment a week before the tokens are actually issued
      • Once the FCT is transferred, there will be time required to liquidate them
      • Currency risk If an OTC trade is used by a grant recipient, funds will need to accumulate to the point that an OTC trade can occur, since OTC desks almost always have minimum trade limits. Limits of $20,000 to $100,000 or more are common
    • If the IRS sees that the scheduled payment occurs a week before the coinbase transaction, they might assert the tax event marking income occurs on scheduling the payment, not when the payment actually clears
    • An Oracle is required to determine what tokens should be issued. This means a harder programming task than simple issue of FCT.
    • The Oracle that dictates the trading price of the FCT token becomes an attack vector for the grant system
    • Supposing a grant is denominated in dollars, the grantee will have limited exposure to the token price and misaligning incentives
    • The grant pool must maintain a reserve to guard against currency risk, and that reserve can eventually fail no matter what
    • Grantees and the Community may question the conversion rate used to issue FCT
      • Grantees may call for indemnification from currency risk, i.e. go back to the process to get tokens to make up for a large swing down in the market.
      • The Community may call for indemnification from currency risk, i.e. call to reduce future FCT payments to make up for a large swing upwards in the market.
If I am missing points to be made, let me know and I'll update this list. But we should discuss!
 
Secured
#3
Hi Paul. You lay out the pros and cons well. What are you looking to specifically discuss? Are you trying to gauge if we will support only denominating in FCT so your programmers don't have to worry about implementing USD methodology?

Were any grants specifying the amount they need in USD rather than a set amount of FCT? I don't remember seeing any but may have misread.
 
Secured
#5
I just reviewed the grants and understand what you're saying. These will be lump sum payouts, correct? When I initially reviewed the grants the idea that stuck in my mind was at the time of hardcoding you do the math, figure out how many FCT that is, and set that number of FCT to be disbursed. I don't see how it's viable to guarantee that amount of USD.
 
Secured
#6
@PaulSnow Apologies for slow response. Been on the road.

Here's my big concern with pricing grants in FCT (it's actually playing out now):

For this example, let's assume the project costs $20,000 and FCT is trading at $20.

1. Projects are budgeted in a base currency such as USD
2. For a $20,000 project, that means 1,000 FCT ($20,000/$20 FCT) are needed
3. If FCT stays at this level, then everything goes off without a hitch. However, that's not how crypto works :)
4. If FCT falls 50% after the grant has been approved but before grant payout, then all the sudden this project is only funded to the tune of $10,000. However, they need $20,000 to complete. That means they either take a loss or they go back to the grant pool and ask for more. (what's the process for even adjusting a grant??? I'm sure it wont be simple). However, the main point I am trying to make is that if the price of FCT falls after the grant is issued, then the grant receiver has an insurance policy built in because they will most likely just get more FCT from the grant pool in order to account for the FCT price drop. If you want to use finance terms, they are long a free put.
5. But what if the price of FCT goes up 50% in the meantime? Is the FCT going to the grant going to get reduced? I highly doubt it. In finance terms, the grant receiver is long a free call option.

So, to wrap it up, if the FCT price goes down, the grant receiver is 100% covered by the community since the community will make the grant receiver whole. However, if FCT goes up, the grant receiver gets 100% of the profits and the community gets nothing. In a way, it's loosely the same idea as privatized gains and socialized losses.

If the downside is capped, then the upside needs to be capped.
If the downside is uncapped, then the upside can be uncapped.

But, you can't have the best of both worlds (capped downside and uncapped upside) :)

*For longer term grants (multi-payout grants/monthly payout grants), pricing grants in USD alleviates the FCT price fluctuation issue as much as possible.
*For shorter term grants (or single payout grants), I am fine with pricing in FCT assuming the grant payout will happen relatively quickly (1-2 weeks).
 
Secured
#7
Of course you have problems with timing as noted above, which you've ignored. First of all it takes a week to actually issue the tokens, so you still have currency risk. Then on top of the week, you have potential delays before the tokens Can Be liquidated.

Then you're tying up 2 times the tokens to keep the Grant denominated in USD. So right now, whenever the token price is really low, we have half the tokens that we can actually use.

On top of this, is the liability that the oracle Master takes on, as they provide fct / USD conversion rates by the factoid Entry Credit address stuff. Unless we pick a different party to take on that risk. This liability comes from just the grantees who might feel that they have been abused by either the USD to fct exchange rate, or the payment timing.

I'd rather, as you suggest, just put the Grant in fct, then come back to the community and discuss.

Another point we brought up above, is that if the grant is denominated in fct, then grantees are incentivized to ensure the fct price goes up, and they are hurt buy a falling price. If in USD, then if the price goes down a grantee is rewarded with more tokens, and if the price goes up then the grantee is punished with less tokens.

I'm not sure why we need to give grants to people who are not provided incentives that are aligned with the community.
 
Secured
#8
Of course you have problems with timing as noted above, which you've ignored. First of all it takes a week to actually issue the tokens, so you still have currency risk. Then on top of the week, you have potential delays before the tokens Can Be liquidated.
*I didn't ignore, my last sentence said I'm fine with pricing short-term/one-time grants in FCT if it will happen relatively quickly (1-2 weeks).
*There's a big difference between a 2-3 week delay and a 20 week delay (e.g. grants that want the amount of FCT to be set 6 months in advance). These are two vastly different scenarios.

(Going forward, it probably makes sense to talk about short-term/one-time grant payments and long-term/multiple-payout grants.)

Another point we brought up above, is that if the grant is denominated in fct, then grantees are incentivized to ensure the fct price goes up, and they are hurt buy a falling price. If in USD, then if the price goes down a grantee is rewarded with more tokens, and if the price goes up then the grantee is punished with less tokens.
No one is rewarded or punished. They would be receiving the same amount of FCT in USD terms no matter if the price of FCT goes up or down. Furthermore, they would still be receiving FCT at the end of the day.

I'm not sure why we need to give grants to people who are not provided incentives that are aligned with the community.
*Instead of asking for 1000 FCT, they are asking for "$X" worth of FCT. (e.g., asking for $10,000 in USD at today's price of $10 would be 1000 FCT). They will still own FCT.
*At this point, grant recipients are also ANOs. So, I'm not really sure how you can say their incentives aren't aligned. They want to grow the protocol. Do you have concerns about ANOs? I'm actually really excited about the caliber of ANOs we have.
*There's a non-profit legal grant priced in USD that just got approved. Are you saying the people that will execute this grant don't have aligned incentives because it is priced in USD??? And because we aren't profiting??? I'm sure those of us that stepped-up and are donating our time for free for the betterment of the protocol will love to read that.

So, to wrap it up, if the FCT price goes down, the grant receiver is 100% covered by the community since the community will make the grant receiver whole. However, if FCT goes up, the grant receiver gets 100% of the profits and the community gets nothing. In a way, it's loosely the same idea as privatized gains and socialized losses.

If the downside is capped, then the upside needs to be capped.
If the downside is uncapped, then the upside can be uncapped.

But, you can't have the best of both worlds (capped downside and uncapped upside) :)
I feel like this part of my response was glossed over... Can you please directly answer why it is ok to have a system similar to socialized losses and privatized gains? Thanks
 
Secured
#9
@MattO An issue I see occurring from pricing grants all in USD is that if the FCT price takes a large dive, there would be a problem if the protocol awarded $x amount of funding for various grants but no longer had enough in the grant pool to cover all of the grants. If denominated in FCT, the protocol can be sure not to come up short of resources after awarding grants since there will be an exact amount available for grant funding.
 
Secured
#10
Hi @Hotday29
It's an issue either way. If my project needs $20,000 (so 200 FCT at $10/FCT), but price falls 50%, then all the sudden I am underfunded. I now only have $10,000 (200 FCT * $10/FCT) for a project that requires $20,000 to complete. I can't complete my project without going back and asking for more FCT. Therefore, the grant pool would need to keep FCT in reserve for scenarios like the above.
 
Secured
#11
Hey @MattO I think the argument can be made that the grant wouldn't "need" to keep FCT in reserve for those situations because the grant was never in USD terms but instead in FCT and the protocol/grant pool would have fulfilled its obligation by providing the full amount of FCT. Obviously on the other hand, grants having fewer resources than originally anticipated in problematic as well, but I don't see that problem being solved by denominating grants in USD. FCT denominated grants at least prevent the protocol from being liable for not following through with grant awards and leaving projects without the promised funding. This is a rough one as both options have considerable problems that can occur.
 
Secured
#12
Let’s up this thread.

On my mind there are 2 cases:

1) grant recepient is doing something by himself or partially by himself + hire additional people (e.g. developers)

Examples: Factom Inc. dev grant, BIF dev grant

In this case grants should be only FCT denominated — it’s better to the Protocol because off no market dependance.

Let’s imagine we have few dev projects in next round that all denominated in USD and at current $6/FCT whole grant pool is going to be spent on this elected projects.

Then whole market and FCT accidentally loses 30% (as we already saw this summer), and we have approved grants and not enough grant pool cause USD denominated. It may be the problem.

Another one argument to set 1) as strict rule:
Such grant projects (made by grantees + hired people) are for the Protocol improvement -> Grantee and community are aiming to expand Protocol or it’s usage with such grant -> so there is no one reason to liqiuadate whole grant after receiving, better to save it -> so there is no one reason to have such grants USD denominated

2) grant project is fully made by third-party

Examples: Legal Review by third-party company

This case is quite simple: third-party usually works for fiat and budgets in fiat.

So in this case there can be 2 options (no strict rule):
A. USD denominated grant for paying third-party
B. FCT denominated grant for paying third-party (if third-party agreed with payment in FCT)


I suggest Guides and community to discuss this ideas and possibly set it as grant pool rules. @Niels @quintilian @briandeery @Julianft @SamuelVanderwaal @PaulSnow
 
Secured
#13
Hi @ilzheev

First I want us to remember that once the grant pool is set up properly, we can be at a point where there is no difference between USD and FCT denominated, unless you have a milestone payment grant. The issue surround this last grant round was that there was something like a month and a half (dont remember exact amount) delay between approval and issuance of the grants. That will not be the case once a grant system is set up. If I need 50k USD to do my project, and fct = 10$, in the time it takes to review and vote on the grant (maybe a week?), it is very unlikely that we will have the same thing that happened last time, which was a drop from around $15 per fct to near $5. So in that case $ denominated is pretty much the same thing as FCT denominated.

Now the case of milestoned payments. I believe that this is a far better method for larger grants. It allows the community to watch over the grant as it progresses and make sure the grantee is actually accomplishing the goals, and it makes it far harder for the worst possible scenario to occur: someone running away with a large grant payout.

Now, often overlooked, is that our Governance Document itself specifically indicates that this should be the case, and specifically indicates that these should be $ denominated.

Doc 001, Section 4.1.5:
For complex efforts, grant awards will be issued on completion of milestones specified in the grant proposal. When a grant has multiple payments, 2x or more of the tokens should be set aside to manage currency risk (falling or rising FCT values) that might cause under paying or over paying the grant.

While the wordage here is poor, this clearly indicates that according to current Governance, large grants should be awarded in a way that is broken up, and where the grantee will receive less tokens if the price of FCT increases, and more tokens if the price of FCT decreases (thus the 2x FCT pool to make sure you have enough), and this is definitionally pegging grants to a $ value, not a FCT value. So we do in fact have governance guidelines in place already, they simply were not observed last grant round due to hardcoding the grants.

Section 4.1.5 also solves your issue of not having enough FCT to pay out if we accept grants totaling X FCT and do not have enough FCT to fulfill that due to a large value swing, unless that swing is greater than a 50% loss. We should, though, include something in governance or grant submissions themselves to deal with that case, as we should have as few easily spotable holes in governance as possible.

Now a last thing to address, because we can of course always change our governance: I dont think we should in this case. Doing work costs a certain amount of money. If a grantee receives a grant for lets say 250k for a huge project, and ends up only getting 150k, we are asking the grantee to either cover the extra 100k themselves, or suffer the consequences of not delivering on a 250k grant in their standing. This takes most projects off the table, those are simply not conditions that many businesses will be willing to work under. On top of that, I think we should be pushing large grants to go for milestoned payouts. We cannot force that on grantees without protecting their downside (lets say grantee planned on liquidating immediately to receive the 250k so they could be sure they would complete the project).

What I propose is that we handle small grants the way we were before, FCT denominated is the same as $ denominated so thats fine. For large grants, we break them up into milestones. This does 2 main things, 1) It protects the protocol from bad actor grantees, and 2) It allows the grantee to choose between A) being paid out a set amount of FCT at each milestone (This option would be utilized by grantees that have the capital to deliver on the grant even if they receive less FCT, and want to risk it and lock in capitalizing on any potential upside if FCT value goes up during the course of the grant work), and B) being paid out a set amount of $ at each milestone (This option would be utilized by grantees with stricter budgeting requirements such as hiring outside developers, grantees that want to play it safer, or grantees that do not have the capital to deliver on the grant if they do not receive the full grant value. Option B could even be an expandable window model, where a grantee can say that they want for example a 20% funding stability (Hard cap say at 50%, the current governance doc numbers). In the case of 20%, the protocol sets aside 125% in FCTs of the value of all future payments to the grantee. If there is a currency value drop, that first 20% drop in FCT value is suffered by the protocol as it is covered in full by the funds set aside, and any additional drop in value is suffered by the grantee. On the otherhand, if the price of FCT increases by 20%, the grantee will only receive ~83% of the FCT they otherwise would have been awarded and will suffer the lost upside there, and any additional FCT gain after that is suffered by the protocol because it has to hand out more $ value of funds than was requested by the grant. (For clarity, this means that anything between a -20% price swing and +20% price swing, the protocol will pay out exactly the amount of value in $ requested by the grantee). This allows Grantees to tailor exactly how much risk they are willing to accept for the given upside they are targeting, and should be fairly easy to implement in the future grant system.

This is a little more of a response than you might have been asking for ;), but I'm curious to hear what peoples thoughts are on this approach.
 
Secured
#14
@Julianft Agree that USD grants are needed for milestone projects with multiple payments.
If we would able to reduce total time between application — discussion — voting — payments to 2-3 weeks, it would be perfect.

Like Application — Day 0
Discussion — Day 1-14
Voting — Day 15-17
Payments — immediately after voting ends (via voting-on-chain mechanism).

Btw, does voting-on-chain allows to automate payouts after voting ends? @Alex
 
Secured
#15
Havent't read the whole thread yet, but want to correct something about the BIF grant. BIF has stated from the start it will only hire outside devs in the starting period, since the risks with Dutch labour laws would be too big for BIF to hire employees from the start. Given the prices of FCT that has proven to be the correct choice. So according to your arguments we should be in the latter case and not in the former @ilzheev ;)

And the client has been made at a loss BTW. It means we had to divert development power from projects that would be making us more money. That is the risk you take with FCT denominated grants. You have both the potential upside and downside. I believe FCT denominated grants should make up most grants btw :)
 
Secured
#16
@ilzheev

Adding automated grant payouts requires the voting protocol to be integrated with coinbase transactions, which is not in the scope of the current grant. However, the team are aware that this is a very important use case, so are keen to implement it sooner rather than later.

Note that automating grant payouts will require modifications to factomd, and that is on Factom Inc.
 
Last edited: