Skip to content

Troubleshoot wallets and Safes

Reject the prompt, switch in the wallet extension, and prepare the action again. The connected address and chain must match the handoff exactly.

  1. Refresh txcast and start a new WalletConnect pairing.
  2. Confirm that your browser, VPN, or firewall can reach WalletConnect Verify and Relay services.
  3. If the console reports that the origin is not allowed, add the exact txcast origin to the WalletConnect project allowlist and wait for the change to propagate.

Do not disable browser security or install an extension that bypasses the page’s Content Security Policy.

  • Confirm the same chain, Safe address, nonce, and safeTxHash.
  • Refresh Safe Transaction Service state.
  • Check whether STS is delayed or rate-limited.
  • Do not submit a second proposal with changed data unless you intend a different Safe transaction.

If txcast shows Signature queued, leave the exact signed payload alone. The pending relay retries after STS rate limits or an interrupted worker and checks the exact safeTxHash before another POST. A matching externally created proposal is adopted automatically.

Verify that the signer is a current Safe owner, signed the exact EIP-712 data, and has not already submitted. Owner or threshold changes can invalidate an older prepared attempt.

The two wallet confirmations are separate. A declined or failed execution does not discard an accepted Safe signature; reopen the step and execute the ready attempt. If the wallet broadcast succeeded but txcast could not record it, keep the displayed transaction hash and retry after connectivity returns. Safe sync can also reconcile the onchain execution. Before any execution broadcast, txcast refreshes the attempt and stops if it was already submitted from another tab or wallet.

txcast allows one active execution wallet prompt per attempt. Wait for the displayed countdown. The claim is renewed while that wallet stays open and is released on rejection or a pre-broadcast failure. If you know no transaction was broadcast, retry after expiry. If a hash may have been broadcast, sync and check the Safe before trying again.

The transaction may be unmined or below the network’s configured confirmation depth. Sync after more blocks. For Safe execution, txcast also requires the matching ExecutionSuccess event.

Another pending Safe transaction at the same nonce permits additional signatures but blocks execution. If another transaction consumed the nonce, txcast invalidates the old attempt. Sync the run, compare the onchain event, and prepare a fresh attempt only after understanding the competing transaction.

Inspect each transaction index. Never resend an already successful index. Determine whether the remaining request is still safe against the new state, then use the run’s current recovery options or cancel it.