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 → /predictions
├── My Predictions → /predictions/mine
└── Leaderboard → /predictions/leaderboardNavigation 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
zkLoginQuestions
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?