Viewer flow

A real person, watching streams, getting paid for time spent. From first hearing the streamer mention BitView through long-term loyalty holding — every step they take and every system they touch.

Timeline at a glance

T0       Discovery — sees streamer mention BitView
T+5min   Wallet setup (one-time, only if they don't have one)
T+10min  Sign in to BitView, link wallet to Twitch (one-time)
T+10min  Receives 100 BTV onboarding airdrop (anti-sybil stake covered)
T+10min  Watches the stream — bot detects them in chat
... ticks accrue every periodicity_seconds while they're present ...
T+1h     Possibly receives an NFT drop notification mid-stream
T+stream-end  Distribution period ends. Backend snapshots.
T+~24h   Distribution finalized. Tokens claimable.
T+~24h   Claims tokens (one-click) — lands in wallet
T+~24h   Decides: hold for utility, or cash out via swap router
... returns next stream, no re-onboarding ...
T+30days Possibly first NFT drop received from this streamer
T+90days Compounds: stake levels up, NFT loyalty stacks, fee discounts kick in

Total friction from cold to first earned token: about 10 minutes if they need a wallet, 2 minutes if they already have one.

Phase 1 — Discovery

Trigger: The streamer mentions BitView mid-stream, posts in their Discord, or tweets about a distribution event. The viewer is curious and visits bitview.so.

What they see: A landing page that explains the loop in one paragraph and presents two CTAs — "Connect wallet" and "Read the viewer guide". Most click "Read the guide" first; about a third skip straight to connect.

No action required from BitView yet. Marketing surface. Funnel metric tracked: visits → wallet-connect click.

Phase 2 — Wallet setup (one-time)

If they already have a Solana wallet: skip this phase entirely. This applies to maybe 10% of incoming traffic in early days, growing toward 40%+ as crypto-native streamers' audiences arrive.

If not:

1. They install Phantom (we recommend by default — it's the most widely-used Solana wallet and works on every device including mobile via the Phantom in-app browser).
2. They fund it with a small amount of SOL — typically $5–10 worth buys plenty of headroom for transaction fees + token-account rent over many claims.
3. We provide a "Get a wallet" walkthrough that links to Phantom's own onboarding for the actual setup, then deep-links back to BitView when they're ready.

Cost to viewer: Whatever SOL they fund the wallet with (~$5–10 out-of-pocket on a fiat ramp). They keep this; it's not a fee to BitView.

Phase 3 — Wallet linking (one-time)

This is the single step where BitView identity is created. It happens exactly once per viewer.

1. User clicks "Sign in with Twitch"
   → Twitch OAuth flow opens
   → User authorizes BitView (scope: user:read:email)
   → Twitch returns user-access token to BitView frontend

2. User clicks "Link wallet"
   → Wallet adapter prompts to connect (Phantom popup)
   → User approves
   → Frontend constructs a nonce message:
     "BitView wallet link. Twitch user_id=12345, timestamp=2026-05-10T15:00Z"
   → Wallet pops up "Sign Message" prompt
   → User signs

3. Frontend calls POST /bitview-api/user/link with:
   - Authorization: Bearer <twitch token>
   - body: { solana_wallet, signature, signed_message }

4. Backend:
   a. Verifies the Twitch token against Helix /users
      (returns the same user_id encoded in the message)
   b. Verifies the ed25519 signature against the wallet pubkey
   c. Verifies the user_id in signed_message matches the Helix response
   d. Screens wallet against OFAC sanctions list
   e. Upserts the (twitch_login, twitch_user_id, solana_wallet) record
      in MongoDB

5. Backend mints + transfers a 100 BTV onboarding airdrop
   (one-time per Twitch user_id, sourced from the 30% viewer-rewards
   bucket). This immediately satisfies the anti-sybil stake floor.

6. Frontend confirms: "Linked. You're now eligible to earn from any
   distribution where you appear in chat."

Cost to viewer: Zero (BitView covers the airdrop transfer fee).

What they walk away with:

• A linked Twitch ↔ Solana wallet identity, recorded in BitView's database.
• 100 BTV in their wallet.
• Eligibility to earn on any active distribution.

What can go wrong here, and how it's handled:

• Twitch account younger than 30 days → friendly "your account needs to be at least 30 days old to qualify" message. We don't link.
• Wallet sanctions hit → "we can't link this wallet" with a generic message (we don't tell them why; counsel-driven posture).
• Signature mismatch → "signature verification failed, please try again" — usually a wallet-extension cache issue, retrying clears it.

Phase 4 — Accrual (passive)

Now they watch streams. The whole point of BitView is that they don't have to do anything else to earn.

Behind the scenes, every periodicity_seconds (typically 60s):

1. Backend's accrual loop wakes up.
2. For each active distribution, it reads the in-memory chat-presence map (populated by the Twitch IRC listener) — list of twitch_logins currently in the channel's chat.
3. For each present login, it looks up the linked wallet in MongoDB.
4. It applies engagement weighting:
   • 0.25× if they're connected but haven't messaged recently
   • 1.0× if they sent a PRIVMSG in the last 10 minutes
   • +0.25× bonus if they have a sub/mod/vip/founder badge
   • +0.50× welcome bonus if first hour in this channel
   • +0.10× bonus if Twitch account ≥ 1 year old
5. It computes the per-tick share: pool_per_tick / weighted_viewer_count.
6. It upserts an accruals document in MongoDB: +amount, +1 tick.

The viewer sees nothing on-chain yet. Accruals are off-chain ledger entries. This is intentional — putting every tick on-chain would be financially suicidal even on Solana. The on-chain commitment happens once at finalize via the merkle root.

What the viewer can see: their current accrual balance for each active distribution, via the BitView app dashboard. Updates in real time.

Friction: Zero. They literally do nothing except watch.

Phase 5 — Engagement boosts (optional, viewer-driven)

Smart viewers push their accruals higher by:

• Posting in chat. Lurkers earn at 0.25×; chatters earn at 1.0×. This is by far the highest-leverage thing they can do.
• Subscribing to the channel. Sub badge adds +0.25× across the whole stream.
• Showing up early. Welcome bonus (first hour) is +0.50×.
• Holding ≥ 1,000 BTV. Stake-weighted bonus is +0.10× across all streams.
• Participating in quests (Phase 3+). Streamer-defined conditions ("PRIVMSG includes #pewpie", "follow before tick") trigger one-time bonus accruals.
• Catching boost periods (Phase 3+). Streamer declares "next 30min = 3×" and viewers present during that window earn at 3× rate.

A maximally-engaged viewer can earn roughly 3–4× what a pure lurker earns in the same stream. This is calibrated to make engagement worth more than alt-accounting.

Phase 6 — NFT drop event (optional, streamer-driven)

Some streams trigger an NFT drop alongside the regular accrual. See NFT drops for the full mechanics. From the viewer's side:

Mid-stream or post-stream:
  → Push notification (in-app + Discord if connected): "You're eligible
    for [Streamer] [Drop name]"
  → Click to open the claim page
  → Frontend computes their merkle proof
  → Wallet popup signs the claim transaction
  → NFT lands in their wallet within ~30s

Cost to viewer: ~$0.001 in Solana network fees + ATA rent if it's a new token-account. Effectively free.

What they walk away with:

• A Solana NFT (Core asset for premium drops, Bubblegum compressed for mass drops) tradeable on Magic Eden / Tensor.
• Discord role auto-assigned by the BitView bot if the streamer configured one.
• Future-drop priority for this streamer.
• Optional accrual multiplier on future distributions from this streamer (if streamer toggled it on).

Phase 7 — Distribution finalizes

The stream ends. Time passes (typically 24h grace period for last-minute viewers to be picked up by the snapshot). Then either the streamer or the BitView ops team triggers /distributions-api/{id}/finalize.

What the viewer sees: the distribution status flips from "active" to "claimable" in their dashboard. They get a notification.

What's happening behind the scenes:

1. Backend reads all accruals rows for that distribution from MongoDB.
2. Builds a merkle tree where each leaf = (wallet, accrued_amount).
3. Stores the tree to disk + a merkle_snapshots document.
4. An operator (multi-sig + timelock for safety) calls set_enable_slot on the distributor program with the merkle root, opening claims.
5. Distribution status: claimable.
6. The merkle proof API begins serving proofs at /claims-api/proof/{wallet} (which proxies the underlying distributor proof API).

Phase 8 — Claiming

1. Viewer opens the rewards page
   → frontend calls GET /claims-api/summary/{wallet}
   → returns list of claimable distributions for this wallet

2. They see "Claim 4,500 BTV from PEWPIE Charity Stream"
   plus other claimable entries

3. Click "Claim"
   → frontend calls GET /claims-api/proof/{wallet}
     for each pending entry
   → constructs a `new_claim` instruction per entry
   → bundles them into a single transaction (or splits if > 6 per tx)
   → wallet pops up to sign

4. Transaction submits to Solana
   → distributor program verifies proofs against on-chain root
   → vault transfers tokens to viewer's ATA (creates ATA if needed)

5. Viewer's wallet shows the new token balance
   → frontend confirms claim, marks the entry as claimed

Cost to viewer: ~$0.001–0.005 per claim (Solana network fee + ATA rent if new). BitView fee on claim itself: 0%. The path is deliberately frictionless to get tokens into wallets.

What can go wrong:

• The transaction fails because the proof was computed for an outdated tree → frontend retries with fresh proof, succeeds.
• The viewer doesn't have enough SOL for fees → friendly "you need ~$0.005 of SOL to claim" message with a link to a fiat-onramp partner.
• The vault is empty (clawback already happened) → "this distribution was clawed back at [date]" message. Should be impossible if claim windows are honored, but defended anyway.

Phase 9 — Decision: hold or cash out

This is where viewer behavior splits and where BitView's revenue becomes real.

Path A — Hold for utility (the BTV stickiness path)

Viewer keeps BTV / STREAM in their wallet. Reasons to hold:

• Anti-sybil stake — the 100 BTV floor is permanently required.
• Fee discount — once they hit 10K BTV, swap fees drop.
• Future-drop priority — holding a streamer's prior NFT drop guarantees eligibility for the next.
• Governance vote weight (Phase 5+) — locking BTV into governance earns vote weight scaled by lock duration.

A viewer on this path generates ~zero swap revenue for BitView in the short term, but they're a sticky long-term participant whose holding compounds their earned-rate via stake bonuses.

Path B — Cash out via swap router

Viewer wants USD-equivalent value. They click "Cash out" in the app:

1. Frontend calls POST /swap-api/quote with:
   { input: 50000 BTV, output: USDC, slippage_bps: 50 }
   → backend asks Jupiter aggregator for best route
   → backend computes its own 0.10% protocol fee skim
   → returns a quote: ~$245 USDC out (at $0.005 BTV, 0.30% total fees)

2. Viewer reviews the quote, clicks Confirm
   → frontend constructs a transaction:
     a. Transfer 50 BTV (0.10%) → BitView treasury fee wallet
     b. Jupiter swap 49,950 BTV → USDC

3. Wallet pops up to sign once
4. Transaction confirms
5. USDC lands in their ATA

BitView captures: 50 BTV (0.10% of input) — value transferred atomically into the BitView fee-collection wallet. This is the single most important revenue line.

Path C — Cross-streamer rebalancing

Same swap router, different intent. Viewer earned LIRIK and PEWPIE, wants to consolidate into more PEWPIE. The router routes LIRIK → BTV → PEWPIE in a single transaction, paying two BitView fee legs (0.10% each) and the underlying LP fees.

This is the highest revenue-per-viewer path because two swap legs are charged.

Phase 10 — Returning (no re-onboarding)

The viewer comes back next week to watch another stream. Everything is already linked. They just watch.

Compounding effects on returning viewers:

Compound	Mechanism
Stake-weighted bonus	Holding ≥ 1,000 BTV across multiple distributions = +10% across all earnings
Future-drop priority	NFTs from prior drops guarantee eligibility on subsequent ones
Fee discount	Once they hit 10K BTV, every swap costs less
Governance weight	Phase 5+, longer-locked BTV = more vote weight
Discord roles	Auto-granted by BitView bot in streamers' Discords as they accumulate NFTs
Streamer-token reserves	Viewers who held a streamer's token early benefit if the streamer grows

The retention engine: a viewer who comes back for stream #2 is ~3× more likely to come back for stream #5 than a one-time visitor is to come back for stream #2. The compounding utility is the reason — they're not just "a viewer" anymore, they're a stake-weighted, fee-discounted, NFT-loyalty-stacked participant whose return ROI is visible.

What can go wrong over the long term

Failure	Mitigation
Viewer's wallet seed phrase is lost	They need to onboard a new wallet. Past accruals + NFTs are gone (we cannot recover; nor should we). Frontend warns about backup at every wallet-connect.
Streamer they earned from rugs their token	We delist; viewer's STREAM holdings are stuck on their original mint but worthless on the platform router. Public delisting list maintained.
BTV price crashes 80%	Stake threshold gets cheaper in USD; we may raise the 100 BTV floor proportionally with public pre-announcement. See Tokenomics §Scenario A.
Twitch suspends their account	Linked wallet remains; they can still claim past accruals. New accruals stop until Twitch ban lifts.
Wallet compromised	They notice (their accruals stop or another wallet appears). They click "I think my account was compromised" → 30-day cooling-off + manual review path.

What the viewer never has to do

This list is as important as the action list above:

• Never deposit funds with BitView — non-custodial throughout.
• Never approve unlimited token spending allowances — every swap is a single signed transaction with explicit amounts.
• Never run a custom client — everything works in any major Solana wallet + the BitView web app.
• Never KYC — viewers are anonymous beyond Twitch ID + wallet pubkey.
• Never wait for batch airdrops — claims are pull-based on their schedule.

Cross-references

• Anti-fraud — what protects the viewer's accruals from sybil farms
• NFT drops — full mechanics of the loyalty NFT layer
• Tokenomics — what BTV does and why holding helps
• API reference — the live endpoints that power each phase
• Viewer guide — the streamlined how-to version of this page