Voting Mechanism

Presently, our voting system encompasses four key activities: adding games to our node, removing games from our node, and conducting mass withdrawals of utility tokens from our node and community-driven campaigns.

Games, along with their respective owner addresses, can be voted into our node to facilitate asset transfers without necessitating the game owner to top up our utility token. Conversely, games found in violation of our community guidelines or policies can be voted out, rendering them ineligible to utilise our facility. Additionally, occasional events such as airdrops, task rewards, or the introduction of new gaming nodes may prompt mass withdrawals of our utility token. These represent just a few scenarios that may trigger voting activities, with the list being non-exhaustive as we encourage community governance over time.

For a vote to succeed, any of the three activities must receive at least one affirmative vote. Conversely, a vote fails if it accumulates three negative votes. Once a vote concludes—whether with a positive or negative outcome—it is immediately executed by the contract and cannot be retracted. While vote creators may terminate a vote prematurely, once a conclusion is reached, the vote becomes final.

In instances of a deadlock vote—where two votes are cast for and two against—action may be stalled if the last top 5 address refrains from voting due to various reasons such as inattention or security concerns. In such cases, the vote can be recreated in another node or a new address can ascend to the top 5, replacing the non-participating address to cast the decisive vote.

All announcements and voting eligibility criteria are accessible on our official website. Users have access to view overall votes, filter votes by subnode number, and review past voting activities. Additionally, new votes are broadcasted on our social media platforms, underscoring the importance of following us or periodically checking our voting page for updates.

Our default voting mechanism operates on a basis where any three out of five identical votes determine the success or failure of a vote. Participation in voting is limited to the top five minters of NFTs within our ecosystem. It's not mandatory for all five voters to participate; if any three of the top five minters cast a vote, whether for or against, the vote will conclude, and the corresponding action will be automatically executed.

In instances of erroneous or duplicated votes, the creator of the vote retains the authority to terminate it at any point before its conclusion. Once a vote has concluded, however, it cannot be cancelled. Utilising only the top five minters may introduce bias and skew results, particularly in smaller, closely-knit communities where communication is efficient.

The decision to employ the top five minters at this early stage of our voting system is twofold. Firstly, due to the limited size of our community, involving every member in the voting process could lead to extended waiting periods. Even as our community expands, encouraging widespread participation may remain challenging due to nominal gas fees associated with voting. Secondly, the top five minters have already made significant contributions to our ecosystem through their purchases. By investing in our ecosystem, they demonstrate a vested interest in its success and are likely to make decisions that benefit it as a whole.

Incorporating an odd number of voters helps prevent stalemate situations where an equal number of votes are cast, rendering decision-making impossible. Our top five minters exhibit dynamic behaviour; if, for instance, four votes are cast (two for and two against) and the last party abstains or is unaccountable, we await the entry of another address into the top five, which can break the deadlock by making the deciding vote.

To ensure fairness, permanent sub-node numbers are assigned upon initial minting. These numbers determine the group to which the minter belongs, with the top five minters determined within each sub-node group. For instance, if there are ten sub-nodes, there will be ten groups of top five minters. The use of sub-nodes mitigates the difficulty of attaining top-minter status by distributing opportunities across groups, fostering more equitable decision-making. Additionally, the random assignment of sub-nodes reduces the likelihood of minters being grouped together maliciously. Decisions made within any sub-node group are reflected in the overall functioning of the main node.

All our voting types are managed through separate contracts, which are then linked to the main node via memory positioning. This setup allows for dynamic addition or removal of voting modules. Each voting module is assigned a unique prefix code during its creation, which remains consistent throughout the duration of the vote, ensuring stability and reliability.

Our system supports up to 255 distinct voting types. Currently, we have three default voting types: addition of a game (prefix number 1), removal of a game (prefix number 2), and bulk withdrawal (prefix number 3). These default voting types are subject to change; when a vote to update the voting modules is initiated, these types can be replaced or removed based on community consensus and evolving needs.

Presently, our voting criteria require a consensus from three out of the top five minters, each with sub-node numbers, with each participant allowed only one vote. However, these criteria are flexible and can be adjusted or replaced to accommodate different requirements. For instance, alternatives could include requiring votes from all top five minters, expanding voter participation to include 99 individuals instead of just five, allowing top five ERC20 token holders to vote instead of ERC721 holders, permitting anyone to vote with the ability to cast multiple votes, or mandating a payment of a specified amount of our tokens for each vote. The possibilities are extensive, and there are no fixed methods, ensuring adaptability to suit diverse circumstances.