# Token Access, Fees & Game Integration — Strategy & Research

> **Created 2026-06-06.** Deep-research response to the owner's model: users own
> their BTLM007, we don't take it to play, we charge a *very low* recurring fee for
> unlimited play, users can transfer/donate to each other, fees auto-collect to a
> treasury, and we sweep the treasury to the business weekly.
>
> ⚠️ **Not legal advice.** This maps what each feature triggers and how to structure
> it more safely, so you can hand counsel a concrete plan. The 🔴 items still need a
> crypto attorney (and likely a separate token entity) per
> [`MONETIZATION_AND_BUSINESS_SETUP.md`](MONETIZATION_AND_BUSINESS_SETUP.md).

---

## 1. Your model, restated

| You want | In plain terms |
|---|---|
| User buys BTLM007 → it's **their** token in **their** wallet | Non-custodial ownership ✅ (already how it works) |
| We **don't take** their token to let them play | Access is based on *holding*, not *spending* |
| **Unlimited hearts based on how much they bought** | Tiered access by balance (hold more → more perks) |
| **Very low fee** for unlimited play (weekly / 3-day / monthly) | A cheap **subscription** |
| Users can **transfer** tokens to each other / **donate** to a leader | Peer-to-peer transfers |
| We take a **3% fee** on those transfers | A cut of every transfer → treasury |
| Treasury auto-fills, we **sweep to the business weekly** | Fee collection + off-ramp to USD |

The cleanest version of your idea is **"hold/lock to play, pay a small fee to
subscribe"** — *not* "spend your token to play." That one change keeps the user's
token theirs (exactly your goal) **and** dramatically lowers the legal weight.

---

## 2. The hard truth — what each feature triggers

| Feature | Regulatory trigger | Risk | How to make it safer |
|---|---|---|---|
| Hold/lock BTLM007 → unlock hearts | None (you never take the token) | 🟢 Low | Non-custodial balance/lock check |
| Subscription **in fiat** (Stripe) | Normal SaaS | 🟢 Low | You already have Stripe |
| Subscription **in token** (auto-pull) | Token-as-payment | 🟡 Med | Solana Subscriptions program (non-custodial) + counsel |
| **3% fee on P2P transfers** | **Money transmission** (MSB/MTL) | 🔴 High | Stay non-custodial (see §5); counsel required |
| Spend token → hearts (treasury) | Token-as-currency + securities | 🔴 High | Already scaffolded + gated |
| Selling token with profit promises | **Securities (Howey)** | 🔴 High | Market as *utility/access only* (see §6) |
| Treasury token → USD weekly | Off-ramp (provider is regulated) | 🟡 Med | Use an OTC desk; keep tax records |

**The two big red flags in your plan** are (a) **taking a % of user-to-user
transfers**, and (b) **anything that makes BTLM007 look like an investment.** Both
are solvable, but they're the parts that need the lawyer.

---

## 3. The safe building blocks games actually use

### a) Token-gating (hold to access) — non-custodial
The standard web3-game pattern: the user connects their wallet, the app **checks
their balance**, and unlocks features if they hold ≥ a threshold. The platform
**never stores or touches the token** — it just reads a public on-chain balance.
This is exactly "unlimited hearts based on how much he holds," with zero custody.
Used across web3 gaming (Sequence, Unlock Protocol). [1][7]

### b) Token *locking* (better than staking) — keeps ownership
Even better for your "we don't touch his token" goal: the user **locks** tokens
**in their own wallet** (a flag prevents transfer); the game reads the lock and
grants access. Unlike staking, **the tokens never leave the player's wallet** — no
staking contract, no custody, no "we hold your funds." [8]

> **This is the centerpiece I'd recommend:** *"Lock 1,000 BTLM007 for the week →
> unlimited hearts."* The user keeps full ownership, you take nothing, and it
> creates real buy-and-hold demand for the token (healthier price, less sell
> pressure) — all while matching your vision precisely.

### Tiering (your "based on how much he buys")
| Tier | Hold/lock | Unlocks |
|---|---|---|
| Free | 0 | Hearts regenerate normally |
| Bronze | 1,000 BTLM007 | Unlimited hearts |
| Silver | 5,000 | Unlimited hearts + extra Zoom meetings |
| Gold | 25,000 | All of the above + premium levels/cosmetics |

> **Built (Track A, this iteration):** the tier engine is live & non-custodial —
> tiers defined in `js/token-config.js → tiers`; `BVWallet.getTier()` /
> `tierForBalance()` resolve a user's tier from their on-chain balance (read-only,
> never touches the token; 8/8 headless tests). The dashboard holdings card now
> shows the member's tier ("Membership: Bronze · ♾ unlimited hearts"). Still to do:
> wire the tier into `js/hearts.js` (unlimited hearts when `tier.unlimitedHearts`),
> the prepaid Stripe top-up, and the transactions ledger.

---

## 4. The recurring "very low fee" — how to charge it

You have two good options. **Start with fiat; add crypto later.**

### Option 1 — Fiat subscription via Stripe (recommended first)
"Unlimited hearts — $1.99/week" billed by **Stripe** (you already have it wired:
`stripePublishableKey` in `js/app-config.js`, `stripe` in the backend). This is a
plain SaaS subscription: **lowest legal risk, no crypto/MSB/securities issues, works
for users who don't even hold crypto.** The token stays untouched; holding it can
*unlock the right to subscribe* or give a discount.

### Option 2 — On-chain subscription (crypto-native, later)
Solana shipped a **native, audited Subscriptions & Allowances program** (live on
mainnet; audited by Cantina & Spearbit; integrators include Helius & Dynamic). It
lets a user authorize a **capped recurring pull** (e.g., "up to 50 BTLM007/week")
**without you taking custody or building a billing stack.** [2][3] Alternatives:
**Loop** (card-like recurring, accepts SPL tokens, plugs into Stripe), **Sphere**
("subscribe and forget"), **Superfluid** (streams a tiny fee *per second* for
"always-on" unlimited play). [2]

> Charging the fee **in the token** is token-as-payment → 🟡 needs counsel. Charging
> in **fiat** is clean. Many games do exactly this: token for ownership/access,
> fiat for the subscription.

### Pricing reality — charging $0.05 (the micro-price trap)
The owner wants it **so cheap anyone can buy in** — ~**$0.05** ("5 cents"), not a
percentage. A nickel charge **cannot** go through Stripe each week: Stripe takes
~**$0.30 + 2.9%** per charge, so you'd *lose* ~$0.25 on every $0.05. Keep the cheap
*feel* while staying profitable:
- **Prepaid balance (recommended):** user pays **once** (e.g., $2.99) into an
  off-chain balance; you deduct $0.05/week from it. One Stripe charge → ~60 weeks.
  Record each deduction in the transactions ledger.
- **Bundling:** sell the cheap rate in blocks — "$0.99 for ~20 weeks", "$2.99/year".
- **Free tier stays free:** the existing rewarded-ad → +1 heart flow already keeps
  $0-spend users playing; the paid tier just removes the wait/cap.

Advertise "**from ~$0.05/week**", bill it as a small **prepaid top-up**.

---

## 5. The 3% transfer / donation fee — the tricky one

Two ways to collect a fee on transfers, plus the legal catch.

### a) Application-layer fee (works with the *existing* BTLM007)
When a user donates through **your UI**, the app builds **two** transfers in one
transaction: the donation (user → leader) **and** the fee (user → treasury). The
user signs once. Works today, non-custodially. **Limitation:** it's a "soft" fee —
users can always transfer directly from any wallet and bypass it.

### b) Protocol-level fee (Token-2022 Transfer Fee extension)
Solana's **Token-2022** program has a built-in **transfer-fee extension**: set
`transferFeeBasisPoints = 300` (3%) and **every** transfer auto-withholds 3% into
the recipient account; you (the withdraw authority) **harvest/withdraw** it to your
fee account. Enforced at the protocol level — **even outside your app.** [4]

> 🚧 **Big catch:** this only works on a **Token-2022 mint.** BTLM007 is a *standard*
> SPL token (live ~18 months) and you **cannot add a transfer fee to it
> retroactively.** Getting protocol-level fees means **launching a new Token-2022
> token and migrating holders** (snapshot + airdrop/swap). That's a real project and
> it *increases* the securities/MSB profile (every transfer pays the issuer). Decide
> deliberately with counsel.

### The legal catch (applies to both)
Taking a cut of value moving between two users is the classic **money-transmission**
question. FinCEN's **"total independent control" test** (2019 guidance) is the key:
**non-custodial / unhosted wallet software providers are *not* regulated as money
transmitters**, because the *user* keeps total independent control of the value — you
never receive or control it. [5][6] So the defensible structure is: **the transfer
happens entirely from the user's own wallet; you never take custody of the
transmitted amount.** Even then, *taking a percentage* may still draw MSB scrutiny —
**this specific feature is the one to clear with a crypto attorney before shipping.**
A safer interim: take the donation platform fee **in fiat** (a "service fee"), not as
a slice of the transmitted crypto.

---

## 6. Keeping BTLM007 a *utility* token, not a security (Howey)

The SEC's **2026 interpretive guidance** is a meaningful thaw, but "**Howey's still
here.**" [skadden] The token itself isn't automatically a security; a **sale becomes
an investment contract** when it's marketed **with promises of profit from your
managerial efforts.** Utility/access tokens *can* cross the line **depending on how
they're marketed and sold.** [wilmerhale][sec-2026]

**Practical rules that lower the risk a lot:**
- Market BTLM007 as **access/utility** ("hold to play, donate, subscribe"), **never**
  as an investment ("buy now, price goes up because of our roadmap").
- No promises of returns, staking yield, buybacks, or "the team will pump it."
- Emphasize **consumption/use today**, not future appreciation.
- Keep tokenomics and treasury **transparent**.

---

## 7. Treasury → your business account (the weekly sweep)

- Your **treasury wallet** (hardware wallet or **Squads multisig**) collects fees/tips.
  Public address goes in `js/token-config.js → treasury`; **private key never in the
  repo.**
- To turn tokens into USD for the business, use an **OTC desk / Coinbase Prime** —
  built for "revenue arrives on-chain, bills are in fiat." They quote an all-in price
  and wire fiat; far less slippage than dumping on a public market. [otc]
- **Tax/records:** report crypto holdings and conversions; keep records of every
  sweep. (Your Country Trips LLC handles the fiat side; the off-ramp provider is the
  regulated money-services entity, not you.)

---

## 8. Recommended architecture — two tracks

### 🟢 Track A — build now, low legal risk (recommended start)
1. **Hold/lock to play** (token-gating + locking): unlimited hearts by tier. You
   never touch the token. ✅
2. **Fiat subscription via Stripe** for "unlimited play $X/week." ✅
3. **Non-custodial P2P donations** (user → leader, from their own wallet). Take any
   platform fee **in fiat**, or none at first. ✅
4. **Backend records** every purchase/subscription/lock as transactions (you asked
   for this — a ledger of who bought how much). ✅
5. **Treasury** (your own tokens/tips) → **OTC off-ramp** weekly. ✅

This delivers your whole experience (own your token, low weekly fee, unlimited play,
donations, treasury) with the **least** regulatory exposure.

### 🔴 Track B — needs the crypto attorney (and likely a new token + DE/WY entity)
- Subscriptions/fees **paid in BTLM007** (Solana Subscriptions program → treasury).
- **3% protocol fee** on every transfer (requires a **new Token-2022 token + migration**).
- **Spend** tokens for hearts (already scaffolded + gated: `BVWallet.spend()`).
- Cash-out flows. → All gated behind counsel.

---

## 9. How to integrate the token into the games (concrete)

| In-game thing | How the token plugs in (Track A) |
|---|---|
| **Hearts / lives** | Lock-tier = unlimited hearts; or buy a Stripe "unlimited week" |
| **Extra Zoom/conference meetings** | Gated perk for Silver+ holders (balance check) |
| **Premium levels / continents** | Token-gated unlock (hold ≥ N) |
| **Cosmetics / avatars** | Buy with fiat, or gate "exclusive" ones to holders |
| **Civic / leader donations** | Non-custodial peer transfer; optional fiat tip fee |
| **Leaderboard / status** | Show holder tier badge (Bronze/Silver/Gold) |
| **Rewards for playing** | Airdrop small BTLM007 from treasury for milestones (no "yield" promises) |

Implementation hooks already in the repo: `js/wallet.js` (`BVWallet` —
balance reads done; add a `hasTier(n)` / `isLocked()` helper), `js/hearts.js` (the
"Buy Hearts" stub → point at the Stripe sub or the tier check), `js/token-config.js`
(`treasury`), and the dashboard holdings widget.

---

## 10. My added suggestions

1. **Lock, don't spend.** "Lock to play" matches your vision *and* is the safest,
   *and* it props up the token (locked supply = less sell pressure). Best single idea here.
2. **Two-layer currency.** BTLM007 = ownership/access/trade; off-chain **hearts/points**
   = the in-game consumable (earned, or bought via Stripe). Avoids "spend the security."
3. **Fiat-first, crypto-optional.** Default everyone to the Stripe subscription;
   offer the on-chain subscription as an *option* for crypto-native users.
4. **Tiered membership** for "based on how much he buys" — Bronze/Silver/Gold.
5. **Don't retrofit fees onto BTLM007** unless counsel + a new Token-2022 migration
   make sense; start with an **app-layer/fiat** fee.
6. **Marketing discipline** (utility language only) — this single habit removes a lot
   of securities risk under the 2026 guidance.
7. **Publish treasury address + weekly sweep cadence** — transparency builds trust and
   helps the compliance story.

---

## 11. Decisions for you (bring these to counsel)

1. **Subscription currency:** fiat (Stripe, safe) vs token (needs counsel)? *Rec: fiat first.*
2. **Access model:** *lock-to-play* vs *spend-to-play*? *Rec: lock.*
3. **Transfer fee:** none / fiat service fee / app-layer token fee / new Token-2022
   token? *Rec: start none-or-fiat; revisit Token-2022 only with counsel.*
4. **New token?** Keep BTLM007 as-is (app-layer fees) vs launch Token-2022 + migrate.
5. **"10 pc" / "5 pc":** did you mean **percent** or **cents/cash**? (Changes the
   pricing + which rules apply.)

---

## Sources
- [1] [Sequence — Token gating in web3 gaming](https://sequence.xyz/blog/how-to-use-token-gating-access-in-web3-gaming)
- [2] [Solana native subscriptions & allowances (The Defiant)](https://thedefiant.io/converge/blockchains/solana-ships-native-payments-rail-for-subscriptions-and-allowances) · [Loop](https://www.loopcrypto.xyz/) · [Sphere](https://medium.com/@spherepay/true-on-chain-subscriptions-798d4c6625a2) · [Superfluid](https://superfluid.org/)
- [3] [Solana subscriptions on mainnet (TheStreet)](https://www.thestreet.com/crypto/innovation/solana-brings-subscription-billing-and-spending-limits-on-chain)
- [4] [Solana docs — Token-2022 Transfer Fees](https://solana.com/docs/tokens/extensions/transfer-fees) · [QuickNode guide](https://www.quicknode.com/guides/solana-development/spl-tokens/token-2022/transfer-fees)
- [5] [FinCEN 2019 CVC Guidance (FIN-2019-G001)](https://www.fincen.gov/system/files/2019-05/FinCEN%20CVC%20Guidance%20FINAL.pdf) · [Coin Center summary](https://www.coincenter.org/fincens-new-cryptocurrency-guidance-matches-coin-center-recommendations/)
- [6] [Kelman PLLC — Money transmitter licensing for crypto](https://kelman.law/insights/money-transmitter-licensing-for-u-s-crypto-companies/)
- [7] [Unlock Protocol — token-gated application architecture](https://docs.unlock-protocol.com/tutorials/building-token-gated-applications)
- [8] [Proof of Play — "Don't stake, lock your tokens"](https://proofofplay.com/resources/dont-stake-lock-your-nfts)
- [Howey/SEC] [WilmerHale — SEC's 2026 Howey framework](https://www.wilmerhale.com/en/insights/client-alerts/20260324-the-secs-new-framework-for-crypto-assets-under-howey) · [Skadden — "Howey's Still Here"](https://www.skadden.com/insights/publications/2025/08/howeys-still-here)
- [OTC] [Transak — crypto OTC trading](https://transak.com/blog/crypto-otc)