Process Discussion Factom to upgrade and change into Accumulate Network

Public: Only invited members may reply

  • Viewed BlockVenture Blockchain Innovation Foundation Blockchain Innovation Foundation Consensus Networks Consensus Networks Cube3 Cube3 DBGrow DBGrow De Facto De Facto Factom Inc Factom Inc Factoshi Factoshi Federate This Federate This Go Immutable HashnStore HashnStore Innovative Secured Connection (ISC) Kompendium Kompendium Luciap Luciap Niels Klomp PrestigeIT PrestigeIT Stamp-IT Stamp-IT The Factoid Authority The Factoid Authority VBIF VBIF
  • Not Viewed None

Do we want to upgrade the Factom Protocol and become Accumulate Network, with the listed principles?

  • No, do not upgrade

    Votes: 0 0.0%
  • Abstain

    Votes: 0 0.0%

All votes are in

  • Total voters
    18
  • Poll closed .

Timed Discussion

Discussion ended:

Status
Not open for further replies.
Hi Everyone,

As most people are aware and especially ANOs, a community around Accumulate Network has been working on an improved implementation. This thread is to follow proper governance, as this is the single biggest vote and question the community at large and the ANOs specifically have ever had.

I have held several presentations as Factom Interim director, and my main priority is and has always been to put the protocol first and ensure that we have a fighting change. I have had countless discussions and meetings with most of you, external parties and with Inveniam and Defi Devs.

As presented 1.5 weeks ago to the ANOs and half a week ago to the wider community, I believe it is best that the Factom Protocol upgrades as Accumulate Network, having a rebrand as an automatic consequence. There are parties already interested in using Accumulate Network, and to me this upgrades gives the Factom Protocol the best change at success in the long run. I have attached the last presentation that I gave to the community, which also contains links to previous presentations and analysis.

I realise that there are still details to be filled out, but the question at hand is:

Do we want to upgrade the Factom Protocol and become Accumulate Network, with its native ACME token in the process, with the following set of principles:

  • Hard token cap of 500M
  • Retain the mint and burn model
  • Introduce staking to the ecosystem.
  • Upgrade Activation Block: 30% of supply, 150M tokens
    • 60% to support upgrade participants, 40% for protocol promotion
  • Convert existing Factoids to ACME tokens at a 5 ACME to 1 FCT ratio, meaning 50M ACME tokens will be available after all FCT would be converted.
  • Approximate 300M tokens unissued after Activation Block and Factoid conversions
  • 16% of outstanding tokens to be distributed annually
  • Staking percentage to be decided by the community
  • Switch existing Authority Node Operator resources to support Accumulate Validators nodes.
  • Have parties and individuals step in and help with the build by contributing development resources. The Upgrade Activation Block will include tokens awarded on pro-rata basis according each parties overall contribution to the overall effort in creating Accumulate.
  • Step in and help define the governance model. We have the broad outlines defined but there are details yet to be worked out prior to the launch of the fork.
  • A Factom Improvement Proposal, detailing the requested fork, will be created.
  • ACME supports Simple Token Addresses and Simple Data Chains.
  • ACME will support RC1 signatures on STAs that are built from converting Factoid addresses over, with existing FCT balances.
  • Simple Data Chains will convert with the data scraped from Factom along with timestamps..
  • Entry Credits will not be converted (a total of less than 6,000 dollars).
  • Simple Data Chains will still accept data and converted Factoid addresses will be able to trade ACME tokens.
  • Existing FCT addresses can be imported into Accumulate wallets at any time.


PS. Not really part of this major timed discussion, but just wanted to inform everyone. If ANOs vote in favor, it automatically means I have done my job and would resign as Factom Interim Director. Obviously I will help out with the upgrade, but not from current capacity. If ANOs vote against it, or if we cannot reach consensus then I will continue till the end of the year, with the second best avenue, which IMO doesn't come close to this proposal. In any case I will be resigning in roughly 2 months.
 

Attachments

Chappie

Factomize Bot
This thread is a Major Timed Discussion and I am designed to help facilitate efficient communication.

Only ANOs may take part in this discussion and vote. Unless this discussion is ended early or extended, it will end in 8 days after which a vote may take place. After 18 hours from the start of the thread or any point up until 24 hours are left in the discussion, you can make a motion to end the discussion immediately or extend the discussion beyond it's initial time frame by selecting the pertinent button at the top of this thread. If someone "seconds" your motion, a poll will take place and if a majority of voters vote yes by the time the discussion is scheduled to end, the time period will be extended for 72 hours.
 
I think this is the future of Factom and needs to be done. In my opinion, the most important thing to be done is to change the incentive structure of Factom, which is exactly what Accumulate does. My two biggest concerns, which we've started to discuss in the previous thread are:

1. How exactly control of the new (150M) tokens works - who decides who gets what, etc. I'm worried that, if not managed properly, could result in internal squabbling over who deserves what, worries over inside dealing, and regulatory concerns.
2. Admission as a validator - it sounds like this will be similar to the original Factom admission process to become a validator. I'm worried that this could result in the same governance dynamics (and gridlock) we saw in Factom v1 as well as being a barrier to entry for many qualified entities.

These two concerns will not stop me from voting yes but we will need to make sure they are properly handled as we move forward for v2 to succeed.
 
I highly recommend voting in favor of this proposal. There's no other future for Factom and going for Niels' second best avenue when he's going to resign anyway makes zero sense, because nothing will get done and we'd have wasted an entire year.

Also agree with @Nate Miller - it brings me to the same two points.

1. Control over the 150M tokens.

I want to stay far away from a system where those awarding grants are the same people applying for a grant. It has ruined any ability to keep each other accountable and it promotes self-interested behavior. An alternative is the Director-Council model, but it isn't a legal structure, and so it has lacked enforceable policy to judge performance. It falls back on the same social accountability and it's susceptible to inside dealing. The conflicting interests are simply too staggering and not solvable.

The only serious contender is a foundation with a clear regulatory position and enforceable policy. Policy with a clear charter that puts Accumulate first and with a focus on maximum integrity and minimal conflicts of interest. Alternatively, there's a hybrid model where validators control most of the tokens, but a certain amount vests inside a foundation or gets transferred to a foundation at certain intervals. A foundation then acts as a benevolent entity to protect against unknown actors (Coincheck with a 12.5% stake) and ineffective validators. From a regulatory perspective, this would also mean that the foundation doesn't hold close to a majority stake and isn't the primary 'driving force' behind the whole operation, which is good.

2. Switching Factom ANOs to Accumulate validators

If we end up with validators controlling all 150M tokens (which I'm against), I do not support a blank slate where we simply carry over all existing ANOs. I want more discussion on the vetting procedure. If it's dubious a party should even be a current Factom ANO, then they shouldn't be an Accumulate validator.
 
Last edited:
@Nate Miller @WB

The 150M tokens will be distributed based on participation and investment in the deployment the Accumulate activation block. The process will be transparent, and it is important to get past this vote to get existing Factom interests involved. Inveniam is actively driving and tracking the process at this point. Given their investment, that's likely going to continue through the activation block. The observation is that the decisions will be made by those putting up the resources and the effort in the success of the platform. But we need participation. And I think we all want to reward merit.

Accumulate immediately creates the ability to involve many more validators, and lighten the resources and responsibilities required to be a validator. We should have validators onboarding and offboarding with relative ease. We are going to have staking immediately both for governance and for validation. Data servers will provide an additional path for participation. Participation should be very fluid.

If participation is relatively easy, and participation pretty fluid, I see no reason why ANOs should have any trouble participating and moving over to Accumulate. All current Factom ANOs run their nodes and update their servers. A validator should not be required to do something that cannot be objectively measured, like staking and validation. We should have other roles and other ways to incentivize soft contributions.

We will easily be able to onboard hundreds of participants in the decision making process with Accumulate. And onboard them very quickly. High participation is about the only way to ensure a range of interests being involved in decision making.

The only purpose of vetting is to ensure we are not subject to wealth attacks. We do not need the complexity of ANO elections. easier. And because we are an identity based protocol, vetting will be easier to manage over time. For example, we may be able ro carry vetting forward if participation is not continuous. The process of vetting can be coordinated on chain, and reputation systems are possible.

As far as grants go, we should never allow the protocol to lose all support for development and management of the protocol. We should not neglect the liquidity of our tokens, and community engagement and promotion. A successful protocol needs a diverse set of people supporting and promoting crypto projects and its crypto economy.

Setting up a foundation is an issue independent of upgrading the protocol, and I am sure the value of doing so is somewhere between your high regard for the idea @WB, and my very high skepticism.
 
I'm just a simple holder who has been following the project since 2017. I fully support the project's progress to Accumulate. Under the direction of Paulsnow and the enthusiastic members so far, I believe that this is the only way for FCT's soul to survive and grow.
 
1. I assume that initial 150M ACME will be under control of Accumulate development company’s — DeFi Devs — right?

2.This tokens will not be fully distributed among the community/contributors at the time of hard-fork, but rather will be kept (by DeFi devs?) and will be spent over time?

3. I also point on the lack of efficiency in the current grant system in the Factom and the issue, when node validators vote for grants/themselves often even without having a proper expertise in the topic.

3.1. Do you have plans to centralize grant management / decisions / evaluations to make grant system more efficient and consistent in its aims? Not necessary that only single entity to decide (but it’s also fine), maybe setup a competent committee, but not making all node validators to vote without proper expertise. Keep in mind that many traditional node validators are not developers or marketing people, they just run servers.

E.g. other protocols setup open calls for grants applications on the specific topics (that they wish to have — e.g. bridges/dapps/etc.), choose among many applicants and pay by milestone completions.

3.2. We need to differentiate node validators and contributors from beginning. Node validators rewards depend on their stakes, contributors rewards depend on contributions and are clearly accountable. The same entity can be both validator and contributor for sure, but this roles should not be mixed in any way like it is in Factom.
 
Speaking for BIF as a ANO and for myself as a holder, I see the progression into Accumulate as a very positive way forward into the future.
They bring in experience, expertise, reputation, relationships and the capital to make Accumulate successful.
 
1. I assume that initial 150M ACME will be under control of Accumulate development company’s — DeFi Devs — right?
From a pragmatic perspective, yes, the initial token distribution will be coded up by the developers. We do want to maintain distributed decision making for many reasons though, so they will not be totally distributed based on DeFi Devs' and Inveniam's interests alone. Transparency will be there, and discussions with various participants will be had.
2.This tokens will not be fully distributed among the community/contributors at the time of hard-fork, but rather will be kept (by DeFi devs?) and will be spent over time?
I expect most of the tokens will be distributed, but this is TBD because we are not there yet, and the process will include all participants.
3. I also point on the lack of efficiency in the current grant system in the Factom and the issue, when node validators vote for grants/themselves often even without having a proper expertise in the topic.
Hence the ability to delegate your credit to parties you have faith in will be important. Luckily the Identity structure in Accumulate is very powerful and will able to do this for us. It is important for us to be able to support entities that are capable and not have to participate in every decision.
3.1. Do you have plans to centralize grant management / decisions / evaluations to make grant system more efficient and consistent in its aims? Not necessary that only single entity to decide (but it’s also fine), maybe setup a competent committee, but not making all node validators to vote without proper expertise. Keep in mind that many traditional node validators are not developers or marketing people, they just run servers.

E.g. other protocols setup open calls for grants applications on the specific topics (that they wish to have — e.g. bridges/dapps/etc.), choose among many applicants and pay by milestone completions.
A good bit of this is TBD to the extent that it extends past delegation of authority and accumulated voting power and authority.

It is a very hard problem, and we need to be able to experiment and improve over time. Luckily this can all be done on chain but with off chain but transparent code bases.
3.2. We need to differentiate node validators and contributors from beginning. Node validators rewards depend on their stakes, contributors rewards depend on contributions and are clearly accountable. The same entity can be both validator and contributor for sure, but this roles should not be mixed in any way like it is in Factom.
We definitely want to have validators that are responsible for validation, data server validators responsible for the historical record, developers responsible for development, and other softer off chain tasks responsible for what they sign up for.

Mixing responsibilities with running authority nodes and the efficency thing all made for a muddled mess. It was cool and unique in some ways, but didn't get us what we expected.
 
Like @WB I too strongly recommend this proposal for the reasons outlined in the previous thread.

I think there are a few primary considerations, none of which are deal breakers but are things we should work through:

  • Allocation & distribution of tokens.
  • Initial validator selection

I am concerned that the token distribution is as broad as it can be. We may run a risk of allocating too many tokens to a "closed" community of developers and early contributors which in turn may end up with too much influence and almost replicate some of the original challenges Factom has had.

Validator selection needs to be as objective as possible with clear requirements established. This should shortly be followed by some sound measures on dashboards/leader-boards so that a diverse group of token holders (possibly with staking pools) can delegate stake to capable validators. In this way we get away from the subjective assessments of the past and select/reward validators based on merit.

Ultimately though we need to get on with this and I wholeheartedly support @Nate Miller's proposal that we clearly identify everything that needs to be done, resource appropriately and use some project management disciplines to bring this to fruition.
 
Like @WB I too strongly recommend this proposal for the reasons outlined in the previous thread.
Thanks, and I do as well. But to your other points:

I would push back on one theory common in our community, that the token distribution was weighted heavily 'to a "closed" community of developers and early contributors' Or more simply, Factom Inc.

Were too many tokens allocated to Factom Inc? Not really. In the Genesis block Factom Inc. got 200k tokens, or less than 2.5 percent of the tokens issued. That grew to as much as 10 percent before things went off the rails for Factom Inc.

What Factom Inc. did have is investment capital. Unfortunately Inc did not have the critical mass of industry actors that could push the protocol forward, and Inc invested too little in development resources to resolve technical issues once deployed (which later drained the protocol's development budget).

What we are proposing is a strong technical sponsor in Inveniam, one with revenue of their own, but whose interests are deeply tied to the technology in Accumulate. And as far as the protocol is concerned, we have embedded into Accumulate all the technology that proved to have traction with Factom (around identity, organized data, and organizational modeling). We stripped Factom cool cryptographic ideas that complicated the code and didn't gain us market, like our unique consensus algorithm. Accumulate leverages industry "standard" consensus (tendermint) and side chains to get the scaling and rapid transaction clearance we now know the market admires and rewards.

We all believe the governance of the protocol should be simple, transparent, distributed. If there was an obvious path to doing this in a way that makes all happy, I'd do it in a second. In the mean time, we need to make sure decisions are merit based, transparent, and represent the people that contribute resources AND deliver value to the protocol. We want a low but secure bar to become validators. We would like many more validators, stakers, and such that participate in governance.

And we want to work with the community, even past this vote, to achieve the dream we have shared.
 
Last edited:
I would push back on one theory common in our community, that the token distribution was weighted heavily 'to a "closed" community of developers and early contributors' Or more simply, Factom Inc.

And we want to work with the community, even past this vote, to achieve the dream we have shared.
Hi Paul,

Thank you for your response,

Mine was not an observation about the historical position of Factom but more of a concern about the future proposal whereby a majority of the 150m tokens in the Upgrade Activation Block go to upgrade participants. On reflection given that there will be a further 350m tokens subsequently released and that a number of tokens will get distributed through sales on exchanges maybe this concern will be short lived.

I do endorse your sentiment that we should work together to achieve the dream that has been have shared and look forward to being part of this.
 
The Factom protocol lacked accountability and had too many conflict of interest situation when it came down to the grant system.

I agree with the general sentiment that we need a process surrounding the grants that is more robust than what we had. A general council, guide or a director are all good avenues as long as these 2 initials concerns can be fixed

Will vote delegation be built-in at the very launch ?

How many validators are going to be needed to boot strap Accumulate ? From what I understand, all validators are going to be on the same footing with the same responsibilities?
 
Last edited:

Chappie

Factomize Bot
We are now 18 hours into the discussion. You may now make a motion to extend this Major Discussion by an additional 72 hours or end this conversation by selecting the pertinent button at the top of this thread. This option will end when there are 24 hours left in the discussion.
 
I expect most of the tokens will be distributed, but this is TBD because we are not there yet, and the process will include all participants.
So to be clear, the intent is to distribute 60% out of 150M to contributors at the time of the fork, leaving 40% for promotion through whatever grant process we've agreed on. This may be obvious, but I want to make sure everyone's on the same page to understand the scope of this grant discussion.

Is there a list of contributors you can share with us early, or say with the council? Even if it's just the current draft.

Not necessary that only single entity to decide (but it’s also fine), maybe setup a competent committee
We need to look past having a single party calling any shots if we don't have the tools or involvement to enforce performance standards. Ideally, we'd have had experience with a new grant process over the last nine months, so we'd have something tangible to evaluate and see if it fits inside Accumulate, but we don't, and that illustrates my point.

The same performance issues can be true for committees or guides, by the way, or any system that primarily relies on social accountability (the community holds roles accountable, versus actual legal power to enforce, e.g. in a corporation/nonprofit). Though I'd consider them sooner than a single entity at this point, because Accumulate will have better on-chain tools for reputation management, but it's hard for me to visualise what that might look like in practice.
 

Chappie

Factomize Bot
Anton Ilzheev has made a motion to extend the discussion. If someone seconds this motion by selecting the button below, a vote on the motion will start.

A majority voting yay will pass the motion and the discussion will be extended for 72 hours. This motion will remain open until the normal discussion period ends or a motion to end the discussion is passed by a majority.
 
@Anton Ilzheev Is there a specific reason why you are making the motion? We have not seen any discussion since almost a week!

I am totally fine to be clear, and don't want to rush things. Typically we use it if there is more to discuss, or if we are not in agreement about something. Unless I am mistaken I do see questions being asked and not every single details will be clear for everyone, as that is part of this process. On the other hand I also don't see any glaring issues at present that would warrant the need for a motion.
 
@Anton Ilzheev Is there a specific reason why you are making the motion? We have not seen any discussion since almost a week!

I am totally fine to be clear, and don't want to rush things. Typically we use it if there is more to discuss, or if we are not in agreement about something. Unless I am mistaken I do see questions being asked and not every single details will be clear for everyone, as that is part of this process. On the other hand I also don't see any glaring issues at present that would warrant the need for a motion.
I misread the bot's message as "18 hours left", sorry.
 
The Factom protocol lacked accountability and had too many conflict of interest situation when it came down to the grant system.
Accountability in a grant system is a hard problem. No grant system public or private does this the way many want it done in Factom.

The confusion is between grants and projects. With projects done by organizations like governments and businesses, a highly controlled process exists to fund and manage the projects. You have clear centralized control, clear processes to vet and approve projects, well thought out statements of work, funding, resources, timelines, and defined specifications for success. The goal is to deliver in the context of a high expectation of success.

In grants, the process is mostly a "Hail Mary" pass into a crowd of issues. Funding is granted to very high risk efforts often to mostly new or small teams that operate independently and with minimal oversight.

Grant systems have high failure rates.

Projects are features of centralized organizations, something we want to avoid.

I'm not sure how to fix this. We can do better, and I think much more participation in the protocol is the path to do better, which we intend to do day one with this upgrade.
I agree with the general sentiment that we need a process surrounding the grants that is more robust than what we had. A general council, guide or a director are all good avenues as long as these 2 initials concerns can be fixed

Will vote delegation be built-in at the very launch ?
Yes
How many validators are going to be needed to boot strap Accumulate ? From what I understand, all validators are going to be on the same footing with the same responsibilities?
Validators will validate
Data Servers will serve data
Stakers will delegate to Validators and Data Servers, or just stake to have governance rights

We want participation to be far far easier and much more widespread.
 
So to be clear, the intent is to distribute 60% out of 150M to contributors at the time of the fork, leaving 40% for promotion through whatever grant process we've agreed on. This may be obvious, but I want to make sure everyone's on the same page to understand the scope of this grant discussion.

Is there a list of contributors you can share with us early, or say with the council? Even if it's just the current draft.
The distribution is still in process, i.e. the work isn't done yet. But the distribution will be transparent as we go, and with approval we can do more to integrate parties into the process. We are not waiting for approval, it is just that it makes integration with everyone easier.

I believe much of the 40% for promotion will be distributed. This is a topic we have made the least headway on so far.

We need to look past having a single party calling any shots if we don't have the tools or involvement to enforce performance standards. Ideally, we'd have had experience with a new grant process over the last nine months, so we'd have something tangible to evaluate and see if it fits inside Accumulate, but we don't, and that illustrates my point.
For many reasons, but not the least has been the drum beat for a few years to get rid of developers, and to punish them for taking on some very hard problems around the protocol. Once the developers were gone, I am not sure what @Niels Klomp could do to magically bring them back to their keyboards.

We have projects, and we have budgets. One of the failures of the grant system was an inability to realize we have to fund ongoing infrastructure.

This is a hard problem, and it exists in many contexts.
The same performance issues can be true for committees or guides, by the way, or any system that primarily relies on social accountability (the community holds roles accountable, versus actual legal power to enforce, e.g. in a corporation/nonprofit). Though I'd consider them sooner than a single entity at this point, because Accumulate will have better on-chain tools for reputation management, but it's hard for me to visualise what that might look like in practice.
We need to work together to figure it out. Organizations are complex beasts, and Accumulate will have the tools needed to model many times of decision processes. I am optimistic that we can distribute and integrate many more voices to make a better reputation/management/decision making platform.
 
How much easier wouldn’t it be to do away with any kind of grant system? If anyone wants to add to the core code base, let them do so on their own expense and see if the other validates will accept the code. If the commercial value is big enough, someone will sponsor the work…

The question above is partly rhetorical, as I do see the merit of distributing the value the protocol creates towards development. But the contours of conflict is already showing, with these 150 million tokens that has to be distributed according to some fair, transparent and still unknown scheme 🤷‍♂️
 
I tend to agree with the overall sentiment that the discussed upgrade into Accumulate is the only real way forward, however it seems like many of the same parties are involved in this new venture. What measures will be taken to protect the same self-serving gamification of the tokenomics and vetting of the involved parties/validators? Going back to the first ANO elections, we saw guides game the vetting process to get their own businesses elected regardless of any technical merit or talent. Some of those original guide led ANOs actually ended up being extremely weak links during critical moments of downtime if memory serves correctly.

Over the years we have also had the same parties make the same failed promises and commitments time after time with zero accountability. In fact, we've had parties awarded several hundred thousand dollars over the years in grants and delivered next to nothing of real value to the greater community. In fact, many grant recipients used grant funding in an attempt to build services and platforms intended to further their own financial position rather than further the protocol in a meaningful way. Trivial and oftentimes petty politics got in the way of almost every meaningful initiative ever proposed, meanwhile we were fooled quarterly into paying for nonsense of no value to the average token holder. The recent governance overhaul is another prime example of how people in power have absolutely failed this protocol. What technical measures will be adopted at the protocol level to eliminate or reduce the needed trust and reliance on people or organizations acting in good faith?

In my opinion, this was always the fatal flaw of Factom.
 
  • Like
Reactions: WB
I don't think your memory is doing you any good and you are for sure factually incorrect, but that discussion is going to help no one.

I certainly hope with a move to DPOS and having fresh blood on board we can leave these type of energy draining discussions and accusations behind us to a large extent, because that seriously hampers progress.

People, and processes are imperfect. We have to accept that to a certain degree, as long as everyone's intentions are sincere of course.
 
The addition of DPOS is huge IMO and adds a level of accountability that Factom never had. There are changes that Accumulate is making that are game changers. These investors saw the governance and all the other litany of issues with Factom and still decided to invest and use the tech. I invested in early 2017 solely for the viability of the tech and that position has been (somewhat) vindicated.

I don't see how injecting new energy, money, and much more into this ecosystem is 'failing.' Its always good criticize issues you see, especially in a system that is still in development. But I believe you should bring some solution to the table rather than solely bashing something that has been long hoped for in the community.
 
I'm not trying to bash anything or point fingers at any single individual or party, so I sincerely hope nobody takes personal offense to my comments. None of the above were accusations, but things that generally already happened, for better or for worse. I'm just attempting to ask how these concerns will be addressed with code at the protocol level in Accumulate? I have nothing to gain by ruffling any feathers at this point, I am only asking for overall benefit of the community. DPOS is a great upgrade, but it's not a fix all solution. I believe for Accumulate to be a success, we will need to decentralize and open source many processes and decisions that Factom historically kept managed by closed communities, and open them to wider participation without internal gatekeeping.
 
Status
Not open for further replies.
Top