# Freeze The Bridge Via Large ERC20 Names/Symbols/Denoms

Attacker deploys ERC20 with huge name/symbol/denom via Gravity.deployERC20, bloating eth_getLogs past 10MB limit and permanently freezing all Ethereum oracles.

- Payout: Audit contest
- Severity: high
- Program: Althea Gravity Bridge
- Found by: nascent
- Disclosed: 2021-08-19
- Write-up quality: 8/10
- Original: https://github.com/code-423n4/2021-08-gravitybridge-findings/issues/5
- Library page: https://bugbountylibrary.com/r/c4%3A2021-08-gravitybridge%3AH-03
- Tags: area:web3 domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:rust tech:solidity technique:source-review vuln:dos

**Target:** Gravity.sol deployERC20 / orchestrator eth_getLogs event watcher
**Root cause:** eth_getLogs response is capped at 10MB in web30; a single ERC20DeployedEvent with a huge denom/name/symbol exceeds the cap, causing a persistent BadResponse error that halts the oracle loop.
**Steps:**
1. Call `Gravity.deployERC20(_cosmosDenom, _name, _symbol, _decimals)` with a very large string (denom cheapest at ~256 gas/32 bytes; name/symbol ~584 gas/32 bytes using mostly zero bytes).
2. Event ERC20DeployedEvent is emitted with the oversized string.
3. Oracle's `check_for_events` calls `eth_getLogs` over the 6-block window; response exceeds the 10MB `limit(10_000_000)`.
4. web30 returns `Web3Error::BadResponse`, oracle loop errors perpetually; `get_last_checked_block` never advances.
**How found:** Code review of the orchestrator's event watcher traced into web30's eth_getLogs, noticing the hardcoded 10MB response limit and that deployERC20 accepts unbounded user-controlled strings emitted in the event.
**Exploitation:** Attacker with minimal capital deploys one or more ERC20s with oversized metadata; every validator's Ethereum oracle repeatedly fails fetching logs, so no attestations (batches, logic calls, deposits, valset updates) are produced and the bridge freezes until patched.
**Insight:** When an oracle/indexer fetches logs over a block range with a fixed response-size cap, look for any user-triggerable event whose payload size is unbounded—one cheap transaction can permanently wedge the loop if the error isn't chunked/retried.