The manual.

Everything you need to read pev correctly: how the metrics are computed, what they mean for your contract, what the data covers, and where the limits are. No marketing prose; just the manual.

1. 01What pev is
2. 02How parallel execution works
3. 03Metrics glossary
4. 04How to use pev
5. 05Data coverage and caveats
6. 06API reference
7. 07About + contact

Parallelism Score

A 0-100 measure of how parallel-friendly a block is. 100 means every transaction could have run in parallel; no contention. 0 would be every transaction blocking the next one, fully serial. Real Monad blocks typically land between 60 and 95. Computed as the ratio of tx count to required execution waves: a 30-tx block that fits in 2 waves scores around 93; the same block forced into 10 waves scores around 70.

Execution Waves

The minimum number of sequential rounds the block needs because of conflicts. Wave 1 runs everything that has no upstream dependency. Wave 2 runs everything blocked only by Wave 1 results. And so on. A block with depth 1 is fully parallel. A block with depth 5 had a chain of 5 transactions where each one couldn't start until the previous finished. Useful for spotting stack-of-dependent-writes patterns vs. broad parallel work.

Hot Storage Slot

A storage slot (a specific 32-byte location at a specific contract) touched by 2 or more transactions in the same block. Hot slots are the literal bottleneck: every tx that wants to read or write a hot slot has to wait for the txs that already wrote it in this block to commit. pev ranks hot slots by conflicts caused (how many tx-pair conflict edges in this block share this slot), then by touches (how many txs touched it at all). The top slot on a contract page is usually the line of Solidity worth re-architecting.

Write-Write Conflict

Two transactions in the same block both wrote the same storage slot. One has to win the race, the other is re-executed. About 94% of all conflicts we observe on Monad mainnet are write-write, dominated by hot counters and shared pool state.

Read-Write Conflict

One transaction read a slot that another transaction in the same block wrote. The reader has to retry after the writer commits. About 1% of observed conflicts. Rare because most reads are of slots that don't get written in the same block.

Mixed Conflict

A pair of transactions that conflict on multiple slots, with at least one write-write and at least one read-write among them. About 5% of conflicts. Common in transactions that touch several pieces of shared state at once (router contracts, complex AMM paths).

Conflicts Caused

On the contract page, the count of conflict edges where this contract owned the hot slot. A contract with high "conflicts caused" is putting load on the execution lane, regardless of how many of its own txs were the ones blocked.

I have a contract on Monad and want to know if it's a bottleneck

1. 01Open /contract/<your-address>. Default view is the last 7 days.
2. 02Read the verdict line at the top: Healthy, Bottlenecked, or Throughput-killer. That's pev's one-line take.
3. 03Scroll to Hot Storage Slots. The top entry is the most contested location in your contract. If you can refactor that one slot, you'll move the score.
4. 04Scroll to Methods Causing Conflicts. Groups conflicts by 4-byte selector so you can see which function (mint, swap, claim, etc.) is responsible for what share.
5. 05If you've made a change and want to compare, use the window selector at the top: 1h, 24h, 7d, 30d, all-time. Each window queries fresh.

I want to know what the busiest contracts on Monad look like

1. 01Open /analytics. The page is refreshed every 5 minutes from a pre-aggregated cache, so it loads in <1s.
2. 02The Top conflict-causing contracts list ranks contracts by total conflicts in the window. Click any one to see the per-contract breakdown.
3. 03Top hot slots ranks specific (contract, slot) pairs, useful for finding the single 32-byte location creating the most contention chain-wide.
4. 04Methods, Conflict kinds, and Wave depth distribution let you see the chain's overall shape.

I have a transaction hash from my dapp and want to debug it

1. 01Open /tx/<hash>. We show you the block it landed in, the wave it executed in, what other txs it conflicted with, and which storage slots it touched.
2. 02Click any conflict edge to jump to the other transaction. The conflict graph lets you trace the chain of dependencies.

I want to share a finding with my team

1. 01Every page generates a dynamic OG card. Paste the URL into Twitter, Discord, Slack, Telegram and the preview shows the real numbers.
2. 02Per-block, per-contract, per-tx, and the landing page all have their own card variants.

History depth: ~12 days, growing

Our indexer started on Monad mainnet on April 25, 2026 and has been live-tailing the chain head since. Older blocks are not currently indexed. We may run a backfill if there's demand, otherwise the window grows naturally as the indexer runs.

DELEGATECALL targets may be missing

When a tx calls a proxy that DELEGATECALL's to an implementation, storage changes happen at the proxy's address, not the impl's. prestateTracer (the RPC tracer we use) doesn't surface the impl address in that case. So proxy implementations may show as "not seen" in pev even when they execute constantly. Custom JS tracers would fix this; the RPC we currently use doesn't support them. We're tracking this as a known limitation, not a bug.

Sourcify name coverage is thin

We resolve contract names via Sourcify. Coverage on Monad mainnet is still early, so most contracts show as short hex (0xab12…cd34) rather than human names. If you want yours labeled, verify it at sourcify.dev and pev will pick the name up automatically.

Aggregates lag real-time by a few minutes

The /analytics page reads from a cache refreshed every 5 minutes. Per-contract aggregate lookups read from a cache refreshed every 15 minutes. Live per-block and per-tx pages compute on demand from the same data the indexer just wrote, so those are real-time. The lag is a fast-page-load trade.

Parallelism scores are theoretical, not actual

Every metric on this site is computed from the conflict graph prestateTracer produces. It tells you the maximum speedup the block's conflict structure permits. It doesn't tell you what Monad's actual scheduler picked, which is an internal decision not exposed via RPC. Score 80 means "this block could have run 80% as parallel as it had transactions to support." The actual execution may have been better or worse depending on scheduler choices.

Re-execution cost is reported, not modeled

pev counts conflict edges and execution waves. It doesn't model the exact gas cost of re-execution under Monad's specific re-execution rules. Treat wave count as a relative signal across contracts and blocks, not as an absolute throughput dollar figure.