astroport-fi / astroport-core Goto Github PK

offer_amount: greater_precision
return amount: ask_precision

for example, If offer_precision = 9 and ask_precision = 6
offer_amount: 9
return amount: 6

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

Is it possible to add sender and receiver(receiver is only for the swap) at the events log like terraswap?

https://github.com/terraswap/terraswap/blob/97cefa337798bdb0cba0327dd4152607839a5c77/contracts/terraswap_pair/src/contract.rs#L421

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).

Add and Set have a with_update parameter, but anyways the operation always calls update_rewards_and_execute.

https://github.com/astroport-fi/astroport/blob/2b73e3e436a4f280cb3474b344fb4f9eece5b580/contracts/tokenomics/generator/src/contract.rs#L65-L76

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.

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!

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)

1. Client sends an ExecuteMsg with an amount of A and a request to receive an amount of B
2. If there is not enough A to convert into the amount of B, transaction fails (with meaningful error message)
3. If it coincidentally happens to match exactly, then the exact amount of B is returned (and nothing else)
4. If there is excess A, then the exact amount of B is returned as well as the excess A

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

https://github.com/astroport-fi/astroport/blob/0743c710f177d546b34296fe3c08b621711cf612/contracts/tokenomics/generator/src/contract.rs#L433-L438

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.

can't add liquidity pool. transaction completed but ASTRO - SEI Pool not add on chart.

Chromium Version 120.0.6099.129 (Official Build) Fedora Project (64-bit)
Keplr 0.11.41
Ledger nano

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

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.

v3.10.0

There are several contracts where cargo schema is not working.

example path:
/contracts/periphery/liquidity_manager

Are there any specific reasons?

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?

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 ?

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

Rewards aren't distributed correctly if user transfers lp tokens

The receive_cw20() receiver in the vesting contract does not validate a contract admin or owner.

https://github.com/astroport-fi/astroport/blob/2016df9ca31c7adfb877e0b4f1f59d0e18bdfc44/contracts/tokenomics/vesting/src/contract.rs#L75-L86

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.

https://github.com/astroport-fi/astroport/blob/2016df9ca31c7adfb877e0b4f1f59d0e18bdfc44/contracts/tokenomics/vesting/src/contract.rs#L99-L101

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.

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?

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.

https://github.com/astroport-fi/astroport/blob/2016df9ca31c7adfb877e0b4f1f59d0e18bdfc44/contracts/factory/src/contract.rs#L193-L198

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

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.

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.