Why Arbitrum Changes Your Sender Address on L1 to L2 Calls
When you send a message from Ethereum to Arbitrum, something unusual happens: the sender address gets changed. This isn't a glitch. It's a deliberate security feature called address aliasing.
Arbitrum modifies the sender address to prevent cross-chain replay attacks. Without aliasing, a valid transaction on L1 could be replayed on L2 with unintended consequences. The mechanism ensures that a message intended for one chain cannot be copied and executed on the other.
How the aliasing works
Arbitrum takes your original L1 address and adds a fixed offset to it. The offset is 0x1111000000000000000000000000000000001111. This calculation is deterministic; anyone can compute the aliased address from the original.
For example, if your L1 address is 0x1234..., the aliased address becomes 0x1234... + 0x1111.... The result is a new address that exists only within Arbitrum's context, and this aliased address is what appears as the msg.sender when an L1-to-L2 message executes.
Why contracts must account for it
Any contract that receives L1-to-L2 messages must handle the aliased sender. If your contract checks msg.sender against a whitelist, it must include the aliased address, not the original L1 address. Failing to do this causes the message to revert.
The typical pattern is to convert the expected L1 address to its aliased version inside the contract, using a simple function that adds the offset. Contracts designed for cross-chain use often hardcode this logic.
The 'Sender is aliased address' error
This error appears when a user or wallet sends an L1-to-L2 message but the contract on L2 expects the original address. The message executes, but the sender comes through as the aliased version. The contract rejects it because the sender doesn't match expectations.
The fix is usually on the contract side. Developers must update their code to accept the aliased sender. For users, the error simply means the destination contract isn't compatible with Arbitrum's aliasing system.
How smart contract wallets interact
Smart contract wallets like Safe (formerly Gnosis Safe) face a particular problem: these wallets manage permissions and signatures across multiple addresses. When a Safe on L1 sends a message to L2, the aliased address differs from the wallet's L1 address. Safe modules and guards must account for this. If the wallet's logic checks the sender against its own address, it will fail. The module needs to recognize the aliased version as a valid caller, which often requires custom deployment or configuration.
Some implementations use a msg.sender check that compares against both the original and aliased addresses. Others rely on the retryable ticket mechanism, which handles aliasing automatically for certain message types.
Practical implications
If you're building on Arbitrum, you cannot ignore aliasing. Every L1-to-L2 message goes through this transformation. Your contracts must expect it, your frontend must handle it, your error logs must account for it.
The system is simple. The offset is fixed. The math is straightforward. But the consequences of forgetting it are real: a contract that doesn't handle aliasing will silently reject messages. Arbitrum's approach is not unique; other rollups use similar techniques. The specifics differ, but the principle is the same - prevent replay by changing the sender identity between chains.
What to check
When debugging an L1-to-L2 call that fails, verify the contract's sender handling. Look for address aliasedAddress = address(uint160(originalAddress) + uint160(0x1111000000000000000000000000000000001111)) in the code. If it's missing, that's likely the issue.
The aliasing mechanism is a design trade-off. It adds complexity for developers, but it removes a class of security vulnerabilities. For most users, it happens invisibly. For builders, it's a mandatory detail. Arbitrum's documentation covers this in depth, and the offset never changes. The rule is consistent: learn it once and it applies to every L1-to-L2 interaction you write.
Not financial advice. dogekaki.com publishes market data and general information about digital assets. Crypto assets are volatile and you can lose everything you put in. Nothing here is a recommendation to buy, sell or hold, and we make no price predictions.
Prices are sourced from third parties and may be delayed or wrong. Verify anything you intend to act on against a primary source.