Sui SIP-45 Local Fee Markets (Builder-First): Why Fees Get More Predictable
Local fee markets keep congestion local: hotspots pay the price while unrelated apps stay stable. Builder-first overview + what to change.
TL;DR - Sui’s object-based model makes “hot shared objects” the main source of congestion pain. - Local fee markets aim to price/limit congestion closer to the hotspot instead of punishing the whole network. - Builder win: design to avoid shared-object write contention, and ship retry-safe UX.
If you’ve ever shipped a claim/mint flow and watched it collapse under congestion, you already understand the problem: hot spots.
This is builder-first: what changes for your app and what doesn’t.
Related: - Sui JSON-RPC vs GraphQL - Walrus Explained
The problem: hotspots punish everyone
In global-ish fee dynamics, a hotspot can spill pain across unrelated activity: - one shared object becomes popular - demand spikes - throughput collapses or the effective cost spikes - users spam retries (making it worse)
Builders experience: - unpredictable performance - intermittent failures - “why is it expensive today?”
The idea: price congestion closer to the hotspot
A “local fee market” tries to behave more like: - if this part of state is hot → this part gets more expensive / constrained - unrelated state stays more stable
So congestion is “contained” rather than contagious.
Builder implications (what you should actually do)
1) Avoid shared write bottlenecks
If everyone must touch the same shared object/state, you’re creating a hotspot.
Better patterns: - shard state by user - move aggregation off-chain, commit summaries on-chain - prefer per-user objects/resources where possible
2) Design retry-safe UX
Even with better fee mechanics, spikes happen. Build: - retry with exponential backoff (+ jitter) - clear “pending/retrying” UI - idempotent server-side operations
3) Monitor the right signals
Track: - submit success rate - median + p95 latency - failure codes grouped by cause - retries per minute per user/app
Quickstart
Use this as a builder checklist when you’re designing a “high traffic” feature (mint/claim/checkout):
1) Identify your shared writes: - “Which object/state does every user touch?”
2) If you find one shared write path, redesign: - shard by user, or - batch + commit summaries
3) Add a retry policy to your client/backend: - exponential backoff + jitter - max retries - dedupe key (request_id)
Common errors
- Building a “single shared object” claim counter that every tx writes to.
- Treating retries as “spam until it works” (no backoff/jitter).
- Using public endpoints in production without rate limits or keys.
- No visibility into which objects/packages are hotspots during incidents.
FAQ
Do local fee markets guarantee my app never gets congested?
No. They aim to contain congestion and make pricing/limits more local. Your app can still hotspot itself.
What’s the biggest builder mistake on Sui?
Shared-object write contention for popular flows (claims/mints).
What should my product do during congestion?
Show “pending/retrying,” backoff automatically, and avoid telling users to hammer refresh.
Related Natsai
- Sui JSON-RPC vs GraphQL
- Walrus Explained
- Enterprise support & keys: /contact/
