badger-finance / badger-system

Badger Finance

Badger Finance is a community DAO, focused on bringing Bitcoin to DeFi. The DAO's debut products are Sett, a yield aggregator, and Digg, a BTC-pegged elastic supply currency.

Visit our GitBook for more detailed documentation.

Build

The Badger contracts & tests are built around the Eth-Brownie Python framework.

If you're not familiar with brownie, see the quickstart guide.

Dependencies

• Python 3.9
• Node.js 10.x development environment (for Ganache).
• Eth-Brownie
• Ganache (v6.12.1)

Install

This repository is currently only supported on Linux based systems. For Windows 10 users, it is recommended to use the Windows Subsystem for Linux 2 (WSL2) in order to run Linux executables natively and interact with the system in a convenient way. Instructions on how to quickly setup WSL2 can be found here.

For Ubuntu, you can install the prerequisite packages with the following command:

sudo apt-get install -y python3 python3-virtualenv python3-pip

For other systems, install Python 3.9, Pip, and use pip to install virtualenv with

pip install virtualenv

To install NodeJS and yarn on UNIX based systems, it is recommended to use the following commands:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash
nvm install v14.16.1
npm install -g yarn

With prerequisites installed, install the project with:

git clone https://github.com/Badger-Finance/badger-system
cd badger-system
yarn install --lock-file
virtualenv venv
source venv/bin/activate
pip install -r requirements.txt

Compile

source venv/bin/activate
brownie compile

Test

source venv/bin/activate
brownie test

Add coverage and gas profiling

source venv/bin/activate
brownie test --coverage --gas

Local Instance

Run a local ganache instance connected to badger contracts, with all Sett-related assets distributed to a test account specified in the TEST_ACCOUNT env variable. Assumes the default network is mainnet-fork in the brownie config and uses Alchemy as a web3 provider through the ALCHEMYAPI_TOKEN env variable. Ganache will continue to run until the process is closed.

source venv/bin/activate
export TEST_ACCOUNT=<enter your account here>
export ALCHEMYAPI_TOKEN=<enter Alchemy key here>
brownie run scripts/local_instance.py

Running Scripts on non-Ethereum chains

The included brownie-config.yaml has configurations for running forked environments on non-ethereum chains where Badger contracts are deployed. To run scripts against another chain, append the appropriate --network parameter to any brownie run or brownie test command.

The appropriate live Badger deploy for that chain will automatically be read.

As an example, bsc-fork is the networkID for a Binance Smart Chain forked environment.

brownie run scripts/local_instance.py --network bsc-fork

Badger Deploy Files

These files maintain a registry of all live Badger contracts on a given chain.

• Ethereum Mainnet: deploy-final.json
• Binance Smart Chain: badger-deploy-bsc.json

Post-Update

• Set boost flag to false to upload boosts to production instead of staging
• Run scripts with --network mainnet instead of --network mainnet-fork

Documentation

You can read more about Badger at our GitBook.

Discussion

To join the community, head over to the Discord server.

badger-system's Issues

new thing

text

mStable guarded launch content

Bot Improvements

The Sett system requires a series of bots to perform key actions.

Earn

earn() is called on the Sett and brings deposits into the strategy position. By batching the deposits, we save gas costs for the users and ourselves.

This should be called whenever sufficient deposits have accumulated in the Sett, as defined on a per-sett basis.

Earn script

Harvest

When strategies are harvested, it realizes the profit from the strategy position activities. The most common way is claiming & selling rewards tokens.

The harvest bot needs to be more intelligent about gas usage. By doing a read call (staticcall) of the harvest function on chain, it can view what the expected profit of the harvest would be. This should exceed the expected gas price by a certain extent in order to harvest. The harvesters current harvest on a pre-defined interval, which ranges from 24 hours on Ethereum to 30 minutes for certain BSC Setts.

Harvest script

Tend

The tend() bot runs maintenance on strategy positions between harvests. It's designed to include functionality that increases the yield on harvest. (For example, rewards tokens might be staked between harvests, with any gains re-injected into the staking position)

This bot needs to have the same gas analysis as harvest(). The amount tended should justify the gas cost. It currently runs on a 12-hour schedule on ethereum.

Tend script

External Harvester

Many strategies are incentivized by Badger and/or Digg rewards. These rewards are handled by the External Harvester. This system:

• Converts badger and digg into the underlying vault tokens.
• Deposits the gains into the appropriate strategy.
• This increases the value of each shares just like gains from the strategy activities.

This should be run once a day, and be 100% reliable in doing so. If needed, we can have the contract emit more data around when the latest external harvest was for a strategy.

External harvester

Rebase

The rebase() function needs to be called within a certain window every day in order to trigger that days' DIGG rebase. The rebase reads the most recent valid reports from oracle data and enacts a supply change based on that. It is a permissionless function with no parameters, and just needs to be called as soon after the rebase window opens at 3pm EST as possible.

Rebase script

Bot Automation

The current bots run on a simple loop, in the scripts/keeper/auto folder there are variants of each bot logic that are run on a pre-defined interval. If an iteration fails, the script catches the error and tries again after the interval has passed.

You can see the keeper config for all intervals.

A note on ETH Transactions

To avoid transactions getting stuck, we use the ExponentialScalingStrategy created by brownie. This re-sends a transaction with a higher gas price if the previous one is not confirmed within a configurable amount of time. The gas price scales at a gentle exponential slope. This could use some thought as to the specific parameters to use.

Desired Improvements

Crash Handling

When a bot crashes, it does not restart automatically. The machine running the bot should restart it.

Hanging Node Connection Handling

The bot may lose connection to the node at some point. It should have a timeout, backup node, and report if it cannot reach either.

Transaction Never Posts Handling

If a transaction get stuck for too long, even with the exponential scaling strategy, it should report.

Smarter Gas Estimation

As mentioned in the tend() and harvest() sections.

Xuefeng - A UI To debug Vaults and Strategies for V2

Deliverables

The React code for a website

The website will interact with the onChain registry to pull the vaults from a given author

For each vault, show all the view data from the registry

Also allow to deposit, withdraw, harvest and tend

Also allow to run any other command on the vault or strategy

Chainlink hardcoded oracle bot script

The chainlink data updates at 2pm EST. Between 2pm & 3pm EST, the data must be posted to the medianOracle by calling getThePrice() on the adapter oracle (the adapter oracle simply converts latest chainlink data to 18 decimals and posts it to medianOracle)

Adapter oracle lives here

• Bot addresses will be added to ACL for calling oracle.

Explore/Spec fee change: Withdrawal Fee -> Management Fee

We are ultimately looking to migrate our Setts to a Yearn V2-like architecture for the multi-strategy functionality and safety features. This is a longer term project, but in the meantime it would be nice to have the ability to charge management fees on our vaults rather than withdrawal fees.

Evaluate possible implementations to enable an optional management fee on the current Setts / Strategies. Is it worth the complexity required, or should we wait for V2?

• SettV3 is the latest Sett code
• BaseStrategy is extended by individual strategy logic. One can find of the contract type of all active strategies in the strategy_artifacts section of deploy_final.json.

Note that there are some older setts with a slightly different storage layout. We'll probably just maintain a separate contract file for these (SettV4Legacy.sol, or something) until we figure out a more robust migration plan during a potential change to YearnV2 architecture.

• Is it possible for management and withdrawal fees to co-exist?

Fix Strategy that report 0

Issue
in the strategy contract deployed for 0x444B860128B7Bf8C0e864bDc3b7a36a940db7D88
I was doing some task for the badger analytics tasks, and I went dig into the logic of a strategy and spotted a bug, which it is not allowing the strategy to grab properly the performance fee
while calling the harvest method
https://etherscan.io/address/0x8b60386a978dfc3241e9112db3ea009331838846#code#L1524

The problem is on that line
it should be instead harvestData.wantProcessed
that is why in all the majority of harvest tx I have inspected the performance fee deposited to governance or strategist is zero
Here an example:
https://etherscan.io/tx/0x9b5ff82c8d8a40c3e35ba39e73cb7063e38574aa2e58530ef7648450706ae4a0

You can see that in that case nothing is send as performance fee from this product
while it should be instead 0.05430035950013234 crvRenWBTC for the strategist and also for the governance
in this particular tx
Also this was one of the events emitted, where it printed 0 also due to the mentioned above

native.renCrv": "0x444B860128B7Bf8C0e864bDc3b7a36a940db7D88",
"native.sbtcCrv": "0x3Efc97A8e23f463e71Bf28Eb19690d097797eb17",
"native.tbtcCrv": "0xE2fA197eAA5C726426003074147a08beaA59403B",

Salvage test suite to run in isolation, simplify CI

Fix test suite to remove calls to interface. which are in the global scope to fix common bug

Rename existing tests/ directory to something else where we can keep the scripts that depend on specific forks / networks / other than mainnet-fork

Add fork block to brownie-config.yaml so we can replicate the environment

Salvage tests which can run at the prescribed block and keep in the new tests/ directory

Anything which works with a static fork, keep

Refiller bot that refills eth on other bots

Create approvePayload() script for new centralized oracle

It should verify the value is within X% of the proposed payload based on it's own rendition of the same calculation.

(The bot needs a different account than the proposer)

Add fork block number to brownie-config.yaml

Add an environment variable for the intended fork block on the brownie-config.yaml file that defaults to the latest block. This will allow users to run test suites meant for an specific mainnet fork block as needed.

Additionally, the testing section on the README needs to be adjusted accordingly.

Auto-compounding Rewards Bot - Refactor

The BadgerRewardsManager manages the auto-compounding portion of incentive rewards.

It's bot script could use some improvement as it was quickly written as an MVP.

• Dedup the logic. There is code that is repeated for each sett rather than being done in a generalized fashion.
• Use an on-chain data source for reading the amount of rewards to inject (currently reads from active_emissions.py config file)

On-chain data source

The data can be the same format as the Emission schedules for the BadgerTree. A new RewardsLogger contract can supply information to the bots. This will define unlock schedules as "A given Sett will earn X tokens of type Y over a week, starting from timestamp A)

Flexibility

It should emit events to understand the last time each given operation was taken.
It should be able to fail at any part of the transactions and resume where it left off.
It should use multisend to batch all operations related to a sett, such that they are atomically executed (Important for reducing complexity of the above)

Pancake strategy LP-creation optimization

badger-system/contracts/badger-sett/strategies/pancake/StrategyPancakeLpOptimizer.sol

Line 303 in 2b0ee9b

swapData.convertedToToken0 = amount.div(2);

maybe we could consider the babylonian calculation proposed by Alpha Homora team?
https://blog.alphafinance.io/onesideduniswap/

Rari Fuse Pool Accept Admin

call _acceptAdmin on the pool Comptroller from the dev multisig

https://etherscan.io/address/0xe3952d770fb26cc61877cd34fbc3a3750881e9a1#writeContract

MiniDeploys should only distribute relevant assets from whales

distribute_from_whales should optionally take a list of assets to distribute. This will speed up test setup time by drastically reducing the number of TX required.

Where is this file

Hi , I would like to call claim but I got stuck in getting merkle Proof
in your test file, the merkle Proof seems from this file

rewardsFile = (
"rewards-1-0x5da9ee3f9424d85a599405f3375709481bcf49d39c757372ac52763f0491c4c1.json"
)

but where is this file?

or could you give an example of getting merkle proof in claiming badger and digg?

AffiliateToken deposit precision

The deposit functions:

• Takes the want from the user and deposits it into vault
• Calculates the vault shares it expects to receive via _sharesForValue()
• Mints a corresponding number of wrapper shares to user
  

The issue arrises in _sharesForValue()

The total balance of the wrappers' vault shares is calculated to be less than the amount deposited.

Say, 1000 wei deposited vs 998 value calculated. Beacuse of this, the subtraction of the original amount deposited reverts.

Digging further into totalVaultBalance(), we can see the calculation.

Write a script to test E2E rewards flow

Now that we don't rely on raw events to generate the rewards data, we can easily E2E test the rewards flow in a single script.

Each new rewards releases should be tested with the following two tests:

Results Comparison

If a mechanic changed, test the result vs the current iteration. Each users' amounts and metadata should be compared along with the overall results.

E2E Flow

We should test the full rewards flow in a forked env to ensure it will work in prod when new mechanics are introduced

• propose_root generates data and uploads files
• approve_root sees that a root is proposed and confirms the results (also re-uploads files)
• logic from test_all_claims.py should be used to ensure that claims work as expected

So the test script should combine all these actions in a forked env, uploading the files to test directories.

(Take care not to override the prod files during the testing scenario)

The GR9 Badger Builder Honey Pot

The GR9 Badger Builder Honey Pot

The explosive growth of the Badger DAO over the last three months has led to a number of challenges and opportunities. As a major supporter, Badger DAO recognizes how Gitcoin enables and encourages the future of Open Source.

Badgers never hide; we like to build in the open with our community. More community, more engagement, and more building the products our users and participants love. We’re always in search of new Badger Builders to grow the protocol, the ecosystem, and help Badger DAO bring BTC to DeFi.

Gitcoin nestles in comfortably with the Badger ecosystem grants and the Badger Annexe, the DAO’s onboarding flow that turns users into champions, community members into contributing creators, and startups into integrated products. Any individual or team can build on Badger, some get to build with the Badgers.

The possibilities with Badger are endless. Take this opportunity to see and be seen in DeFi.

Prize Bounty

A total of 30,000 DAI, 600 Badger, 10 NFTs, and 1 Jersey will be allocated as prizes to this GR9 Hackathon’s Badger Builders. The breakdown is the following:

Challenge Description

Hackers should focus on creating projects that accelerate Bitcoin usage across blockchains and anything that would make DeFi more accessible, engaging, and fun!

A few areas to explore could be:
Furthering BTC in DeFi as collateral on multiple chains
New Sett mechanics
DIGG price stabilizing mechanisms
Gamification of bAssets, the Badger.Finance application, or anything else in relation
Innovative NFT usage
Part of what makes Crypto special is exploring your own ideas for how to use protocols, so feel free to build and submit anything Bitcoin in DeFi, Badger, or DIGG related.
Here are some examples of what a submission could look like:
A PR to uniswap.info that would make WBTC pairs tracked on the site
Come up with an original idea and build a demo for a new Sett
Demo for a new DIGG price stabilization mechanism
Gamification of bAssets and tokenized BTC
Create a mini-game for the Badger App
Port Badger app to any Alternative Layer 1 chain
Port Badger app to any Layer 2 solution
Analytics Dashboards that cover different aspects of BTC adoption in DeFi

Submission Requirements

The project needs to be open-source and released on GitHub for us to review the entire source.
The project needs to include a demo.
The project needs to include all relevant docs and links.
All submissions must list the addresses of their contracts.
The application must be USEFUL and/or INTERESTING.

Judging Criteria

The newly appointed Badger Council + guest judges, Mr. Po, and Bitcoinpalmer, will evaluate your submission.
Here are the criteria by which your work will be judged:
Is the application useful and/or interesting?
Does it align with Badgers’ core values?
The complexity of the application, protocol, or project.
Design, Usability, & Innovation.
Potential to evolve.

Winner Announcement Date

Winners to be announced within 2 weeks after the hackathon ends.

Important links

• Getting Started with Badger Finance
• DIGG FAQ
• Badger Logos

Follow us

➡️ Visit Our Website

➡️ Check Out Our Github

➡️ Join Our Community Discord

➡️ Explore our Governance Forum

➡️ Follow Us on Twitter

➡️ Connect on Telegram

Script to migrate governance.rewards() to Governance multisig

The vault controller currently forwards fees that are bound to governance to the Badger Aragon DAO. We've since decided to move the treasury to the Governance Multisig until we 100% figure out the next stage of the decentralization plan.

Create a script that changes the rewards() address of the controller to the governance multisig.

This script will need to pass through the governance timelock (based on compound governance module). You can see examples of programmatically doing this on forknet here and here.

The crvRen Sett that deposits into Harvest is on a separate controller that will also need to have it's rewards address changed.

Here is an example of a script upgrading things through the timelock.

Backup nodes for bots

Issue: Bots can hang on web3 calls if the node connection is unreliable.

They should have a backup node they can retry with after sufficient time has past. If both nodes fail, they should notify admin.

Develop a method for setting a backup node, and wrapping calls in the retry logic.

BOUNTY: DeFi Yield farming strategy review for Badger Vault: Unit RenBTC

Badgers never stop building and that includes our community of builders. Since inception, BadgerDAO has solidified itself as the # 1 place to put your Bitcoin to work in DeFi by implementing successful vault strategies while maintaining the highest level of security across all products. Our most recent NFT launch was the first of many to be minted directly on Ethereum using our own smart contracts. As we continue to scale and grow our presence within DeFi, we are looking to add more highly qualified and eager Solidity Developers to our builder community in order to support our existing workload and continue to build with us into the future.

The fun doesn’t stop here. Badger is committed to onboarding and retaining top candidates who show an interest in building with Badger long term and ultimately contribute elements that are then implemented and used. Successful developers and strategists not only have the opportunity to graduate from bounties and grants to become a long term core contributor, they also stand to benefit from both profit sharing and the developer mining program.

The Ask:
The strategy listed below is currently undergoing our detailed review process before launch. We are seeking 3 independent reviews for this vault. We ask that these are completed no later than EOD on June 2nd. If you are a highly skilled solidity developer with relevant experience and are interested in building with Badger, we hope you will consider completing this bounty. We’d also ask that you include a recent version of your CV with your submission.

Bounty:
We will pay 75 BADGER for the best 3 submissions that fulfil all the criteria outlined below. We will pay a further 75 BADGER as a bonus to anyone we choose to continue to work with.
Note that badger is super under valued right now, we will pay a 25% bonus on all bounties paid out at any time badger is under $25.

Badger currently holds over $20 million USD and over $20 million in BTC/ETH in our treasury, which is under control of token holders, and a $150 million dollar market cap. We also made over 25 million in fees in our first 6 months of operation.

Review Guidelines:
Google Doc[ We also welcome well thought out feedback on our review guidelines ]

Strategy
PR: #101

Submission:
Please submit as a PR to our Github repo in MD format.

Add iBBTC to retroactive sushi logic

Add iBBTC to the list of Setts to gather retroactive sushi from. Ensure subgraph has required info for this.

This code has duplicated logic and hardcoded aspects and should be refactored. Though as we intend to only use it once more we can leave as it.

testing

disregard

Determine parameters for mStable guarded launch

For each guarded launch phase:

• Total cap
• Per-user cap
• Guest list
• Emissions

UMA Optimisitic Oracle DIGG forwarder

Creating new contract to request, get, publish report from UMA's optimistic oracle for DIGG akin to Chainlink forwarder

Add Chainlink oracle as DIGG oracle data source

Chainlink DIGG/WBTC is live and ready to be used on mainnet.

This oracle data will be supplied to the DIGG MarketOracle contract and used to calculate how the DIGG supply should change.

MarketOracle (code)
MarketOracle (live contract)
A wrapper oracle needs to be created that converts the DIGG/WBTC price (which is in an 8-decimal format) to an 18 decimal version. This oracle will be called via bot and will post the most updated data from the Chainlink oracle.

How to use chainlink oracle.

The wrapper oracle will need to be added as a source to the MedianOracle and call the pushReport() with the 18-decimal version of the data from chainlink.

An example of the pushReport call from the current centralized oracle. (Note that it is wrapped in a gnosis safe transaction)

The live addresses for each contract can be found in the deploy-final.json file In the badger-system repo.

ImmuniFi report: Non-critical code issues in contracts/badger-sett/strategies/pancake/StrategyPancakeLpOptimizer.sol

Note that neither of these issues have any security impact, but more reveal less than perfect coding styles and review processses.

Conversation with Immuifi:

Immunefi wrote a message

Hi,

a whitehat has identified a vulnerability in your application.

Following, the complete report:

Smart Contract Bug Description
I am reporting several issues here. In my opinion, these are too small to be reported separately and they are closely related to the same strategy.

Comment above says: "Performance fees are taken on Cake directly". However, actually the fees are deducted from LP token, not Cake: // Process performance fees in LP token harvestData.toStrategist = _processFee(want, lpAfterSell, performanceFeeStrategist, strategist); harvestData.toGovernance = _processFee(want, lpAfterSell, performanceFeeGovernance, IController(controller).rewards());

function _sellTokenForWant declares that it should return TokenSwapData but there is no return statement at the end so it basically returns a default empty struct. The return value is not used anywhere so there is no impact on calculations, etc.

07.30.2021 13:30 +0200
Badger DAO wrote a message

This sounds like a problem with our documentation that has no real effect on the users returns. The disclosure above has no link to said documentation, which maybe we should change. That being said, our BSC setts have very little AUM and the pancake emissions seem to be retiring, we are likely to retire these setts.

The most action we would take here to update our documentation. That being said, happy to pay a $250 bounty if the whitehat can provide a more detailed report that includes code samples (with context) and links to the contract the code was in, and a link to whatever documentation is incorrect.

07.31.2021 18:24 +0200
Immunefi wrote a message

Hi,

the whitehat has provided us updates, you can find them here.

Please, let us know how you'd like to proceed.

Best,
Simone

Whitehat's original message
A simplified code snippet demontrating that _sellTokenForWant assigns values to struct but does not return it:

struct TokenSwapData { address tokenIn; uint256 totalSold; } function _sellTokenForWant(address tokenIn, uint256 amount) public returns (TokenSwapData memory) { TokenSwapData memory swapData; swapData.tokenIn = tokenIn; swapData.totalSold = amount; }

Here is the contract we are talking about: https://github.com/Badger-Finance/badger-system/blob/beadfc54042ec57ae51534c252aa613bb630f60d/contracts/badger-sett/strategies/pancake/StrategyPancakeLpOptimizer.sol

Here the comment says "Performance fees are taken on Cake directly":

badger-system/contracts/badger-sett/strategies/pancake/StrategyPancakeLpOptimizer.sol

Line 25 in beadfc5

- Performance fees are taken on Cake directly

and here it actually deducts these fees from LP tokens:

badger-system/contracts/badger-sett/strategies/pancake/StrategyPancakeLpOptimizer.sol

Lines 268 to 270 in beadfc5

	// Process performance fees in LP token
	harvestData.toStrategist = _processFee(want, lpAfterSell, performanceFeeStrategist, strategist);
	harvestData.toGovernance = _processFee(want, lpAfterSell, performanceFeeGovernance, IController(controller).rewards());

Balance Snapshotter Improvements

The BalanceSnapshotter class (In token_utils.py) can take snapshots of the balances of multiple tokens / accounts at once. It's primarily used for seeing and verifying the diff of balances between operations and just viewing a snapshot of state.

The following improvements could be made

• Allow the tokens and accounts input parameter arrays to take in Contract objects as well as raw addresses (Look to the brownie code for examples of this)
• Use multicall to read all balances at once to improve efficiency
• Filter out 0 balances in the print functions
• What new formatting options or views do you think would be useful?

The basic goal here is to snapshot balances of a bunch of tokens and addresses before and after transactions to make sure things went as expected.

Will pay a 50 badger bounty to any developer who creates a new python module with basic docs and readmes that can be imported and used. It should be published on pypi. We are interested in someone to take a lot more of our current development/scripting code and move it into a well documented module for people wanting to interact with Badger and the contracts we interact with via brownie. If you do good work we will carry on a relationship.

We will pay 25 badger to up to 2 additional developers who submit functional modules that show serious work.

If you have questions, please join our Builder Discord and contact Tritium | BadgerDAO

Whitelist Rari for bBadger and bDigg

Whitelist below contract for rari fuse pool to enable liquidations on bDigg and bBadger

0xf0f3a1494ae00b5350535b7777abb2f499fc13d4

CLAWs frontend

Full implementation of CLAWs frontend

Solution design documentation available at: https://www.notion.so/Badger-CLAWs-Design-Doc-379fe1e26d3d451a959b47430f03e6a3

Fix test suite compiling issues and bugs

Fix the different test suite compiling issues and remove calls to interface which are in the global scope to fix common bug.

FARM Rewards test printout w/ new logging

mitche50's new testing vault

example

Allow approved contracts to skip BlockLock

This interferes with bBadger distribution from multisig. We can safely whitelist the multisigs (exclusively)

This will be a different list than the usual allowed() list

mStable Strategies integration & simulation testing

PR with code.

• Write a settConfig test setup
• Adapt test_strategy_flow and test_strategy_permissions to the strategy logic
• Run simulation test vs vault, adapting what is necessary

Develop execution shell for bots

• Run reliably at proper times
• Recover from failure
• Use AWS secret manager for keeper keys

Badger Open DeFi Hackathon + Pooltogether Bounty

Badger Open DeFi Hackathon + Pooltogether Bounty

Prize Bounty

BadgerDAO is happy to join the Open DeFi hackathon and run its own contest as a part of it.

Up to 1000 Badger will be allocated as prizes to the hackathon winners in the following way:

On top of that, there is a special task for this hackathon that would grant extra 5000 DAI from Pooltogether on top of Badger rewards.

Challenge Description

Hackers should focus on creating projects that accelerate Bitcoin usage across blockchains and anything that would make DeFi more accessible, engaging, and fun!

The general focus areas for Open DeFi hackathon are:

• Liquidity - NFTs+DeFi, New token primitives, asset wrapping
• Risk management - Insurance, security, oracles
• Innovation - Project integrations, L2/cross-chain DeFi, new asset and governance models

We would like to keep things open-ended, so anything Bitcoin in DeFi, Badger, or DIGG related could be submitted. Governance-related submissions, like solutions to cross-chain snapshots, are also welcome.

Special Task: adding Badger and WBTC as yield sources on Pooltogether.

In addition to the general contest, there is a special task with an added 5000 DAI bounty from Pooltogether on top of Badger rewards: to integrate Badger and WBTC yield sources on Pooltogether.

1. To integrate the new WBTC vault from the Badger app as a yield source on Pooltogether. WBTC deposited will accumulate rewards and contribute those rewards to the prize pool.
2. To integrate Badger as a yield source on Pooltogether. Badger deposited into the pool is to be wrapped into bBadger - and the yield acquired from bBadger staking rewards should be added to the prize pool.

Aside from building up your own ideas or participating in the special task, you can also fulfill the tasks from Badger Bounty Billboard in Badger Discord, and submit them for the contest.

Submission Requirements

• The project needs to be open-source and released on GitHub for us to review the entire source.
• The project needs to include a demo.
• The project needs to include all relevant docs and links.
• All submissions must list the addresses of their contracts.
• The application must be USEFUL and/or INTERESTING.

Judging Criteria

The Badger Council + guest judges, Mr. Po, and Bitcoinpalmer, will evaluate your submission.
Here are the criteria by which your work will be judged:

• Is the application useful and/or interesting?
• Does it align with Badgers’ core values?
• The complexity of the application, protocol, or project.
• Design, Usability, & Innovation.
• Potential to evolve.

Winner Announcement Date

Winners are to be announced within 2 weeks after the hackathon ends.

Important links

• Getting Started with Badger Finance
• DIGG FAQ
• Badger Logos
• Badger Gitcoin Channel
• Badger Open Defi Hackathon Channel
• Bader Builder GR9 Workshop
• Find a team channel on Open Defi Discord

Special Task links:

• Pooltogether Documentation site
• Pooltogether Smart Contract Guidelines
• A good example of yield source integration for Aave
• Pooltogether Yield Source interface documentation

Follow us

➡️ Visit Our Website
➡️ Check Out Our Github
➡️ Join Our Community Discord
➡️ Explore our Governance Forum
➡️ Follow Us on Twitter
➡️ Connect on Telegram

Restructure test suite to run only static tests on CI

Several of the tests on the badger-system repo were written for a specific mainnet fork environment at a specific block. Since the test suite is set to fork and run the latest block, many of these tests now fail.

We should identify the tests that fail due to this issue and organize them outside of the tests/ folder in order to avoid having them been executed at the current block.

I think this can be deleted (already set approval in constructor)

badger-system/contracts/badger-sett/strategies/convex/StrategyConvexStakingOptimizer.sol

Line 395 in 203049a

cvxToken.approve(address(cvxRewardsPool), MAX_UINT_256);

Add extra token rewards to ibBTC

The contracts that hold the bTokens for ibBTC accumulate badger rewards and in the future will also accumulate convex rewards.

We need to look at how many rewards these contracts have allocated to them and redirect them to users who hold ibBTC.

We can do this through the BadgerTree - the amount of rewards will be weighted by how much ibBTC each address holds

GR9 Badger Builder Honey Pot

Gitcoin Grants Round 9 Badger Builder Honey Pot

The explosive growth of the Badger DAO over the last three months has led to a number of challenges and opportunities. As a major supporter, Badger DAO recognizes how Gitcoin enables and encourages the future of Open Source.

Badgers never hide; we like to build in the open with our community. More community, more engagement, and more building the products our users and participants love. We’re always in search of new Badger Builders to grow the protocol, the ecosystem, and help Badger DAO bring BTC to DeFi.

Gitcoin nestles in comfortably with the Badger Ecosystem Grants and the Badger Annexe, the DAO’s onboarding flow that turns users into champions, community members into contributing creators, and startups into integrated products. Any individual or team can build on Badger, some get to build with the Badgers.

The possibilities with Badger are endless. You can take this opportunity to see and be seen in DeFi.

Prize Bounty

A total of 30,000 DAI, 600 Badger, 10 NFTs, and 1 Jersey will be allocated as prizes to GR9 Hackathon’s Badger Builders. The breakdown is the following:

Challenge Description

Hackers should focus on creating projects that accelerate Bitcoin usage across blockchains and anything that would make DeFi more accessible, engaging, and fun!

A few areas to explore could be:

• Furthering BTC in DeFi as collateral on multiple chains
• New Sett mechanics
• DIGG price stabilizing mechanisms
• Gamification of bAssets, the Badger.Finance application, or anything else in relation
• Innovative NFT usage

Part of what makes Crypto special is exploring your own ideas for how to use protocols, so feel free to build and submit anything Bitcoin in DeFi, Badger, or DIGG related.

Here are some examples of what a submission could look like:

• A PR to uniswap.info that would make WBTC pairs tracked on the site
• Come up with an original idea and build a demo for a new Sett
• Demo for a new DIGG price stabilization mechanism
• Gamification of bAssets and tokenized BTC
• Create a mini-game for the Badger App
• Port Badger app to any Alternative Layer 1 chain
• Port Badger app to any Layer 2 solution
• Analytics Dashboards that cover different aspects of BTC adoption in DeFi

Submission Requirements

• The project needs to be open-source and released on GitHub for us to review the entire source.
• The project needs to include a demo.
• The project needs to include all relevant docs and links.
• All submissions must list the addresses of their contracts.
• The application needs to be useful and/or interesting.

Judging Criteria

The newly appointed Badger Council + guest judges, Mr. Po, and Bitcoinpalmer, will evaluate your submission.

Here are the criteria by which your work will be judged:

• Is the application useful and/or interesting?
• Does it align with Badgers’ core values?
• The complexity of the application, protocol, or project.
• Design, Usability, & Innovation.
• Potential to evolve.

Winner Announcement Date

Winners to be announced within 2 weeks after the hackathon ends.

Important links

• Getting Started with Badger Finance
• DIGG FAQ
• Badger Logos

Follow us

• Visit Our Website
• Check Out Our Github
• Join Our Community Discord
• Explore our Governance Forum
• Follow Us on Twitter
• Connect on Telegram

Script to support new Centralized Oracle

The new centralized oracle is here

The code can be found at the logic address.

There are approved oracle accounts that can propose new values. There is a two-step consensus process where another oracle account has to approve the new value, which results it in getting submitted to the Digg MedianOracle.

1. proposeReport(payload)
2. approveReport(payload)

Build an independent brownie strategy mix

Use the brownie mix for new strategies

Add Badger NFT's to boost mechanism

Currently, the users stake ratios are calculated by the formula:

SR = Native Balance / Non Native Balance.

The NFT boost adds an extra parameter to the equation :

SR = Nft Multiplier * Native Balance / Non Native Balance

where Nft Multiplier is a number between 1 and 1 + Max_Nft_Boost and is calculated by via a scoring mechanism based on each NFT's rarity

Misleading error msg in StrategyBadgerLpMetaFarm contract

badger-system/contracts/badger-sett/strategies/native/StrategyBadgerLpMetaFarm.sol

Lines 98 to 102 in c67c41e

	function _onlyNotProtectedTokens(address _asset) internal override {
	require(address(want) != _asset, "want");
	require(address(geyser) != _asset, "geyser");
	require(address(badger) != _asset, "geyser");
	}

require(address(badger) != _asset, "geyser");

imo error msg is misleading, should be:

require(address(badger) != _asset, "badger");

NEW VAULT: test new vault

Network

xDAI

Vault / Strategy Description

a test vault on xDAI

Deposit Token

wBTC

Rewards

xDAI

Version (V1 [single strategy], V2 [multi strategy])

V1

Allow approved non-signers to upload TX to multisig

Gnosis Safe has a feature where approved delegates can upload transactions to a multisig.

This would be useful as it allows developers to run complex scripts generating the actions, which can then be reviewed by the signers.

Research how to use this feature and what the best implementation of a service for this would be. ApeSafe shows an example of using this service with python and brownie (which is what badger uses for writing scripts)

BOUNTY: DeFi Yield farming strategy review for Badger mStable BTC vault

Badgers never stop building and that includes our community of builders. Since inception, BadgerDAO has solidified itself as the # 1 place to put your Bitcoin to work in DeFi by implementing successful vault strategies while maintaining the highest level of security across all products. Our most recent NFT launch was the first of many to be minted directly on Ethereum using our own smart contracts. As we continue to scale and grow our presence within DeFi, we are looking to add more highly qualified and eager Solidity Developers to our builder community in order to support our existing workload and continue to build with us into the future.

The fun doesn’t stop here. Badger is committed to onboarding and retaining top candidates who show an interest in building with Badger long term and ultimately contribute elements that are then implemented and used. Successful developers and strategists not only have the opportunity to graduate from bounties and grants to become a long term core contributor, they also stand to benefit from both profit sharing and the developer mining program.

The Ask:
The strategy listed below is currently undergoing our detailed review process before launch. We are seeking 3 independent reviews for this vault. We ask that these are completed no later than EOD on June 2nd. If you are a highly skilled solidity developer with relevant experience and are interested in building with Badger, we hope you will consider completing this bounty. We’d also ask that you include a recent version of your CV with your submission.

Bounty:
We will pay 75 BADGER for the best 3 submissions that fulfil all the criteria outlined below. We will pay a further 75 BADGER as a bonus to anyone we choose to continue to work with.

Badger currently holds over $20 million USD and over $20 million in BTC/ETH in our treasury, which is under control of token holders, and a $150 million dollar market cap. We also made over 25 million in fees in our first 6 months of operation.

Review Guidelines:
Google Doc[ We also welcome well thought out feedback on our review guidelines ]

this strategy is built in collaboration with mStable and leverage their BTC pools for optimized yield:
PR: #111

Submission:
Please submit as a PR to our Github repo in MD format.

Fix Sushi distribution on native LP setts

Sushi stacks on Native LP setts are currently not harvestable. Quick patch to fix:

Checklist

• Remove harvesting of obsolete staking rewards pool
• Remove associated auto-compounding logic (now handled externally)
• Write upgrade script for forked env
• Run integration & simulation tests vs upgraded state.
• Verify the new complied & flattened contract vs the live strategy logic to ensure only the changes expected were made (I use npx hardhat flatten <path> for flattening).
• Deploy new logic and create prod upgrade script for multisig timelock

Notes

• sushiBadgerWbtc uses the StrategySushiBadgerWbtc contract.
• sushiDiggWbtc uses the StrategySushiDiggWbtcLpOptimizer contract.

See the PR for the logic changes (already implemented). Work should be on that feat/sushi-harvest branch.

The generic contract StrategySushiLpOptimizer works as expected already.