Outcome of 1-(J) to 14-(C)

  • -


    • Particl Community Forum as primary choice for proposals and structured community discussions


    • The proposer is responsible to open and to maintain for the duration of its proposal listing a discussion group (topic) on the community forum in the governance proposal category. He will have to follow the procedure as described here.


    • The “importance” of a proposal can be underlined by “donations” to this specific proposal. However, the “donations” (backing of proposals with part) are all supposed to be given to the same entity (e.g. particl foundation, or redistributed as staking rewards) and is not meant as funding for the realization of the proposal (problem of centralization --> the owner of the private key might become held responsible for the proposals “consequences”). Thus, a potential “donation” (backing) can be seen as a simple form of spam-protection. The proposals with the most backing parts would receive the top ranked status in a potential proposal ranking.
      A “lighter” kind of ranking and spam-protection could also be achieved when “donations” are becoming replaced by “locking a certain number of coin”. Let’s say the proposer is backing his proposal with 5.000 part for the duration of the voting. After the vote is finished he then gets his 5.000 part back.


    • Independently of 3-(N), the intention and relevance of the votings outcome to the later project development, might impose higher constraints to certain proposal descriptions and maybe as well to the voting procedures. Thus it’s recommended to distinguish between two forms of voting:
      – informal votings (lower proposal and voting constraints)
      – binding votings (higher proposal and voting constraints)


    • For not having the need to move any coins onto specific wallets or addresses, it’s suggested to vote by an outgoing transaction, also as a kind of “spam deterrent”. By that also active marketplace vendors/sellers or liquidity provider can vote with their “public balance”. Additional voting power shall be given to those staking their coins, because they are supporting the network. Those stakers shall be allowed additionally to vote with their staking rewards (also by an outgoing transaction). Those “staking votes” might represent e.g. 1/3 of the overall final voting results, while the other 2/3 being represented by votes out of the public balance addresses, as present at a certain defined block number (block hight).

    • For voting and proposal entering, a defined time-limited period have to be set. Time is gonna be measured by number of blocks on the particl blockchain (e.g. 50.000 blocks for entering proposals, 10.000 blocks for voting).

    • To motivate particl investors with smaller balances also to express their vote, those shall be favoured by following measures:
      – they can delegate their staking voting power to staking pools
      – a grading curve shall reduce the voting power of very large balances (measures to be taken to prevent that large balances easily can be split up into many smaller balances)


    • There have to be a structured way to present your proposal. Following points are essential for most proposals and thus should be addressed by each proposal description:
      – What the proposal is about
      – Why it is important for the community
      – Who will complete the proposal
      – How and by what means this proposal is going to be realized
      – (amount of funding in the case needed)
      – When will proposal be finished (milestones, timeline, expiration dates, …)

    • Ideally the proposals description should be veryfiable based on the information given on the particl blockchain and thus can’t be changed or influenced by any third party authorities anymore.

    • The proposer should be able to choose an application of his choice to present the proposal in a way he think is most convinient for the community to read and to understand. He finally can wrap-up all his documents to a single file and post its SHA256-Hash as “fingerprint” inside the proposal description (only the hash, to prevent bloating the blockchain).

    • For very short or small proposals a limited number of characters should be possible to store directly on the particl blockchain as proposal description. Thus preventing to provide an additional hashed file, which would have to be made available on a third party storage medium.

    • Hyperlinks to other documents should only be given for informal purposes and shouldn’t contain any relevant data to describe the scope of the proposal.


    • Since Particl uses a form of “Proof of Stake” consensus, the staking rewards can be seen as form of “skin in the game” as it required a certain amount of coins locked during a previous period of time. By using the stake rewards as a form of “voting ticket”, the underlaying staking coins are in principal free to spend and thus aren’t locked in any sense.

    • By delegating “voting power” to cold staking pools, a kind of “Voting Service Provider” as know by the Decred Voting procedures can be realized for those not running their own staking node.

    • As described in 5-(B) there’s also a need for active PART users/traders to participate in votings, despite they may have not been able to stake their coins. By making a small outgoing transaction from their public addresses, the corresponding balances at a given “voting block hight” could be used as a form of voting power, while the balances are only “locked” at the specified “voting block hight” and could be moved before and afterwards without diminishing their voting power.


    • There’s a common understanding that there shouldn’t be any restrictions neither to the number of proposals nor to the number of proposers (so multiple and repetetive proposals are legitimit)

    • fixed publishing and voting phases means that you don’t have to constantly try to keep up with new proposals, and there is only a limited number of voting periods where voters might be confronted with repetetive “spam” proposals.

    • Proposal-spam-protection can be achieved by making it costly to propose large numbers of proposals (put some “skin into the game” --> Sitg), e.g. fee based, or ranking by financial backing of individual proposals. Anyway, to prevent big voting efforts for a still large number of proposals, a preselection might be needed, e.g. rounds-based votings, or ranking based on its financial backing. Also a combination of pre-voting and financial backing has been discussed.


    • Establishing a reputation system to better judge the proposer of a proposal might be interesting for self-governance. However, how to calculate and represent a fair reputation ranking still have to be evaluated.


    • A direct democracy is prefered for not helding anyone responsible for distinct project decissions, e.g. governance. However, having elected or choosen community groups to express their opinion in a defined way, e.g. info boxes within each particl application, could help to “streamline” the overall community consensus.


    • see outcome of 5-(B)


    • For a blockchain-project governance and its decissions may be documented onchain and are being managed by a smart contract (e.g. see Compound)


    • Proposals can’t be modified anymore, once they are set up for proposal period (generate Sitg).
    • As soon as any Sitg has been actively given to the proposal, the proposal can’t be “deleted” anymore (rather set up a new proposal).

    14-(C ):

    • for binding voting: splitted yes/no options (e.g. 20% yes / 80% no, or 50% yes / 50% no). Typically the voters will choose either 100% yes or no, but that’s up to each voter.
    • for informal voting: multiple options possible (e.g. blue/red/green/yellow)
Log in to reply