Dekan + TW UH WarGames Braindump

--- ###### tags: `WarGames` --- # Dekan + TW UH WarGames Braindump ### Audience - Who will be playing? Open to the public or Warcamp only? ### Overview / Setup - Games happen between DAOs, since we are testing a federated system. - Individuals will be representing an imaginary DAO of 100 people. - Game provides instructions/tutorials for an individual player: - Spin up a DAO - Spin up the minion - Join the UH simulation - Alternatively, the game designers spin up the federated DAO on behalf of players. ### Initial Scope 1. Onboarding UX to identify problems with engagement. 2. The Uber DAO requires a neutral single member with one share (historically Sam, now Dekan). This person can sponsor proposals. Potential threat: this one member goes rogue, no one notices their proposal. - We need an EOA for the minion. - Negative incentives can exist within DH; doesn't need to be tested in the UH scenario. ### Scenarios / Attack Vectors 1. **Spam Attack**: like Foundations DAO - An individual makes 40,000 proposals in one day - Front end can't process that much data = kills the front end, super annoying - Contracts are still accessible through Etherscan, or similar - Grief level is high = most of the members are excluded from participation Potential Solution: Add Offering - Require an offering to the DAO to make a proposal. Example: send xDAI to make a proposal. - Attackers will be discouraged from spamming, but most of the DAO population would not be greatly affected. Test: Mandatory rule to make an offering with each proposal submitted. Different from paying tribute (where the funds are sent after the proposal passes, instead of before). 2. **Misleading Minion Proposal**: - A vulnerability in the txn builder. - When making a proposal, some malicious code is inserted. The title of the proposal might be misleading: "Transferring 1 token" when the multicall actually transfers many tokens. - Different call functions could be deployed in the code. Potential Solution: Audit Process During Sponsorship - A representative needs to look at the minion action details, know how to read them, and can verify that the proposal does not have any malicious code. - This could be a single EOA signer (like Dekan or whoever from DH). - An education opportunity to teach DAOs how to read and understand the parameters so the community can collectively hold accountibility for these audits. - The auditor becomes their own social attack vector. This role requires a lot of trust: UberPaladin, form of social accountibility. 3. **Unsponsored Proposals or No One Votes/Executes; Unsponsored Rogue** - Low threat, high grief. - Creates noise in the proposal queue: combination of the spam attack and a misleading proposal. Potential Solution: Make a social process for the flow. - Add role/bot that take responsibility for the process. - Example: If you audited the proposal, you then sponsor it so others can vote on it, the auditor would process and execute. - Really this is about singular accountibility to a clearly defined role. - There is currently a 2 week expiration date, but the proposal remains in the code. - The auditor role requires accountibility/potential slashing. 4. **Shaman Contracts Fail; DAO Contract Fail; Baal Contract Fail** - A critical bug in the security contract itself, smart contract risk! - Interfaces with the Shaman: misleading minion proposal variation that adds a new Shaman. - Shit happens in Web3, but this would be disasterous. - Someone might figure out how to give themselves infinite loot, or shares, and then RageQuit the entire treasury. Potential Solution: Engineers Security Auditing the Contracts, Battle Testing, Bountiess - How to incentivize white hat hackers with a strong social upside that would outweigh the potential economic gains/perverse incentives of waiting until there was a large honeypot to steal. - Maybe a grant opportunity to identify the contract vulnerabilities before widespread launch. ### Coin Voting Problems 5. **Yeeter Sybil Attack** - High effort, low risk, but very high grief. - Depends on how the Yeeter is setup. Yeeter is permissionless: loot only, no voting power. Has caps: max cap for the round and cap for an individual address. - One person could control multiple addresses to capture all the loot. - Yeet, RQ, Yeet, RQ: attack could happen with a small amount of money. Potential Solutions: - Some kind of verification on the address. - 3% fee (basically for spam prevention) is important: someone could buy all slots for a Yeeter, then Ragequits all except one, so they have all the loot and no one can participate. - We might consider the distribution of this 3%, how it's returned or vested. - A drip mechanic: so the distribution is controlled and can't be taken all at once, but it could still be many addresses controlled by one person. 6. **Snapshot Gridlock** - All proposals need to pass through off-chain consensus first. - To have voting power in the Snapshot the address needs Loot, which is sourced from the Yeeter. - Could potential block the whole DAO proposal process. Potential Solution: Two Body System - If we notice someone is blocking Loot from the Yeeters, the a policing guild of DAOS take action to social enforce the attacker. - Neighborhood watch in the community. - UberPaladins role is to put up the propsal after Snapshot and facilitate process; the Federation still needs to audit and vote on it. - Snapshot has some features that might help: thresholds - token amount before making a proposal or voting; and quorum - a certain amount of voters required for a proposal to be valid. --- ### Incentive Mechanism - Either payout in HAUS like previous Wargames - Chucky Cheese style arbitrary tokens, that can be redeemable for DAOhaus prizes later TBD ### LARPing Ideas - Star Trek Federation of DAOs. - Each DAO is a different player from the Star Trek universe; they can stylize their players accordingly. - Make a list of the different character types. - Maybe visiting MMORPG worlds to pull in.