---
# System prepended metadata

title: Dekan + TW UH WarGames Braindump
tags: [WarGames]

---

---
###### 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.