Milestone 1

[bonustrack]

See snapshot-labs/snapshot#2110 for context.

For the first milestone here is what I propose:

Focus on a single use case where anyone can rewards voters on a proposal with an ERC20 and a fixed amount per voter. Here is the requirements:

• Work with any ERC20
• No need to deploy a new contract to boost a proposal
• When adding a boost, we should define a proposal id, the amount to reward per user, an expiration timestamp a guard and erc20
• The guard is the address that verify the integrity of the boost, in our case it will be Snapshot hub which sign a message with the correct merkleRoot
• Depositors should be able to withdraw the rewards they deposited after expiration of the boost
• You can claim for someone else
• Multiple users can deposit into a boost if they use the same setup (erc20, amount per user etc)
• A proposal can have multiple boosts
• A Snapshot plugin where we can see current boosts on a proposal and claim for it

I imagine a contract with these functions:

create(id, amtPerAccount, token, expires, guard)
To create a new "boost" with fixed amount per voter, the id is a proposal id in our case but we can imagine the contract being used for others scenario.

start(boostId, merkleRoot)
To send a merkle root so users can start claim

deposit(boostId, amt)
To add more ERC20 into a boost

withdraw(boostId, account, amt)
To withdraw funds that you or someone else deposited

claim(boostId, account, merkleProof)
To claim your or someone else ERC20

[mktcode]

About amount per account:

This would certainly attract users but how do you ensure they all get their reward? There needs to be some limit. Maybe "First X voters get Y tokens." But that would just incentivize uninformed decisions. Rewards must not be based on time. How about "X random voters get Y tokens"? That would also indirectly favor smaller voters, as it at least does not favor anyone at all.
_{snapshot-labs/snapshot#2110}

[mktcode]

Suggestion:

You can claim for someone else
You can claim for multiple accounts

claim(boostId, accounts[], merkleProofs[])

[mktcode]

For this first milestone, we agreed that we don't require merkle trees. Individual messages for each vote will be signed and signatures published via IPFS (as a single file) to allow claiming. That means no start method is required to store a tree root.

start(boostId, merkleRoot)

Therefore the claim method takes a signature instead:

claim(boostId, account, signature)

And here a more detailed todo/checklist for hub and UI:

The frontend/plugin:

• settings
  • enable plugin
  • set defaults for token and amount
• create proposal
  • create boost / deposit
    • set token
    • approve total token amount (so contract can take the deposit)
    • set amount per claim
    • display how many claims that makes based on chosen deposit size
    • set expire
  • store boost id in proposal plugin metadata
• proposal page
  • display amount per claim
  • check for ipfs hash in plugin metadata (maybe waiting for hub)
  • load ipfs data
  • check logged in user, find signature
  • display claim button
  • or "can't claim" message
  • for depositers: withdraw button after expire date

The hub:

• in intervals:
• get closed/finalized proposals with boost enabled and ipfs hash pending
• generate signatures based on boost id + voter address
• upload to ipfs
• update hash in proposal plugin metadata

A thought on allowing multiple deposits from different accounts: I could imagine that this isn't really that much demanded and just the DAO itself deposits in most cases. I'm a bit concerned that this makes withdrawals of remaining funds (after expire date) more complicated. Do we really want to support this? Maybe it's easier to allow just top-ups from the account that created the boost.