feat: flashloans #105
feat: flashloans #105
Conversation
zavgorodnii
force-pushed
the
feat/flashloans
branch
from
26456e8 to
b6c4ee8
Compare
There was a problem hiding this comment.
It also adds the neutron-flashloans-user contract that is only used in the integration tests.
It should be in our dev-contracts repo then.
| requested_amount: Vec<Coin>, | ||
| ) -> Result<Vec<Coin>, ContractError> { | ||
| // Prepare the query | ||
| let all_balances_query = BankQuery::AllBalances { |
There was a problem hiding this comment.
I don't think this is safe.
I can spam the source address with an infinite amount of TF tokens, so after the certain number of created tokens your AllBalances query will return a gas error, thus users can't get new flashloans
There was a problem hiding this comment.
Do you suggest having an allow list of tokens that we are ready to loan?
There was a problem hiding this comment.
Either that, or do a separate BankQuery::Balance { address: String, denom: String } query for each denom.
That way a flashloan can be broken only if a user himself provides a lot of tokens to loan. But it's kinda his problem, not contract's
There was a problem hiding this comment.
Makes sense, I like the separate query approach more
|
|
||
| // Filter all balances leaving only the balances of the requested coins | ||
| let mut pre_loan_balances: Vec<Coin> = vec![]; | ||
| for requested_coin in requested_amount { |
There was a problem hiding this comment.
Or i can get a gas error here.
TLDR infinite loops are not good
There was a problem hiding this comment.
I see your point, spamming might be an issue; will fix.
| expected_balances: Vec<Coin>, | ||
| ) -> Result<(), ContractError> { | ||
| // Prepare the query | ||
| let all_balances_query = BankQuery::AllBalances { |
There was a problem hiding this comment.
The same about a potentially infinite loop
There was a problem hiding this comment.
Acknowledged, will fix!
Co-authored-by: Mike Mozhaev <programmer10110@gmail.com>
Co-authored-by: Mike Mozhaev <programmer10110@gmail.com>
Co-authored-by: Mike Mozhaev <programmer10110@gmail.com>
| let maybe_source_coin = all_balances_response | ||
| .amount | ||
| .iter() | ||
| .find(|x| x.denom == requested_coin.denom && requested_coin.amount.le(&x.amount)); |
There was a problem hiding this comment.
not important but seems kinda inefficient, since if there is not enough of denom it will still check all the other coins (even thought it won't find it?)
Co-authored-by: sotnikov-s <34917380+sotnikov-s@users.noreply.github.com>
Co-authored-by: sotnikov-s <34917380+sotnikov-s@users.noreply.github.com>
Co-authored-by: sotnikov-s <34917380+sotnikov-s@users.noreply.github.com>
Co-authored-by: sotnikov-s <34917380+sotnikov-s@users.noreply.github.com>
Co-authored-by: sotnikov-s <34917380+sotnikov-s@users.noreply.github.com>
Co-authored-by: Dmitry Kolupaev <dmitry.klpv@gmail.com>
| fn get_pre_loan_balances( | ||
| deps: &DepsMut, | ||
| source: Addr, | ||
| requested_amount: Vec<Coin>, | ||
| ) -> Result<Vec<Coin>, ContractError> { |
There was a problem hiding this comment.
please update comments in the func body. some of them are outdated
# Conflicts: # Cargo.lock # contracts/dao/neutron-chain-manager/schema/neutron-chain-manager.json # contracts/dao/neutron-chain-manager/schema/raw/execute.json
4 participants
This PR adds the
neutron-flashloanscontract that uses another address as the source of funds (in our case, the DAO core address). You can find a detailed description of the contract logic and implementation in README.md, or in the docs.Note: the
neutron-flashloans-usercontract that is only used in the integration tests is added to theneutron-dev-contractsrepo: neutron-org/neutron-dev-contracts#57.