Troubleshoot wallets and Safes
Wallet is on the wrong account or chain
Section titled “Wallet is on the wrong account or chain”Reject the prompt, switch in the wallet extension, and prepare the action again. The connected address and chain must match the handoff exactly.
WalletConnect does not open or pair
Section titled “WalletConnect does not open or pair”- Refresh txcast and start a new WalletConnect pairing.
- Confirm that your browser, VPN, or firewall can reach WalletConnect Verify and Relay services.
- 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.
Safe proposal is missing
Section titled “Safe proposal is missing”- 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.
Signature is rejected
Section titled “Signature is rejected”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.
Signing succeeded but execution did not
Section titled “Signing succeeded but execution did not”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.
Another signer is submitting execution
Section titled “Another signer is submitting execution”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.
Transaction hash stays pending
Section titled “Transaction hash stays pending”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.
Nonce conflict or replacement
Section titled “Nonce conflict or replacement”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.
EOA batch partially succeeded
Section titled “EOA batch partially succeeded”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.