Decentralised Governance 2.0: Better, Stronger, Faster, Fairer

Free TON is a community-driven blockchain project, owned by everybody and nobody at the same time. Hypothetically, this sentiment sounds beautifully utopian.

Let me level with you though, in reality, sometimes decentralisation can be a right pain in the... Satoshi.

We've all heard the old clichés about chefs and broths before. To counter one hackneyed saying with another though: anything worth doing is never easy, and is worth doing well, and is best served cold, or something like that.

So how are Free TON planning to decant our already abundantly seasoned soup of decentralisation, into an even more decentralised saucepan?

Drumroll please...

Introducing Governance 2.0

This next diagram may seem more complicated than a magic-eye sudoku puzzle to the untrained eye. But fear not! If I can get my head around it, as a hyper-intelligent Hackernoon reader, you should have no trouble!

We won't go through every nuance, just the main components, so let's start with the funky purple boxes -- the SMV (Soft Majority Voting) smart contracts. These SMV contracts work very simply: they need 50% +1 of the active votes in a given proposal to pass. I.E, if only 10% of eligible voters say yes, but none say no, it will pass. The proposal is sufficiently supported by those who care/understand the decision.

Getting back to our purple boxes, if you're a little familiar with Free TON, you'll know everything works via a system of contests and proposals. If an actor (you, me, or anyone else) wants to launch a contest, we put a proposal forward.

To decide the fate of the proposal, Padawan/Padavan smart contracts (user ballots) allow voting for proposals. Assuming the idea holds merit, and is accepted, the proposal is passed to the Demiurge smart contracts. Think of this like a central smart contract in a voting system, a ledger which creates and stores proposals and user padawan addresses. When all the Demuirge's relevant fields are filled, we move to the dark green boxes.

Contests have four separate stages to them, hence there are four separate smart contracts handling each: Contest (main), Contest (underway), Contest (voting.), and, everyone's favourite, Contest (Rewards).

• Contest (main) interacts with the JuryGroup and ContestGiver smart contracts to assign roles and rewards.
  
• Contest (underway) handles participant submissions before voting.
  
• Contest (Voting) interacts with JuryContract for both the the commit, and a reveal phase of voting. This ensures voting is independent and free from the influence of previous votes cast.
  
• And Contest (Rewards) distributes rewards and prizes, of course!
  

In addition to awarding those hard earned TON Crystals though, the Contest (Rewards) contract also now automates new Juror registration via the Demuirge smart contract.

And that, is about all there is to it, folks! Simple, right? Given fair weather, it will be deployed for testing in the DGO subgovernance group very soon. If you'd like to dive even deeper into the system, check out this link to read the full paper, smart contracts and all.