Qortal Project

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Updated Information About 'Voting' on Qortal =====
\\
The previous concept of a 'Voting System' for Qortal is now being modified. In a similar fashion to the new Minting Methods, the 'voting' of Qortal is done in multiple ways. 
\\
\\
=== 'GROUP_APPROVAL' transactions ===
GROUP_APPROVAL is essentially a method of 'multi-signature transactions' that can take place on the Qortal Blockchain. Qortal is the only blockchain with this type of transaction. Group approval transactions allow a group to make a 'group decision' with on-chain transactions controlling that decision. 
\\
\\
Group approval transactions are currently what control both the auto-update signatures for the developer group, and now also the MINTER group INVITES, and promotion of 'Minter Admins' in the new Mintership concept. 
\\
\\
Group approval will be leveraged more in the future as well, as it is a means to have a true 'group decision' on Qortal. Wherein the decision can only take place if a certain percentage of the group's admins sign a transaction signifying they approve it. 
\\
\\
===== Polling =====
\\
Qortal Also has a 'polling' system, in which the weight of Blocks Minted is assigned to each minting account, and a decision may be weighed in on by the community. The polling of Qortal is utilized to get the overall opinion of the community on any given topic. 
\\
\\
Polling on Qortal may be utilized for any reason. Any user may create a poll and obtain the opinion of the community within said poll. 
\\
\\
=== Polling in Mintership ===
\\
In the new Minting concept, 'Mintership', polling is leveraged to enable the next stages of the Mintership process. 
\\
\\
Seeing this in action may be done within the 'Q-Mintership' app. 
\\
\\
In Q-Mintership, when a new or existing account on the Qortal Network, wishes to obtain Minting Rights (be invited to the MINTER group), they will put up a request 'card' on Q-Mintership's 'Minter Board'. Once this has taken place, a poll is attached to the card, and the community may then 'weigh in' on whether they believe this account should be able to mint on the Qortal Network or not. 
\\
\\
The poll attached to the card keeps track of votes from both users and Minter Admins separately. When the amount of Minter Admin poll results in the positive direction reaches the number required to obtain the 40% needed for the GROUP_APPROVAL transactions, the ACTIONS appear on the card for the Minter Admins to see. The actions allow the Minter Admins to then take action on the card and its subsequently attached account (the account that published the card). 
\\
\\
The polling here also keeps track of the weight of both the Admin poll results, and the Minter poll results, so that the card's support by not only the admins, but the general minting community may be taken into consideration by the admins. 
\\
\\
There is also a location for comments to be published on the card. This way if a Minter or Admin wishes to, they may explain the rationale behind their vote, and why they voted the way they did. It is also possible for the user publishing the card to comment and make their case as to why they deserve to be one of the Minters of the Qortal Network. Discussion then takes place, poll results are obtained, and depending on the results of the admin poll results, actions may or may not be available to the Minter Admins, such as sending a GROUP_INVITE to the user whose card received aforementioned positive results. 
\\
\\
Upon such a GROUP_INVITE being created, and since GROUP_INVITE transactions for the MINTER group(s) is (are) controlled by GROUP_APPROVAL, the next stage in the process involves the Minter Admins signing that GROUP_INVITE transaction, via a GROUP_APPROVAL transaction. (See more about GROUP_APPROVAL below.) 
\\
\\
Following the number of GROUP_APPROVAL transactions reaching the required percentage threshold (at the time of this writing, March 2025, that threshold is 40%, or 10 signatures total with 25 Minter Admins) the GROUP_INVITE transaction is then (and only then) made active, thus allowing the invited account to issue a JOIN_GROUP transaction, which, once confirmed is the first step of actually minting on the Qortal Network. 
\\
\\
Polling allows the creation of any poll with any number of potential poll 'answers'. The poll is published via a CREATE_POLL transaction, with the details published on-chain therein. Subsequent 'VOTE_ON_POLL' transactions created by other accounts, then provide the results for such polls. Everything is done on-chain, and as such is an immutable method to keep track of the decisions made by the community over time. 



===== Voting System Overview (deprecated, left for historical reasons)=====
\\
(this data is here for historical reasons only, the methods surrounding 'voting' on Qortal are evolving as time goes on.) 
{{:qortal_official_logo_transparent_.png?400|}}

Qortal aims to create a true direct democracy where no outside government or party will have control. Instead, the people who contribute to Qortal by minting blocks will earn a weighted vote accordingly. Accounts will have a voting influence that is weighted based on the blocks minted count. For example, an account with 100 blocks minted would have more weighted influence than an account with 99. This is an extremely important concept as it is based on time and contribution.

The Founder accounts will have a different weighted vote that is based on their blocks minted count PLUS level 10 blocks minted count. What we mean by this, as seen on the [[Leveling System]] wiki page, for an account to reach level 10 requires 4,074,400 total blocks minted. So Founder accounts will have a weighted vote of 4,074,400 PLUS their actual blocks minted count. For a simple example, if a Founder has 100 blocks minted, the account would have a weighted influence of: 4,074,400 + 100 = 4,074,500

When the first Founder reaches level 10, Founders will no longer have the boosted weighted vote as explained in the previous paragraph. Founders will then only have a weighted vote based on actual blocks minted. Also, those who were given pre-enabled levels as “QORA Forgers” will be given a 'blocksMintedPenalty' equal to the number of blocks they were credited with at Genesis. This will remove that number of blocks from their total minted blocks. This will not only affect their voting weight but also their minting reward blocks minted account, as blocks minted is an across the board credit. This also means that if they have NOT minted by the time the first Founder hits level 10, they could be sent back to level 0. (7 years should be plenty of time for them to have paid enough attention to start minting, and if they haven't by then, that's their choice. They were given ample time to take advantage of the opportunity given). Yes, this does mean QORA Forgers will lose blocks minted, and could affect their level if they are on the cusp of reaching or had just reached a level. Refer to the [[Leveling System]] page to see how blocks minted credit for levels 1-5 will not have too much of an impact on the QORA Forgers who will have high leveled accounts at the time of the ‘blocksMintedPenalty’.

This penalty (just a technical term) is simply to be sure the voting system is fair for everyone who actually started at 0 blocksMinted at Genesis, including but not limited to the Founders. Therefore this is simply an effort to 'level the playing field' for those who did NOT have pre-enabled blocks minted. The Founders have level 10 + blocks minted, until the first Founders actually reaches level 10, then they are actual blocks minted like everyone else. At the same time, those who were given pre-enabled levels get the penalty for however many blocks they were credited with at Genesis. This structure will incentivize users to keep their existing account minting, opposed to if we kept the previous concept where everyone would max out at level 10 and incentivize users to begin a second account. This is the latest concept for building a fair system of egalitarianism. Subject to further modification.

Please note: Qortal is ever evolving, as we build this from scratch. Development does not always have room for the community’s involvement, although when possible, it certainly will be. The DevTeam will always be the final decision maker of what is best, as they understand what is technically possible and what will make the most sense. We realize that some folks might not fully grasp this reality, as ideologically we’d all love to be more involved. This is where we must respect and credit the team’s time and track record of building a fair system for all. One that is built with truly decentralized features that meet the foundational goal of egalitarianism.

Voting will be used to help steer the project’s direction when possible. Rather than leaving everything up to the DevTeam, the community will be able to vote on certain matters with how the DevTeam should allocate their time with options presented to the community. Such as which coins or features to implement next, or certain modifications needing to take place and which options the community thinks are the best ones to pursue. There will NEVER be any voting for sanctioning or censoring as this will never be a possible action by the DevTeam! In the case of the Voting System itself, there does not seem to be any alternative solutions that could be presented as ‘options’ to vote on. This is a small example of how the DevTeam has to make decisions on behalf of the community, and the track record of building a system with genuine intention, deserves credit and trust.

Voting will also be used to help approve new developers as an admin of the DevTeam. What this means is that we have two types of DevTeam members: 1) anyone can join the team and help develop the codebase who DO NOT have the ability to vote on the 60% approval to push updates to the chain, and 2) DevTeam admins who DO have the ability to vote on the 60% approval to push updates to the chain. The DevTeam will vote to approve new admins by pushing the update with their 60% approval. This update will then assign the admin permission to the vetted dev(s) and it's official. It is extremely important to have this layer of security with these two types of DevTeam members as the DevTeam admins will be the only ones who can vote for a 60% approval to push updates. This creates a way for the DevTeam admins keep the rest of the DevTeam in check as DevTeam admins are the only devs who can push the 60% approval updates to the chain.

The community will NOT be voting to directly approve code updates. There's no sense in having the community vote on what they cannot read and understand (code). Especially when they have not vested the time contributing to the codebase as the DevTeam does. Otherwise let us know and join the DevTeam, and one day based on time and contribution, you may be vetted and casted in a vote to earn the admin permission and take part in the 60% approval as explained above. 

The community will always be able to submit proposals and vote on them. This can be done by anyone. If they are approved by the community vote, they will get passed on to the DevTeam for review and to determine what is actually possible. The DevTeam will make changes to the concept if necessary, then submit a final approval for the community to vote on. Thereafter, the DevTeam will move forward with development of the concept. 

In regard to projects that wish to have their own minting system and/or asset, they will be required to submit a proposal to be reviewed by the Dev Team. The Dev Team will then submit a summary to the community as to what the project entails and is worth a community vote to approve. The community will then vote to approve and development of the project can begin. 

Of course at any time, anyone is able to submit pull requests. That will always remain an option and has nothing to do with the Voting System.

Voting System is expected to be implemented sometime in the near future when we can address the self sponsorship issue further. Also keep in mind that these voting system ideas are not necessarily fully conceptualized and may be further designed in the most sensible way!

We also have made a blog explaining how Qortal is not a DAO: https://qortal.org/qortal-is-not-a-dao/
Qortal Project

User Tools

Site Tools

Page Tools
