Flow Diagrams
Five maps. Each answers a question. Each answer feeds the next question. By the end, per-unit custody is named as an instrument — or killed.
What does success look like?
Four binary gates. No interpretation required.
OUTCOME MAP — Walked DePIN Product
═══════════════════════════════════
┌─────────────────────────────────────────────────┐
│ ONE WALKED JAR WITH FULL CUSTODY │
│ (Hive → harvest → lab → batch → jar → shelf │
│ visible via single QR scan) │
└────────────────────────┬────────────────────────┘
│
┌──────────────┴──────────────┐
│ │
┌──────────▼──────────┐ ┌──────────▼──────────┐
│ PHONE-FIRST │ │ ATOMIC │
│ ONBOARDING │ │ SPLIT │
│ │ │ │
│ Beekeeper │ │ Batch → N jars │
│ registers hive │ │ in one PTB. Every │
│ in under 5 min │ │ jar inherits chain │
└──────────┬──────────┘ └──────────┬──────────┘
│ │
└──────────────┬──────────────┘
│
┌────────────────────────▼────────────────────────┐
│ SCAN AT SHELF │
│ QR resolves full custody in under 3 seconds │
│ on testnet within 30 days of deployment │
└─────────────────────────────────────────────────┘Outcomes defined. Where does time die in the current flow? Paper world vs walked world — where the chain of custody compresses.Where does time die?
VALUE STREAM — Paper World (Current State)
══════════════════════════════════════════
HIVE HARVEST LAB PROCESSOR SHELF
──── ─────── ──── ───────── ─────
┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
│ Hand- │ │ Paper │ │ PDF email │ │ Average │ │ Label │
│ written │ │ harvest │ │ lab report │ │ across │ │ claim │
│ book │ │ log │ │ days late │ │ batch │ │ only │
│ No chain │ │ No link │ │ Unsigned │ │ Dilutes │ │ Brand │
│ │ │ to hive │ │ digitally │ │ provenance │ │ vouches │
└────────────┘ └────────────┘ └────────────┘ └────────────┘ └────────────┘
TOTAL: weeks to verify | 6x fraud multiple | brand = only proof
VALUE STREAM — Walked World (Target State)
══════════════════════════════════════════
REGISTER HARVEST LAB SIGNS SPLIT SCAN
──────── ─────── ───────── ───── ────
┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
│ Hive │ │ Harvest │ │ Lab key │ │ Batch → │ │ Full chain │
│ object │ │ event │ │ signs │ │ N jars │ │ in <3s │
│ on-chain │ │ signed │ │ attestation│ │ in 1 PTB │ │ no login │
│ <5 min │ │ by │ │ <60s │ │ │ │ backward │
│ phone only │ │ operator │ │ │ │ │ │ walk free │
└────────────┘ └────────────┘ └────────────┘ └────────────┘ └────────────┘
TOTAL: seconds to verify | compile-time custody | object = proof
COMPRESSION RATIO
═════════════════
Verification: weeks → 3 seconds (thousands-x faster)
Trust source: brand → chain state (decentralized)
Fraud class: label vs origin → compile-time impossible
Attestation: PDF email → signed write on object
Onboarding: forms + wallet → 5 min phone flow
Value stream mapped. What depends on what — and what kills the project? Critical path and hard dependencies. Operator onboarding is the highest-risk node.What depends on what?
DEPENDENCY MAP — Critical Path
══════════════════════════════
Move Contracts ──→ Operator App ──→ Lab Signing ──→ Split PTB ──→ Scan Endpoint ──→ Dogfood
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
hive.move zkLogin lab key batch.move public read
harvest.move sponsored tx management split PTB chain walk
batch.move GPS capture attestation atomic backward walk
attestation.move signing QR resolver
jar.move
transfer.move
RISK REGISTER
═════════════
┌──────────────────────────┬─────────────┬──────────┬────────────────────────────┐
│ Dependency │ Probability │ Impact │ Mitigation │
├──────────────────────────┼─────────────┼──────────┼────────────────────────────┤
│ Operator onboarding │ HIGH │ Critical │ Phone-first design, │
│ under 5 min │ │ │ sponsored tx, zkLogin │
├──────────────────────────┼─────────────┼──────────┼────────────────────────────┤
│ Lab key management │ HIGH │ Critical │ Partner with one lab, │
│ │ │ │ hardware key storage │
├──────────────────────────┼─────────────┼──────────┼────────────────────────────┤
│ Gas station balance │ Medium │ High │ Alerts at 50%, per- │
│ │ │ │ operator daily cap │
├──────────────────────────┼─────────────┼──────────┼────────────────────────────┤
│ Split PTB at high N │ Medium │ High │ Test at 10, 100, 1000, │
│ │ │ │ 2500 jars │
├──────────────────────────┼─────────────┼──────────┼────────────────────────────┤
│ Scan latency │ Low │ Medium │ Chain walk under 2s, │
│ │ │ │ full render under 3s │
└──────────────────────────┴─────────────┴──────────┴────────────────────────────┘
Dependencies mapped. How does the operator move from paper to chain? Five stages. Each stage earns the next.How does the operator move from pain to performance?
PAIN-TO-PERFORM JOURNEY
══════════════════════
Pain │ Paper book. Lab report by PDF. Brand vouches. Fraud runs 6x.
│ The producer has no way to defend the claim
▼
Awareness │ "Register your hive" — operator receives QR invite
│ First contact is mobile-first, no crypto jargon
▼
First Value │ Hive on-chain in 5 minutes. Harvest signed.
│ The beekeeper holds a QR code that resolves their hive
▼
Habit │ Every harvest signed. Every batch sent to lab.
│ Onboarding is the one-time cost
▼
Mastery │ Lab attests directly. Processor splits atomically.
│ Every jar walks on its own. No intermediary needed.
NAVIGATION STATES
══════════════════════════════════════════
┌─────────────┬──────────────────────┬─────────────────────┬────────────────────┐
│ Persona │ App │ Job │ Output │
├─────────────┼──────────────────────┼─────────────────────┼────────────────────┤
│ Beekeeper │ /operator │ Register, harvest │ Hive + harvest │
│ │ │ │ objects on chain │
├─────────────┼──────────────────────┼─────────────────────┼────────────────────┤
│ Lab │ /lab │ Sign attestation │ Signed write on │
│ │ │ │ batch object │
├─────────────┼──────────────────────┼─────────────────────┼────────────────────┤
│ Processor │ /processor │ Split batch → jars │ N jar objects in │
│ │ │ │ one PTB │
├─────────────┼──────────────────────┼─────────────────────┼────────────────────┤
│ Buyer │ /jar/{"{id}"} │ Scan, verify │ Full chain visible │
│ │ │ │ in <3s, no login │
└─────────────┴──────────────────────┴─────────────────────┴────────────────────┘
Navigation connects the screens. What gets built in what order? Four sprints. Sprint 1 proves the hardest thing. Sprint 2 proves the split. Which map surprised you — and what does that surprise reveal about your assumptions?What gets built in what order?
SPRINT 1 (2 wks) SPRINT 2 (2 wks) SPRINT 3 (1 wk) SPRINT 4 (1 wk)
───────────────── ──────────────── ─────────────── ───────────────
#1 Hive register #3 Batch aggregate #6 Transfer custody #8 Backward walk
#2 Harvest attest #4 Lab attestation #7 QR scan endpoint Dogfood: 1 jar end
#9 Sponsored tx #5 Split PTB to end
CONTRACTS: CONTRACTS: CONTRACTS: CONTRACTS:
hive.move batch.move jar.move (none — frontend)
harvest.move attestation.move transfer.move
FRONTEND: FRONTEND: FRONTEND: FRONTEND:
Operator app Lab app Scan app Scan improvements
GPS capture Signing flow QR resolver Backward walk UI
zkLogin Attestation display
INFRA: INFRA: INFRA: INFRA:
Testnet deploy Lab key storage Walrus for media Monitoring
Gas station Attestation cache CDN for QR Dogfood ops
PROVES: PROVES: PROVES: PROVES:
One beekeeper One batch splits Full chain One walked
registers one hive into N jars in visible in <3s jar proves
in under 5 minutes single PTB by scan the pattern
Questions