Is your contract killing parallelism?
Paste a block number. pev reconstructs the execution graph, surfaces storage contention, and tells you exactly which slots are costing you throughput.
Monad doesn't process transactions one at a time. It runs them in parallel, many at once, across separate execution lanes. The catch: when two transactions touch the same storage slot in the same block, the chain has to run one first and re-execute the other once it finishes. So the shape of your contract decides how parallel the chain can be. Contracts with isolated state (per-user balances, sharded counters) parallelize cleanly; contracts with hot shared state (a single global counter, a shared queue) become the chokepoint everyone else waits on.
An interactive map of how Monad's protocols compose at runtime: which contracts share transactions, and which of them collide on storage. Hover any contract to trace its connections.
Every metric on this page is computed from real prestateTracer output. We show theoretical parallelism, the maximum speedup the block's conflict structure allows, not what Monad's scheduler actually decided. That's internal and not exposed via RPC, so we don't fake it. Method names are decoded via the 4byte directory when a selector has been submitted there; otherwise we show the raw 4-byte hex. Contract names come from Sourcify when verified, coverage on Monad mainnet is still early.