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.

Benchmark-First Direction​

This PRD follows a benchmark-first order:

1. Define wallet safety benchmark checklist as deterministic landing surface
2. Validate implementations against that checklist
3. Compare chain implementations (Solana, Sui, EVM)
4. Encode benchmark attestations onchain (target: Sui/Move)

Reference landing standard: Wallet Safety Benchmarks.

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.

Product Features​

Business Dev​

The first market is teams and apps that need trustworthy wallet UX, not speculative token users.

Commercial Paths​

1. Open standard path: Free reference implementation and docs.
2. Integration path: Paid implementation and safety review.
3. Platform path: Bundle into Stackmates trust layer for ventures needing asset operations.

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.

Engineering Handoff: Navigation and Safety Corrections​

This section is the current RFP-style handoff from Dream repo to Engineering repo.

Job To Be Done​

Make Sui safety patterns discoverable and trustworthy in the design system so teams can evaluate and adopt them without ambiguity.

Current failure mode:

• Sui pages exist in code, but main crypto navigation hides/blocks them.
• Some pages are presented as complete while still demo/mock.
• A destructive operation demo bypasses ownership check.

Scope (Engineering Repo)​

Primary implementation paths:

• apps/dreamineering/drmg-design-system/src/app/_components/navigation.tsx
• apps/dreamineering/drmg-design-system/src/app/(crypto)/crypto/page.tsx
• apps/dreamineering/drmg-design-system/src/app/(crypto)/sui/destructive-ops/page.tsx
• apps/dreamineering/drmg-design-system/src/app/(crypto)/sui/page.tsx

Required Outcomes​

Commissioning Checklist (Independent Verification)​

Commissioner verifies in browser and code:

1. /crypto shows active link card to Sui (not disabled).
2. Sidebar crypto section includes both Solana and Sui.
3. Navigating to /sui exposes 5 pattern pages:
   • /sui/connection
   • /sui/transaction-safety
   • /sui/destructive-ops
   • /sui/balance-guard
   • /sui/asset-operations
4. DestructiveOpGate does not use skipOwnershipCheck in default demo path.
5. Sui readiness badges match implementation reality (demo/mock clearly labeled).

Acceptance Evidence​

For delivery to be marked "ready for inspection", provide:

• Screenshot/video of /crypto and sidebar showing Sui discoverability
• Diff references for navigation/status changes
• Screenshot/video of destructive op flow with ownership check enforced
• Short note describing remaining mocked dependencies (if any) and their current status

Priority​

P0 — This is a commissioning integrity issue, not a cosmetic issue.

If discoverability and safety signaling are wrong, commissioning cannot be trusted.

Lead Architect: Plan Instantiation Pack​

This block is formatted for the orchestration flow in:

• .ai/orchestration/team-operations/user-interface/
• .ai/orchestration/team-operations/intelligence-engine/

Primary Team Route​

Plan Metadata (for plan-cli.ts create)​

Use these values when instantiating the first UI plan:

UI Scope Mapping​

Task Seed (Phase 1)​

1. Enable Sui discoverability on /crypto and sidebar.
2. Remove default ownership-check bypass in destructive operations.
3. Correct readiness labels to reflect real state (demo/mock vs complete).
4. Align route model to avoid split between legacy and active crypto nav paths.

Cross-Team Note​

If API/contract validation is required for phygital-agent flows, raise follow-up to intelligence-engine templates. UI team owns biological-flow proof through CDD and E2E, per team charter.

Onchain Benchmark Roadmap (Sui/Move)​

Intent: engineer wallet safety benchmarking into verifiable onchain artifacts.

Job To Be Done​

As a commissioner, I need wallet safety results represented as deterministic, auditable objects so benchmark outcomes are comparable across wallets and over time.

Proposed Move Artifacts​

Deterministic Rules​

1. Any critical-rule breach sets run status to Fail.
2. CertificationState can only promote when required dimensions are Pass.
3. Every state transition stores prior state reference for audit trail.
4. Same spec version + same inputs must produce same result state.

Phase Sequence​

1. Spec Freeze: finalize checklist fields and thresholds in docs.
2. Offchain Runner: implement repeatable benchmark runner + result schema.
3. Move Registry: write minimal onchain package for spec/run/cert state.
4. Dual-Chain Comparison: run Solana and Sui implementations through same spec.
5. EVM Extension: add EVM implementation track against unchanged benchmark model.

Success Criteria​

• Benchmark checklist is single source of truth for all chain comparisons
• Pass/Warn/Fail outcomes are reproducible
• Certification state can be independently re-verified
• Sui/Move implementation proves onchain auditability for wallet safety

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