SOL transaction failed
Why did the Solana transaction fail?
There are several reasons why the transaction is not on the chain:
Reason 1: The transaction fails at the initiation stage. Common reasons include insufficient wallet balance to pay priority fees and account rent, etc.;
Reason 2: Due to blockchain congestion, priority fees/jito fees are not enough, resulting in a queue. If it is not packaged into the block for a certain period of time, it will lead to failure;
Reason 3: Failure is caused by blockchain fluctuations. Because DEX and on-chain data are not always stable, network fluctuations may occur occasionally.
Failure of transactions that have been put on the chain: This type of transaction has been put on the chain, but problems occurred during the execution process and caused the failure:
Common reasons: Insufficient slippage or priority fee. For example, when submitting a transaction, the price is within the slippage limit, but the price fluctuation during the transaction exceeds the slippage limit, resulting in failure. Due to the complexity of the on-chain situation, the specific cause of the failure can be viewed on the block browser.
Why is the Solana network congested?
On-chain transactions require a “majority” of nodes to reach consensus to complete state synchronization.
Taking Solana as an example, most of the nodes in the world can complete state synchronization within the standard block time most of the time, but blockchain technology is still essentially a distributed database technology based on final consistency. This will also cause the state of all nodes in the world to be out of sync at certain times. At present, this problem involves the fundamental existence of blockchain distributed technology.
Especially when some extremely popular transactions are "artificially" stuffed with spam junk transactions, Solana's global nodes will be congested and blocked on such transactions. The busy nodes will then cause delays in state synchronization. With the continuous iteration of Solana nodes, although the spam filtering ability is constantly improving, this problem will still occur occasionally and is difficult to avoid.
DBot will reply with a failure message when the sale fails. If it fails continuously, you can try to switch to the plug-in wallet to sell manually.
At the same time, we are also preparing to open more solana private staking nodes in more global regions for users to choose. If the node status of a certain area is blocked, users can automatically/manually switch to nodes in other continents to try.
What makes DBot SOL so fast? Why is there a chance to buy in the same block or first?
DBot's DEX automated trading system uses professional financial-grade technical solutions. Unlike robots on the market, our trading system is embedded in private nodes, which means that we have modified the node code.
A node is a node, but it is also an automated trading system. We do not have the traditional network interaction delay. All data delays occur in the memory and cache inside the computer system, thereby achieving the lowest delay and the fastest speed. Our engineers have been continuously optimizing the code integration of nodes and automated systems, optimizing data structures and CPU cache design to achieve the fastest trading speed.
When the transaction is triggered, under the pure memory-level delay inside the DBot node computer (which can be understood as 0 delay), your transaction will be pushed to the global node consensus through our own private node as soon as possible. The time in this process will be affected by the network fluctuations of the global node consensus. Gas fees, bribery fees, network congestion, etc. will affect the final result.
At present, according to our observation, the DBot speed has the opportunity to be the same block, and sometimes it can even exceed the copy target. We are self-built nodes, and there will be no situation where they are occupied by external services. We can ensure that service resources are exclusively for our member users during the peak period of the market. At the same time, we have pledged nodes and have done a lot of intelligent routing broadcast optimization, striving to get on the chain as quickly as possible.
However, there are many global chain nodes, and the synchronization is very complicated. Occasionally, unexpected events such as short-term forks may occur. At the same time, the final chain is closely related to the current transaction concurrency and congestion level on the chain. However, in general, our current speed is ahead of the market, and we are continuously optimizing each version in this regard, constantly strengthening node firepower coverage and routing algorithm acceleration.
How to set up DBot SOL copy trading to be the fastest?
Due to the complexity of the on-chain situation, please set it according to personal needs, the style of smart wallet (the popularity of sniping tokens) and other factors.
The priority fee may vary depending on the congestion on the chain and the popularity of the token. The DBot automatic priority fee is currently a relatively gas-saving solution. It is recommended to use a custom priority fee setting during congestion. In the default mode of turbo mode, the priority fee will be auto split into multiple optimal transaction routing channels. (Customized priority fee and bribery tip for Solana's transactions supported)
Slippage determines the deviation between the purchase price and the price of the smart wallet. The slippage price is calculated as 1/(1-slippage). If it is set to 20%, it means that a maximum price deviation of 25% is accepted. It is not recommended to set too high slippage for large-amount purchases. It is recommended that the slippage be set within a reasonable range. 50% slippage means that you can accept a 2x price purchase, and 100% means that you can accept any price purchase. The slippage tolerance price is calculated as 1/(1-slippage). This depends on your copy trading needs and risk preferences.
Generally speaking, for the same gas, Turbo Mode will be faster and Anti-MEV mode will be safer. The speed and success rate of Turbo Mode are generally higher than Anti-MEV mode.
If you pursue high-frequency quantification and chain speed, and the single transaction amount is not large and the slippage is not high, you can use Turbo Mode, which is faster and has a higher success rate. If it is a large amount and high slippage transaction, it is recommended to use Anti-MEV mode.
At the same time, DBot provides professional advanced filtering functions in SOL copy buying, which can be set according to your needs to assist your transactions to the greatest extent.
SOL chain copy buy filter settings
Effective Time: Copy buy is only executed every day within this timeframe
Skip Fresszable: Freezable token won't be bought when enabled, the filtering function is realized through smart contract analysis and can only be judged based on the state of the transaction, and will be filtered as much as possible but not 100% guaranteed
Skip Mintable: Mintable token won't be bought when enabled, the filtering function is realized through smart contract analysis and can only be judged based on the state of the transaction, and will be filtered as much as possible but not 100% guaranteed
Skip Delegated: Delegated tokens have permission to be able to control all accounts of this token, allowing them to burn or transfer your tokens, no such tokens will be bought when enabled, the filtering function is realized through smart contract analysis and can only be judged based on the state of the transaction, and will be filtered as much as possible but not 100% guaranteed ( Only for Solana)
Only Buy Once: Buy the same token only once when enabled (The on-chain data is highly volatile, and this feature is only used as an auxiliary)
Skip Added Tokens: Skip tokens held by smart money when enabled
Min LP Burnt: The burned portion of the liquidity pool cannot be removed by the liquidity provider, e.g. if you set 50%, only tokens with a burned portion of the liquidity pool greater than or equal to 50% will be bought, Raydium(AMM) and Raydium(CPMM) supported, if you don't understand this option, just keep it to 0 (The on-chain data fluctuates a lot, this function is only used as an auxiliary)
Token Holding: If the following wallet buys tokens that your wallet is holding, whether or not to continue to follow buying (The on-chain data is highly volatile, and this feature is only used as an auxiliary)
Min Liquidity: Only buy tokens with liquidity above this value, the filtering function is realized through smart contract analysis and can only be judged based on the state of the transaction, and will be filtered as much as possible but not 100% guaranteed
Token Age: Only buy tokens with ages are within this range (Judged based on token creation time, not trade pair creation time, and the on-chain date is highly volatile, this feature is only used as an auiliary)
Top 10 Max Holdings: Only buy tokens with top 10 holdings less than this value (the filtering function is realized through samert contract analysis and can only be judged based on the state of the transaction, and will be filtered as much as posseible but not 100% guaranteed)
Copy Range: Only buy tokens that are bought within this range by the copied wallet, the filtering function is realized through smart contract analysis and can only be judged based on the state of the transaction, and will be filtered as much as possible but not 100% guaranteed
Market Cap Range: Only tokens with market cap in this range will be copied buy, the filtering function is realized through smart contract analysis and can only be judged based on the state of the transaction, and will be filtered as much as possible but not 100% guaranteed
Last updated
