The first thing I blamed was gas.
It wasn’t gas.
Two transactions. Different instructions. Both reaching for the same state account inside Fogo’s Solana Virtual Machine runtime. I thought SVM parallel execution meant they’d just… pass each other. Slide through separate lanes. Whatever.
They didn’t.
The SVM transaction scheduler didn’t stall. That’s the part that confused me. It resolved both cleanly. Logs were quiet. Too quiet. Compute unit burn within budget. No red flags. Just account locking doing its quiet, deterministic thing.
“Parallel.” No. Not through.
Inside Fogo’s slot-based execution, access patterns don’t argue. They decide. The 40ms block cadence didn’t widen. It never does. One instruction grabbed the account. The other waited. Not failed. Waited.
Which is worse.
The PoH-driven clock kept sequencing. Fogo’s deterministic leader schedule moved forward. Slot N extended. Then N+1. My second tx landed, technically, but inside the next inclusion window. Tower BFT vote locking didn’t blink.
I rewrote the account structure. First split by user. Still contention. I stared at it longer than I should have. Then by action type. Cleaner. Not elegant. Just less collision.
Parallel state updates stayed parallel until they hit that account. Then they didn’t. Fogo ( @Fogo Official ) didn’t care that the layout looked elegant. The account was locked. That was enough.
I almost wrote “high performance.” Deleted it.
The slot didn’t feel fast. It felt tight.
On Fogo, the scheduler doesn’t fail loudly. It shifts you one slot over and keeps moving.
Slot N+1 was already extending before I convinced myself it was fine.
It wasn’t.
Slot N+2 was already building.
I was still staring at the trace.