Sui Wallet Exploration

How do safety standards actually get written?

Not from committees. From the workshop floor, after someone gets hurt.

The Incident​

On January 2, 2026, an official Solana Mobile notification deleted a seed phrase without warning. ~$10K gone. No confirmation dialog, no balance check, no recovery path. Support ran 33 days without resolution.

In a factory, that's a near-miss report. It becomes a procedure. The procedure becomes a standard. The standard prevents it from happening to anyone else.

The Standard​

The response was not a complaint. It was architecture — five safety patterns built for Solana, now adapted for Sui. Not a port. A rethink. Because Sui's object model and Move language prevent entire categories of failure at the language level.

This is the knowledge stack in action:

Every safety procedure in a factory started the same way. Someone got hurt. Someone wrote it down. The write-up became the standard. The standard transformed the industry.

The Safety Thesis​

Four failures from the incident. Each maps to an architectural fix:

The principle: Safety is an architectural constraint, not a feature. The best safety code is code that doesn't need to exist because the platform prevents the failure.

Patterns​

1. Connection​

Solana: Wallet adapter connects, app receives only public key.

Sui: Same principle, better primitives.

zkLogin changes the game: Most wallet UX problems stem from the wallet itself — install friction, seed phrase management, network switching. zkLogin eliminates the wallet as a user-facing concept. Sign in with Google. Sui handles the rest.

2. Transaction Safety​

Solana: TransactionSimulator dry-runs transactions and shows balance impact before signing.

Sui: PTBs make this more powerful — up to 1024 operations in one transaction, all previewable.

The object difference: On Solana, simulation shows "your SOL goes from X to Y." On Sui, it shows "Object A (your NFT) transfers to Address B, Object C (coin) splits into Object D (payment) + Object E (change)." Explicit objects make consequences visible.

3. Destructive Operations​

Solana: NuclearWarningDialog — multi-step confirmation with countdown for irreversible actions.

Sui: Move's type system adds a layer Solana can't have.

Move's structural safety: A resource with the key ability can only be transferred or stored — never silently dropped. The Solana Seed Vault incident was a "resource accidentally dropped" bug. Move makes that a compile-time error.

// A Coin<SUI> cannot be silently destroyed.
// The compiler enforces it. No UI warning needed.
public fun transfer_safely(coin: Coin<SUI>, recipient: address) {
    // coin MUST go somewhere — transfer, merge, or split
    // letting it drop = compile error
    transfer::public_transfer(coin, recipient);
}

4. Balance Guard​

Solana: BalanceAwareGuard — checks all token accounts before destructive operations.

Sui: Objects make this simpler and more complete.

The Solana problem was hidden state. Token accounts exist but aren't visible unless you know to look. On Sui, every asset is an explicit owned object. getOwnedObjects returns everything. Nothing hides.

5. Asset Operations​

Solana: Separate patterns for SPL tokens vs SOL vs NFTs.

Sui: Everything is an object. One pattern.

Cross-Chain Comparison​

Build both, learn from both:

Architecture​

Stack​

┌─────────────────────────────────────────────────┐
│              SAFETY PATTERNS (UI)                │
│  Connect │ Simulate │ Guard │ Balance │ Assets   │
├─────────────────────────────────────────────────┤
│              SUI DAPP KIT                        │
│  Hooks │ Components │ Wallet Connect │ RPC       │
├─────────────────────────────────────────────────┤
│              MOVE CONTRACTS                       │
│  Identity │ Links │ Loyalty │ Device Registry    │
├─────────────────────────────────────────────────┤
│              SUI CORE                            │
│  Objects │ PTBs │ zkLogin │ Mysticeti (~390ms)   │
└─────────────────────────────────────────────────┘

Existing Move Contracts​

Already built in Stackmates:

Each has a TypeScript client. The wallet UI wires to these.

Why This Matters​

Crypto products are unfriendly to non-experts. Hiding what's going on undermines the trust the technology ensures. Every wallet team navigates this tension independently. There is no shared standard.

Compare that to factory engineering. NIST, ISO, OWASP — every safety-critical industry has extractable standards that prevent known failure modes. Crypto wallets don't. Each team learns the hard way.

This PRD is the beginning of a wallet safety standard:

The Dream-Engineering handoff: the dream is wallets that don't destroy people's assets. The standard is the spec. The engineering is building it in the open.

Commissioning​

Each component progresses through the factory model:

Pre-existing: 12 Move modules deployed to testnet. 5 TypeScript clients built. Wallet UI is the gap.

Next Steps​

1. Port TransactionSimulator → PtbInspector (highest learning)
2. Implement ZkLoginConnect (biggest UX unlock)
3. Build ObjectDiffPreview (Sui's unique advantage)
4. Wire to existing Move contracts
5. Deploy alongside Solana version for comparison

Smallest move: One component. Both chains. Compare. The feedback loop validates the thesis.

Context​

• The Incident — The near-miss report that started the standard
• Solana Safety Patterns — First implementation, single chain
• Standards — How protocols become standards become platform
• Knowledge Stack — Pain → protocol → standard → platform
• Sui Technical — Object model, Move, Mysticeti
• Sui Dev Resources — SDKs, tools
• Stackmates — The platform these patterns plug into
• Open PRDs — Building in the open