-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Max supply query doesn't work for addresses with large tx volume #14
Comments
Hmm ok, thanks. I can't guarantee a quick analysis of this but it's on my radar. |
All good my main flag for you is that the logic and query are fine the issue is that the query response can't handle the amount of tx volume on that address. Also just for curiosity sake even the blockchain nodes themselves reject transactions trying to move too many cashtokens at the same time on that address even if I tried to pay ~$1 in fees the byte size gets too big and is rejected so the broadcast doesn't work. I hope that participating in this community we were able to give more than we took and identified some areas for improvement but are moving to other blockchains now so also won't be able to put any focus into this one. |
If that's the case then it may be an issue with the chaingraph server, which I am borrowing from mainnet_pat and which is quite expensive and resource-intensive to host. Yes, indeed, we are kind of in the same boat. Did you report the issue with the transaction size to cashtoken_devs by chance? |
I agree definitely not a trivial problem and I'm sure those constraints are there with good reason it just invalidates the original solution which we knew was time limited. I did flag it in one of the dev channels and haven't heard back from anyone there or on twitter so we can just leave this open for now. Hope your other ventures are doing well and it has been great working with you. |
there is currently a bug with the gql query causing market cap and max supply to be incorrect (at least for XLV) this value is absolutely fixed at 79000.57996200 from the burns done on June 5th and should be 61000.57996200 after the burns done today
The issue is with the qrstt2d9djm5pnh65jrfw3kwfwesnnafnyvqamdp2g address which has generated Main (31,700) transactions and CashTokens (FT) (15,443) transactions on cauldron micro LPs which is likely exhausting the limits of the query responses
The text was updated successfully, but these errors were encountered: