Flow Diagrams

Five maps. Each answers a question. Each answer feeds the next question. By the end, the settlement stack is named as an instrument — or killed.

What does success look like?

Four binary gates. No interpretation required.

OUTCOME MAP — Prediction Game (Sui)
════════════════════════════════════

              ┌─────────────────────────────────────────────────┐
              │  50+ PREDICTIONS SETTLED ATOMICALLY ON TESTNET   │
              │  (The stack works at product scale, not just     │
              │   in unit tests)                                 │
              └────────────────────────┬────────────────────────┘
                                       │
                        ┌──────────────┴──────────────┐
                        │                             │
             ┌──────────▼──────────┐      ┌──────────▼──────────┐
             │  WALLETLESS         │      │  SINGLE-PTB          │
             │  ONBOARDING         │      │  SETTLEMENT          │
             │                     │      │                      │
             │  User completes     │      │  Oracle result +     │
             │  prediction without │      │  payout + status     │
             │  wallet extension   │      │  update in ONE tx    │
             └──────────┬──────────┘      └──────────┬──────────┘
                        │                             │
                        └──────────────┬──────────────┘
                                       │
              ┌────────────────────────▼────────────────────────┐
              │  FIRST PREDICTION SETTLED                        │
              │  At least one prediction settled atomically      │
              │  on Sui testnet within 14 days of deployment     │
              └─────────────────────────────────────────────────┘

Outcomes defined. Where does time actually die in the current flow?

Where does time die?

EVM vs Sui lifecycle — where transactions and time compress.

VALUE STREAM — EVM Flow (Current State)
════════════════════════════════════════

CONNECT          APPROVE          PREDICT          SETTLE           CLAIM
────────         ───────          ───────          ──────           ─────
┌────────────┐  ┌────────────┐  ┌────────────┐  ┌────────────┐  ┌────────────┐
│ Install     │  │ Approve    │  │ Place bet  │  │ Oracle     │  │ User claims│
│ wallet ext  │  │ token      │  │ + stake    │  │ pushes     │  │ winnings   │
│ Connect     │  │ spend      │  │            │  │ result     │  │            │
│ 30-120s     │  │ 1 tx       │  │ 1 tx       │  │ 1 tx       │  │ 1 tx       │
│ 0 tx        │  │ 15-60s     │  │ 15-60s     │  │ 15-60s     │  │ 15-60s     │
└────────────┘  └────────────┘  └────────────┘  └────────────┘  └────────────┘

TOTAL: 4-5 transactions  |  2-5 minutes  |  5 failure points  |  User pays gas each time


VALUE STREAM — Sui Flow (Target State)
═══════════════════════════════════════

AUTHENTICATE         PREDICT + STAKE         SETTLE + PAY
────────────         ───────────────         ────────────
┌────────────┐      ┌──────────────┐        ┌──────────────┐
│ zkLogin     │      │ Single PTB:  │        │ Single PTB:  │
│ via Google  │      │ create pred  │        │ consume      │
│             │      │ + transfer   │        │ OracleResult │
│ 0 tx        │      │ stake        │        │ + calculate  │
│ 3-5s        │      │ 1 PTB ~390ms │        │ + distribute │
└────────────┘      └──────────────┘        │ 1 PTB ~390ms │
                                             └──────────────┘

TOTAL: 1-2 PTBs  |  <10 seconds  |  2 failure points  |  Zero user gas


COMPRESSION RATIO
═════════════════
Transactions:  4-5 → 1-2    (2-5x fewer)
User wait:     2-5 min → <10s (12-30x faster)
Gas decisions: 4-5 → 0       (eliminated)
Failure points: 5 → 2        (60% fewer)
Wallet setup:  required → none (eliminated)

Value stream mapped. What depends on what — and what kills the project if it slips?

What depends on what?

Critical path and hard dependencies. The oracle is the highest-risk node.

DEPENDENCY MAP — Critical Path
══════════════════════════════

Move Contracts ──→ Oracle Integration ──→ Settlement PTB ──→ Frontend ──→ Dogfood
     │                    │                    │                │
     ▼                    ▼                    ▼                ▼
  game.move          oracle.move         compose PTB        dApp Kit
  prediction.move    result feed         test atomic        zkLogin flow
  treasury.move      attestation         payout math        sponsored tx
  leaderboard.move                                          match UI
  season.move
  admin.move


RISK REGISTER
═════════════
┌──────────────────────────┬─────────────┬──────────┬────────────────────────────┐
│ Dependency               │ Probability │ Impact   │ Mitigation                 │
├──────────────────────────┼─────────────┼──────────┼────────────────────────────┤
│ Sports data oracle       │ HIGH        │ Critical │ Redundant feeds, admin     │
│                          │             │          │ manual override            │
├──────────────────────────┼─────────────┼──────────┼────────────────────────────┤
│ zkLogin salt service     │ Medium      │ High     │ Wallet extension fallback  │
├──────────────────────────┼─────────────┼──────────┼────────────────────────────┤
│ Gas station balance      │ Medium      │ High     │ Alerts at 50%, auto-       │
│                          │             │          │ disable sponsorship        │
├──────────────────────────┼─────────────┼──────────┼────────────────────────────┤
│ Move contract bug        │ Low         │ Critical │ Testnet first, phased      │
│ post-deploy              │             │          │ mainnet migration          │
├──────────────────────────┼─────────────┼──────────┼────────────────────────────┤
│ Low user engagement      │ Medium      │ Medium   │ Dogfood with rugby         │
│                          │             │          │ community first            │
└──────────────────────────┴─────────────┴──────────┴────────────────────────────┘

Dependencies mapped. How does the user move from pain to performance?

How does the user move from pain to performance?

Six stages. Feature flag controlled. Each stage earns the next.

PAIN-TO-PERFORM JOURNEY
══════════════════════

Pain        │ Prediction = multiple sites, multiple transactions, gas confusion
            │ Show the cost of the current path
            ▼
Awareness   │ "Predictions" in sidebar, homepage CTA
            │ Surface the new entry without disrupting existing flow
            ▼
First Value │ zkLogin → predict → confirm in <30s
            │ That was genuinely fast
            ▼
Habit       │ Check before every match
            │ Push notification before kickoff (future)
            ▼
Mastery     │ Leaderboard, season stats, export
            │ Support power-user shortcuts
            ▼
Effortless  │ AI-assisted prediction suggestions (future)
            │ The game suggests what you'd pick


NAVIGATION STATES (Feature Flag Controlled)
══════════════════════════════════════════
┌─────────┬──────────────────────┬─────────────────────┬────────────────────┐
│ State   │ Sidebar              │ Dashboard           │ Widget             │
├─────────┼──────────────────────┼─────────────────────┼────────────────────┤
│ Flag OFF│ Existing nav         │ No prediction       │ Hidden             │
│         │ unchanged            │ widgets             │                    │
├─────────┼──────────────────────┼─────────────────────┼────────────────────┤
│ Flag ON │ "Predictions" added  │ Upcoming matches    │ Hidden             │
│ (T0)    │                      │ card                │                    │
├─────────┼──────────────────────┼─────────────────────┼────────────────────┤
│ Flag ON │ Same                 │ Same + win streak   │ Match reminder     │
│ (T2+)   │                      │ widget              │ floating button    │
└─────────┴──────────────────────┴─────────────────────┴────────────────────┘


SIDEBAR HIERARCHY
═════════════════
Predictions (new section)
├── Upcoming Matches    → /vision
├── My Predictions      → /predictions/mine
└── Leaderboard         → /predictions/leaderboard

Navigation connects the screens. What gets built in what order?

What gets built in what order?

Four sprints. Sprint 2 proves the thesis. Everything else supports it.

SPRINT 1 (2 wks)              SPRINT 2 (2 wks)           SPRINT 3 (1 wk)         SPRINT 4 (1 wk)
─────────────────             ────────────────           ───────────────         ───────────────

#1-4   Browse + Predict       #5-9  Oracle + Settlement  #10-13 History          #18  Admin override
#14    zkLogin                       + Receipts          #16-17 Onboarding       #12  Leaderboard
#15    Sponsored tx                                             polish            Dogfood: 50 preds

CONTRACTS:                    CONTRACTS:                 CONTRACTS:
  game.move                     oracle.move                leaderboard.move     admin.move
  prediction.move               treasury.move              season.move

FRONTEND:                     FRONTEND:                  FRONTEND:              FRONTEND:
  Match list                    zkLogin + sponsored tx     My predictions         Leaderboard
  Prediction form                                          Receipts               Stats

ORACLE:                       ORACLE:
  Mock oracle                   Agent-operated HTTP
                                Attestation + hot potato

INFRA:                        INFRA:                     INFRA:
  Testnet deploy, CI            Gas station backend        Walrus integration    Monitoring, alerts

PROVES:                       PROVES:                    PROVES:                PROVES:
  Prediction created            Full settlement cycle      Complete user         Real users care
  on testnet via                in single PTB              journey               enough to predict
  zkLogin

Questions

Which map surprised you — and what does that surprise reveal about your assumptions?

If the outcome map shows all four gates passing on testnet but zero real users care, what did we actually prove?
The value stream map shows compression — but does compression matter if the oracle is unreliable?
If the oracle is the highest-risk dependency, why isn't it the first thing we build?

Overview VV Stories