AttributeError: 'solders.rpc.errors.InvalidParamsMessage' object has no attribute 'value'

[VeryBoredPanda]

Hi,
I was often getting this error while using this bot stock.
I've been working on it few days to set some rules so it only buys some coins and sell based on price instead of fixed time.
Now I get this error i would say 9 times out of 10 when selling.
I'm using Chainstack Growth plan.
Maybe i'm wrong but i don't think it's a code problem because some transaction still goes through.
Could be my plan limit? Or maybe if the coin is getting lot of transaction?
Thank you

edit: looks like it happens when the price of the coin goes up or down very fast.

[akegaviar]

Hey there @VeryBoredPanda

Now I get this error i would say 9 times out of 10 when selling.

I think you forgot to provide the error.

Could be my plan limit?

It could very well be. Have a look at our docs:Limits. This bot isn't using any Limits from any specific/exception methods, so double check these:

• your limit plan is 250 RPS, make sure you are
• if your new parts of code or your version of code isn't using of the other Solana limits specified in the article that have a lower RPS.

edit: looks like it happens when the price of the coin goes up or down very fast.

That looks like a slippage value issue?

[VeryBoredPanda]

Thanks for replying.
The error I get is the one in the title:
AttributeError: 'solders.rpc.errors.InvalidParamsMessage' object has no attribute 'value'
I only added a priority fee with compute unit price, 10sec price check before buying, a take profit and stop loss instead of fixed 20secs so no big changes.
Pretty sure is not a slippage value issue, I tried to remove Minimum Sol Output and also happens when selling price is higher.

The error appears in like this
Transaction confirmed
Waiting for 20 seconds before selling...
Selling tokens with 35.0% slippage tolerance.
An error occurred: AttributeError: 'solders.rpc.errors.InvalidParamsMessage' object has no attribute 'value'

[akegaviar]

I only added a priority fee with compute unit price

A fixed one? As a hardcoded value?

Try looking into the transactions adjacent to the one where you expect to have done the sell transaction. See here Analyzing adjacent transactions for priority fees.

Could be related to a priority fee not high enough. Also, if you are willing to spend a few cents or a dollar, try with a Warp transaction and a priority. Do note that each Warp transaction (not all requests, just the transaction itself) costs $0.15, so don't let it run wild. But just for an experiment.

[VeryBoredPanda]

Yeah priority fee is fixed for now, I check recent fees and set a high number just to make sure, something in between 2-6 lamports per cu depending on current situation (I wanted to make sure bot works before adding
getRecentPrioritizationFees Method)
I also already tried a trader node same result, 1-2 competed transaction and the rest just having error when selling. Same as Growt plan
I'll try tomorrow to cancel all print functions with numbers or log saves from buy/sell maybe it's some problem with values printing.

[VeryBoredPanda]

Hi again,
I found the problem to be the get_token_balance function before selling.
I changed it so it can print the response from RPC:

async def get_token_balance(conn: AsyncClient, associated_token_account: Pubkey):
try:
response = await conn.get_token_account_balance(associated_token_account)
print(f"RPC response: {response}")

The result is like this:
RPC response: InvalidParamsMessage { message: "Invalid param: could not find account" }

Buy transaction went ok, tokens are in my wallet and ATA is Initialized.
As I said happens only with coins with high profits, which are obv pumped by bots.
Anything I can do about it?
I understand that they may be faster in transactions but why not finding account when I already buyed with it?
Thank you

[akegaviar]

Hey there, starting from the next week (week of March 10) we'll be rolling out updates to the bot v2 based on the feedback and the reported issues, including updating to the latest libs, better error handling etc. We are already actively working on it.

That'll be in a separate branch.

So for this particular issue, I suggest trying out a new version in a separate branch. We'll let you know.

Also, check out the readme for the roadmap that I just added in the README file for the full overview.

[VeryBoredPanda]

Hi thanks for the heads up.
The problem was caused by the RPC node not updating fast enough so it doesn't find any ATA before 15-20 secs after it was created.
That's why it only happened in take profit o stop loss situations and not happening when selling at time out, because after 40+ sec there was not problem finding ATA.
Tried with Chainstack Growth plan and trader's node, other RPC such has Quicknode and Helius.
Don't know if depends on the chosen plan or the blockchain data updates with same delay through all plans.
Putting a minimum of 20 sec before checking for take profit or stop loss resolved the problem entirely.

[akegaviar]

@VeryBoredPanda you might want to give it a try next week and later on as well as there will likely be changes related to your specific issue.

Note that it's not just a node (as in node provider), but also has to do with the Solana architecture. Eg it is discussed with the Solana guys here anza-xyz/agave#3074 and here anza-xyz/agave#3879

A couple of things that will be rolled out as part of the stage 1 & 2 that will be useful to you are:

• Being able to switch between using logsSubscribe & blockSubscribe
• Being able to set RPS as per your plan
• Being able to do retries instead of a 20 sec cooldown (as in it'll keep retrying until it gets the data, so you don't have to set a fixed period).

[smypmsa]

⚠ The completely refactored bot has been merged into the main branch. Please use the updated bot.

Among others, the updated bot has so-called extreme fast mode - there are no additional RPC calls between token detection (Geyser or logsSubscribe are much faster than blockSubscribe) and sending a buy transaction. Creating ATA is incorporated into the buy transaction - so now there is no need in sending an additional RPC call and wait for nodes to be synced. Feel free to test it.

Closing this issue since it refers to the outdated code.