A user connects their Keplr wallet to an Osmosis liquidity pool, approves a swap, and watches the transaction sit in pending status for ten minutes, then twenty. The gas fee paid appears reasonable, but the transaction has not moved, and resubmitting it risks doubling the cost. This scenario repeats across the Cosmos ecosystem: a user initiates a cross-chain transfer via IBC, sees the transaction accepted by the wallet, but finds no confirmation on the receiving chain. Network congestion, miscalculated gas limits, and chain-specific peculiarities can all cause transactions to stall, and the remedy depends on accurate diagnosis rather than panic repeating.

The Keplr wallet extension has become the standard interface for managing assets across Cosmos Hub, Juno, Terra, Secret Network, Evmos, Akash, and dozens of other Cosmos-connected blockchains. Its browser-based convenience and support for hardware wallets like Ledger make it accessible to both experienced users and newcomers. However, the same multi-chain architecture that enables seamless asset management also means that transaction failures carry different causes depending on which network is involved, which gas estimation was used, and whether the issue lies with the wallet, the blockchain, or the dApp being accessed.

Understanding why transactions get stuck on Cosmos networks

The Cosmos ecosystem consists of independent blockchains that prioritize transactions using a mempool—a holding area where transactions wait to be included in a block. When a transaction enters a mempool but the network is congested, the transaction may sit indefinitely if its gas price is too low relative to competing transactions. Unlike Ethereum’s dynamic base fee, Cosmos chains typically use a simpler gas price model: a transaction must offer enough per-unit gas to incentivize validators to include it. If the Keplr wallet extension automatically calculated a gas price based on historical averages, and those averages have suddenly risen, the transaction becomes uncompetitive.

Network-specific slowness also matters. Osmosis, for example, experienced several periods of reduced block time and validator activity when traffic spiked. Secret Network’s privacy features add computational overhead, which can affect confirmation speed. Juno, Evmos, and other application-specific chains have their own distinct validator sets and block-production cadences. A transaction that takes two seconds to confirm on Cosmos Hub might take thirty seconds on a smaller chain, not because anything is wrong but because blocks are produced less frequently or validators are fewer. The Keplr wallet does not always make these differences visible in the interface, so users may mistake normal variation for failure.

IBC transfers deserve special mention because they involve two separate transactions: one to initiate the transfer on the source chain, and one or more relayer transactions that move the data across the IBC protocol. A pending IBC transaction can appear stuck if the source chain confirmed the transaction but relayers have not yet submitted the receiving chain’s side. This is not a wallet failure; it is the asynchronous nature of IBC. Users who check only the wallet interface may not see the source transaction succeed while waiting for the receiving chain to show the funds.

Gas limits also interact unpredictably with contract logic. A swap through Osmosis or a stake through a validator might fail silently—the transaction is confirmed on-chain, but the actual swap or stake did not execute, leaving the funds stuck in a contract or returned incorrectly. The Keplr wallet extension displays transaction success or failure status, but intermediate contract failures may not be obvious without reviewing the actual transaction logs in a block explorer.

Step one: Identify the transaction status in a block explorer

The first diagnostic step is to open a block explorer corresponding to the chain where the transaction was sent. Cosmos Hub transactions can be checked on Mintscan or Ping; Osmosis uses Mintscan; Juno uses Mintscan or Juno.Ping; Secret Network uses Secretscan; and most other Cosmos chains have dedicated explorers listed on Cosmos Chain Registry. The Keplr wallet typically displays a link to the transaction hash in the transaction history panel. Clicking that link should open the block explorer, or the user can copy the transaction hash and search manually.

In the block explorer, look for the “Status” field. A confirmed transaction will show “Success” and a block height. A failed transaction will show “Failed” and typically include an error message in the logs. A transaction still waiting in the mempool will show “Pending” with no block height assigned yet. This distinction is critical: a pending transaction can potentially be rebroadcast with higher gas, while a failed transaction needs to be re-initiated, and a successful transaction is complete even if the Keplr wallet interface has not yet updated its display.

For IBC transfers, check the source chain first. If the source transaction shows “Success,” then the IBC transfer has been initiated correctly, and the delay is on the relayer or receiving-chain side. Wait another block or two, then check the receiving chain for an inbound IBC packet. If the source transaction shows “Failed,” the problem originated on the sending side, and the user should review the error message and attempt the transfer again with adjusted parameters.

Gas spent is also visible in the explorer. Compare the gas actually used against the gas limit that was approved in the Keplr wallet. If gas used is very close to the gas limit, the transaction may have been cut off mid-execution—this is a strong indicator that the gas limit was too low and should be increased on the next attempt.

Adjusting gas settings for future transactions

When a user initiates a transaction through the Keplr wallet extension, a dialog box appears with fields for gas limit and gas price. The wallet provides a default calculated based on the transaction type and network conditions. For simple transfers, the default is usually sufficient. For more complex operations—swaps, staking, cross-chain interactions—the default estimate often underestimates the actual gas needed.

Gas limit is the maximum amount of gas the transaction is allowed to consume. If the transaction consumes more gas than the limit, it fails and the gas fee is still charged. Gas price is the amount per unit of gas, expressed in the native token (ATOM for Cosmos Hub, OSMO for Osmosis, and so on). Multiplying gas limit by gas price yields the total fee. Increasing the gas price makes the transaction more attractive to validators when the network is congested; increasing the gas limit allows more complex operations to complete.

The Keplr wallet typically shows preset options: “Low,” “Average,” and “High” gas price. During network congestion, selecting “Average” or “High” often prevents the transaction from stalling. For gas limit, users can select a preset or input a custom value. A safe strategy is to raise the estimate by 20 to 50 percent above the default recommendation, particularly for smart-contract interactions or IBC transfers. Some explorers show recently confirmed transaction details, which can inform realistic gas limits for similar operations.

Hardware wallet users (those using Ledger with the Keplr wallet extension) should note that gas adjustments happen before signing. The Ledger device displays the transaction details and asks for approval; gas parameters are set in the Keplr interface beforehand. Review the gas settings carefully before connecting the hardware device, because changing them afterward requires the entire signing process to restart.

Handling failed swaps and stuck contract interactions

A transaction confirmed on-chain but a swap did not execute—or executed partially—is a common scenario on DEXes like Osmosis. This occurs when the transaction succeeded at the blockchain level (gas was paid, the transaction is in a block) but the smart contract encountered an error and reverted the intended operation. The block explorer shows the transaction as “Success” but includes error details in the logs, often a message like “insufficient output amount” or “slippage exceeded.”

Slippage is the difference between the expected output price and the actual executed price. If a user approved a 0.5 percent slippage tolerance and the price moved more than that between the time the transaction was submitted and the time it executed, the contract rejected the swap to protect the user. This is a safety feature, not a loss; the funds are returned and can be used for another attempt. However, the gas fee for the failed transaction is already spent.

When a swap fails due to insufficient liquidity or slippage, the user should check the Osmosis or other DEX interface to confirm the current price and liquidity depth. A second attempt with adjusted parameters—a larger slippage tolerance or a higher minimum output—may succeed if conditions have stabilized. Submitting the identical swap immediately after failure is unlikely to help; waiting a few blocks allows market conditions and mempool depth to shift.

For complex interactions like automated liquidity provision or leveraged positions, contract failures can be harder to interpret. The block explorer may display raw error codes rather than user-friendly messages. In these cases, reviewing the contract documentation or asking in Cosmos community forums with the transaction hash often clarifies what went wrong. The key principle remains: a confirmed transaction with a “Success” status is final. The funds cannot be recovered through retransmission; they can only be recovered if the smart contract logic allows an explicit withdrawal or recovery function.

Using RPC endpoints and network diagnostics when standard approaches fail

Sometimes the bottleneck is not the user’s transaction but the network state itself. A large number of pending transactions, validator downtime, or consensus issues can cause all transactions to slow. The Keplr wallet extension connects to a default RPC endpoint (a server that relays transactions and provides blockchain state information). If that endpoint is overloaded or out of sync, transactions may appear stuck even though the network is functioning normally.

Users can change the RPC endpoint within the Keplr wallet settings. Each Cosmos chain has several public RPC endpoints listed on Cosmos Chain Registry. Switching to an alternative endpoint—provided by a different service provider—may resolve connectivity issues. In the wallet, open Settings, select the chain in question, and look for an option to change the node or RPC endpoint. Some users prefer to run a personal node, though this requires significant technical effort and disk space.

Block explorer activity also provides a clue. If Mintscan or a similar explorer shows a high number of pending transactions and confirmations are slow across many users, the network itself may be congested. In this case, waiting an hour or two and retrying with higher gas is often more effective than immediately resubmitting. If the explorer shows normal activity and only the user’s specific transaction is stuck, the issue is more likely to be insufficient gas for that particular transaction.

For users running the Keplr wallet extension on a system with limited memory or internet connectivity, also consider local factors. A browser extension that has been open for days may accumulate memory overhead; restarting the browser sometimes helps. A network with packet loss or latency may cause timeouts in the wallet’s communication with the RPC endpoint, making transactions appear pending when they have actually been included in a block but the wallet has not received the confirmation.

Preventing future transaction delays through better planning

The most reliable way to avoid stuck transactions is to anticipate network conditions before they cause problems. This begins with understanding which chains tend to be congested and at what times. Cosmos Hub typically sees higher traffic during ecosystem-wide events or governance votes. Osmosis spikes during liquidity events or when significant price swings trigger high trading volume. Secret Network’s validator set is smaller, so congestion can build faster. By checking block explorer history and community announcements, users can schedule important transactions for calmer periods.

A second layer of prevention is to confirm gas settings before clicking approve. The Keplr wallet extension should always display the total fee in human-readable terms. If a transaction shows a fee of 0.5 ATOM, that is reasonable. If it shows 10 ATOM for a simple transfer, something is misconfigured. Users should double-check estimated gas limits against recent transactions of the same type in the block explorer. Most swaps use 200,000 to 400,000 gas; most transfers use 100,000 to 150,000 gas. Outliers warrant investigation.

A third approach is to batch transactions when possible. Instead of initiating five separate transactions over five minutes during congestion, submitting them in quick succession can reduce the total time spent waiting. Batching also improves cost efficiency because the per-transaction overhead of RPC communication is spread across more actions.

For high-value transactions, a hardware wallet integration provides an extra safety checkpoint. The deliberate process of connecting a Ledger, reviewing transaction details on the device screen, and signing creates a pause that encourages careful verification. Non-custodial wallets like Keplr give the user full control over their private keys, but that responsibility includes reviewing transaction details before approval. Taking an extra ten seconds to confirm the amount, recipient, gas limit, and gas price on the wallet extension screen before initiating the signature request can prevent most irreversible errors.

When to seek help and how to report transaction issues

If a transaction has been pending for more than one hour on a normally-functioning chain, and the block explorer confirms it is still in the mempool, the transaction is very unlikely to confirm at its current gas price. At this point, resubmitting with higher gas is reasonable. Some users worry that this will create a duplicate transaction, but if the original transaction has not been included in a block yet, increasing its gas and rebroadcasting it replaces the pending version rather than creating a second transaction. Check the transaction hash in the block explorer afterward to confirm only one transaction was included.

If a transaction failed on-chain but the funds have not been returned within a few blocks, and the block explorer shows no obvious recovery function in the contract, the next step is to identify the exact error message. The block explorer’s transaction detail page should include a “Logs” or “Events” section. Copy the error text and search for it in the Cosmos chain community Discord or Telegram. Most common errors have known causes and solutions documented by the community.

For support specific to the Keplr wallet extension itself—such as questions about how to connect a Ledger, restore from a recovery phrase, or use multi-chain portfolio features—the official Keplr documentation and support channels are the authoritative source. Users can find detailed guides through the official website and should verify they are using the legitimate keplr wallet extension by checking the Chrome Web Store or official mobile app stores before installation.

When reporting transaction issues in community channels, include the transaction hash, the chain name, the block explorer link, and a description of what was expected to happen versus what occurred. Avoid posting private keys, recovery phrases, or other sensitive information even when describing a problem. A well-documented transaction report often attracts help from experienced users or developers who can decode logs and suggest recovery steps.

Multi-chain asset management and transaction prioritization

Users managing balances across multiple Cosmos chains face a secondary challenge: which transaction should be prioritized when networks are congested? A pending swap on Osmosis may tie up trading capital, while a pending IBC transfer from Cosmos Hub delays the arrival of liquidity. The Keplr wallet does not queue transactions or allow explicit prioritization, but understanding the cost-benefit of each pending action can guide manual decision-making.

If gas fees are elevated on all chains, prioritize transactions with the highest opportunity cost. A liquidity provider position that is losing value due to impermanent loss, or a leveraged position that is at risk of liquidation, should be resubmitted with higher gas. Routine transfers and non-urgent swaps can wait for network conditions to improve. The block explorer’s recent transaction list shows the gas prices of confirmed transactions, providing real-time guidance on what is currently feasible.

For users with hardware wallets, multiple pending transactions introduce a workflow challenge: each hardware wallet signature request requires physical interaction with the Ledger device. Batching helps here too. Instead of resubmitting one transaction multiple times, collect several failed transactions and resubmit them in sequence, each with improved gas parameters. This reduces the number of signing sessions while increasing the likelihood of overall confirmation.

The cross-chain nature of the Keplr wallet also means that failures on one chain can cascade. If an IBC transfer from Cosmos Hub to Osmosis fails, capital intended for a swap on Osmosis is delayed, which in turn affects the timing of any downstream transactions. Mapping out dependencies between transactions—which transaction provides liquidity for a subsequent operation—helps identify which failures are most urgent to resolve.