No Canonical GitHub Repository

No Canonical GitHub Repository


Currently the Terra-Money and Terra-Rebels GitHub organizations contain the only canonical GitHub repositories approved by the Terra Classic governing consensus body. This makes it hard for validators to accept PRs from other people/groups/organizations that might want to upgrade, improve or hotfix our network. Thus to encourage the creation of more development teams that can support our needs for “client diversity” we believe that it would be preferable to implement the solution suggested by Jacob Gadikian and adopt a release strategy that revolves around commit IDs. This combined with increased due diligence from the validator pillar (related to security audits of the code that is deployed to mainnet), will in our view lead to more decentralization and will ultimately benefit everyone.


The current proposal consists of two amendments, one which seeks to repeal proposal #4940 and another that enables validators to receive client update from anyone providing a commit ID, granted that it works, passed QA testing, contains no malicious code and does not result in halting the chain.

Amendment 1/2

Repeal proposal #4940 to enable updates to be sourced from anywhere.

Amendment 2/2

Allow any person/group/organization to produce a release for the validator pillar as long as they respect the semantic versioning schema and coordinate with other development teams.

Acceptance Criteria

Anyone can produce a client release based on a specified commit ID.


To summarize, we seek to ensure that we can increase the number of people with access to improving the network client while ensuring the overall stability of our network.

If the Agora proposal is approved we suggest that it is ported directly to a text proposal and submitted for ratification.

Consequence of a YES vote

If the vote results in a YES, we will enable validators to take client updates from anyone they believe can create value for the network. This would result in a net productivity gain for developers, granted that teams can agree to synchronize changes between them in a civil manner (no closed source repos & drama).

Consequence of a NO vote

If the vote results in a NO, we will be forced to continue pushing upstream PRs to the aforementioned repos which by and large are no longer maintained. We could add the L1 teams current repo to the canonical list, but that would only really push the problem down the road, which overall results in a net productivity loss for the developers until the situation is resolved.


Are proposals by L1 Team meant to be biased and sarcastical?

I mean, unless you are pandering to a specific audience - you can communicate the issue of having a central party in Github previously, in the itroductiom/explanation phase.

Yet, you specifically used language for a “no” vote to cast this option as a negative.

1 Like

Scaling productivity and creating a user friendly environment for development is of crucial importance to the blockchain. A shift to non canonical GH repo will facilitate this process. However, it begs the question if whether such a strategic move wouldn’t inadvertently create loopholes for exploitation by malicious elements. If not, an unqualified YES.


Yes :+1:

1 Like

No with veto,Again.
If it passes.It doesn’t mean decentralization,but almost equal give out our chain to unprofessional and bad actors.
Almost announce the end of our chain.
Sorry,we community can’t buy your sel-idealism test,because we only have one shot.
It’s highly dangerous.
No with veto!

1 Like

This isn’t “giving out the chain” to anybody, it just allows for community members other than L1TF to submit code that they wrote. It also states in the prop any code submitted will first have to go through a series of checks i.e “providing a commit ID, granted that it works, passed QA testing, contains no malicious code and does not result in halting the chain.”

1 Like

You don’t need to explain that to me.
Just have a look at previous post of this topic and see what most people think.


Yes, lets get this done. The more decentralized we are the better. If quality checks are done to PR this creates more opportunity for community teams to support L1 infrastructure which will lead to greater self sustainability in the future.


@LuncBurnArmy When will it be pushed for voting? With the recent developments it is quite clear that the system we have needs to change. Ol’ boys club having a blast on Twitter isn’t feasible in a Community owned, open source, free for everyone chain.


That is logically correct.

I hadn’t thought about this since the details of how the vote will be implemented wasn’t discussed.

If the commit which passes is the commit which gets merged, it’s an issue. It has to be the ID of a PR which is passed, not a commit (damn, I forgot that can’t be done without resolving merge errors).

Cause a discussion and vote takes close to 14-20 days. Lots of people would have committed their changes and also created new PRs by then which will again have to be merged. Merging from a commit will also create a fckd up looking timeline of merges.

This has to be reconsidered.

I am not against a decentralized set of repositories, actually am for decentralized repositories as long as it also protects code security. I offered a few thoughts here for community maintainers that decentivizes them from centralizing the official community repositories.

The good part of this proposal is the commit hash does allow for immutability for a decentralized set of repositories (as long as the validators do not install, or upgrade/update, to anything other than that commit hash once a proposal, listing the commit hash, has passed for that code). This helps strengthen and follow the pattern of 4159 suggested, and that EK has used for the L1JTF proposals, of listing pull requests in proposal discussions and in the proposal itself, so that governance and developers can review the code and know exactly what changes are being made for consideration, and the vote actually covers the acceptance or rejection of that code.

It does seem though that there needs to be development of some tools for this, since it does disrupts development (or at least it could help development if this type of a model suggested in this discussion is adopted). For instance, each project that is not the one proposing the code will have to overwrite their repo in order to start with the commit hash that is being voted on if it is accepted - so they get the starting commit hash (to establish that no prior code has been manipulated). You can’t cherry pick in Github and come up with the same commit hash (which is good for immutability of the code, but does mean you have to overwrite your repo and manually move all development from branches into the new copy of the repository with the correct starting commit hash). This actually happened for Terra Rebels, where they had to archive their repository, and fork the classic-terra repository, so they could end up with the approved commit hash that a proposal listed as official.

It is not the end of the world to continue like this, nor is it to pay some community maintainers that just pretty much hold the repos (possibly making no changes to them at all - similar to the way a mirror site of the repos with the last commit hashes that passed a vote). I am also not opposed to a project holding the set of canonical repositories, as long as it does not cause a civil war every time someone wants to change it (or maybe the last person to have a passed vote for code is the new canonical org/repositories unless they remove the commit hash, and then it falls back to the previous canonical org/repositories).

Just a few thoughts for what they are worth…


Maybe one of these tools would work to merge repositories (while retaining the history and commit hashes)? Have not tried it though to see if it will retain the correct commit hashes or not:

Of course, there would need to be care to always check to make sure a sophisticated hashing conflict has not been exploited for tree hash (basically a diff between last known good code base and the one being proposed should reveal any code changes - at least for the appropriate branch or tag being compared after git checkout <commit | branch | tag>, or using git diff).

1 Like


When’s this prop going up for voting @LuncBurnArmy?