How to Read an Arbitrum Transaction on Arbiscan

01 October 2026

Arbiscan is the block explorer for Arbitrum, and reading a transaction there means distinguishing between what is real, what is a rollup artifact, and what matters for your funds. The first thing to understand: a transaction on Arbiscan is not a clean record of "you sent X to Y." It is a compressed rollup message that Arbiscan interprets for you, and the interpretation is usually right, but not always complete. To read it correctly, you focus on three things: the transaction type, the internal calls, and the L1/L2 linkage.

The transaction overview: what you see first

When you open a transaction hash on Arbiscan, the top panel shows the standard fields: Transaction Hash, Status, Block, Timestamp, From, To, Value, and Fee. On Arbitrum, two of these deserve extra attention.

Status. A green "Success" here means the sequencer accepted and executed the transaction. It does not mean the result is final on Ethereum. For that, you need to check "Finality" or the L1 state root, which is covered in the site's article on finality. A red "Failed" means the transaction executed but reverted - gas is still charged, and you can read the revert reason by expanding the "More" section or looking at the "Revert Reason" field if present.

From and To. On Arbitrum, these are the L2 addresses, not the L1 addresses. If you bridged from Ethereum, the L1 sender is not shown here. The site's earlier piece on sender address changes explains why. For a basic read, just know: if you sent funds from an exchange, the From will be the exchange's hot wallet, not you.

Read the "Method" and "Input Data" for What Actually Happened

The Method field (e.g., "deposit" or "approve") is Arbiscan's best guess at the function called, based on the 4-byte selector. Do not trust it blindly. The same selector can be repurposed by different contracts. To verify, expand "Input Data." You will see a long hex string. The first 4 bytes are the selector; the rest are the encoded arguments. You do not need to decode it manually - copy the entire input, go to the "Decode" tab on Arbiscan, and it will translate it into readable parameters. If you see a method like "swapExactTokensForTokens" and the decoded output shows a token swap, that is your real transaction. If the method is "0x" (empty) and the transaction value is non-zero, it was a plain ETH transfer.

Internal transactions: where the real action is

Arbitrum transactions often wrap multiple internal calls. For example, a swap on Uniswap on Arbitrum will show the top-level transaction as a call to the router, but the actual token movement happens in internal calls to the pair contract. Click the "Internal Txns" tab. You will see a tree of calls: from Router to Pair, from Pair to your address, etc. This is where you confirm the actual token received or sent. A common mistake is reading only the top-level "To" field, which is the contract, not your counterparty. The internal calls show the true transfer path.

L1 and L2: the two tab system

Arbiscan shows two tabs for every transaction: "L2" and "L1." The L2 tab is the execution you see. The L1 tab shows the compressed calldata that was posted to Ethereum. For most reads, you can ignore the L1 tab. But there are two cases where it matters.

First, if you are checking a deposit or withdrawal. A deposit from Ethereum will have an L1 transaction hash, and Arbiscan will link it under the "L1" tab. Clicking that link takes you to the Ethereum transaction that triggered the bridge. Second, if you want to verify that the sequencer did not censor or modify your transaction, the L1 tab shows the "Data" field - a long hex string that contains the rollup block. You cannot easily read it, but its presence confirms your L2 transaction was included in the batch.

Reading Fees: The "Gas Used by Transaction" and "L1 Fee"

Arbitrum has two fee components, and Arbiscan shows them separately. The "Gas Used by Transaction" is the L2 execution gas. The "L1 Fee" is the cost of posting your transaction's calldata to Ethereum. The total fee is not simply gas price times gas used; it is L2 fee plus L1 fee. If you see a transaction with an unexpectedly high fee, check the L1 fee first. During periods of high Ethereum gas, the L1 fee can dwarf the L2 fee. Arbiscan shows both under "Transaction Details." There is also a "L1 Fee Scalar" field - you do not need to know how to compute it, but if you are comparing costs across RPC providers or wallets, this is the field that changes with network congestion.

The "State" and "Batch" Fields: Finality, Not Success

Below the fee fields, you will typically see a "State" field (e.g., "Batch Confirmed" or "Confirmed on L1") and a "Batch" number. "Success" only means the sequencer accepted it. "Batch Confirmed" means the data was posted to Ethereum. "Confirmed on L1" means the state root was finalized. For a complete read of a transaction, you should not call it settled until you see it confirmed on L1, unless you are comfortable with the sequencer's liveness assumption. The site's finality article covers this in depth; here, the key is to know that Arbiscan shows you which stage you are at.

A practical walkthrough: reading a simple transfer

Suppose you sent 100 USDC to a friend. Open the transaction hash.

1. Check Status: "Success."
2. Look at From and To. The To is your friend's L2 address. The From is yours.
3. Look at Method. It might say "transfer." Expand Input Data. If you see a "to" parameter and a "value" parameter, that is your recipient and the amount in the token's smallest unit.
4. Go to "Internal Txns." You should see a call to the USDC contract, and the transfer event. The token's decimal places (6 for USDC) matter: 100 USDC shows as 100000000.
5. Check the fee. The "Transaction Fee" is what you paid. If you want to know why it was high, compare the L1 fee to the L2 gas cost.

If the transaction was a swap, replace step 4: the internal txns will show a series of calls between the router, the token pair, and possibly a transfer to your address. The last internal call that credits you is the output amount.

Common traps when reading

• Token transfers disguised as contract calls. If you see a transaction "To" a contract and the Method is "0x", it might still be a token transfer. Check Internal Txns.
• Wrong token decimals. Arbiscan will show the raw value. If you see 1000000000000000000 next to a token with 18 decimals, that is 1 token. If the token has 6 decimals, the same raw number is a billion tokens. Always confirm the token contract and its decimals.
• Phantom values. Some transactions show a "Value" of 0 ETH but move tokens. That is normal for ERC-20 transfers. The value field only covers the native token (ETH on Arbitrum).
• The "More" dropdown. Click it. It shows the revert reason on failed transactions, which is often the only way to understand why a swap failed without decoding the entire stack trace.

When the Read Is Hard: Use the "Logs" Tab as a Fallback

If the internal txns are empty or confusing, go to the "Logs" tab. Every token transfer emits a Transfer event. The logs will show the sender, recipient, and amount in the indexed topics and data. For most ERC-20s, topic 0 is the Transfer event signature, topic 1 is the sender, topic 2 is the recipient, and the data field is the amount. This is the raw truth, even if the method decoding fails. If you see a Log with a "From" that matches your address and a "To" that matches your friend's, the transfer happened, regardless of what the Method field says.

Reading an Arbitrum transaction on Arbiscan is a skill of ignoring noise. The top panel gives you the headline; the internal calls and logs give you the facts. Start with the method, verify with the internal calls, and confirm the token amounts with the logs. That sequence will cover the vast majority of transactions you need to understand.

Back to arbitrum