getunite / dao-automation

DAO-automation

dao-automation's Issues

Build Execute Github Action for IbAlluoXXX APY change

Summary

1. Name: Modify voteExecutor.sol to to voteExecutorMaster.sol vote automated DAO vote execution
2. About: voteExecutor needs to be modified so that it is able to receive the DAO vote execution data format and send execute it, this includes sending it to the correct L2

Is your proposal related to a problem?

Execution of votes today is slow, time-consuming and VERY centralised.

Describe the solution you'd like

Here is a diagram of how the DAO vote execution will work: https://app.diagrams.net/#G1JQkShtAdyb-l4YM1D_E_lOOAOP5UuZGM

This task is to do the actions of this part of the diagram:

This Github action is pretty straightforward, it should run on a cron, every 2 weeks at 15 GMT (2hrs after the regular DAO votes have ended)

It should simply take the result of the latest APY change vote, match that with the JSON key in the main body of the proposal and take the byteCode associated to it to be sent to the voteExecutorMaster on L1

Additional context

Build automation for proposal and execution of the Liquidity Direction

Summary

1. Name: Build automation for proposal and execution of the Percentage of treasury invested
2. About: Build automation that would run every 2 weeks to create a proposal asking the DAO opinions on Liquidity Direction for each IbAlluoXXX

Is your proposal related to a problem?

Creating a governance vote today is very time-consuming which leads to them not being created on schedule, automation would solve this.

Describe the solution you'd like

This is blocked by #1

The idea here would be to automate the creation of a vote like this one: https://vote.alluo.com/#/proposal/0xf6eaa945ea0da75bd04bee2ede1d84ffce585b9dca1652e8a582e023534d90c3

Needs to be on a corn schedule on a bi-weekly basis, at the same time then: #1

This is a quite tricky one because we need to find a way to be able to edit the weekly proposals with the correct pools as this might change every week. Maybe via a Git action whereby we would be able to add a file in the repo, the pipeline would use the latest file as a reference for what pool to add for what IbAlluo, if there is no file, it would just use the previous week's file.

Design

NA

Additional context

NA

Fix DAO Automated votes for APY votes

https://snapshot.org/#/alluo.eth/proposal/0x0df8d7b5fffcca11f1c11959cbe5ab5cd00a57b92db5adb2f137c3e82ab5fed6 \n \n The automated votes for APY have incorrect descriptions. \n \n https://snapshot.org/#/alluo.eth/proposal/0x35f33766d7453820749ab77f7c5f1f199fbda4713e824d895f57e8f9a9dca77b \n \n This is what it should look like. \n \n As Alex said, it has to do with a copy paste error. The options and title match but the description causes confusion when voting.

Read more about this task and rewards on Dework.xyz

Build automation for proposal and execution of the Percentage of treasury invested

Summary

1. Name: Build automation for proposal and execution of the Percentage of treasury invested
2. About: Build automation that would run every 2 weeks to create a proposal asking the DAO much of treasury should be invested in the protocol

Is your proposal related to a problem?

Creating a governance vote today is very time-consuming which leads to them not being created on schedule, automation would solve this.

Describe the solution you'd like

This is blocked by #1

The idea here would be to automate the creation of a vote like this one: https://vote.alluo.com/#/proposal/0xc4125eab8b6164c836b7fbf9515333951e1b9552d0c1d63566b9ace729540ace

Needs to be on a corn schedule on a bi-weekly basis, at the same time then: #1

Design

NA

Additional context

NA

Build withdraw in ERC20 balance function in ibAlluos

At the moment, when the mobile app tries to withdraw all the ibAlluo balance a user has, it leaves the user with dust in their account because our current withdraw functions are based on USD values. \n \n We need to therefore build a withdraw function that takes a parameter amount in ibAlluos. \n \n Relatively straightforward, one function to do so so that the frontend can call balanceOf(), then use the value in the withdrawIbAlluoValue function to clean out the user’s account. \n \n Thread explaining the issue: \n https://discord.com/channels/897502629213667329/1002540454044250193/1002550857688174593 \n

Read more about this task and rewards on Dework.xyz

Trading bot for Uniswap positions

Is your feature request related to a problem? Please describe.
Today we have an issue in getting list on CCM and CG, the main reason for that was that we were listed only on Balancer and secondly that we do not have much volume on the token.

They are requiring at least 80k volume daily. This does not matter if its buys or sells, just volume in general.

Describe the solution you'd like
The idea would be to build a bot that would be able to cycle between a set of addresses, up to 100 and open and close buy and sell positions against the Alluo/ETH pair on Uniswap.

The bot would be able to run on an EC2 Python or C# or javascript/typescript (this could simply be a node server) Environment. It should trigger buy and sell orders at random intervals between 1-15 minutes from a different address in random order.

Every time the bot opens a buy or sell order from one address, it should wait a random interval between 1-2 minutes and open an opposite trade. This should ensure that overall, there is little possible loss (apart from trading fees of course).

The aim is to generate at least $80k of trading volume every day, so the amount of the trade should be random between 0.05 and 1 ETH from a pool of ETH that will be stored by the bot accessing all the addresses.

Each bot address will manage its own funds and pay for its own fees. The bot should not trade if gas fees are above 15 GWEI.

Describe alternatives you've considered
NA

Additional context
NA

Add spreadsheet monitoring for all price routers and exchange routes on every chain

Is your feature request related to a problem? Please describe.
We have already implemented monitoring of curve pools that are currently invested in / are candidates for investments. This is to make sure we can quickly react to changes in liquidity to protect capital for liquidity direction.

Now we are expanding liquidity direction crosschain, we need the same monitoring for the optimism pools (underlying the beefy vaults / omnivault contracts) as well as all the price routes.

These are all used directly in liquidity direction and we need to make sure that we are aware of abnormalities in liquidity / possible misconfigurations in the routes.

Describe the solution you'd like
Add the monitoring / expand to all the new optimism pools and create a a system so that we can easily add / expand to more pools and chains.
Describe alternatives you've considered

Additional context

Create end time for IbAlluo streams

Currently, superfluid only supports creating infnite duration streams. This is not user friendly so we need to create a way to take care of this for the user. \n \n How it will work is below as subtasks

Read more about this task and rewards on Dework.xyz

Automate displayed parameters in vote creation

Is your feature request related to a problem? Please describe.
Today we need to update multiple json files every governance cycle to include updated:

1. APYs for each liquidity direction pool
2. Current treasury value across all chains.

This is inconvenient and this can be automated by calling the appropriate APIs for this information.

Furthermore, it can lead to APYs that are not up to date if we create the jsons in advance.

Describe the solution you'd like

Add new functions in the vote creation script so that we can call the relevant APIs for our liquidity direction pools.

This should mean the vote should be created similarly to how it is today, but just with automated APYs and automated calculation of treasury value.

Please discuss with xec about how treasury value was calculated manually to ensure accuracy.

Describe alternatives you've considered

Additional context

Upgrade VoteExecutor to change APY on Mainnet ibAlluos

Read more about this task and rewards on Dework.xyz

Add view function to return total amount of ibAlluos + StIballuos

At the moment, the getBalance function returns value in USD across the user’s ibAlluo + StIbAlluo balances. However, we will also eventually need a function that returns the total number of ibAlluos across the two contracts.

\

Read more about this task and rewards on Dework.xyz

Build automation to create APY updated governance vote and execute result

Summary

1. Name: Build automation to create APY updated governance vote and execute the result
2. About: Build automation that would run every 2 weeks and for each IbAlluoXXX create an APY update proposal

Is your proposal related to a problem?

Creating a governance vote today is very time-consuming which leads to them not being created on schedule, automation would solve this.

Describe the solution you'd like

We need to create automation which would on a corn schedule (every 2 weeks on a Wednesday) create a governance proposal to update the APY of the IbAlluoXXX farms.

Here is an example governance proposal with the right formating that we would need to create: https://vote.alluo.com/#/proposal/0xc03078efd1015a49e5a64b8c6426b33603b819ddaa6cd7572268793fdc0d16e4

There are 2 main routes we can explore

1. Github actions: building a pipeline with a link to the Graphql snapshot API which would first iterate through the LiquidityHandler.sol
   getListOfIbAlluo() and create a snapshot proposal for each. Then build another cron that would run 4 days later, once the proposal is closed, and do the update in each of the IbAlluoXXX via the gnosis safe. The pipeline would need a key added to the main gnosis safe on the polygon and the action would still need to be approved by one other signer.

2. Zodiac (safeSnap) by Gnosis: this is a tool that was developed by Gnosis exactly for our purpose (used by the GnosisDAO), execution on chain of off chain governance. I have not yet done much research on this, but it seems like it should be able to do all we need in a fully trustless way, using snapshot template proposals. https://gnosis.github.io/zodiac/docs/tutorial-module-reality/finalize-parameters is a how-to guide. We might still need to have a GitHub pipeline that would trigger Zodiac for each IbAlluo on a corn

Design

NA

Additional context

NA

Build automation for minting of $ALLUO and adding to the vlALLUO pool

Summary

1. Name: Build automation for proposal and execution of the minting of $ALLUO and adding to the vlALLUO pool
2. About: Build automation that would run every 2 weeks to create a proposal asking the DAO how much ALLUO should be minted to reward lockers

Is your proposal related to a problem?

Creating a governance vote today is very time-consuming which leads to them not being created on schedule, automation would solve this.

Describe the solution you'd like

This is blocked by #1

The idea here would be to automate the creation of a vote like this one: https://vote.alluo.com/#/proposal/0x07a6da0c1d2b7b4b75062ac1b15450c91363ad80509694fec84197ca220d6d19

Needs to be on a corn schedule on a bi-weekly basis, at the same time then: #1

Design

NA

Additional context

NA

Create a new Curve strategy to work with Frax.convexfinance

Today, Frax.convex.finance offers double the rewards for staking curve Lp tokens than the traditional convexfinance. \n \n The current adapter does not work with Frax.convexfinance pools so we must create an adapter that works with it.

Read more about this task and rewards on Dework.xyz

Write gitbook documentation for the protocol

Alluo Protocol has a large ecosystem of contracts that interact with each other: \n \n 1. Liquidity direction contracts: Including IbAlluos, Superfluid integration, automated Vote execution, cross-layer communication. \n 2. Exchange \n 3. Strategies \n \n By building comprehensive documentation, we can enable the web3 community of developers to build on top of the protocol as was intended when the core contributors were building. \n \n This is a large task that will take many months to polish. It will be divided up in stages with timelines. \n

Read more about this task and rewards on Dework.xyz

Dashboard showing breakdown of invested yeild farms

We need to bring clarity to our $ALLUO token holders on where is the protocol liquidity invested in and what sort of realised APY are we generating.

Ideally, we would have a Dune analytics dashboard per Strategy. The main data point that we would show are:

• The current generated APY for USD, EUR, BTC and ETH
• Breakdown of current TVL and which pool it is invested in that strategy
• TVL over time broken down per pool
• Generated APY over time
• Current advertised APY (in the mobile app and for depositors
• Any other data that the builder might find useful

We currently have 2 main strategies:

1. Curve/Convex [ETH mainnet]: https://etherscan.io/address/0xa95edb5d867996717d873ca1c2a586fec9c80754#code
2. Harvest [Polygon mainnet]: https://polygonscan.com/address/0x22dAdc912EF37a5D9d4439D81A2c5Dc6a75aBe0e

Both need to be represented on the dashboard for this to be completed

Read more about this task and rewards on Dework.xyz

Add support for "Do nothing" for liquidity direction votes

Is your feature request related to a problem? Please describe.
At the moment, we only have support for a single "Do nothing" vote option that is used when underlying stables are in trouble.

We should add support for "Do nothing" that is added alongside other liquidity direction options.

If this vote wins, all deployed funds should be exited into the primary token of the asset class.

Describe the solution you'd like

1. Add "Do nothing" in vote creation

2. Add logic in execution where:

a. If ' Do nothing ' has the simple majority of the votes,
b. Submit removing funds from all active strategies with percentage 0.

Describe alternatives you've considered
We should consider what case we consider a majority.

If "Do nothing" wins with 30%, but the other 70% are distributed amongst other strategies, should we withdraw everything?

Or should we put a minimum threshold "Do nothing" must pass before we can act on it?

The second makes more sense to me, but we should discuss this.
Additional context

Curve monitoring function

Is your feature request related to a problem? Please describe.
We are invested in a bunch of curve pools but have no real way to monitor how well they are balanced. This could be fixed with a simple script that would return the ratios of the underlying assets in the pool and how much could we get for a specific amount of LP for each asset.

Describe the solution you'd like

The easiest way to do this would be to create a lambda function (whatever language is preferred, Python, C++ or Javascript/Typescript) that would be triggered on a corn schedule every hour and output data in a google sheet using the Google API.

The lambda function should be triggered using the CRON schedule every 1hr and write to a set google sheet the following values:
ratio of asset A, ration of asset B, ration of asset C, ration of asset D, value of 1 LP in asset A, value of 1% of all LP in asset A, value of 5% of all LP in asset A, value of 10% of all LP in asset A, value of 25% of all LP in asset A.

The post can be done using the scripting language of Google sheet: https://developers.google.com/sheets/api/samples/writing

The lambda function should be able to post the set of data for multiple pools, the pool's address should be gathered from the chain, this could be read from the latest raw input in the voteExecutor for the latest LD. Each pool should have its own Sheet in in the google sheet document.

The lambda should run in the production environment of our AWS account and should be deployable via CDK (talk with @nuno or @n3onix for more details on how this works)

The goal of this task is NOT to treat this data in google sheet, but just to post the raw data.

Describe alternatives you've considered
NA

Additional context
More described here: https://docs.google.com/document/d/1x4HU_VjzCFRLFNLVA0RNL11vDtyhtK_NiPs28FlkbvY/edit

Build CONTRIBUTING.md file

Summary

1. Name: Build CONTRIBUTING.md file
2. About: To help external contributor with setting up the project and contribute in a format that we can accept

Is your proposal related to a problem?

Making the life of external contributors easier as today its a bit everyone for himself and standards are not kept unless @alexanderem49 looks at the code 😨

Describe the solution you'd like

Here is a good example: https://github.com/atom/atom/blob/master/CONTRIBUTING.md from Atom
Mozilla has a good tutorial as well: https://mozillascience.github.io/working-open-workshop/contributing/

Let's not make this too long either, ideally could be read in 10 min.

Let's update the README.md as well to make sure we mention this file.

Additional context

Create new CurveConvex strategy that works for all pools

At the moment, the CurveConvex Strategy is bugged and doesn’t work for all pools - the exitAll function reverts if the pool index is a uint256 rather than a int128. \n \n Also, it doesn’t work with native ETH and the exit all function only exits partially if we have a cvx investment (otherwise, it exits all).

\n We need to have the following subtasks completed so that when we use it with the VoteExecutor for liquidity direction, we can minimise slippage and enter a larger range of pools.

Read more about this task and rewards on Dework.xyz