0

I am trying to make a swap transaction on Raydium using Python. I always preparing the transaction and necessary instructions for the swap in advance:

print("Add Instructions To Transaction...")
swap_tx = Transaction()
signers = [payer]
swap_tx.add(modifyComputeUnits)
swap_tx.add(addPriorityFee)
swap_tx.fee_payer = payer.pubkey()
if swap_token_account_Instructions != None:
    swap_tx.add(swap_token_account_Instructions)
swap_tx.add(instructions_swap)

Those instructions are not the issue, they work fine. I run needed code for sending the transaction in a loop and all I am changing is the recent_blockhash of the transaction. After that, I try to simulate the transaction to make sure it does not throw any errors. If there are no errors, I send the transaction. I am using max_retries=0 to customarily resend the transaction. I am attaching the relevant code.

    while txnBool:
        """Send transaction"""
        try:
            blockhash_resp = solana_client.get_latest_blockhash(Confirmed)
            swap_tx.recent_blockhash = blockhash_resp.value.blockhash
            last_value = blockhash_resp.value.last_valid_block_height
            print("5. Execute transaction...")
            txn = solana_client.simulate_transaction(swap_tx, commitment=Processed)
            if txn.value.err == None:
                send_time = datetime.datetime.utcnow()
                print(send_time)
                blockheight = solana_client.get_block_height(commitment=Confirmed).value
                while blockheight < last_value:
                    print("Trying to send")
                    new_txn = solana_client.send_transaction(swap_tx, *signers, opts=TxOpts(skip_preflight=True,
                                                                                            max_retries=0),
                                                             recent_blockhash=blockhash_resp.value.blockhash)
                    txid_sig = new_txn.value
                    try:
                        status = solana_client.get_signature_statuses([txid_sig])
                        status = json.loads(status.to_json())
                        if status["result"]["value"][0] != None:
                            print(status)
                            success_time = datetime.datetime.utcnow()
                            print(success_time)
                            print("Transaction Success", new_txn.value)
                            print(f"https://solscan.io/tx/{new_txn.value}")
                            txnBool = False
                            break
                        else:
                            blockheight = solana_client.get_block_height(commitment=Confirmed).value
                    except Exception as e:
                        print(e)
                pass
            else:
                print(txn.value)
        except Exception as e:
            print("Exception, Retrying")
            print(e)

The problem is that there can be a difference of up to 15-20 seconds between the send_time and success_time values.

Also, in the transaction, I am already using a priority fee, and there should be no issues with the rpc node as well. I see on solscan that people are able to send transactions quite quickly, literally tens of transactions per second, even though they use a priority fee much lower than mine, but their transactions reach the target at the right time, while mine do not. Please advise me on what I am doing wrong, perhaps I am using the wrong methods.

1
  • I'm wondering the same thing too!
    – 01jayss
    Commented Mar 13 at 2:59

3 Answers 3

2
+25

It's just congestion! You're waiting for the tx to be "confirmed", which takes a while, usually several slots. In March 2024, it's 5-12 seconds average depending on the RPC and time of day but the high values are often well over 10s.

You can see live confirmation times a https://www.validators.app/ping-thing?locale=en&network=mainnet

You can keep sending more txes while one awaits confirmation, so that's why you're seeing others sending many txes in the same timespan.

1
  • Thank you for the response, indeed sending more transactions speeds up the process. And thank you for the link, it's exactly what I was looking for. I also wanted to ask, would it make sense to replace legacy transactions with versioned transactions? More specifically, will it affect the speed or the likelihood of a transaction reaching the leader?
    – xallve
    Commented Mar 14 at 20:15
0

This might not be what your looking for but what it sounds like to me it could be a few things.1. It could be the other traffic of other people doing what they are doing. 2. It could be your WiFi single or your cellphone whatever your working on. Because I just did the same thing to get here and I had no problems. I am sorry to inconvenience anyone but that's what it sounds like to me.

-1

It seems like you're facing latency issues with your transaction confirmation time, even though you're setting a priority fee. There are a few potential reasons why your transactions might be taking longer than expected:

  1. Network Congestion: Even though you're setting a priority fee, if the network is congested, it can still take time for your transaction to be processed. The priority fee helps to prioritize your transaction, but it doesn't guarantee instant confirmation, especially during times of high network activity.

  2. Optimization Opportunities: Your code can be optimized to reduce latency. For instance, instead of constantly polling for block height in a loop, you could use asynchronous programming or event-driven approaches to listen for transaction confirmation events.

  3. RPC Node Performance: The performance of the RPC node you're connected to can also affect transaction confirmation times. If the node is under heavy load or experiencing issues, it can slow down transaction processing.

  4. Retry Mechanism: While setting max_retries=0 might seem like a way to ensure the transaction is sent immediately, it might be causing unnecessary retries or delays. Consider adjusting this parameter or implementing a more intelligent retry mechanism.

  5. Synchronization Delays: There might be delays in synchronizing your local node with the rest of the network, leading to discrepancies between the block heights you're querying and the actual state of the blockchain.

To improve transaction confirmation times, you could:

  • Monitor network congestion and adjust your priority fee accordingly.
  • Optimize your code for better performance, considering asynchronous programming and event-driven approaches.
  • Ensure you're connected to a reliable and high-performance RPC node.
  • Fine-tune your retry mechanism to balance between transaction reliability and latency.
  • Double-check your code for any potential bottlenecks or inefficiencies.

Additionally, consider reaching out to the Raydium community or support channels for more specific advice or insights tailored to their platform. They might have additional recommendations or best practices for optimizing transaction throughput and latency on their network.

2
  • Thank you for your answer! Currently, the best approach I've found is to send multiple transactions in parallel, as it reduces the interval between transactions and increases the chance of a transaction reaching the leader faster. However, even with this approach, there are some issues. And yes, the logic of retrying transactions that I provided above indeed has its issues.
    – xallve
    Commented Mar 18 at 20:33
  • And I see that everyone uses Versioned Transactions not Legacy. Should I use them instead of Legacy? I`m not really aware of the advantages of those except Lookup table accounts
    – xallve
    Commented Mar 18 at 20:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.