Funded [BEDROCK-CRYPTLOGIC-DEFACTO-TFA-002] Factom Open Node (ex. Courtesy Node) Continuity

Not open for further replies.
We’re requesting a grant for continuity of operating load-balanced community courtesy Mainnet nodes – — for the next 3 months.
MyFactomWallet is now operational on the Factom Open Node system, and the Factom Enterprise Wallet will default to Open Node in the next release.

Usage stats of Factom Open Node for the last 30 days:
— 588 unique hosts used Factom Open Node
— 594,823 requests were processed


Open Node usage for last 30 days

Changelog: I have uploaded "v2" with the indemnification clause included.


Last edited:
Thank you for your proposal.

This is a generic question I ask in each grant thread.
This is currently the 3rd grant round. I consider that one of the very important criterion to select a grant (apart from its potential value) is the capacity of the grantee to deliver in time what it pledged. Therefore past grants can be used as an indicator.

If you did receive grants in previous rounds, could you please fill the following fields? This would increase transparency and help the standing parties to select grants.

- Have you, or one of your partners, previously received grants : Yes/No. If No, then you can stop here :)
- List of grants received : grant X1 from round Y1, grant X2 from round Y2...
- Status for each grant : grant X1/Still ongoing or Completed, grant X2/....
- Description of the work accomplished so far and Links supporting it : Discord Group/Factomize thread/Github/Reports/...
- Description of the residual work to be completed : XXXXXX

Thank you for your cooperation.
A few questions:

Cloudflare doesn’t provide a splitted stats. So it’s total numbers for both &

But, I have a data from Google Analytics for only:
35 unique visitors within last 30 days
102 page views within 30 days

So, 99,999% of requests shown in CloudFlare — to ;)
The grant does ping Factom Inc. for centralization, when the approach we used does not exclude others from deploying courtesy nodes. This grant does not include a plan for decentralization beyond the 4 operators.

Factom Inc.'s courtesy node is to be deprecated in favor of the ones provided by the 4 operators. This grant should include a plan to retire Factom Inc.'s node, to save our resources.

The idea of promptly updating the software is perhaps implied by maintenance, but not mentioned. Since a courtesy node may operate for a long time without updates, a commitment to updates would be nice.

Some development or improvement plan would be nice.

All that aside, Factom Inc. can support this grant
The idea of promptly updating the software is perhaps implied by maintenance, but not mentioned. Since a courtesy node may operate for a long time without updates, a commitment to updates would be nice.
Perhaps the proposal should be made more clear, but my understanding has always been that we are being paid to administer an up-to-date API endpoint. This means that the load balancer is monitored and adjusted as necessary, and that the individual nodes all deliver the same API. The nodes themselves will have varying hardware specs, but, in terms of the HTTP and JSON-RPC specs, they should all behave the same. Right now, the pool of nodes is small because usage is small, but rest assured that steps are being taken to make scaling the pool painless. My current assumption is that the ANOs running nodes will all be running their nodes in K8s clusters, which should allow for quick changes to replica count and the triggering of rolling updates.

In terms of commitment, it's questionable that the Open Node should become a ragtag collection of donated nodes. There just isn't enough skin in the game for that to translate to an enterprise class service. As the service's usage grows, it needs to scale by 1) having current operators increase their number of nodes, and 2) bringing in new operators. Scaling by accepting random donated nodes won't work. Paying for the service is done via this grant, which will also scale with usage.

What will probably happen is that node providers will deploy their own load balancers to front their nodes, and those load balancers will then be spanned by the central, Cloudflare load balancer. That will allow each provider to scale up or down painlessly, without needing to communicate changes to the central load balancer admins.
Not open for further replies.