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?
Where does time die?
Paper world vs walked world — where the chain of custody compresses.
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?
What depends on what?
Critical path and hard dependencies. Operator onboarding is the highest-risk node.
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?
How does the operator move from pain to performance?
Five stages. Each stage earns the next.
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?
What gets built in what order?
Four sprints. Sprint 1 proves the hardest thing. Sprint 2 proves the split.
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
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 jars walked, what did we prove?
- The value stream map shows verification compression — but does that matter if the beekeeper never onboards?
- If operator onboarding is the highest-risk dependency, why isn't it the first thing we test with a real user?