Altlayer
Altlayer transaction checks distinguish completed execution from unfinished settlement
Altlayer provides rollup infrastructure where transaction execution and settlement can require separate checks before another submission. Start with the transaction record on the rollup you used. A successful receipt establishes execution status; a withdrawal or other dependent action may need further confirmation. If the receipt is missing, establish whether the transaction remains pending before creating another request. A delayed interface alone doesn’t establish failure, and repeating an already successful action can create a second transaction.
In this guide
Key takeaway: A successful rollup transaction can still await settlement, so a delayed completion indicator alone doesn’t justify another submission.
Execution Can Finish Before Settlement
Rollup execution can produce a receipt before the underlying settlement process completes, leaving an application waiting after the transaction has already executed. MACH adds fast confirmation for rollups using that service, with its own verification mechanism. Its confirmation shouldn’t be substituted for a separate withdrawal requirement. Identify the confirmation the application accepts and the state the next operation requires.
Does This Transaction Need Another Submission?
Don’t repeat a successful initiation just because settlement is incomplete; submit again only when the transaction record and application state show another action is needed.
Successful Execution
A successful receipt calls for reconciliation with the application state. Match the transaction to the intended account, destination contract, and operation. Then inspect the relevant result, such as the recorded request or updated contract state. Execution success doesn’t establish that every later operation has finished. An application waiting for settlement can therefore remain incomplete without needing the original action again.
Pending or Unresolved Submission
A missing receipt leaves the outcome unresolved. On an Ethereum-compatible RPC interface, pending transactions don’t have receipts, and a receipt lookup returns null when it finds none. That response alone doesn’t distinguish a pending transaction from one the queried node doesn’t know. Check the transaction lookup and network selection before interpreting the absence as permission to retry. A connection timeout also describes the connection’s outcome, not necessarily the transaction’s outcome.
Transaction Details That Resolve Ambiguity
The transaction hash, execution status, and application result answer different questions, so keep them associated with the same chain and operation.
Chain and Transaction Identity
The selected rollup determines which transaction history matters. A wallet address alone doesn’t identify the network where an action occurred. Preserve the chain identifier and transaction hash together. If a replacement exists, keep its hash alongside the original so an unresolved original record doesn’t conceal a completed replacement.
Execution Status
Ethereum-compatible receipts encode successful execution as 0x1 and failure as 0x0. These values describe execution, not elapsed waiting time. The receipt also identifies the containing block. Apply these fields only where the rollup exposes compatible receipt semantics; don’t assume every execution environment uses the same response format.
Application Result
The intended result needs its own check. Contract events and readable state can establish which operation completed. A successful outer transaction doesn’t necessarily prove every internal call succeeded, because a contract can handle an internal failure without reverting the entire transaction. Interpret the application’s actual outcome before authorizing a repeat.
A Stricter Completion Requirement
Consider a hypothetical withdrawal on an Altlayer-supported optimistic rollup whose bridge requires settlement before completion. The withdrawal, displayed statuses, and completion requirement in this example are hypothetical.
Before submission, the sender defines completion as the withdrawal reaching its destination. The required network, destination, and withdrawal details must match that intention before signing. Rejecting an unsigned request avoids broadcasting it; after submission, closing the interface doesn’t provide an undo mechanism.
Now suppose the initiation transaction has a successful receipt, while the destination withdrawal remains incomplete. Both views concern the same request. Under an execution-only requirement, initiation is complete. Under the sender’s stricter requirement, the task remains open because the destination result is still missing.
Only the required completion state changed. Accepting execution permits earlier acknowledgement of initiation, while requiring destination completion means waiting through the bridge’s remaining conditions. The applicable challenge or proof conditions come from the deployed bridge, so a familiar waiting period from another deployment cannot settle this case.
Keep the successful initiation and continue tracking its existing withdrawal record. Once the bridge permits any required finalization, that step concerns the original withdrawal. A second initiation would create another request rather than complete the first one.
Withdrawal Completion Conditions
Optimistic rollup withdrawals can require a challenge period to finish before the settlement contract permits finalization. Proof acceptance and execution of the destination transaction may remain distinct steps. Other rollup designs use different verification conditions, so the word "confirmed" doesn’t establish a universal withdrawal deadline. Follow the state of the particular withdrawal record; repeating its initiation doesn’t advance its proof or finalization.
Replacement and Recovery Boundaries
Recovery depends on whether the original transaction remains pending, failed during execution, or completed without the application result you expected.
Pending Replacement
For ordinary Ethereum-style account transactions, supported replacement mechanisms reuse the sender’s nonce on the same chain. A new transaction with a later nonce is a separate submission and can duplicate the intended action. Replacement acceptance and fee requirements depend on the network and client. Cancellation attempts also compete with the pending transaction; they aren’t guaranteed to win. An already confirmed transaction can’t be undone through pending-transaction cancellation.
Failed Execution or Conflicting Records
A failed receipt requires a cause-specific adjustment. Raising a fee doesn’t repair a contract condition that rejects the operation. An execution failure can also consume gas even though the intended state change doesn’t persist. If the wallet, application, and chain record disagree, preserve the transaction details and stop additional submissions until the discrepancy is resolved. A retry should address an established failure, rather than add another unresolved transaction.
Before you start with Altlayer
Can Reopening My Wallet Cancel a Pending Rollup Transaction?
Reopening a wallet doesn’t cancel a transaction already submitted to the network. It can refresh the wallet’s displayed history, but the network processes submitted transactions independently of that window. Treat a refreshed display as an opportunity to inspect the existing transaction, not evidence that its submission disappeared.
Why Can a Transaction Remain Unresolved After a Fee Increase?
A higher fee doesn’t resolve every reason a transaction remains pending. An earlier pending nonce can prevent a later ordinary account transaction from executing, and a replacement must satisfy the network’s acceptance rules. Check which transaction the wallet actually replaced before assuming the fee adjustment affected the intended request.
Which Details Help Support Investigate an Incomplete Transaction?
The chain identifier, transaction hash, intended operation, and exact error message give support a useful starting record. Include any replacement hash and distinguish the wallet’s message from the application’s message. Transaction investigation doesn’t require a recovery phrase or private key; those credentials authorize control of the account.
Does a Successful Token Approval Mean the Intended Operation Finished?
A successful ERC-20 approval sets the spender’s allowance; it doesn’t complete a separate operation that uses that allowance. Identify which contract call the receipt covers. If the application requires a subsequent transaction, approval success alone won’t establish that the later action executed.
What Happens If a Receipt Disappears After Initially Appearing?
A disappearing receipt requires another check of the transaction’s inclusion and the node’s view of the chain. Before finality, a chain reorganization can change block inclusion. A missing response from one service doesn’t by itself establish a reorganization, so don’t immediately turn that discrepancy into another submission.
Is Rebroadcasting Signed Transaction Data the Same as Creating a New Transaction?
Rebroadcasting identical signed transaction data retains the same transaction identity. Creating and signing a different transaction can produce another hash, even when the requested action looks identical. Whether that new transaction replaces the original depends on its nonce and the network’s replacement rules.