@Xeonus you mind giving some feedback on current state, maybe also run it locally?

i think the only thing that is really missing atm is epoch management, but it is maybe a bit too early to implement that already

@gosuto-inzasheru initial thoughts / observations:

1. could run locally successfully. Had to reconfigure web3 dependencies in my venv. might need to check if that is an issue for the action run too
2. Make a more structured config file (similar to watchlist), so it is human readable and we easily see what we create airdrops for:

# Current
GAUGES = {
    "0x10A04efbA5B880e169920Fd4348527C64FB29d4D": "0x5bBaeD1fADC08C5fb3e4ae3C8848777E2dA77103",
    "0xc4Ce391d82D164c166dF9c8336DDF84206b2F812": "0x4B891340b51889f438a03DC0e8aAAFB0Bc89e7A6",
}

# Suggestion: 
GAUGE_CONFIG = {
    "pools": {
        "0x10A04...": {
            "gauge": "0x5bB...",
            "description": "Pool name/description"
        }
    }
}

3. math checks out for weighted average. How many snapshots do we want to take? One per day might not be enough.

@Xeonus this GAUGES dict is a quick fix for the fact that the gauges subgraph is currently not aware of v3 pools. once it is, we can simply retrieve the preferential gauge of the pool without any manual intervention, and thus the gauges dict will become obsolete

re: the amount of snapshot im not sure, it is actually quite fast right now for n=7. given we dont expect that many more pools, we could consider an hourly snapshot or something