Grant Goals / Focus

Secured
#1
We've just (almost) completed another grant round, so I wanted to take the opportunity to discuss my thoughts on how we should prepare for future grant rounds.

Regardless of the price of FCT we're always going to have limited funds for each grant round and its because we have limited resources, that we need to openly discuss what our goals are for the quarter and align our grant applications accordingly.

I understand that we all have different interests and priorities but the reality is that with the limited resources we've got, that it isn't going to benefit us to continue building out Factom into multiple different niches, that we would be much better off focusing as a community on the opportunities that are going to give Factom the best chance of success.

I also really feel like we need to openly decide what our short and medium-term focus is for Factom. Should we be focusing on attracting new investment? Should we focus on enterprise adoption? Should we focus on mainstream usage? Or should we be putting more focus into PegNet?

I would love to hear what your ideas and vision are for the future of Factom and see some consensus between us. This is our opportunity to build something unique :)
 
Secured
#2
Thanks for starting this discussion, Keith. I agree that we should try to orientate our efforts so that we're all pushing in the same direction. We could perhaps take some inspiration from Tezos, who release RFPs once every 3 months that define specific needs of the protocol.

Right now, I believe PegNet is our best chance to deliver a successful application for the protocol and to (continue to) burn a meaningful percentage of FCT inflation. As such, I believe we should ask for grant proposals that advance that goal.

Additionally, I would like to see proposals that are able to build on the foundational work we have done in other areas, such as DIDs. I believe this was brought up at the previous grant round, and I agree wholeheartedly with that position. I'd like to avoid starting anything new right now unless there is a very compelling reason to do so.

Finally, I think one of the big elephants in the room, both in past grant rounds and during the last week, is core development. We have invested a lot into core dev now, yet I am concerned about the continuing instability of the protocol. I am interested to know how others feel about this. How should we approach future funding?
 
Secured
#4
These continued core dev salaries masked as grants are a terrible idea for an ecosystem that is increasingly resource-starved. We’ve already had to cull marketing, what’s next?

So yes, focus is key. Last August, I stated:
We’ve reached a critical juncture where, given current restraints in price and grant pool size, we must wonder if we should approve certain grants by default, or if instead we should be selective in the overall theme of a grant round and the quarterly workload that follows.

Culture has progressed to a point where no one’s willing to halt all core dev altogether, so how about we introduce actual competition?

My proposal, plain and simple: limit core dev funding to an x amount of FTE per grant round. That way the various core dev parties (Factomize, Sphereon, Inc) can genuinely start competing to put in the best offer and the protocol will pay the most favourable price.
 
Secured
#6
I agree we should be focusing resources into short term gains. PegNet has proven to attract people in, and already offers more than most protocols worth billions.

The mining alone has the ability to prop up the floor price at these levels when we scale up.

I was expecting many PegNet grants this round for wallets etc, but nothing was there. A beautiful trading platform for pFX would bring in a lot of outsiders to blockchain for the first time. Being something they already are familiar with, yet removing the thorn from their side of slippage and fees.

That’s an amazing business for someone who can bring it to market.

We need to bring value to the World, and it’s through applications that non-crypto users can pick up and benefit from. Apps that are easy to understand.

Let’s build a PoC for Payments with PegNet; Perfect for micropayments. Make a live action video and wow people.

Integrations have proven slow to adopt, as you’re totally relying on another party putting in the skills, and making a significant investment and risk to build software.

We need to build the entire solution and sell it off the shelf. So yes, I think we should get behind PegNet as it has the power to propel the protocol into the top of the charts.

Then build another. Take a large established industry like FX trading, or I’m doing with eSignatures, and build it from the ground up with blockchain.

As shown, you don’t need even a working protocol to attract mass investment. You just need to show people the future. So let’s show them a world of applications made far more efficient with Factom.

If standing parties aren’t willing to do it, then yeah let’s put out RFPs for it. Who’s willing to build us a FX trading platform with some financial and tech support?

We need to turn FAT and Identity work into products. Capitalise on these investments and technology we’ve made. Not sit back and wait for someone else to hopefully find it and start building.
 
Secured
#7
I’ve almost gone to set up a group to work on a FX trading platform, but I’m just so stretched right now. I’d call on people like Paul to consider putting together a working group to build this, as a business for themselves. They’d have my support during grant rounds, knowing that the protocol will benefit hugely from it. I’d gladly help with design work, and marketing content.

Or the protocol could wholly own the trading platform and pump revenues back into the grant pool. Let’s do it! It would also unite and incentivise the ANO set again. Imagine having a startup with 20 diverse co-founders? Delivering the world’s most efficient trading platform for a $5trillion daily market. What’s stopping us? Let’s come together and build this product ASAP.

We can incorporate a for-profit company in US and look for VC funding together.

The point is, we need people building businesses - not just infra that is invisible to anyone outside of Factom.
 
Last edited:
Secured
#8
Losing core devs means killing the protocol. The protocol is a technology product, if you do not have a core development infrastructure to service that product then you are relegating it to a stagnant status that will decay. This usually happens in a very mature product that an entity is happy riding out the last years of service of a product.

This doesn't mean that sometimes you don't have ineffective developers, or that you aren't focusing your development resources appropriately. Keith is absolutely right to point out that we need goals and focus. Any product manager will tell you that. I think collectively we should decide our top 5 priorities of core development and ask the hard question of are grants going to those goals?

I'm worried that the networks stalls are going to start negatively impacting pegnet's shine. We have a testnet, which Tor and others have recently taken to upgrade to be more like mainnet. I think we should beat the heck out of testnet. I believe when we load testnet, it is currently in a controlled environment just to try to get max transactions per second. I think it could be beneficial to have some scripts that put more stochastic loads on testnet that are running continuously. Any destabilizations of the testnet can be inspected and hopefully resolved. I'd much rather have testnet go down 10 times in a quarter because we are abusing it if it means we find 1-2 bugs each quarter that might have brought down mainnet.

I think its also reasonable to ask if there are enhancements to the protocol that will bring greater stability, then spec out the stages or steps that are needed to complete the enhancement. Then identify a timeline and execute. This is all pretty basic project management.

It is also reasonable to expect developers to be held accountable, but the road map needs to exist for devs to be held accountable.
 
Secured
#9
Losing core devs means killing the protocol. The protocol is a technology product, if you do not have a core development infrastructure to service that product then you are relegating it to a stagnant status that will decay. This usually happens in a very mature product that an entity is happy riding out the last years of service of a product.

This doesn't mean that sometimes you don't have ineffective developers, or that you aren't focusing your development resources appropriately. Keith is absolutely right to point out that we need goals and focus. Any product manager will tell you that. I think collectively we should decide our top 5 priorities of core development and ask the hard question of are grants going to those goals?
Let's keep talking focus. How much of the grant rounds is going to core development?

Q1 – 34% ( it’s actually 60%, as another 26% was included as backpay for Inc)

Q2 – 42%

Q3 – 45%

Q4 – 59%

This is a problem.

While grant capacity goes down, the relative core dev cost goes up. We all seem to agree that the protocol needs interesting stuff built on top so we actually get some traction and interest going, but our actions don’t reflect that.

What if the price drops another 40%? Do we spend 75% on core dev? I want us to be proactive in this, and not sit idly by waiting for better days. Last August, FCT price was a juicy $4 and according to Paul there was no need to limit core dev work, because:
Hogwash. we are at a bottom now, but we're reversing that.

A fledgling protocol needs to be agile in its allocation of resources and not stay married to certain work. Instead it should periodically reassess where priorities lie and allocate accordingly.

Frankly I’ve been very put back by the comments of Niels in this topic and in past topics by Paul. A hostage situation isn't what we need right now. If we don’t pay, devs walk and don't come back? Why is this so black and white? How about you use them to put up other grants, instead? Surely if they can contribute to core code, they can also contribute in a myriad other ways.
 
Secured
#10
Yeah - no one is advocating for removing core dev all together. But to possibly redeploy some of those resources to areas that will have short term gains. When resources allow, we can go back to throwing everything at core dev.

When we look at the positive impact of PegNet, I hope we can all see the benefits of having visible solutions, rather than invisible infra.

Core dev is about the future of the protocol. If we don’t attract investment into the protocol, there may not be much of a future to provide for.
 
Likes: WB
Secured
#11
We believe we should not set absolute values for how much funds goes to core/other.Standing parties should though take this into consideration when voteing and it is also very important to highlight this issue by having these discussion.

reasoning:
- having a set fraction to core/other (or varying with fct price/pool size) addss administrative overhead
- less agility for providing funds where necessary (making changes to process takes time)
- possibly reduces availability of core developers (they need continuity and may decide to not apply at all in future as Niels allude to)
- adds complexity to voting process (already many variables)
- standing parties are the ones that would approve such a system and also the same that votes in actual grant procedure. if they believe it is important they could use their votes to say this during grant voting instead.
 
Secured
#12
Frankly I’ve been very put back by the comments of Niels in this topic and in past topics by Paul. A hostage situation isn't what we need right now. If we don’t pay, devs walk and don't come back? Why is this so black and white? How about you use them to put up other grants, instead? Surely if they can contribute to core code, they can also contribute in a myriad other ways.
It is not about hostage at all. We are a company you of all people know that under Dutch law you cannot just fire people or something. So we have been taking a risk to allocate people to core development. At the same time, we have structurally done that without making money on it. Till this round we have been the only one doing that for core development. So if you think we are going to take more risks on that, you are wrong. It would mean we would have to reevaluate our contributions to this protocol. Till date that only has been an investment and not any profit, contrary to what people might think. Also contrary to what a lot of people might think Sphereon is not really reliant on Factom for it's operations and integrations.

So what you describe as a hostage situation, to Sphereon simply is a calculation, which already is net negative. That is all I mean with not going down a "more competitive route". Take away core development and you kill the protocol. You kill the protocol, a company like Sphereon will have to reevaluate.
 
Secured
#14
Nope. Given we have structurally put more resources and money into every single grant, we regard them the same with regards to funds/people for Sphereon.

We do regard core dev work (either us or others) as being higher priority than most other grants. No core dev should not take all grant money, but with low prices removing core dev kills the protocol. And we do regard that as the biggest risk for Factom. It is too simple to just say, well let's skip core dev for X period
 
Secured
#16
It is not about hostage at all. We are a company you of all people know that under Dutch law you cannot just fire people or something. So we have been taking a risk to allocate people to core development. .
Right. And that's exactly the issue here. So because you've hired people with fixed salaries, at this rate the protocol will pay 60% for core dev at a FCT price of $2.5, 70% at a price of $2 and 80% at a price of $1.5.

Why should the protocol in effect be stuck paying these salaries because your company took on this kind of risk?

And again, what's stopping you from reallocating those people to other grants, instead of all this strong language about killing the protocol if we stop spending the majority of grant funds on core development ?
 
Secured
#17
So please tell me which other entities to date have calculated these risks in their grants.

Reallocating is not as simple as you propose. Core development is something different from the projects surrounding Factom (2nd layer). It is different skillsets, different languages.

As I mentioned core development is the most important development for any blockchain project. I always find it interesting when people that do not know an awful lot about R&D start talking like they do. Anybody in development knows that killing R&D is long term success for killing a project/company.

BTW. Please also tell me which companies in this ecosystem bring actual customers, are doing meetups, doing presentations, talking with governments (both local and central) etc.

Because I can count that on one hand unfortunately

(and to be really clear, I/we do really appreciate all efforts by individuals)
 
Last edited:
Secured
#18
BTW the reason I am mentioning that, is because people can get hung up by what they regard as the "big money" and forget what type of investments are being done. If we look at FCT price, BIF should have been at 0% efficiency most of last year. Instead, we are at 35%, because we believe in the grant system.

Nobody bothers to look at entities that changed their efficiencies because of training core devs, doing projects etc.
Yet we do get hung up about whether a grant is one month late. It is fine to be critical about that. Don't get me wrong. But it would even be nicer if people were a little bit more critical overall.

I think people will have to accept the reality that with the current FCT price, there simply isn't a whole lot to invest into the protocol. It would be nice if some parties did some more for the protocol like they promised to begin with. To me, that is the biggest problem for the success of this protocol.
 
Secured
#19
So please tell me which other entities to date have calculated these risks in their grants.

Reallocating is not as simple as you propose. Core development is something different from the projects surrounding Factom (2nd layer). It is different skillsets, different languages.

As I mentioned core development is the most important development for any blockchain project. I always find it interesting when people that do not know an awful lot about R&D start talking like they do. Anybody in development knows that killing R&D is long term success for killing a project/company.

BTW. Please also tell me which companies in this ecosystem bring actual customers, are doing meetups, doing presentations, talking with governments (both local and central) etc.

Because I can count that on one hand unfortunately

(and to be really clear, I/we do really appreciate all efforts by individuals)
You'll know as well as I do that a lot of companies allocate a fixed % of (forecasted) revenues on R&D over a given period. You'll also acknowledge that a lot of companies have a set breakdown of those revenues and where it needs to be spent. The Factom protocol has none of that and that's what we're discussing here. If we were swimming in money, then sure, throw all that $ around and see where it sticks. But we're trending down. So no, debating how we allocate funds doesn't equal killing R&D. It equals taking responsibility during a time where we're leaving many things unchecked.

I see apathy increasing across the board, and what's really not helping is if every reasonable discussion of a 'touchy' subject is flat-out rejected.

I think people will have to accept the reality that with the current FCT price, there simply isn't a whole lot to invest into the protocol. It would be nice if some parties did some more for the protocol like they promised to begin with. To me, that is the biggest problem for the success of this protocol.
I'm on your side for many of the issues that need addressing. Especially when it comes to pledges and frequent efficiency changes.
 
Secured
#20
I agree with you @WB To be clear I am not rejecting anything regardiing our core dev. It is the standing parties that vote. As I mentioned earlier in this thread. If people do not vote for Sphereon grants including our core dev grant, that is their decision. We will have to decide accordingly if that would happen.

But at the same time I am making clear that you should not expect Sphereon to keep investing as a company in the protocol if core-dev would be stopped/paused and or expect us to do more "competition". We are not reliant on the protocol, but of course we have made investments into it. At the same time It is not like we are sitting and waiting for projects and clients to come in every now and then and/or live of grants or anything. Several other blockchain projects have approached us to do similar things for them.

We can only spent every dollar (euro) once and currently a decent percentage is going to resources and open-source projects for the protocol, as well as Sebastian, Maarten and me putting their time into the protocol, meetups, workshops, presentations, conferences etc. IF standing parties decide to stop core-development, we simply cannot count on everything working out.

This is not to threaten, be unappreciative to others, create pitty or whatever. It is pure business for Sphereon, as we still put the company before the protocol ;) It would not be smart as a company to just ignore anything in a direction that threatens survival of what you invested in.