getunite / liquidity-direction-protocol

Alluo - Protocol

Main logic of the Alluo liquidity direction protocol.

Table of Contents

1. About The Project
   • Built With
2. Getting Started
   • Prerequisites
   • Testing
3. Roadmap
4. Contributing
5. License
6. Contact

About The Project

This repo contains all the main logic the Alluo protocol to invest the funds that are held by Alluo.

The main logic deals with liquidity management, interaction with the DAO, orchestration of the vote execution.

It also manages the deposit and withdraw process, accross chains.

All the addresses of the contracts deployed to all the networks that are part of the Alluo Protocol are available here: Protocol Library

(back to top)

Built With

Here are the major framework / languages used to build the Protocol.

• Hardhat
• Typescript
• Solidity Coverage
• Etherscan

hardhat

npx hardhat accounts
npx hardhat compile
npx hardhat clean
npx hardhat test
npx hardhat node
npx hardhat help
npx hardhat coverage
npx hardhat run scripts/deploy.ts
TS_NODE_FILES=true npx ts-node scripts/deploy.ts
npx eslint '**/*.{js,ts}'
npx eslint '**/*.{js,ts}' --fix
npx prettier '**/*.{json,sol,md}' --check
npx prettier '**/*.{json,sol,md}' --write
npx solhint 'contracts/**/*.sol'
npx solhint 'contracts/**/*.sol' --fix

Etherscan verification

To try out Etherscan verification, you first need to deploy a contract to an Ethereum network that's supported by Etherscan, such as Rinkeby.

In this project, copy the .env.example file to a file named .env, and then edit it to fill in the details. Enter your Etherscan API key, your Rinkeby node URL (eg from Alchemy), and the private key of the account which will send the deployment transaction. With a valid .env file in place, first deploy your contract:

hardhat run --network rinkeby scripts/sample-script.ts

Then, copy the deployment address and paste it in to replace DEPLOYED_CONTRACT_ADDRESS in this command:

npx hardhat verify --network rinkeby DEPLOYED_CONTRACT_ADDRESS "Hello, Hardhat!"

Performance optimizations

For faster runs of your tests and scripts, consider skipping ts-node's type checking by setting the environment variable TS_NODE_TRANSPILE_ONLY to 1 in hardhat's environment. For more details see the documentation.

(back to top)

Getting Started

This is an example of how you may give instructions on setting up your project locally. To get a local copy up and running follow these simple example steps.

Prerequisites

This is an example of how to list things you need to use the software and how to install them.

• npm

  npm install
  cp .env.example .env
  nano .env

• yarn

  yarn install
  cp .env.example .env
  nano .env

Testing

npx hardhat clean
npx hardhat test

(back to top)

Roadmap

See our public roadmap here: Roadmap

See the open issues for a full list of proposed features (and known issues).

(back to top)

Contributing

Contributions are what make the open source and DeFi communities such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.

If you have a suggestion that would make this better, please fork the repo and create a pull request. You can also simply open an issue with the tag "enhancement". Don't forget to give the project a star! Thanks again!

1. Fork the Project
2. Create your Feature Branch (git checkout -b feature/AmazingFeature)
3. Commit your Changes (git commit -m 'Add some AmazingFeature')
4. Push to the Branch (git push origin feature/AmazingFeature)
5. Open a Pull Request

Bug bounties

If you notice any vulnerabilities, bugs, or even efficiency improvements please checkout our Bug Bounty program on Gitcoin

(back to top)

License

Distributed under the MIT License. See LICENSE.txt for more information.

(back to top)

Contact

0xtuytuy.eth - @0xtuytuy - [email protected]

Project Link: https://github.com/GetAlluo/alluo-protocol

(back to top)

liquidity-direction-protocol's Issues

Deployment of IbAlluoUSD on mainnet

Is your feature request related to a problem? Please describe.
Most of the liquidity is on Mainnet, we are hoping that by deploying the IbAlluoUSD on Mainnet we will attract even more TVL to the protocol.

Describe the solution you'd like
Deploy the IbAlluoUSD with the same entry coins as on polygon to ETH mainnet.
Plz work with @0-xec to get ETH for gas.

We will of course have to remove the St ability of the IbAlluo standard, as Superfluid is not on mainnet.

Could we explore depositing the funds directly into the voteExecutor V3 rather then in gnosis as well (0x4Fd58328C2e0dDa1Ea8f4C70321C91B366582eA2)

Describe alternatives you've considered
No alternative ETH mainnet is king

Additional context
The 3 entry coins to use are:

• 0xdB25f211AB05b1c97D595516F45794528a807ad8
• 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
• 0xdAC17F958D2ee523a2206206994597C13D831ec7

With USDC as the reference coin and the output coin.

LiquidityBuffer V2

Summary

1. Name: LiquidityBuffer V2
2. About: Implementing a standard buffer that can then be used by the IbAlluoXXX Standard.

Is your proposal related to a problem?

No problem, just enabling the protocol

Describe the solution you'd like

The current liquidity buffer is currently linked to a specific curve pool.

Given that, with the new IbAlluoXXX standard, we could technically have assets that are not supported by any Curve pool without any impermanent loss.

We need to improve our current liquidity buffer so that the admin has 2 options that can be set on deployment and modifiable in the future:

• keep the buffer coin in the contract, locked and uninvested
• invest the buffer into a defi pool:
  • Consider following the same principle then we did with the Exchange.sol and Adaptors.
  • Every Defi protocol would have a new adaptor.
  • We need to build the first adaptor for curve aave pool on polygon

Of course, we should keep all the standard functionality of the liquidityBuffer as they are today.

Additional context

Build FRAX/USDC EIP-4626 vault

Is your feature request related to a problem? Please describe.
No problem, the goal is to increase TVL in the protocol and the number of CVX rewards $ALLUO lockers earns.

This is related to the white paper here: https://www.notion.so/alluo/Yield-booster-933737d27e1f4808b425081f3ecbd60c

Describe the solution you'd like
This task is to build the first part of the Yield Booster product, the vault. The vault should take in base assets, create the LP on Curve, and issue the AlluoBoostedXXX token to the user.

We would like to use the ERC-4626 standard (described here by open Zepplin: https://docs.openzeppelin.com/contracts/4.x/api/token/erc20#ERC4626) and implement the UX improvements that come with EIP-2612 as well.

This issue includes:

• create the template vault to create more AlluoBoostedXXX tokens
• implement the AlluoBoostedFraxUsdc
• implement the wrapper that will convert the USDC and FRAX into LP and then deposit them into the AbFraxUsdc vault

The AlluoBoostedFraxUsdc should be able to take in USDC or FRAX tokens and invests them in the Frax/Usdc pool on the Curve (https://curve.fi/fraxusdc) then move the LP token to the booster pool (issue to be created)

The AbFraxUsdc vault should implement all the standard functions described in the ERC:

• asset() -> should return the address of the underlying Curve LP
• totalAssets() - should return the amount of Curve LP managed by the vault.
• convertToShares(assets)
• convertToAssets(shares)
• maxDeposit(_)
• maxMint(_)
• [maxWithdraw(owner)](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20#ERC4626-maxWithdraw-address-
• maxRedeem(owner)
• previewDeposit(assets)
• previewMint(shares)
• previewWithdraw(assets)
• previewRedeem(shares)
• deposit(assets, receiver) - this should take the Curve LP and NOT the underlying 2 assets.
• mint(shares, receiver)
• withdraw(assets, receiver, owner)
• redeem(shares, receiver, owner)

The vault should then be complemented by a wrapper contract which will actually be used by the Alluo webapp and mobile app to interact with this boosted pool. This contract should implement the following functions:

• getBalances(address, address = 0x) -> this should return the underlying balance of the tokens addresses passed. So in the Frax / USDC case, you would be able to query the view function with both USDC and FRAX addresses and it would give back the amount of USDC or FRAX you are able to claim back from the vault if you are to unwind your LP
• getRewardsBalance() -> this function would return the balance in reward from the boost pool for the Frax/Usdc case if it is attached to the boost pool Cvx/ETH it would return how much ETH and how much CVX a share of the vault is entitled to.

Describe alternatives you've considered
this is the only standard out there for now, so better than building our own stuff!

Additional context
This task is linked to the booster pool which will be described the next task.

[Polygon] Integrate IbAlluo standard with Exchange.sol

Summary

1. Name: [Polygon] Integrate IbAlluo standard with Exchange.sol
2. About: Add the ability for the IbAlluo Standard to automatically exchange the input coin into one of the entryCoin

Is your proposal related to a problem?

No problem, just improvement

Describe the solution you'd like

Today, to enter an IbAlluoXXX you need to own one of the entry coins. This is a limitation as it forces the user to take care of the exchange himself ahead of the txt to enter the farm. This is particularly a problem for Mobile app customers where the onramp experience for some smaller assets like the EURO pegged stables is not existent on Polygon.

The aim of this task is to build the Exchange.sol into the IbAlluo Standard, allowing users to enter the pool with any coin supported by the Exchange.sol and from which there is a route to an entryCoin in the IbAlluo.

Here is an example of the deposit flow would be as follow:

1. user has wETH
2. user sends wETH to IbAlluoEUR
3. IbAlluoETH exchange the wETH into EURt
4. IbAlluoETH invests the EURt it gets from the exchange into the Strategy via VoteExecutor

Here is an example of the withdrawal flow:

1. user presses withdraw in ETH from his IbAlluoEUR position
2. IbAlluoEUR withdraws EURt from the Strategy it is invested in
3. IbAlluoEUR called Exchange.sol with the EURt it receives from voteExecutor and gets wETH
4. IbAlluoEUR then returns wETH to the user

Additional context

This functionality is particularly important for mobile app users as we keep most of the exchange logic at the SC level and therefore the mobile app does not need to worry with integrating with another exchange. It makes things much simpler in terms of handling transactions in the FE.

Deploy Liquidity Direction protocol on Sepolia TESTNET

Is your feature request related to a problem? Please describe.
In an effort to test POS but also to test the LD prototype let's deploy all our protocol on Sepolia :yay:

It seems to have an etherscan: https://sepolia.etherscan.io/

Ideally, let's verify all the contracts from HH as well, but there might be some incompatibility.

Describe the solution you'd like
DEPLOY ALL THE THINGS

Let's run a gas report, and a full test report and ideally paste it on here.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Build vlAlluo value redistribution mechanics

Is your feature request related to a problem? Please describe.
Today the way the value is redistributed to vlAlluo holders is simply by buying ETH from the rewards we generate and providing liquidity in the 80/20 Balancer pool. There are 2 problems with this:

1. Moves the price of the $ALLUO token up but also incentivizes $ALLUO holders that are not locked to sell their token.
2. Is somewhat predatory to the CRV/CVX token as we do not hold but rather sell their rewards every week.

We are trying to achieve better synergies with Curve and Convex which will hopefully increase our attractiveness to CRV believers and therefore our TVL.

Describe the solution you'd like
The idea would be that rather the converting rewards to ETH, convert them to CVX and compound it in the CVX/ETH Pools and allow vlAlluo holders to claim their share of the CVX/ETH LP whenever they want. This can be achieved in the following steps:

• Convert all rewards gathered via liquidity direction into ETH (this can be a manual function call where we tell the contract what token to convert and how much of it to convert to start with)

• Convert ETH to CVX and add liquidity to the CVX/ETH pool on Curve here: https://curve.fi/cvxeth [ this can be done with the Exchange's current routes. There might be an argument here that becomes this becomes the main part of the protocol we might want to make the ETH -> CVX a major route using the Curve pool ] https://etherscan.io/tx/0x66921d5317d672e9b0f84bc26bb363d687a23a98fc8232b949efb6dfac2e0c0d

• Claim the CRV from the CVX+ETH pool on Convex (from the previous 2 weeks) https://etherscan.io/tx/0x4cc03b5fd2b43f5b44696fc8c83af0af8150f903ecc746e79fc760501c935a39

• Convert CRV to CVX using the exchange

• Lock the CVX into the Curve pool against ETH: https://etherscan.io/tx/0x7a259c7fce855013027a880171a183987b9cd8e956d8cefe80299f75fa545156 and https://etherscan.io/tx/0xdd5030cd099986f2124af5314462aae643a9e6b3c61d93d1bad357d2b76100a8

• Add the Curve lp to the Convex: https://etherscan.io/tx/0x5ce79a479d97d300e907c4173e4d86b57330a5150af626967e42afb8862c36ab and https://etherscan.io/tx/0xeb01e59a42f52460a68ccb8d390b2dd4843f5d415451f1190051f4fd23f6b175

These 5 steps should be executed when the function executeSpecificData of the voteExecutor is called.

• Allow vlAlluo token holders to claim their share of the CVX/ETH Curve LP . This can be done directly in the vlAlluo token contract by just adding a claim() function and making sure that this function is also triggered if the user calls withdraw()

This task is to create the functionality of the above mechanics in the voteExecutor.sol but not the functionality that will calculate how much is the spread between advertised and realised APY and what rewards need to be swapped etc.

Describe alternatives you've considered
NA

Additional context
Aditional info can be found here [core contributor page only]: https://www.notion.so/alluo/Revised-Tokenomics-cefc8041471943e4b50ebc4b054ec4c3

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

Deploy Gelato price resolver for IbAlluoEUR

Summary

1. Name: Deploy Gelato price resolver for IbAlluoEUR
2. About: Build a price resolver that publishes the value of 1 IbAlluoEUR on an hourly basis

Is your proposal related to a problem?

No problem just improvements

Describe the solution you'd like

https://github.com/GetAlluo/alluo-protocol/blob/master/contracts/Farming/resolvers/IbAlluoPriceResolver.sol same then here we are going to need one for the IbAlluoEUR

It might be a good idea to find a more sustainable solution, where we could make one generic one that looks up the addresses of the IbAlluoXXX from the liquidity handler.

Additional context

IIbAlluo & IbAlluoUSD

Summary

1. Name: Interest Bearing $LPALLUO - Interface & IbAlluoUSD
2. About: new version of the ALLUO LP which represent a share of the total value deposited (TVD)

Is your proposal related to a problem?

No problem, just improvement in gas cost of most operations that today require the claim function to be called.

Describe the solution you'd like

We need to build a standard interface that can be used to build multiple ibAlluo and build the first iteration of this new token for USD stable coins.

The interface should cater to this logic:

• When I call deposit() and it transferFrom() my Stablecoin, I get ibAlluoUSDC which represents my yield-bearing deposit. 100 ibAlluoUSD =100 of the stables for this implementation (any of this 3 USD pegged stables: USDC, USDT, DAI), compounding at the Advertised APY

• When I call withdraw(), I give back the ibAlluoUSDC and get back a number of stable coin tokens (any of the 3 stables, can be specified by user) equal to 1 Stable * number of ibAlluoUSD * (1+x) (where x is a factor linked to the interest rate and the amount of time I locked my ibAlluoUSD for)

• Once the Stable is deposited, it should be converted using the alluo-exchange to a Target stable, for the IbAlluoUSD the Target coin will be USDC on Polygon (0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174) then dropped into the Gnosis Safe Multisig (https://gnosis-safe.io/app/matic:0x2580f9954529853Ca5aC5543cE39E9B5B1145135/balances) (this is temporary until we can do the auto-investment according to DAO votes)

• Admin should be able to set the interest rate / APY promised for this IbAlluo. This will be changed to a snapshot vote after some real life testing.

The interface should be based on ERC20 so that the mobile app can call getBalance(), transfer(), etc. to perform all normal operations.

Admin of the contract should be set to Gnosis Multisig: https://gnosis-safe.io/app/matic:0x2580f9954529853Ca5aC5543cE39E9B5B1145135/balances

This token should be tested and deployed on Polygon to replace the current implementation: https://polygonscan.com/address/0x29c66cf57a03d41cfe6d9ecb6883aa0e2aba21ec#code

Ideally, we should be able to Upgrade the current implementation to avoid any migration issue and transfer of state.

Additional context

This will be used by the rest of the protocol and future features like Leverage.

Missing liquidityBuffer Check

https://github.com/GetAlluo/alluo-protocole/blob/6e8908b3394d325a2a1186758628a0e2de06cb0f/contracts/StablePool.sol#L100

This is not correct, as per the diagram, the deposits should first be sent to the liquidityBuffer.

If and only if the liquidity buffer is full then they should be sent to the farmingVault to be farmed.

https://app.diagrams.net/#G1XdAkHqRew_pef-1-mKYScVdemdRZWjyt

Build automation to manage the StIbAlluo's liquidation of streams

Is your feature request related to a problem? Please describe.
WIP

Describe the solution you'd like
WIP

Describe alternatives you've considered
WIP

Additional context
WIP

[Polygon] Build IbAlluoBTC

Summary

1. Name: IbAlluoBTC
2. About: Implementation of BTC farm on Polygon

Is your proposal related to a problem?

No problem, just enabling the protocol

Describe the solution you'd like

Build a standard IbAlluo following the same standard as the IbAlluoETH from: #19

The liquidity buffer will be this curve pool: https://polygon.curve.fi/ren we might need to build a new LiquidityHandler.sol Adaptor, if that is the case, please update this issue.

Additional context

[Polygon] IbAlluoEUR & EUR adaptor

Summary

1. Name: IbAlluoEUR & EUR adaptor
2. About: Implementation of #17 for Euro pegged stable coins

Is your proposal related to a problem?

No problem, just enabling the protocol

Describe the solution you'd like

This is the second implementation of the IbAlluoXXX for all Euro pegged coins.

Input coins should be:

• jEUR: https://polygonscan.com/token/0x4e3decbb3645551b8a19f0ea1678079fcb33fb4c
• EURS: https://polygonscan.com/token/0xe111178a87a3bff0c8d18decba5798827539ae99
• EURT: https://polygonscan.com/token/0x7BDF330f423Ea880FF95fC41A280fD5eCFD3D09f

Second part is implementation of EUR adaptor for the new version of LiquidityBuffer.sol described in #20

Target pool: https://polygon.curve.fi/factory/37

Primary token EURT. Means that deposited amount that exceeds buffer percentage should be converted to EURT (if needed) and transferred to Admin:
https://gnosis-safe.io/app/matic:0x2580f9954529853Ca5aC5543cE39E9B5B1145135/balances

This should leverage the IIbAlluo build in #17

Additional context

Price feed router

Is your feature request related to a problem? Please describe.
Today for both our IbAlluoXXX and for the voteExecutor and strategies, we need to have some sort of price feed for the Tokens we are moving around.

We could build an oracle feed in each of the contracts, but this might lead to a difference in price across the whole protocol if we do not use the same price routes in all parts of the system.

Describe the solution you'd like
The idea would be to build a smart contract that is a central part of the system, which would allow another part of the protocol to fetch the exact price of a token in USD.

The view function would take 2 inputs: token address, output fiat currency wanted (from a list of USD, GBP, EUR) and would return the exact price of the Token in the output fiat.

There should be another set of write functions (should only be writable by the admin) that would allow us to program a set of path to price.

The paths could be a combination of (for now) 2 different steps:

• curve pool price
  • https://polygonscan.com/address/0xB446BF7b8D6D4276d0c75eC0e3ee8dD7Fe15783A#readContract is an example of the eurt to 3crv, we should be able to view price of eurt to 3crv.
• price feed oracle contract from chainlink:
  • here is an example contract from chainlink https://polygonscan.com/address/0x9b88d07B2354eF5f4579690356818e07371c7BeD#readContract we should be able to just call the getRoundData() as one of the step

Each step in a path should be able to be combined, for example, we should be able to program the following route:

• Asking EURT to USD price \
• Curve: EURT -> 3CRV via EURT/3CRV pool
• Chainlink Oracle: DAI (from 3CRV) -> USD via chainlink oracle

Describe alternatives you've considered
Alaternative would be to program these sort of paths in each IbAlluo and in vote executor.

Additional context
Add any other context or screenshots about the feature request here.

IbAlluo returns the correct amount of Entry coin based on requsted Value

Is your feature request related to a problem? Please describe.
For off ramping an asset to a currency the user mobile app needs to be able to request x value of the asset and be returned y unit of the asset

Describe the solution you'd like
2 functions:

• 1 view function which would allow a user to figure out how many units of an asset he would get to have x value in the base currency of the farm.
• Change the withdraw function where you would just need to input the amount of the base asset you want out and get x unit of the asset

Both the functions above will rely on a Price Oracle. Let's make it an option in the IbAlluo standard to have this inputed in the constructor along with the rest of the inputs.

We will there need to have the option to add an oracle per input coin of the farm.

Ideally we can try this with the USD farm and here is the oracles for each of the input coins:

• USDC: 0xfE4A8cc5b5B2366C1B58Bea3858e81843581b2F7
• USDT: 0x0A6513e40db6EB1b165753AD52E80663aeA50545
• DAI: 0x4746DeC9e833A82EC7C2C1356372CcF2cfcD2F3D

Describe alternatives you've considered
The front end could call the oracles and check how much it would need to withdraw, but the issue with that is that different front ends might use different oracles which might lead to issues. Easier for the user if this is managed at the contract level.

Additional context
NA

Implement a module / library all alluo governance contracts can opt into for frontrunning protection

Is your feature request related to a problem? Please describe.
Today the biggest issue we have with liquidity direction on standard EVM chains is with frontrunning.

Our exchange is not well equipped to deal with it as setting the min output parameter is almost impossible on chain safely.

Therefore, using the offchain tenderly oracle that has been drafted, we should build a module that we can import into governance contracts.

Describe the solution you'd like
WE should have a contract that can be imported, with the following details:

1. A function that signals a request off chain for prices to be updated for requested tokens

2. A function that can fill in programatically the minOutput slippage parameter in every single exchange function

3. A modifier that rejects frontrunning prone transactions to happen if prices have not been updated in a fixed number of time.

This is very important for our governance contracts.

Describe alternatives you've considered

Additional context
Use the tenderly oracle that has been created

Clacuate how much of the yield farming rewards should be redistributed vs compuonded

Is your feature request related to a problem? Please describe.
Given #100 and assuming the results fo the governance vote https://vote.alluo.com/#/proposal/0xd654f8fdac284cfd93cc51d1b3af646b539e2c366bbf190302a82dc81f337473 stays favourable.

We need to automate the calculation of how much yield farming rewards should be converted to either cvxETH or ETH to be redistributed to all lockers. Today this can be done manually but takes a few hours to calculate and then execute. Automation should bring lots more decentralisation and transparency. There is however quite a big challenge around calculating value without knowing the price of tokens.

Describe the solution you'd like
There are 2 main components to this problem:

1. a gelato resolver calling a function in the rewardCalculation.sol contract that is responsible for doing this math.
2. a rewardCalculation contract which will take all the current invested strategies and perform the math.

The logic that needs to be applied can be split into a few steps:

• understand advertised APY (from IbAlluos). This function should be able to understand the advertised APY for each IbAlluo and its corresponding strategy.
• understand how many rewards tokens the strategies hold since the last execution of the reward distribution. This might require us to redeploy strategies to add a view function where the number of rewards can be queried.
• withdraw the enough of the reward tokens for this cycle compounding.
• send reward tokens to the voteExecutor.sol.

We shouldn't worry about the USD value of the LP but rather focus on removing the difference in advertised APY and realised APY percentage of the total tokens.

Describe alternatives you've considered
We could do all of this via a centralised entity, but mehhhh

Additional context
Add any other context or screenshots about the feature request here.

Bug Bounty Program - HIGH TIER

Bounty Table

Please use this structured bounty table for general guidance. All final decisions are at the discretion of Alluo DAO and the community.

Severity	Payment (50% in $ALLUO 50% in $ALLUOLP)	Gitcoing link
Low	$250	Dework funding
Medium	$500	Dework funding
High	$5,000	Dework funding
Critical	$25,000	Dework funding

This issue is specifically for the High Tier

If you would like to work on a tier that is higher please submit work to the relevant issue.
Once submitted, work will be reviewed and at the discretion of the Alluo DAO following the OWASP model and then assigned to the correct Severity Level.

Response Targets

Alluo will make a best effort to meet the following SLAs for Contributors participating in our program:

Type of Response SLA in business days:

• First Response 3 days
• Time to Triage 5 days
• Time to Bounty 30 days
• Time to Resolution depends on severity and complexity

We’ll try to keep you informed about our progress throughout the process.

Information & Resources

The Alluo protocol is a cross-chain liquidity management protocol that aims to acquire its liquidity via bringing no-coiners on-chain via its Neo-Bank like, non-custodial, backend free (and soon open sourced) mobile apps (andoird & iOS)

The features and improvements that the Core-Contributors team is working on are available on our public roadmap.

More documentation about the protocol and how it is working are a work in progress.

If you have any questions, feel free to reach out on Discord

Scope

All public assets, smart contracts and others that are public in the Alluo's Github repo are part of the scope.

Installation & Setup

We have guides available for how to get a deploy all the code locally in each separate repository. Generally, the Core-Contributor use Hardhat as a framework. See each repo for step-by-step walk-throughs.

Feel free to reach out to our Discord for help.

Program Rules

• Email reports to [email protected]
• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
• When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.

Out of scope vulnerabilities

When reporting vulnerabilities, please consider (1) attack scenario/exploitability, and (2) the security impact of the bug. The following issues are considered out of scope:

• Mentions of secrets, access tokens, private keys, etc. in Github, will be considered out of scope without proof that they are in use in production
• alluo.com and alluo.finance
• any subdomain of *.alluo.com
• Intercom add-on on any asset (the in-browser chat application)
• SGX-related issues or vulnerabilities
• Issues/bugs/vulnerabilities specific to the given Ethereum client (Geth or Parity)
• OS-related vulnerabilities
• Clickjacking on pages with no sensitive actions.
• Unauthenticated/logout/login CSRF.
• Attacks requiring MITM or physical access to a user's device.
• Previously known vulnerable libraries without a working Proof of Concept.
• Comma Separated Values (CSV) injection without demonstrating a vulnerability.
• Missing best practices in SSL/TLS configuration.
• Email or DNS configurations
• Site or domain configuration
• Any activity that could lead to the disruption of our service (DoS; please set up POCs on a private chain).
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

Thank you for helping keep Alluo and our community safe!

Improve USD farm exposure calculations for the treasury

Is your feature request related to a problem? Please describe.

At the moment, we mint iballuos whenever gnsois deposits into iballuo to refill buffers.

However, when we reduce treasury exposure on mainnet, we don't burn iballuos.

This means that we can have an inconsistent iballuo balance of gnosis compared to how much gnosis really owns.

Furthermore, when we increase treasury exposure on mainnet, we don't mint the correct amount back to the treasury.

Describe the solution you'd like

Whenever we increase treausry exposure, mint the correct iballuo balance on polygon

Whenever we decrease treasury exposure, burn the correct iballuo balance of gnosis on polygon

Suggestion to tackle this issue

This change should happen in the VoteExecutorSlave, where if the message passed from mainnet includes a positive/negative delta for treasury exposure, we should transferFrom / transfer to the gnosis safe the correct amount of iballuousd.

IbAlluo adaptor allows update of reference coin

Summary

1. Name: IbAlluo adaptor allows update of Math reference coin
2. About: Making sure we are able to react to a change of depth of liquidity for the reference coin used for the math in any IbAlluo

Is your proposal related to a problem?

All IbAlluo reference to one specific coin (usually the one that has the deepest liquidity at the time of build) for some math.

This coin is hardcoded, and therefore if there is a change in how deep this liquidity is (UST ser ?) the math on withdrawal could be inaccurate.

https://github.com/GetAlluo/alluo-protocol/blob/14cceada727b9239a63d15c9e39ac4c01877fba9/contracts/Farming/adapters/EurCurveAdapter.sol#L85

Describe the solution you'd like

We need to improve the process so that the coin used for reference in math is a primary coin. Therefore, we should also be able to update this coin in case some things change over time.

This primary coin should be used everywhere as the leading coin that Is referenced everywhere in the math.

Additional context

This is particularly important as we start creating new IbAlluo on Polygon like the IbAlluoEUR with very low liquidity (about 4M all together at this time) and therefore the Major coin will quickly evolve.

[Polygon] single user balancer resolver (Gelato)

Summary

1. Name: [Polygon] single user balancer resolver (Gelato)
2. About: Build a resolver that will emit the balance of the user on a daily basis.

Is your proposal related to a problem?

No problem, just improvement

Describe the solution you'd like

WIP

There is no way to know today what the user's balance was yesterday or a few weeks ago. This is very useful metadata for analytics purposes.

Additional context

This resolver event will be used by the mobile app but also by the BE to create analytics allows the core team and the community to analyse growth and give feedback to the users on their gains.

Deploy IbAlluoBTC to mainnet

Is your feature request related to a problem? Please describe.
Most of the liquidity is on Mainnet, we are hoping that by deploying the IbAlluoBTC on Mainnet we will attract even more TVL to the protocol.

Describe the solution you'd like
Deploy the IbAlluoBTC with the same entry coins as on polygon to ETH mainnet.
Plz work with @0-xec to get ETH for gas.

We will of course have to remove the St ability of the IbAlluo standard, as Superfluid is not on mainnet.

Could we explore depositing the funds directly into the voteExecutor V3 rather then in gnosis as well (0x4Fd58328C2e0dDa1Ea8f4C70321C91B366582eA2)

Describe alternatives you've considered
No alternative ETH mainnet is king

Additional context
The entry coin to use are:

• 0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599

With WBTC as the reference coin and the output coin.

[Polygon] IbAlluoETH

Summary

1. Name: IbAlluoETH
2. About: First non-stable implementation of #17

Is your proposal related to a problem?

No problem, just enabling the protocol

Describe the solution you'd like

This is the first non-stable implementation of the IbAlluoXXX for all ETH pegged coins.

Input coins should be:

• wETH: https://polygonscan.com/token/0x7ceb23fd6bc0add59e62ac25578270cff1b9f619

Deposit target & Admin: https://gnosis-safe.io/app/matic:0x2580f9954529853Ca5aC5543cE39E9B5B1145135/balances

This should leverage the IIbAlluo build in #17

In case of wETH we don't have specific pool, so we don't need adaptor.

Additional context

Deploy Gelato withdraw request resolver for IbAlluoETH

Summary

1. Name: Deploy Gelato withdraw request resolver for IbAlluoETH l
2. About: Similar then IbAlluoUSD, just for ETH

Is your proposal related to a problem?

No problem

Describe the solution you'd like

Same as the previous IbAlluoUSD we need to deploy the Gelato resolver to check if there are any withdrawal requests that can be satisfied with the current state of the buffer in the IbAlluoETH

Design

NA

Additional context

NA

Tie up vlAlluo V3 and Yield booster vault

Is your feature request related to a problem? Please describe.
Today, the rewards distributed to lockers is held in CVX/ETH in the VoteLocker contract. We have a new product that allows us to boost CVX/ETH LP APY https://github.com/GetAlluo/yield-booster. Let’s meeeeerrrrggggeeeee.

Describe the solution you'd like
The idea here would be to remove the logic that deposits rewards from the liquidity direction into the CVX/ETH pool from the locker and instead, it would simply deposit the ETH that it gets from the Vote Executor (from the rewards) into the Yield booster CVX/ETH pool.

The CVX/ETH pool will take care of the compounding of the LP and taking a fee for the treasury. The Locker contract should handle the redistribution allowance for each of the locker.

There are 2 main ways to do this, either, somehow the the vault is passed all the addresses of the lockers, and it is the one handling the how much each locker is entitled to a share of the vault or we keep all this math in the Locker contract. @pentatonictritones should be able to help with this.

Describe alternatives you've considered
No alternatives.

Additional context
Add any other context or screenshots about the feature request here.

Add ability to estimate amount of rewards earned by user between harvesting cycles

Is your feature request related to a problem? Please describe.
Today, there is no way for a user to know how many rewards he has pending since the last harvest cycle. This could lead to him exiting the pool on day 6 of the harvest cycle and therefore losing all his pending rewards rather than waiting one day and getting the full rewards he has earned.

Describe the solution you'd like
TBD but the goal is to have a view function that would allow the FE to view how many rewards are pending so we can display this info to the user.

Describe alternatives you've considered
No real alternative

Additional context
NA

Make advertised APY a global variable that can be modified by the DAO

https://github.com/GetAlluo/alluo-protocole/blob/6e8908b3394d325a2a1186758628a0e2de06cb0f/contracts/StablePool.sol#L42

This needs to be something that the DAO can change, ideally, it would be referenced from the DAO contract so we only have one source of truth rather than have a local variable in all different contracts that might need access to that value.

[Polygon] EIP-2771 implementation in IbAlluoXXX for use with biconomy

Summary

1. Name: [Polygon] EIP-2771 implementation in IbAlluoXXX for use with biconomy
2. About: Build EIP-2771 standard in the IbAlluoXXX so we support all FE implementing Metatx

Is your proposal related to a problem?

No problem, just improvement

Describe the solution you'd like

Implement the EIP-2771 in the IbAlluoXXX standard.

This task also includes testing the new standard with IbAlluoUSD and Biconomy as this will be the Trusted Forwarded used by the mobile app.

Please make sure to build the full tests and migration scrips

Additional context

Add valueTransfer event to transfer() and transferFrom() in IbAlluoXXX

Is your feature request related to a problem? Please describe.
WIP

Describe the solution you'd like
WIP

Describe alternatives you've considered
WIP

Additional context
WIP

Build new version of voteExecutor.sol to voteExecutorSlave.sol for L2 vote Execution

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:

The voteExecutorSlave should be able to:

• have a write function that will receive byteCode from the L1 - L2 messaging proxy, it should also verify that the bytecode was signed by a recognised signer
• have an internal function that is able to decode the bytecode and according to the action call another internal function corresponding.
• second internal function that is made for executing the change of APY for the IbAlluoXXX

Additional context

Deploy Exchange on ETH Mainnet

Is your feature request related to a problem? Please describe.
Becasuse of #82 and #83 we need to deploy the exchange on ETH mainnet so users are able to deposit any of the 3 entry coins.

Describe the solution you'd like
Same as on polygon, we need to deploy the exchange and make sure that we have the correct adaptor and routes.

Describe alternatives you've considered
No alternative.

Additional context
We need to cover the following conversions:
USDC <-> USDT
USDC <-> DAI
With DAI as a major coin

EURs <-> EURT
EURT <-> jEUR
With EURT as a major coin

Build Gelato resolver to trigger execute in voteExecutorMaster.sol

Summary

1. Name: Build Gelato resolver to trigger execute in voteExecutorMaster.sol
2. About: Gelato resolver that will check if VOTE_INSTRUCTIONS_CHECKED is true and if 24hrs have passed since last bytecode sent then trigger execute() on L1

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:

should do the 2 checks, and if all ok, should run trigger execute() on voteExecutorMaster.sol

Additional context

Make IbAlluo.sol more storage efficient

Is your feature request related to a problem? Please describe.

Currently the contracts/farming/polygon/IbAlluo.sol is congested with admin functions and is reaching max contract capacity. This ticket is to combine many of these functions, cut down on bloated revert strings.

Describe the solution you'd like

Create more concise revert strings, make admin functions more storage efficient. Cut down on large view functions that are not being used / can be done off chain very simply. We can create a js frontend library instead for these things.

However, this will cause many many tests to fail so we need to go through every farming test and fix them to be compatible.

Describe alternatives you've considered

Perhaps adopting a different standard for upgradeability like diamonds. However, this is not necessary at the moment.

Additional context
No

Implement mid-cycle deployment of funds for liquidity direction

Is your feature request related to a problem? Please describe.
Today, funds deposited through polygon farms are bridged directly to the VoteExecutorMaster on Ethereum mainnet, where it sits until the next deployment cycle to be deployed.
Describe the solution you'd like

We should write a new contract / extend the VoteExecutorMaster to enable mid-cycle deployment of funds once a certain profitability threshold is reached.

Depositing into strategies should be done first, however, future compatability for withdrawals should be achieved.

Describe alternatives you've considered
none

Additional context
Use gas oracles to roughly estimate profitability of depositing

Improvement of gas utilisation for Boosted Vaults

Is your feature request related to a problem? Please describe.
Today the amount of gas used to loop rewards and deposit into the Boosted pool is quite high, because each vault does all the operations individually rather than bulk them with other pools. We should be able to bulk operations so that they can be performed in a more gas efficient way.

Describe the solution you'd like
Each vault will convert all rewards to cvx.

Then we will write a single central cvx-eth pool so that when the vaults deposit cvx into this booster pool contract, their balance is increased (so we can keep track of % of pool cvx-eth rewards are owned by which vault).

When we 'loopRewards' in the centralPool contract, it converts it to cvx-eth lp and stakes it into convex all together in a single transaction.

• To be clear, we still need to individually exchange all rewards to cvx in each vault because of accounting issues.

However now we will have 1 convert to cvxeth lp and 1 stake into convex
And about a feature to be added in the future ---> time weighted rewards.

So to solve the issue where users don't get rewards that are accrued before a loop / when a whale comes and drops a massive amount to eat up all the rewards before a loop, we can weight how much of the rewards belong to each user based on time staked....

Describe alternatives you've considered
Current implementation.

Additional context
Add any other context or screenshots about the feature request here.

Add maxWithdraw function to IbAlluoXXX standard

Is your feature request related to a problem? Please describe.
Today there is no way to withdraw all the funds from your wallet.

We need to add a maxWithdraw() function to allow users to withdraw in what ever asset of the IbAlluoXXX the total value they have.

Describe the solution you'd like
WIP

Describe alternatives you've considered
WIP

Additional context
WIP

Depoly Gelato withdraw request resolver for IbAlluoEUR

Summary

1. Name: Deploy Gelato withdraw request resolver for IbAlluoEUR
2. About: Similar then IbAlluoUSD, just for EUR

Is your proposal related to a problem?

No problem

Describe the solution you'd like

Same as the previous IbAlluoUSD we need to deploy the Gelato resolver to check if there are any withdrawal requests that can be satisfied with the current state of the buffer.

Design

NA

Additional context

NA

Add price router routes for beefy tokens on Polygon

Is your feature request related to a problem? Please describe.
We want to make sure that we have some price router routes for beefy tokens in order to beta test cross-chain liquidity direction.

Describe the solution you'd like
Add stargate USDT , USDC as price routes so that the temporary beefy strategy contract can mark the positions to market

https://app.beefy.com/vault/stargate-polygon-usdt
https://app.beefy.com/vault/stargate-polygon-usdc

So that testing is possible

Describe alternatives you've considered

Additional context
A ticket for adding the exchange routes as well will be added to the exchange repo.

Bug Bounty Program - CRITICAL TIER

Bounty Table

Please use this structured bounty table for general guidance. All final decisions are at the discretion of Alluo DAO and the community.

Severity	Payment (50% in $ALLUO 50% in $ALLUOLP)	Gitcoing link
Low	$250	Dework funding
Medium	$500	Dework funding
High	$5,000	Dework funding
Critical	$25,000	Dework funding

This issue is specifically for the Critical Tier

If you would like to work on a tier that is higher please submit work to the relevant issue.
Once submitted, work will be reviewed and at the discretion of the Alluo DAO following the OWASP model and then assigned to the correct Severity Level.

Response Targets

Alluo will make a best effort to meet the following SLAs for Contributors participating in our program:

Type of Response SLA in business days:

• First Response 3 days
• Time to Triage 5 days
• Time to Bounty 30 days
• Time to Resolution depends on severity and complexity

We’ll try to keep you informed about our progress throughout the process.

Information & Resources

The Alluo protocol is a cross-chain liquidity management protocol that aims to acquire its liquidity via bringing no-coiners on-chain via its Neo-Bank like, non-custodial, backend free (and soon open sourced) mobile apps (andoird & iOS)

The features and improvements that the Core-Contributors team is working on are available on our public roadmap.

More documentation about the protocol and how it is working are a work in progress.

If you have any questions, feel free to reach out on Discord

Scope

All public assets, smart contracts and others that are public in the Alluo's Github repo are part of the scope.

Installation & Setup

We have guides available for how to get a deploy all the code locally in each separate repository. Generally, the Core-Contributor use Hardhat as a framework. See each repo for step-by-step walk-throughs.

Feel free to reach out to our Discord for help.

Program Rules

• Email reports to [email protected]
• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
• When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.

Out of scope vulnerabilities

When reporting vulnerabilities, please consider (1) attack scenario/exploitability, and (2) the security impact of the bug. The following issues are considered out of scope:

• Mentions of secrets, access tokens, private keys, etc. in Github, will be considered out of scope without proof that they are in use in production
• alluo.com and alluo.finance
• any subdomain of *.alluo.com
• Intercom add-on on any asset (the in-browser chat application)
• SGX-related issues or vulnerabilities
• Issues/bugs/vulnerabilities specific to the given Ethereum client (Geth or Parity)
• OS-related vulnerabilities
• Clickjacking on pages with no sensitive actions.
• Unauthenticated/logout/login CSRF.
• Attacks requiring MITM or physical access to a user's device.
• Previously known vulnerable libraries without a working Proof of Concept.
• Comma Separated Values (CSV) injection without demonstrating a vulnerability.
• Missing best practices in SSL/TLS configuration.
• Email or DNS configurations
• Site or domain configuration
• Any activity that could lead to the disruption of our service (DoS; please set up POCs on a private chain).
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

Thank you for helping keep Alluo and our community safe!

Bug Bounty Program - MEDIUM TIER

Bounty Table

Please use this structured bounty table for general guidance. All final decisions are at the discretion of Alluo DAO and the community.

Severity	Payment (50% in $ALLUO 50% in $ALLUOLP)	Gitcoing link
Low	$250	Dework funding
Medium	$500	Dework funding
High	$5,000	Dework funding
Critical	$25,000	Dework funding

This issue is specifically for the Medium Tier

If you would like to work on a tier that is higher please submit work to the relevant issue.
Once submitted, work will be reviewed and at the discretion of the Alluo DAO following the OWASP model and then assigned to the correct Severity Level.

Response Targets

Alluo will make a best effort to meet the following SLAs for Contributors participating in our program:

Type of Response SLA in business days:

• First Response 3 days
• Time to Triage 5 days
• Time to Bounty 30 days
• Time to Resolution depends on severity and complexity

We’ll try to keep you informed about our progress throughout the process.

Information & Resources

The Alluo protocol is a cross-chain liquidity management protocol that aims to acquire its liquidity via bringing no-coiners on-chain via its Neo-Bank like, non-custodial, backend free (and soon open sourced) mobile apps (andoird & iOS)

The features and improvements that the Core-Contributors team is working on are available on our public roadmap.

More documentation about the protocol and how it is working are a work in progress.

If you have any questions, feel free to reach out on Discord

Scope

All public assets, smart contracts and others that are public in the Alluo's Github repo are part of the scope.

Installation & Setup

We have guides available for how to get a deploy all the code locally in each separate repository. Generally, the Core-Contributor use Hardhat as a framework. See each repo for step-by-step walk-throughs.

Feel free to reach out to our Discord for help.

Program Rules

• Email reports to [email protected]
• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
• When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.

Out of scope vulnerabilities

When reporting vulnerabilities, please consider (1) attack scenario/exploitability, and (2) the security impact of the bug. The following issues are considered out of scope:

• Mentions of secrets, access tokens, private keys, etc. in Github, will be considered out of scope without proof that they are in use in production
• alluo.com and alluo.finance
• any subdomain of *.alluo.com
• Intercom add-on on any asset (the in-browser chat application)
• SGX-related issues or vulnerabilities
• Issues/bugs/vulnerabilities specific to the given Ethereum client (Geth or Parity)
• OS-related vulnerabilities
• Clickjacking on pages with no sensitive actions.
• Unauthenticated/logout/login CSRF.
• Attacks requiring MITM or physical access to a user's device.
• Previously known vulnerable libraries without a working Proof of Concept.
• Comma Separated Values (CSV) injection without demonstrating a vulnerability.
• Missing best practices in SSL/TLS configuration.
• Email or DNS configurations
• Site or domain configuration
• Any activity that could lead to the disruption of our service (DoS; please set up POCs on a private chain).
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

Thank you for helping keep Alluo and our community safe!

Enable full liquidity direction cross-chain

Is your feature request related to a problem? Please describe.
Today our liquidity direction automation only works on a single chain. This ticket should:

1. Enable funds to be chain-agnostic, meaning customer funds can be automatically deployed to different chains simultaneously.

2. Allow continuous rate-limited deposits and withdrawals to reduce idle funds and automate satisfying withdrawals.

Describe the solution you'd like

Write new VoteExecutorMaster

Write new VoteExecutorSlave

Write StrategyHandlers

Enable bridging and cross-chain messaging.

Describe alternatives you've considered

Additional context

https://docs.google.com/document/d/1nd82gg6b2AHBNxkGkO2YKHKcFPNL-bDPUbMjxcDieBY/edit?usp=sharing

Liquidity buffer management for ibAlluoUSD + stIbAlluoUSD

Context

To ensure confidence in the protocol, we need to make sure we can let users withdraw their deposits as fast as possible - to ensure this is the case, we keep some funds in a buffer that allows the conversion between ibAlluoUSD/stIbAlluoUSD to one of the 3CRV (usdc, dai, usdt)

Task

Once every X hours (start with once every 24 hours, ideally every block)

Check if there are any pending withdrawals that haven't been satisfied

• If there are then add to the Buffer the pending withdrawal amount + the Target buffer (net of any remaining amount in buffer) amount then call satisfywithdrawal

Otherwise

• Check where buffer is with respect to Min and Max
  • If Buffer < min Buffer, then replenish buffer to Target buffer $
  • If Buffer > max Buffer, withdraw buffer to Target buffer $

Constraint:
Have a max top up amount (e.g. max top up of 250k in any 24h period) that can be overriden to ensure hacks cannot drain more than Y

Set Target buffer as 10% of the Withdrawable ibAlluoUSD + StIbAlluoUSDSet Max buffer as 15% of the Withdrawable ibAlluoUSD + StIbAlluoUSDSet Min buffer as 5% of the Withdrawable ibAlluoUSD + StIbAlluoUSD

Details

See this spreadsheet for more details: https://docs.google.com/spreadsheets/d/1mBFPA_gjTbK4r6BO4OPoLQR-G4rtFQ84QTd603Wh7hw/edit#gid=0

Modify voteExecutor.sol to to voteExecutorMaster.sol vote automated DAO vote execution

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:

The voteExecutorMaster should be able to:

• have a write function that will store a byteCode (contain vote execution instructions), this should be an open function, anyone should be able to send byteCode to the contract
• have a write function that will enable the Gnosis safe (might need a new role for this) that will switch a flag VOTE_INSTRUCTIONS_CHECKED from FALSE to TRUE
• have a write function that can be called by anyone that will:
  - check if 24hrs since the byteCode has been added to contract (can use number of block, 960 is about 24hrs)
  - check if VOTE_INSTRUCTIONS_CHECKED is true
  - send the byteCode to the cross-chain messaging proxy as started here: https://github.com/GetAlluo/liquidity-direction-protocol/tree/layer2messaging
  - set the VOTE_INSTRUCTIONS_CHECKED back to false

Additional context

Deploy IbAlluoEUR on ETH mainnet

Is your feature request related to a problem? Please describe.
Most of the liquidity is on Mainnet, we are hoping that by deploying the IbAlluoEUR on Mainnet we will attract even more TVL to the protocol.

Describe the solution you'd like
Deploy the IbAlluoUSD with the same entry coins as on polygon to ETH mainnet.
Plz work with @0-xec to get ETH for gas.

We will of course have to remove the St ability of the IbAlluo standard, as Superfluid is not on mainnet.

Could we explore depositing the funds directly into the voteExecutor V3 rather then in gnosis as well (0x4Fd58328C2e0dDa1Ea8f4C70321C91B366582eA2)

Describe alternatives you've considered
No alternative ETH mainnet is king

Additional context
The 3 entry coins to use are:

• 0x6B175474E89094C44Da98b954EedeAC495271d0F
• 0xC581b735A1688071A1746c968e0798D642EDE491
• 0x0f17BC9a994b87b5225cFb6a2Cd4D667ADb4F20B

With EURT as the reference coin and the output coin.

[Polygon] Superfluid implementation for IbAlluo

Summary

1. Name: Superfluid implementation for IbAlluo
2. About: Implement the ability to stream IbAlluo tokens to a destination address using the superfluid API

Is your proposal related to a problem?

No problem, just enabling the protocol

Describe the solution you'd like

The idea here would be to be able to stream IbAlluo tokens from one address to another using the CFA library from superfluid. The greater picture is that this would allow ppl to borrow against a Stream to be money in advance for free because we would use the Interest of the token to pay the protocol and the lender (person funding the stream).

There are really 4 main things to do:

• Convert the IbAlluo interface into a StreamingIntersetBearingAlluo token (StIbAlluo)
• Implement the Constant Flow Agreement wrapper for the StIbAlluoXXX tokens
• Implement the StIbAlluo interface in the IbAlluoUSD

The StIbAlluo will need to follow the Super standard described here by Superfluid: https://docs.superfluid.finance/superfluid/protocol-developers/super-tokens

The challenge however is that we want the StIbAlluo to be backwards compatible with ERC20 and with the older IbAlluo. We should therefore have the option to use the streaming functionality or not. This is to enable the mobile app users to choose this feature or not.

Additional context

Bug Bounty Program - LOW TIER

Bounty Table

Please use this structured bounty table for general guidance. All final decisions are at the discretion of Alluo DAO and the community.

Severity	Payment (50% in $ALLUO 50% in $ALLUOLP)	Gitcoing link
Low	$250	Dework funding
Medium	$500	Dework funding
High	$5,000	Dework funding
Critical	$25,000	Dework funding

This issue is specifically for the Low Tier

If you would like to work on a tier that is higher please submit work to the relevant issue.
Once submitted, work will be reviewed and at the discretion of the Alluo DAO following the OWASP model and then assigned to the correct Severity Level.

Response Targets

Alluo will make a best effort to meet the following SLAs for Contributors participating in our program:

Type of Response SLA in business days:

• First Response 3 days
• Time to Triage 5 days
• Time to Bounty 30 days
• Time to Resolution depends on severity and complexity

We’ll try to keep you informed about our progress throughout the process.

Information & Resources

The Alluo protocol is a cross-chain liquidity management protocol that aims to acquire its liquidity via bringing no-coiners on-chain via its Neo-Bank like, non-custodial, backend free (and soon open sourced) mobile apps (andoird & iOS)

The features and improvements that the Core-Contributors team is working on are available on our public roadmap.

More documentation about the protocol and how it is working are a work in progress.

If you have any questions, feel free to reach out on Discord

Scope

All public assets, smart contracts and others that are public in the Alluo's Github repo are part of the scope.

Installation & Setup

We have guides available for how to get a deploy all the code locally in each separate repository. Generally, the Core-Contributor use Hardhat as a framework. See each repo for step-by-step walk-throughs.

Feel free to reach out to our Discord for help.

Program Rules

• Email reports to [email protected]
• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
• When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.

Out of scope vulnerabilities

When reporting vulnerabilities, please consider (1) attack scenario/exploitability, and (2) the security impact of the bug. The following issues are considered out of scope:

• Mentions of secrets, access tokens, private keys, etc. in Github, will be considered out of scope without proof that they are in use in production
• alluo.com and alluo.finance
• any subdomain of *.alluo.com
• Intercom add-on on any asset (the in-browser chat application)
• SGX-related issues or vulnerabilities
• Issues/bugs/vulnerabilities specific to the given Ethereum client (Geth or Parity)
• OS-related vulnerabilities
• Clickjacking on pages with no sensitive actions.
• Unauthenticated/logout/login CSRF.
• Attacks requiring MITM or physical access to a user's device.
• Previously known vulnerable libraries without a working Proof of Concept.
• Comma Separated Values (CSV) injection without demonstrating a vulnerability.
• Missing best practices in SSL/TLS configuration.
• Email or DNS configurations
• Site or domain configuration
• Any activity that could lead to the disruption of our service (DoS; please set up POCs on a private chain).
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

Thank you for helping keep Alluo and our community safe!

Deploy IbAlluoETH on eth mainnet

Is your feature request related to a problem? Please describe.
Most of the liquidity is on Mainnet, we are hoping that by deploying the IbAlluoETH on Mainnet we will attract even more TVL to the protocol.

Describe the solution you'd like
Deploy the IbAlluoUSD with the same entry coins as on polygon to ETH mainnet.
Plz work with @0-xec to get ETH for gas.

We will of course have to remove the St ability of the IbAlluo standard, as Superfluid is not on mainnet.

Could we explore depositing the funds directly into the voteExecutor V3 rather then in gnosis as well (0x4Fd58328C2e0dDa1Ea8f4C70321C91B366582eA2)

Describe alternatives you've considered
No alternative ETH mainnet is king

Additional context
The only entry coin to use is:

• 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2

With weth as the reference coin and the output coin.