Safe Approval on Chain but Not in Queue? Check the Proposal

A Safe developer asked why an owner's approveHash() call succeeded on-chain while other owners still saw nothing in Safe's queue. An on-chain hash approval is not itself a queue proposal. Safe's API Kit uses the separate Transaction Service to propose and share pending transactions with signers. Without that service record, the web app may have no pending item to show.

What did the on-chain approval actually create?

In an illustrative development session, I see the approveHash() transaction succeed on a block explorer and assume the Safe queue will pick it up automatically. The clue that changes the diagnosis is the difference between contract state and coordination state. The contract can record that an owner approved a hash; the Transaction Service stores proposed multisig transactions and off-chain confirmations so owners can discover pending work. The diagram above separates these two records. It is not a live Safe screenshot.

Before changing code, verify the Safe address, chain, nonce, and Safe transaction hash used in the approval. A normal Ethereum transaction hash for the approveHash() call is not the same identifier as the Safe transaction hash. If the approved hash was computed from different transaction data or nonce, proposing a different transaction will not make that approval apply to it.

Is there a proposal in the Transaction Service?

Check the pending transaction record for the correct Safe and chain in Safe's official app or through the supported Transaction Service API. Safe's proposeTransaction reference says it creates a multisignature transaction with confirmations and stores it in that service. Its inputs include the Safe address, Safe transaction hash, transaction data, sender address, and sender signature. Calling approveHash() on the contract alone does not submit those proposal fields to the service.

If the service has no matching proposal, the developer must use the supported proposal flow for the exact transaction they intend other owners to review. If it does have a proposal but the UI omits it, compare chain, Safe address, nonce and service status before assuming the approval failed. Do not generate a second transaction with altered data just to force a queue entry.

Does this mean the transaction is lost or needs reapproval?

Not necessarily. The question author's report says a second on-chain approval followed by execution worked, even though the queue was empty. That shows the queue and on-chain execution are different paths, but it does not prove that a missing proposal is safe to execute or that an approval applies to any similarly named transaction. Verify the exact hash and transaction data before collecting signatures or executing. If the transaction already executed, look in Safe's history rather than the pending queue.

This page explains a developer integration boundary, not a method for approving an unknown transfer. HideFi is independent of Safe and cannot inspect or sign a Safe transaction.