When a Treasury Transfer Is Stuck, Escalate on Evidence

Escalate a stuck treasury transfer when its expected processing window has passed and chain evidence cannot account for the delay. A payment may wait on approvals, network confirmation or a separate bridge step.

The key is to identify which step stopped before anyone retries or sends funds again.

What should you check before escalating?

Start with the transaction record on the sending chain, using the transaction hash and the intended destination address. A wallet interface can lag behind the network, so compare its status with a block explorer or another trusted source of chain data.

Then check the approval trail: who signed, whether the transaction was submitted, and whether any signer or custody service reports a pending action. For a cross-chain route, identify whether the transfer is waiting on the source transaction, a bridge message or a destination-chain transaction. The distinction between bridging first and swapping afterward affects which leg to trace; the fuller manta bridge guide covers that decision.

• Confirm the asset, amount, destination network and address against the approved request.
• Record the transaction hash, submission time and current chain status.
• Check whether the transaction is pending, failed or confirmed on the sending chain.
• For a bridge, look for a destination transaction or message status separately.

When should a treasury transfer be escalated?

Use the team’s expected processing window as the first threshold. If that window has passed, the transaction remains unresolved, and the chain record offers no clear next step, raise it with the person or service responsible for that stage.

Escalate sooner if the details do not match the approved instruction, the transaction failed, the destination address is uncertain or the funds appear to have reached an unexpected address. Those cases call for a review of the transaction and approval record, not a routine wait for confirmations.

A pending transaction needs a different response from a confirmed transfer. On some chains, a pending transaction may be replaceable or cancelable under specific rules, but a retry can create a second payment if the first one later confirms. Don’t resubmit until an authorized operator has checked whether the original transaction can still settle and what the chain’s replacement rules allow.

What information should you send with an escalation?

Give the responder enough detail to locate the exact step without relying on a wallet screenshot alone. Include the transaction hash, sending and destination networks, token and amount, destination address, submission time, approval status and the last observed chain status.

State what has already been checked and what decision you need: for example, whether to wait, investigate a bridge message or ask the custodian to review a submission. Keep the original request and any change approvals with the incident record. That makes it easier to distinguish a slow transfer from a wrong destination or a duplicate attempt.

For treasury teams, the practical rule is simple: escalate when the agreed window expires without an explainable status, and route the issue to whoever owns the stalled step. Preserve the evidence first; decide whether to resend only after the original transfer’s status is clear.