The Death of the Loading Spinner: Designing for Client-Side Proving

The “Pending” Purgatory is Finally Ending

I have spent the better part of a decade staring at loading spinners. If you build interfaces for decentralized applications, you know exactly what I’m talking about. We have normalized a user experience that would get any Web2 product manager fired in a week. You click a button. You sign a transaction. And then… you wait.

Maybe it’s 12 seconds. Maybe it’s a minute. If the network is congested, maybe you go make a coffee and come back hoping the transaction didn’t fail. We’ve plastered over this with “optimistic UI” updates—fake success messages that revert if the chain disagrees—but users can smell the delay. They know the difference between “done” and “hopefully done soon.”

But yesterday, I ran a test on my laptop that felt different. I was messing around with some of the new client-side proving stacks that have been maturing throughout 2025, specifically looking at how Polygon Miden handles state updates. I clicked a button to update a private note. It happened instantly. Not “fake” instantly. Cryptographically instantly.

This isn’t just a backend optimization. This is a fundamental shift in UX design patterns for crypto. We are moving from a “Request and Wait” model to a “Prove and Sync” model. And honestly? It’s about time.

The Old Model vs. The Client-Side Shift

To understand why the UX feels so different, you have to look at where the computation happens. In the standard Ethereum model (or any EVM chain), the UX flow is a disaster of dependency:

1. User initiates action.
2. Interface constructs a transaction.
3. User signs.
4. Transaction is broadcast to a mempool (public waiting room).
5. WAITING PERIOD.
6. Block producer picks it up, executes the code, updates the state.
7. Interface sees the update and refreshes.

That waiting period is the UX killer. It decouples the user’s action from the system’s reaction.

Client-side proving, specifically using STARKs (Scalable Transparent Arguments of Knowledge), flips this on its head. When I tested this locally, the flow was:

1. User initiates action.
2. My laptop executes the code locally.
3. My laptop generates a Zero-Knowledge proof that the execution was valid.
4. The proof is sent to the network.

From a UX perspective, the “action” is completed at step 2. The state on my device updates immediately because I am the one updating it. The network doesn’t need to re-execute my transaction; it just needs to verify the proof I sent. It’s the difference between asking a teacher to grade your math homework (waiting) versus showing them the answer key you already verified (instant).

Privacy is a UX Feature, Not Just a Setting

We usually talk about privacy as a compliance thing or a security thing. But in 2025, privacy has become a major UX component. Why? because “public by default” creates hesitation.

I’ve watched users in usability tests hover over the “Swap” button, paralyzed. They aren’t worried about gas fees. They’re worried about who is watching. They’re thinking, “If I move this USDC, will that bot tracker account tweet about it?”

With architectures like Miden, the state model is distinct. You have public state (like the chain itself) and private state (accounts held locally). When I update my private state locally, the network only sees the hash change. It verifies that the transition from State A to State B was valid according to the rules, but it doesn’t see what changed.

This removes the “Hesitation Friction.” The user feels safer interacting because the app feels like a local tool, not a public broadcast system. It’s closer to the feeling of using Signal than using Twitter. That psychological safety is a massive part of the experience design that we often ignore.

The “Instant Finality” Illusion

Technically, true finality still depends on the chain including the proof in a block. But the perceived finality is instant. This is a crucial distinction for designers.

When I generate a proof locally, I know—mathematically—that this transition is valid. Unless I crafted a malicious proof (which the client software prevents) or the network censors me, that state is the new reality. I don’t need to wait for a validator to tell me I have sufficient funds. I checked my own funds. I ran the logic. I know the result.

This allows us to build interfaces that don’t need “pending” states for 99% of interactions. The UI can transition to the “Success” state immediately after the proof generation is done. Sure, there’s a background sync process (sending the proof to the AggLayer or sequencer), but that’s plumbing. It doesn’t block the user flow.

The Hardware Trade-off

Here is the catch, and it’s one we need to design around: Proof generation isn’t free. It costs CPU cycles.

On my MacBook Pro, generating a basic transaction proof took a few hundred milliseconds. Imperceptible. But on a three-year-old Android phone? That might take 2-3 seconds. As designers, we are trading network latency (unpredictable, often long) for local computational latency (predictable, hardware-dependent).

This introduces a new UI challenge: The “Thinking” state. instead of “Waiting for Network,” we might need to communicate “Encrypting & Proving.” It’s a different kind of wait—one that feels active rather than passive. Users tend to be more forgiving of their device doing work than a server ignoring them.

Designing for 2026: The New Standard

We are sitting at the end of 2025, and looking at the roadmap for the next year, it’s clear that client-side ZK is going to be the infrastructure standard for serious applications. The “fat wallet” era is coming back—not fat with money (unfortunately), but fat with logic.

If you are designing a dApp right now, stop optimizing for RPC calls. Start thinking about:

• Local State Management: How do you represent data that lives on the device but hasn’t synced yet?
• Prover Feedback: How do you visualize the heavy lifting the device is doing?
• Conflict Resolution: What happens if the user tries to spend the same note on two different devices? (Since state is local, this is a harder problem to solve in the UI).

I played around with the AggLayer integration concepts recently, and it effectively unifies liquidity across chains while respecting this local-first approach. It feels like privacy-first money is finally ready for real apps. Not the clunky privacy tools of 2021 that required command-line magic, but actual, usable, consumer-grade applications.

Why This Matters

I’m tired of blockchain apps feeling like second-class software. For years, we’ve made excuses. “It’s slow because it’s decentralized.” “It’s public because that’s how trust works.”

Client-side proving proves (pun intended) that those were temporary limitations, not permanent laws. We can have the trustlessness of a blockchain with the snappy responsiveness of a local app. The chain becomes a verification layer, not an execution layer.

If institutions demand privacy—and they do—and users demand speed—and they always have—then this architecture is the only way forward. By the time Miden hits mainnet in 2026, I expect “waiting for confirmations” to feel as archaic as dial-up internet screeching.

For now, I’m just happy I can finally update a state variable without staring at a spinning circle for 15 seconds. It’s the little things.