While hosting a non-voting validator (RPC node) I noticed that a majority of TXs sent to it are being dropped, the RPC node starts with the following args:

--identity ~/validator-keypair.json
--entrypoint entrypoint.mainnet-beta.solana.com:8001
--entrypoint entrypoint2.mainnet-beta.solana.com:8001
--entrypoint entrypoint3.mainnet-beta.solana.com:8001
--entrypoint entrypoint4.mainnet-beta.solana.com:8001
--entrypoint entrypoint5.mainnet-beta.solana.com:8001
--known-validator 7Np41oeYqPefeNQEHSv1UDhYrehxin3NStELsSKCT4K2
--known-validator GdnSyH3YtwcxFvQrVVJMm1JhTS4QVX7MFsX56uJLUfiZ
--known-validator DE1bawNcRJB9rVm3buyMVfr8mBEoyyu73NBovf2oXJsJ
--known-validator CakcnaRDHka2gXyfbEd2d3xsvkJkqsLw2akB3zsN1D2S
--rpc-port 8899
--vote-account ~/vote-account-keypair.json
--log ~/log/solana-validator.log
--accounts /mt/accounts/solana-accounts
--ledger /mt/ledger/validator-ledger
--wal-recovery-mode skip_any_corrupted_record

These are the default args found in the solana labs guide. In the logs I see the following:

[2024-02-02T23:28:01.605266057Z INFO  solana_quic_client::nonblocking::quic_client] 
Made 0rtt connection to with id 139194177714192 try_count 0, 
last_connection_id: 139483630342160, last_error: 
Some(ConnectionError(ApplicationClosed(ApplicationClose { error_code: 1, reason: 
b"dropped" })))

[2024-02-02T23:28:01.655178394Z INFO  solana_quic_client::nonblocking::quic_client] 
Error sending to with id 139177516703760, error 
WriteError(ConnectionLost(ApplicationClosed(ApplicationClose { error_code: 1, reason: 
b"dropped" }))) thread: ThreadId(1763)

[2024-02-02T23:28:01.655198774Z WARN  solana_quic_client::nonblocking::quic_client] 
Failed to send data async to, error: 
Custom("WriteError(ConnectionLost(ApplicationClosed(ApplicationClose { error_code: 1, 
reason: b\"dropped\" })))") 

Followed by "Retrying transaction" and "Dropped transaction due to max retries" logs. This happens even when sending single transactions to the node.

Things I tried:

  1. Using standard args from the official guide (as seen above)
  2. Storing ledger/ accounts on different NVMe ssds
  3. Increasing dynamic-port-range
  4. Disabling firewall altogether
  5. Using different server location
  6. Using different, stronger hardware
  7. Using/ not using account indexes
  8. Played around with tpu-disable-quic and tpu-enable-udp flags

I'm not sure if this is expected behavior, it doesn't seem like it since it happens in all cases for a majority of TXs. Any help is greatly appreciated!

  • Any recommendations for solution?
    – Eray CANLI
    Mar 28 at 19:49
  • I too have this issue with similar errors. Would love to know how to fix this.
    – CryptoLexx
    Apr 3 at 17:39


Your Answer

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

Browse other questions tagged or ask your own question.