badger-finance / badger-system Goto Github PK
View Code? Open in Web Editor NEWLicense: MIT License
License: MIT License
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.
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.
call _acceptAdmin on the pool Comptroller from the dev multisig
https://etherscan.io/address/0xe3952d770fb26cc61877cd34fbc3a3750881e9a1#writeContract
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.
Creating new contract to request, get, publish report from UMA's optimistic oracle for DIGG akin to Chainlink forwarder
text
require(address(badger) != _asset, "geyser");
imo error msg is misleading, should be:
require(address(badger) != _asset, "badger");
The Sett system requires a series of bots to perform key actions.
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.
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.
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.
Many strategies are incentivized by Badger and/or Digg rewards. These rewards are handled by the External Harvester. This system:
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.
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.
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.
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.
When a bot crashes, it does not restart automatically. The machine running the bot should restart it.
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.
If a transaction get stuck for too long, even with the exponential scaling strategy, it should report.
As mentioned in the tend() and harvest() sections.
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
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?
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.
The deposit functions:
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.
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
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.
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:
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.
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.
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.
The Badger Council + guest judges, Mr. Po, and Bitcoinpalmer, will evaluate your submission.
Here are the criteria by which your work will be judged:
Winners are to be announced within 2 weeks after the hackathon ends.
➡️ Visit Our Website
➡️ Check Out Our Github
➡️ Join Our Community Discord
➡️ Explore our Governance Forum
➡️ Follow Us on Twitter
➡️ Connect on Telegram
disregard
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
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
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
xDAI
a test vault on xDAI
wBTC
xDAI
V1
maybe we could consider the babylonian
calculation proposed by Alpha Homora team?
https://blog.alphafinance.io/onesideduniswap/
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)
Sushi stacks on Native LP setts are currently not harvestable. Quick patch to fix:
npx hardhat flatten <path>
for flattening).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.
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.
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)
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)
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)
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
example
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.
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.
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:
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:
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:
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:
Winners to be announced within 2 weeks after the hackathon ends.
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",
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)
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":
and here it actually deducts these fees from LP tokens:
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.
Use the brownie mix for new strategies
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
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:
If a mechanic changed, test the result vs the current iteration. Each users' amounts and metadata should be compared along with the overall results.
We should test the full rewards flow in a forked env to ensure it will work in prod when new mechanics are introduced
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)
Fix the different test suite compiling issues and remove calls to interface which are in the global scope to fix common bug.
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.
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.
Full implementation of CLAWs frontend
Solution design documentation available at: https://www.notion.so/Badger-CLAWs-Design-Doc-379fe1e26d3d451a959b47430f03e6a3
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.
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:
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
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.
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.
Winners to be announced within 2 weeks after the hackathon ends.
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?
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.
For each guarded launch phase:
Whitelist below contract for rari fuse pool to enable liquidations on bDigg and bBadger
0xf0f3a1494ae00b5350535b7777abb2f499fc13d4
PR with code.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.