You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Seer is a prediction market that would like access to limit orders. AMMs are hard to operate with for both liquidity providers and users. However, users in Seer are prompted to deploy liquidity in Swapr V3 pools, and currently, Cowswap will refuse to operate with those tokens and throw an UnsupportedToken error, claiming balance is below 100000. So, limit orders are not possible.
However, the issue is not that those tokens are not held in enough balance, but probably that Swapr V3 pools were not being indexed properly.
It started showing as supported when a Pool was created for it in Sushiswap V2, which I have been found referenced in various parts of the code.
Are SwaprV3 pools being indexed?
With that out of the way, I'm not experienced enough with Rust to help with this, and I couldn't figure out how to test or install. But I would guess that to start indexing this information you would have to:
Thank you for raising this issue and providing such detailed insights.
You are correct that the issue is likely not related to token balances falling below the threshold, but rather with the lack of indexing support for Swapr V3 Algebra pools in our current implementation.
At this time, we are not actively working on adding indexing support for Swapr V3 Algebra pools, as our focus is on existing sources. However, some external solvers may already support these pools. We are checking internally why limit orders don't work as expected.
Problem
Seer is a prediction market that would like access to limit orders. AMMs are hard to operate with for both liquidity providers and users. However, users in Seer are prompted to deploy liquidity in Swapr V3 pools, and currently, Cowswap will refuse to operate with those tokens and throw an UnsupportedToken error, claiming balance is below 100000. So, limit orders are not possible.
However, the issue is not that those tokens are not held in enough balance, but probably that Swapr V3 pools were not being indexed properly.
Suggested solution
Index Swapr V3 Pools.
Balance was not the issue
services/crates/shared/src/bad_token/trace_call.rs
Line 47 in 5671152
The
MIN_AMOUNT
variable is100_000
, but this is wei, not accounting for decimals.It's compared to the result of
balance_of
;services/crates/shared/src/bad_token/token_owner_finder.rs
Line 423 in 5671152
So this clue was likely wrong:
To show this in a different way, this token can take part in limit orders, will show price on network logs, and is not Unsupported:
This token has less token supply
https://gnosisscan.io/token/0x1ee18c3d2847ff22238130ffdd5223de2a7356e3?a=0x89c4acb8b5b5b8e5b2121934b9e143569a914c80#readContract
100000000000000000000
<== totalSupply (100 * 1e18)100000000000000000000000
<== implied min amount, 100000 * 1e18It started showing as supported when a Pool was created for it in Sushiswap V2, which I have been found referenced in various parts of the code.
Are SwaprV3 pools being indexed?
With that out of the way, I'm not experienced enough with Rust to help with this, and I couldn't figure out how to test or install. But I would guess that to start indexing this information you would have to:
I've been told that SwaprV3 are indeed indexed, but then, why can I not find any of the V3 deployment addresses anywhere in this codebase?
Likewise, I believe SushiSwap V3 is not indexed either, but I admit I'm a bit out of my element here
The text was updated successfully, but these errors were encountered: