# Discrepancy in Default Account Behavior

DefaultAccount fallback asserts msg.sender != bootloader, so a custom account delegate-calling a default account reverts instead of behaving like an EOA.

- Payout: Contest reward
- Severity: medium
- Program: zkSync
- Credited: anon
- Disclosed: 2024-02-29
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-10-zksync-findings/issues/168
- Library page: https://bugbountylibrary.com/r/c4%3A2023-10-zksync%3AM-18
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** DefaultAccount system contract fallback/receive
**Root cause:** The fallback function asserts msg.sender != BOOTLOADER_FORMAL_ADDRESS; during a delegatecall from a custom account's _execute, msg.sender is the bootloader, so the assert reverts, unlike real EOA behavior.
**Steps:**
1. Deploy a custom account whose _execute does `address(to).delegatecall("0x1234")` and requires success.
2. Set `to` to a DefaultAccount address.
3. Bootloader invokes _execute; delegatecall hits DefaultAccount fallback with msg.sender == BOOTLOADER_FORMAL_ADDRESS.
4. assert fails, delegatecall returns success=false, require reverts.
**How found:** Read the DefaultAccount docs claiming EOA-equivalent behavior, compared fallback/receive implementation, and reasoned about the delegatecall path where msg.sender becomes the bootloader.
**Insight:** When a contract promises EOA-equivalent semantics, test it under delegatecall: msg.sender becomes the caller's caller (bootloader), so sender-based asserts that hold for direct calls break under delegation.