Suicide Kings

Note: In our GitHub we have a 3-page concept note that delves more deeply into Non-Fungible Governance and using a game to test it. We have put the most relevant information here, but for a more thorough understanding, we recommend reading the Non-Fungible Governance.pdf.

Suicide Kings is applied research into a theoretical crypto-economic primitive we’re calling Non-Fungible Governance. In traditional forms of Quadratic Voting and Liberal Radicalism users aggregate the degree of their preference by using money (i.e. buying votes or donating to a project). Non-Fungible Governance proposes a new way of aggregating preferences by capturing the Effort an individual gives to a community (e.g. voting, contributing to open source software, volunteering). Allowing communities to set the standard of what is considered Effort can greatly reduce the opportunity for Sybil Attacks. To sandbox and test Non-Fungible Governance in a low risk setting we created a game.

Suicide Kings is a “no-loss” game (e.g. PoolTogether) that uses Non-Fungible Governance in a fun and engaging way. Players have the goal of getting as much interest from the community pool as possible. They win interest by voting on how it is distributed (e.g. I vote on distributing it to my NFT types). They can level-up their NFTs by voting on which NFTs to give experience points. Voting is done in rounds over a discrete time period (e.g. every 12 hours) and interest / XP accumulate for the NFTs throughout the life of the game. Burning an NFT gives the player votes of the NFT’s level squared, hence the name Suicide Kings. When the NFT is burned the player is returned its value, both the original cost and the interest that it won.

So far we have run basic playtests with groups of 3 to 4 players and we have run games where 3 players band together to play hundreds of bots. Based on our several tests and iterations of the game, we believe there is promise for Non-Fungible Governance to reduce the opportunity for sybil attack. Non-Fungible Governance is also showing promise for saying something meaningful about collusion and how to create matching funds for public goods (i.e. The Henry George Theorem).

Paper Simulator

• Uses Roll 20

• Google Sheets

• Google Forms

Our first iteration used the game simulator website Roll 20. We used this sandbox environment to rapidly prototype and test different rule sets.

Once the core mechanic of the game was set and the rules were balanced we used google spreadsheets and google forms to rapidly test what the game might be like on blockchain. We used spreadsheets to simulate wallets and a public ledger, we used a google form to simulate commit/reveal voting, and we used locked excel formulas to simulate the smart contract logic.

Simulator

• Uses SWIFT/Docker:

An offline version of the game was implemented in Swift that allowed the team to simulate full game play-throughs, helping quickly test and iterate on the game’s design.This version of the game implements our final rule set (for more info. see How To Play.md in our GitHub repository).

The simulator can be used to test player vs. player games. In these a facilitator needs to input the choices that players make. The simulator can also be used to test player vs. bot games. This allowed us to test the impact a group of 3 players can have in the game when they are less than one percent of the total number of players.

We also were able to use algorithms and game mechanics from the simulator as a blueprint for our solidity smart contract implementation.

Dapp

• Ethereum/Solidity/Truffle/Ganache-cli: Our smart contracts were written in solidity and deployed using Truffle migrations.

• Open Zeppelin/ERC-1155 Multi-token-standard/Open Sea/Compound: We used various libraries, but primarily those provided by Open Zeppelin and Multi-token-standard. We also used some code from Open Sea to enable display/transfer of our 1155s on Open Sea (Rinkeby).

• JavaScript/Node/React/Drizzle/Redux/MaterialUI/RimbleUI: Our web app consumed artifacts generated from truffle compilation of our smart contracts and exposed a React-based user interface. The Dapp also used Drizzle for managing the web3 provider and application state. We built several React Components that interacted with Drizzle and the deployed smart contracts on testnet.