The Factom Protocol is demonstrating pretty solid stability. At the same time, we are really hurting for resources, and we are competing with protocols that have done some pretty good marketing.
This is the time to do a clean rebuild of the Factom Protocol. We have the opportunity to build on...
We are looking to change the governance and make other changes to Factom. We should also consider changing the tokenomics of the protocol itself.
At this time, we have pretty simple rules. The crowd sale produced X number of tokens, early token buyers, developers, and contributors were issued...
Here I have layed out the logic behind combining the grant determination: https://factomize.com/forums/threads/factom-inc-24-protocol-development.3416/post-28433
The fact is we did actually deploy something close to the resources one might expect from the first grant. The second grant is...
Doc 005 - ANO Election and Demotion system
Paragraph 2.3 reads
Proposed wording:
On this point I am unclear what the downside of not updating standing would be. If their standing ended, that would certainly impact the ANOs and their would be social pressure to correct the matter, that...
Doc 005 - ANO Election and Demotion System does not actually detail what is done with support provided by an ANO or Guide (a standing party) when a standing party leaves their position early (removed or resigns).
Most of the time in other election systems, votes are cast in an election, and...
This post has not been updated in a year:
We need to update this thread. Can we get ANO's and everyone who wants exposure in this post to provide their updates? Here is a google doc, and anyone that asks can get edit privileges.
The Factom Protocol has a number of issues in its current implementation that limit the transaction rate that the protocol can support, and that lead to instability issues. Factom Inc. has been discussing and considering ways to address these issues. We want to publish our thoughts here, and...
A number of grants are missing this clause as required per Doc 153 4.4.1
I'd suggest that we allow the impacted grants to amend their grant proposals, as I am not a great fan of rejecting work on technicalities.
I did give feedback (hours before the deadline) on most of the grants that are...
Continued Discussion on this grant because the discussion was cut off prior to its natural conclusion
In the next three months, I think you will only have your two nodes. While the vision of of ANOs contributing (unfunded?) nodes to Open Node, andvisions of K8s clusters triggering rolling...
The document governing grant round 3 (first grant in 2019) Doc 153
The formal discussion about Doc 153 which will be locked on 19 January 2019
All the grant rounds are pretty important, but here with Doc 153 we are adjusting processes that may set up expectations for following rounds. This...
Here we are talking about people that wish to contribute to the Factom Project as developers, writers, testers, or anyone else that may be able to provide new code, documentation, data files, etc. to be checked into a FactomProject repository.
Steps:
Setup a Github account
Clone the...
The goal is to onboard core developers outside of Factom Inc. At a minimum this involves:
Establishing how bugs and issues are reported
How security or sensitive bugs and issues are communicated
How to propose, review, accept, and implement feature requests (non-forking)
How to propose...
We need a clear specification to implement the initial grants. I am going to suggest a 12 step program:
For the first 3 months, the grants are denominated in FCT and paid out monthly
A specification for Grant Digital Identities (GDIs) will be defined by June 22
All Grant recipients will define...
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...
Also need to change the indemnity clause, since it has no limits on the grantee, effectively meaning the grantee has unlimited liability to protect the parties of the protocol against anything, related to the grant or not. Here is the clause:
What it should be is something like:
Limits...
I believe the existing community needs to have some discussion about grants, and set some expectations. I fully expect that many of us have not considered the trade offs that come from tight/formal oversight vs loose/informal oversight, public oversight processes vs centralized oversight...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.