# `split` transaction's fixed fees undercharge block stuff DOS attacks

Aleo's split transaction charges a fixed 10-credit fee with no dynamic fee commitment, enabling cheap block-stuffing to crowd out liquidations and critical transactions.

- Payout: Contest reward
- Severity: high
- Program: Aleo
- Credited: dtheo
- Disclosed: 2024-05-27
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-05-aleo-judging/issues/35
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-05-aleo%3AH-2
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:high tech:rust technique:source-review vuln:business-logic vuln:dos vuln:fee-bypass

**Target:** L1 consensus/transaction fee mechanism (snarkVM credits.aleo split, block verify)
**Root cause:** The split transaction type has a hardcoded 10-credit fee at the program layer and requires no outer fee commitment, so it bypasses the consensus-layer dynamic fee mechanism that raises costs during congestion.
**Steps:**
1. Observe split transactions with a single transition skip fee commitment and pay fixed 10 credits in credits.aleo split function
2. Note all other execute/fee transactions get dynamic fees at consensus layer (snarkVM/synthesizer/src/vm/verify.rs)
3. Submit many split transactions to fill blocks to max transaction limit (ledger/block/src/verify.rs) at constant cost
4. During congestion, other transactions' fees rise 20-50x while split stays fixed, crowding out liquidations/withdrawals
**How found:** Code review of the split function in credits.aleo and the VM/block verification logic, noticing split lacks the fee commitment required by other transaction types and thus is exempt from EIP-1559-style dynamic pricing.
**Exploitation:** Attacker floods the mempool/blocks with cheap fixed-fee split transactions during volatility, filling the max transaction limit and preventing time-sensitive transactions (DEX liquidations, collateral top-ups, withdrawals) from landing, potentially causing protocol insolvency.
**Insight:** When auditing L1 fee mechanisms, check each transaction type individually for whether it participates in the dynamic fee/priority auction; any type with a hardcoded or program-layer-only fee is a cheap block-stuffing vector even if its baseline cost is higher than others.