astroport-fi / astroport-core Goto Github PK
View Code? Open in Web Editor NEWAstroport DEX core contracts
Home Page: https://astroport.fi/
License: GNU General Public License v3.0
Astroport DEX core contracts
Home Page: https://astroport.fi/
License: GNU General Public License v3.0
offer_amount
: greater_precision
return amount
: ask_precision
for example, If offer_precision
= 9 and ask_precision
= 6
offer_amount
: 9
return amount
: 6
When i try to add pools the request error
https://multichain-nodes.astroport.fi/injective-888/lcd/cosmos/tx/v1beta1/simulate
code
"[reason:\"execute wasm contract failed\" metadata:{key:\"ABCICode\" value:\"5\"} metadata:{key:\"Codespace\" value:\"wasm\"}]: rpc error: code = Unknown desc = failed to execute message; message index: 1: dispatch: submessages: cosmwasm_std::addresses::Addr not found: execute wasm contract failed [!injective!labs/[email protected]/x/wasm/keeper/keeper.go:394] With gas wanted: '50000000' and gas used: '509130' : unknown request"
this error from astro side or on my side ?
I've compared the checksums of the released contracts, but I don't see an address like f6e81f775b41c676907b42755dbedcafe886e777f4f607e87a75c398ba8b397e
. Even if it's a revision, I'd appreciate knowing the version.
I think we should add lower case verification for asset_infos here, extend #121
+ we can add validate function to Asset
https://github.com/astroport-fi/astroport/blob/2016df9ca31c7adfb877e0b4f1f59d0e18bdfc44/packages/astroport/src/asset.rs#L28-L30
The receive_cw20()
receiver in the vesting contract does not validate a contract admin or owner.
As result, arbitrary vesting could be set up unauthorized from token holders. The register_vesting_accounts()
contains an invalid check since the contract suppose to send a message to itself and could be misinterpreted by token_addr
instantiated field.
As a suggestion, move the validation to the receive_cw20
function once a message is received by itself.
Please correct me if I am wrong.
Hello guys and gals.
On Terra Classic a functioning IBC connection between Terra Classic and Cosmoshub has been re-established. There is an active relay, that - for the first time since may - enables users to transfer their Atom from Cosmoshub to TerraClassic.
Now, the issue is, that I wanted to add my IBC transferred Atom to a ATOM-USTC or ATOM-LUNAC liquidity pool on Astroport Classic. However, the liquidity add transaction fails because of insufficient fees. I guess that the burn tax on TerraClassic is not taken into account when calculating the fee denoms from the simulation.
Would you please fix that? It would be the first time since May that users could trade their LUNC against another crypto asset on a DEX. May be also a great marketing opportunity for Astroport ;) If you like you can contact me via my Twitter handle: @tiilentekija.
Thanks!
Best,
Till
For testing my smart contracts I'm using cw-multi-test
which means that I need both the Message type definitions and the smart contract entry points (eg: execute
, query
) together. Bringing in both of these crates results in a type collision because they are not connected together properly on crates.io. This is likely due to the versions being incompatible.
can't add liquidity pool. transaction completed but ASTRO - SEI Pool not add on chart.
Seems like spread_amount
is incorrectly calculated in compute_offer_amount
function in stable pool
https://github.com/astroport-fi/astroport-core/blob/master/contracts/pair_stable/src/contract.rs#L1245
Looks like in calc_amount the ask amount is always lower then offer amount, so we can't just swap the assets as that would mean offer is alway lower. We need to find a way to properly calculate offer amount
Hi, I'm finding it difficult to find Astroport contract address for Testnet. Could you point me in the right direction, or consider this a request to publish them if they're not currently available? Thanks.
Add and Set have a with_update
parameter, but anyways the operation always calls update_rewards_and_execute
.
In here is calling the same operation for all pools:
https://github.com/astroport-fi/astroport/blob/2b73e3e436a4f280cb3474b344fb4f9eece5b580/contracts/tokenomics/generator/src/contract.rs#L211-L213
This mass_update
here also only makes sense if the update_rewards_and_execute
was called before.
https://github.com/astroport-fi/astroport/blob/2b73e3e436a4f280cb3474b344fb4f9eece5b580/contracts/tokenomics/generator/src/contract.rs#L192
Therefore, if with_update
is true, the operation updates 2 times.
Please correct me if I am wrong.
Dear Astroport team, we have some Astroport deps in our project, but we found some common types and queriers are not included in astroport v2.8.0
. Do you think it would be possible to get a new version of the crate published which includes the latest features?
Is it possible to add sender and receiver(receiver is only for the swap) at the events log like terraswap?
It is really useful when other protocol make indexer for user's tx_history. If there is no sender at the event log, it is really hard to know who is the executor, especially contract execute the msg(in these case there are lots of sender so it is really hard to find who is the sender).
Unsure if this is in astroport's purview or not, but bAsset rewards will accrue to the pair-stable/pair contract addresses.
Here is terraswap's bluna-luna contract holding over 1M UST in pending bluna rewards: link
I did not see anything in astroport's codebase to suggest that this edge-case is handled; can we get something to enable routing/swapping rewards back into the pool?
Please correct me if I'm wrong, thanks.
There is an update()
function in the periphery contract that does not validate the executor an its open for anyone to call it.
Unfortunately, I could not find any documentation implying that particular function is meant to be public or restricted. In fact, I'm not sure.
Well, in any case, I'm reporting just to double check if its actually desired in the current implementation below:
https://github.com/astroport-fi/astroport/blob/master/contracts/periphery/oracle/src/contract.rs#L64
As a suggestion, just append a comment (// public function, anyone can call it
) trying to reduce further interpretation and consequentially avoid possible human errors.
Thank you!
v3.10.0
There are several contracts where cargo schema
is not working.
example path:
/contracts/periphery/liquidity_manager
Are there any specific reasons?
Rewards aren't distributed correctly if user transfers lp tokens
Error: [reason:"insufficient funds" metadata:{key:"ABCICode" value:"5"} metadata:{key:"Codespace" value:"sdk"}]: rpc error: code = Unknown desc = spendable balance 24995000000000inj is smaller than 200000000000000inj: insufficient funds: insufficient funds [!injective!labs/[email protected]/x/auth/ante/fee.go:132] With gas wanted: '50000000' and gas used: '15391' : unknown request
Hey Fellas! Eric from the team over at Neptune Finance. We're working on publishing our API to crates.io and we have some Astroport deps in our project. Do you think it would be possible to get a new version of the crate published that's compatible with all the 1.0.0 CW deps?
Proposal
Add a new ExecuteMsg to the pair contracts which enable swaps based on the desired receive amount, instead of offer amount. The returned amount will be the exact receive amount requested, as well as any excess (details below).
Motivation
For many swaps, the current API makes perfect sense. You want to give asset A and receive asset B. In this case we aren't so picky about the exact amount of B, within reason (i.e. "slippage tolerance"). Nothing at all to change here, it's great.
However, sometimes this is not what we want. Instead, we want to receive a precise amount of asset B. The only way to do this currently would be to supply extra asset A, get extra B, and then do another swap of the excess B to A. This is doable, but it's cumbersome and prone to error.
Due to slippage, it's not possible to know the exact amount of A which must be provided in this case. The feature request here is not about doing the impossible - but rather to remove the burden from the user and put it on the contract side, behind this new additional ExecuteMsg.
Aside for a cleaner API and removing errors in downstream code, it will also reduce gas fees.
High-level implementation
(leaving the exact naming naming conventions out of it, as well as details around fees and taxes)
In other words, it's up to the client to query for the current price and provide extra A, but they receive the excess back automatically, as well as the exact amount of B they asked for.
Note that the exact math to work out the amount of A that's required to get B is derivable from x*y=k in the case of the pair.rs
contract, but it's not a direct multiplier of price iiuc, and the above is probably a bit more complex when we account for fees.
Don't we need to update pool.proxy_reward_balance_before_update
to latest reward_amount
?
pool.proxy_reward_balance_before_update = reward_amount
I know it is not the problem now because all function executed after update_rewards_and_execute
, and this function update pool.proxy_reward_balance_before_update
. hmm maybe better to define some CONTRACT
statement like this function should be executed after update_rewards_and_execute
.
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.