For protocol teams · Monad mainnet

Find what's quietly throttling your protocol.

Monad runs transactions in parallel. But when many touch the same storage, they collide and have to re-run one at a time. That hidden serialization caps your throughput. pev traces every block and shows you exactly where it happens, and how to fix it.

parallel · fastcollision · re-runsharedstate
A real contract, audited

Here's pev on a live Monad contract

0x57cf…0ca70x57cf…0ca7✓ measured on-chain✓ verified source · solc 0.8.30 · UUPS · BUSL-1.1
909K
transactions touched
909,409 in 2d
664K
re-executions forced
663,686 storage collisions
0.73
conflicts per transaction
measured · 2d window
The diagnosis

Per-user balances already run in parallel. The contention is a shared accumulator in the balances mapping that nearly every trade writes.

top method 0x0c7abd22

The hot slot is an entry in the balances mapping (storage slot 1). Per-user keys, balances[user, token], are isolated and parallel-safe; the contended entry is a shared key written by a large fraction of all trades.

creditFee writes balances[accountKey(feeCollector, token)] += fee on every trade, so all concurrent trades write the same fee-sink entry and serialize on it. debitUser, creditUser, deposit and withdraw use per-user keys and already parallelize, they are not the problem. (A single dominant market-maker's own balance entry can be hot the same way.)

Source-backed. The exact (user, token) behind the hashed slot isn't reversed, but the storage layout plus the access pattern make the shared balances accumulator (structurally the fee sink) the cause. The feeCollector address would confirm the exact slot.

Fix · Shard the fee accrualsource-backed

The fee sink is a single balances entry every trade writes, so trades serialize on it. Accrue fees into N rotating buckets per token and sweep to the fee collector periodically; concurrent trades hit different buckets and stop colliding, contention on that slot drops ~N-fold. Per-user balances need no change.

before · one shared slotafter · shardedcollideparallel
Before
// before: every trade writes the SAME fee entry, all trades serialize
function creditFee(address a, uint256 fa, address b, uint256 fb) external {
    balances[_accountKey(feeCollector, a)] += fa;   // <- hot slot
    balances[_accountKey(feeCollector, b)] += fb;   // <- hot slot
}
After
// after: accrue into rotating buckets, sweep to feeCollector later
uint256 constant FEE_SHARDS = 16;
uint256 private feeNonce;
mapping(bytes32 => uint256) private feeShard;   // key: hash(token, shard)

function creditFee(address a, uint256 fa, address b, uint256 fb) external {
    uint256 s = feeNonce++ % FEE_SHARDS;        // rotate buckets
    feeShard[keccak256(abi.encodePacked(a, s))] += fa;
    feeShard[keccak256(abi.encodePacked(b, s))] += fb;
}
// feeCollector claims sum(feeShard[token][0..15]) on a sweep

This analysis is read from the contract's verified source. The before/after is the standard shard pattern for the measured contention; Silk Nodes does the full implementation and verifies the contention drop on-chain.

Methods causing conflicts
0x0c7abd22281K
0xab083028189K
0x5339c59f96K
0xed82b07871K
0x6ad2e98b8K
executePacked()3K
0xa09e90402K
0x40e79b1b2K

Names resolved from verified ABI / public signature database (best-effort; selectors are the tx entry method).

2-day window · updated 2026-06-24 07:12 UTC

What pev delivers to your team

A full contract performance audit

Top contention sources, ranked
The exact storage slots colliding
Method-level collision breakdown
Who your contract collides with
Conflict kinds (write-write vs read-write)
Architecture changes by ROI
Historical contention trend
Per-contract API access
Why only pev

Nobody else can show you this

No block explorer shows storage contention.
No analytics dashboard reconstructs it.
No RPC exposes which slot collided.
pev rebuilds it from Monad's execution traces, block by block.

Audit your contract

A full contention review of your protocol, from Monad mainnet data. Silk Nodes is your performance partner, not just a node operator.

WHAT YOU RECEIVE
30-minute review call
Full contention report
Storage-slot + method analysis
Architecture recommendations
Before/after contention estimates
Request a protocol audit →Explore the contract graph

← back to pev