Your Account, Your Keys, Your Money

This chapter answers three questions in one place: how do you actually sign up, what does each step of "getting more serious" with NightWatch unlock, and where does your money (or your Cherry) actually live. It draws together identity and payments on purpose, because on NightWatch they are the same ladder: each rung you climb exists specifically to unlock a new way for money to move, not to earn a badge for its own sake.

Five ways in

NightWatch's login page offers five separate paths, and they are not equally capable:

A few details matter in practice. If you're already signed in and click "Connect wallet," the page deliberately refuses to run a fresh login (which would quietly split you into two separate accounts) and sends you to your Account page instead, where linking a wallet correctly merges it into your existing identity. The page also checks any stored login token against the server before trusting it, so a stale or dead token from a previous session doesn't silently break your next visit. And whichever path you choose, if it hands you an API key or a recovery code, that value is shown to you exactly once, so save it immediately. That one-time recovery code is not decorative: NightWatch has a live API endpoint, POST /auth/agent/recover, that re-issues a fresh API key against your existing account when you provide your agent name together with that recovery code. There's no screen in the web app for this yet, so using it means calling the API directly, but the mechanism itself works today and is the only way back into an account whose key you've lost; without that recovery code, registering again mints a brand-new, separate account rather than restoring the old one.

One consequence of that fifth path is worth stating plainly, because it changes what your Account page looks like. The four human paths all end with your browser holding an account session, and every panel on Account works. The Developer API path ends with an agent key and nothing else: that key is a full sign-in — Account opens, your wallet and funding panels work, your Hyperliquid glance works, and you can create further agent identities — but three things on that page are read against an account session rather than a key, and an agent key cannot read them. Your Cherry balance and plan, your earnings and contribution ledger, and your linked sign-in methods each say so where they would otherwise show a number, in one sentence, with a sign-in link beside it. Nothing is hidden and the page never sends you away; sign in by email, Google, Telegram or wallet in the same browser and those three fill in, with your agent still attached to the same account.

A second case behaves the same way on purpose. If NightWatch cannot be reached at all — a patchy connection inside the Telegram in-app browser is the common one — Account says the server could not be reached and offers a Retry, and your stored session is left exactly as it was. An unreachable server is not the same thing as a rejected login, so it never signs you out.

Where you manage all of this: the six Account tabs

Everything above, and everything below, has one home once you're signed in: Account (/account). It is one spine of six tabs, and each tab shows only what is yours:

Links from before the six tabs still work: ?tab=assets opens Wallet, ?tab=account opens Settings, and ?tab=steward opens My Earn. Every block either shows your own rows or says plainly that there is nothing yet and what will appear there; none of them shows a sample number. The sections below walk through what used to be the single Connections tab and now sits on Agents and Settings.

Your AI agents. Every agent bot identity your account has created shows up here: when it was made, when it last did anything, how many of its API keys are still active, and its Cherry credit balance. Create a new one from this same panel and, because you're signed in when you do it, that agent is owned by your account from birth - its Cherry and contribution history land on your account, not on a separate, unowned identity the way a standalone agent_connect call with no credentials still produces. Two actions are live per agent: rename it, or revoke all of its active keys at once. A third, "Adopt an existing agent" - claiming a standalone agent's Cherry and history into your account by name or key - is not in this version; planned for v1.1. The button is there, with its input inactive, so the rule is visible before it ships.

Ways your AI talks to NightWatch. Five one-line doors, side by side: MCP (point an MCP-native tool at the server; no key needed to browse - see the Connect Your AI chapter for the full tool list), a personal API key (acts as you via the X-NW-User-Key header; free to create, with higher daily call limits behind a Plus subscription), OpenClaw (the programmatic registration path for an autonomous mining bot), a CLI (pip install nightwatch-cli, then nw login --key), and skill.md (a single URL that hands any AI - Claude, ChatGPT, Grok - the whole platform contract in one read).

Wallets. The same wallet-linking flow as the login page, reachable again from inside your account: connect or change the embedded email wallet, or link an external one. This section has its own address, and it is the answer to "I'm told to connect a wallet, but where?":

https://nightwatch-v1-frontend.onrender.com/account?tab=settings#nw-wallets

Opening that URL selects the Settings tab and scrolls straight to the Wallets section (the older address, /account?tab=account#nw-wallets, lands in the same place), on a cold load as well as from a link elsewhere on the site. Every screen that asks you for a wallet — the wallet dashboard, the funding panel, the Buy Cherry popup, the Hyperliquid glance, and the Move funds popup — carries a Connect a wallet link next to the sentence, and all five lead here. The Move funds popup closes itself on the way, so you are never left looking at a dismissed dialog.

Two things about registering a wallet are worth stating exactly, because getting either one wrong costs an afternoon.

A signature from the wallet is required. An address by itself is never enough. Registering a wallet is not a form where you type an address; NightWatch has no endpoint that accepts one. It is a one-time message that NightWatch issues and your wallet signs, which is what proves you hold the address rather than merely knowing it. In the browser that is one click in your wallet. Over the API it is POST /auth/wallet/nonce to get the message, then POST /auth/wallet/link with the signature.

If you are signed in with an agent key only, you cannot register a wallet from that session, and NightWatch cannot tell you whether you already have one. A wallet is registered to an account, and /auth/wallet/link accepts only an account bearer token — an X-NW-User-Key agent key does not authenticate it. So the Wallets section says exactly that, with a sign-in link, and shows no connect control that could not work. Read the wording carefully: it says your wallet cannot be read from this session, which is not the same claim as "you have no wallet." An agent key cannot see an account's wallet either way, so an empty-looking panel is not evidence that nothing is linked.

There are two ways forward, and one of them is probably already in your hands:

• Sign in with an account login in the same browser — email, Google, Telegram or wallet — then connect and sign. Your agent stays attached to the same account.
• Use the bearer_token from your agent registration. POST /auth/agent/connect returns three credentials, not one: api_key, recovery_code, and bearer_token. That third value exists specifically for /auth/wallet/link and the other bearer-only endpoints, and it is shown exactly once. Save it at registration time and an agent can register its own wallet over the API with no browser at all. GET /auth/wallet/status with the same bearer answers "do I have one already?".

If you registered an agent before this was fixed and kept only the API key, there is currently no way to recover a bearer for that account: POST /auth/agent/recover re-issues an API key and no bearer, and nothing exchanges a key for one. Registering again would mint a different account rather than restoring yours, so it is not a workaround. An agent owned by an account has a way through — its owner signs in and links a wallet to the account they share. A standalone, unowned agent in that position does not, and that gap is recorded here rather than papered over.

Messaging. One Telegram link, to the same Telegram account the Mini App runs in. It delivers alerts and reminders; it does not merge your Mini App balance into your web account, which stays separate (see "Three Cherry balances that are not the same thing" below). Alongside it, an in-app inbox fed by GET /me/notices: a running list of what NightWatch has told you, with an unread count and a mark-as-read action on each notice.

Trading keys. A short explainer and a link out to the Torii order screen, where the actual Hyperliquid agent-key approval gets signed on-chain. Nothing on the Agents tab itself moves money or signs anything - it's a pointer to where that happens, not a control for it.

Knowledge, the sixth block: the public Obsidian vault, covered fully in the Knowledge and Obsidian chapter, gets a one-click card here too - when it was last updated, its hub/atom/language counts, a Download vault (.zip) button that opens GitHub's own archive of the public commons repo (branch master), and a "how to open in Obsidian" walkthrough. Download it once, and a later visit adds "N changes since your download" so you know whether it's worth refreshing. The same card, smaller, sits on the Earn hub next to Playbooks. /kg doesn't repeat the card; it links out to the vault chapter instead, and shows the public commons atom count alongside the internal one.

Settings also keeps a separate Sign-in methods block for linking your email or Google account directly, alongside the wallet and social paths already covered in "Five ways in" above.

Referrals

The Account page has a Referrals section: your permanent code, copy buttons for the web and Telegram links, who referred you, and the people you referred. A referral pays a share of their reviewed work, not their signup; the rules and numbers are in Cherry and Payments under referral codes.

Agent key scopes: what each of your agents may do

Until now every agent key carried the full power of its account. On Account -> Agents -> Key scopes you can narrow that, per agent, to any of five scopes:

Next to the scopes you can set a per-order and a per-day limit in USD; they apply to spend, trade and tx actions, and the day resets at 00:00 UTC. Three rules keep this safe:

• An agent with no scopes set keeps full access, exactly as before. Nothing changes for an existing key until you narrow it.
• Scopes only narrow. They never loosen anything else: Torii order caps, the kill-switch and the Telegram confirm code still apply to every agent trade, inside a generous scope as much as a tight one.
• Closing a position always works. A reduce-only order NightWatch has verified against the agent's real Hyperliquid position (never just what the order claims) goes through even without trade, and regardless of its USD limits. Taking trade away is for stopping an agent from opening new risk on your behalf — it must never leave the agent unable to close a position it already holds.
• A paid read only needs read. Paying for a metered read out of the agent's own Cherry balance is governed by read alone, never also checked against spend — a key scoped to read but not spend can still pay for reads out of its own balance. spend still gates every other way of spending Cherry or x402 credit.
• Only your signed-in session can change them. An API key — the agent's or your own — can read an agent's scopes but never change them, so no key can widen what a key may do.

A scope covers every credential of that agent's account, including the bearer token /auth/agent/connect issues, so a new key minted later inherits the same limits. An action outside the scopes is refused with status 403 and a plain reason naming the scope or the limit. Owners use GET, PUT and DELETE /agents/{id}/scopes; an agent reads its own with GET /agent/scopes.

My Forge, gas prices and the x402 top-up

My Forge gathers what you hold in The Forge from reads that already existed: your deposits in each vault (waiting, in the vault, shares), your withdrawal queue — each withdrawal you requested, shown as "Waiting in the queue" until the vault pays it — the bids you placed in open supply auctions with the exclusion reason and fix for any set aside, your supplier tier, the funds you applied to run as a maker, your Forge positions, your registered strategies, and the funds you mirror. No money moves from this tab.

If you mirror a fund and filled one of its signals somewhere Torii did not see, report the fill from Report a fill — on the vault page under Mirror this fund, or under Funds I mirror here. The form writes through POST /forge/signals/{id}/fills with the same checks the API makes (an active mirror, your mirrored account address, the signal's own side, a fill time not in the future), and the report appears in your list as soon as it is saved.

Gas prices on the Wallet tab is a live table of what NightWatch charges in Cherry to pay gas for you on Base and Arbitrum, per kind of transaction, from POST /gas/quote. Top up with USDC opens the same Obsidian Cherry window as the header button, on Base Sepolia only; an agent with its own EVM key tops up the same way — buy Obsidian Cherry (its own wallet, or the gas-sponsored path) and convert it to Cherry — there is no separate x402 top-up call for this any more (see "Buying Cherry: the Obsidian Cherry panel, step by step" above).

The identity ladder: money first, reputation later

NightWatch's own planning documents lay out identity as four rungs, and are explicit about a guiding principle: each rung should unlock only what actually needs it, and reputation alone (a badge, a rank) is not treated as enough reason for someone to bother climbing. Money is the reason people climb.

One detail worth being precise about: registering as an agent (POST /auth/agent/connect, the L0 step) never creates an on-chain wallet on its own. It only creates an internal account: a user row, an API key, and a Cherry ledger entry. A wallet only enters the picture when you deliberately link one, or when you actually need to pay or be paid in USDC.

The wallet security ladder

NightWatch's stated principle is that it should never, at any stage, be the party holding your private key. The plan for how a wallet is supposed to get safer as it holds more money is laid out internally as a four-stage ladder, and only the first stage is actually built and live today:

The design is explicit that if NightWatch ever holds that one guardian vote in stage 3, it is built to be structurally incapable of moving funds by itself; one vote out of three can never be a controlling vote. Until stage 2 exists, though, your email-based wallet is genuinely the only line of defense you have, so size what you keep in it accordingly.

What your balance would unlock: tiers S0 through S3 (not in this version; planned for v1.1)

A related, separate piece of the plan ties what NightWatch lets an account do to how much it's worth, rather than requiring any particular security setup outright. The principle behind it: your assets are yours, so NightWatch cannot force you onto a stronger wallet setup, but it can gate the features it unlocks (trading caps, payout size, operator eligibility) by which stage of the ladder above you've actually reached. The dollar thresholds below are still marked as drafts, not yet confirmed.

The design has NightWatch total up, once a day, everything it can actually see for your account: USDC in wallets you've linked, your Hyperliquid account value, your NightWatch credits, and any pending (unclaimed) royalties. That total places you in one of four tiers:

A drop back below a tier's threshold carries a 7-day grace period before anything is restricted, so a brief dip in your balance doesn't immediately lock you out. You can always opt into a stricter tier than your balance requires; NightWatch never requires it of you. None of this is built yet: no code measures a daily asset total or gates a payout by tier. Don't plan around these specific dollar amounts yet, since even the plan itself marks them as unconfirmed drafts.

Taking your wallet elsewhere (not in this version; planned for v1.1)

Exporting your embedded wallet's private key - both an EVM key and a Solana key - plus creating a Solana account in the first place, is technically possible through the wallet provider NightWatch uses, but none of that is in this version; it's planned for v1.1. There is no button today that exports your key.

Going the other way, importing an external private key into your embedded wallet, isn't supported today at all. So bringing your own wallet works differently in practice: you link an existing wallet instead (MetaMask for an EVM address using the "Connect wallet" sign-in path above, or Phantom for Solana), and then, once linked, you'd choose which linked wallet is your primary one, the one that receives royalty payouts and signs approvals. That primary-wallet selection step is not in this version; planned for v1.1.

Sending funds from your embedded wallet out to an external one is not in this version.

USDC is the money, Cherry is a credit

NightWatch's payments design starts from one rule: USDC (and USDT for some services) is real money, and Cherry (🍒) is NightWatch's own unit for pricing its services — a subscription, a paid data read, sponsored blockchain gas — see GET /prices for the live list. Cherry is not money. It is how you receive utility from the NightWatch protocol: you earn it by contributing and spend it on NightWatch services. NightWatch does not buy back Cherry and does not set or support any market price for it. Cherry has no guaranteed cash value. Its use is paying for NightWatch services. If Cherry circulates for less than the value of the services it pays for, we expect markets to settle its swap rate against other tokens, such as Obsidian Cherry or stablecoins, on their own. The only redeemable, money-backed asset in this system is Obsidian Cherry, bought with USDC (one stablecoin per pool, decision 28) and redeemable at its current share, never below $0.01 (next section).

Buying Cherry: the Obsidian Cherry panel, step by step

Cherry is never bought directly with money. A "🍒 Buy Cherry" button in the site header (every page, desktop and phone) opens the Obsidian Cherry panel — the same popup opens from "＋ Buy" on your Account wallet's own Cherry row, and the Forge pages' entry point too. The panel has three actions — Buy, Redeem, Convert — against PrimaryPool on Base Sepolia, a public test network today (docs/pm/REWARD_POLICY_V1.md decision 28).

The one-step "Buy Cherry" button, the fastest path to a spendable balance:

1. Connect an EVM wallet if you haven't already; the panel won't let you start without one. Your wallet needs test USDC on Base Sepolia.
2. Type a dollar amount. There's no minimum or maximum buying from your own wallet.
3. Press "Buy Cherry." This runs two wallet confirmations back to back, both from your own wallet, both your own gas: first Buy (approve() then buy() — USDC moves into the reserve at share × 1.02, and Obsidian Cherry mints to you), then Convert (burns what you just received and credits Cherry to your account, at the current share, into NightWatch's treasury as revenue). The panel says plainly that two confirmations are coming.
4. Done. The panel shows what converted; your Cherry balance updates the same way any other credit does.

Buy and Convert can also be done separately — useful if you want to hold Obsidian Cherry rather than spend it right away, since it's redeemable for USDC on its own (see below). Where NightWatch pays the gas ("Let NightWatch pay the gas" on the Buy tab, once turned on), Buy instead takes two signatures — one authorizing the net amount, one authorizing a gas fee to the pool's current treasury — with a $5 minimum net amount and 50 sponsored buys per account per day. The server computes the gas fee and you sign exactly that quoted amount — there is no buffer to choose — and any gap between the quote and the real cost is never refunded unless the buy itself fails or expires.

Redeem turns Obsidian Cherry back into USDC, at the current share, with no fee — your own wallet, your own gas, any time, never blocked. Convert is the one-directional step: it burns Obsidian Cherry and credits Cherry; Cherry never converts back into Obsidian Cherry. Never send USDC directly to the pool's contract address outside these documented calls; a transfer that isn't routed through an actual buy can't be credited or recovered.

Obsidian Cherry is redeemable for USDC at its share of the reserve, never below $0.01. NightWatch does not promise a price above that floor. If the stablecoin issuer freezes or seizes reserve funds, that loss is shared pro rata by all holders — redeeming keeps working, just at the honest, reduced price, while that lasts. Today's USDC on Base Sepolia is test-network money with no real-world value; real-USDC purchases, credited to anyone, open on Base's real network at public launch, after a legal review and a contract audit.

Three Cherry balances that are not the same thing

A genuinely confusing detail worth naming directly: there are three separate places you might see a number labeled "Cherry" today, and they do not share a balance:

The welcome credit itself is now unified at 10 🍒 no matter which door you came through, once per account: email, Google, wallet, Developer API, the web's "Log in with Telegram" button, and the Telegram Mini App's own claim all grant the same 10 🍒 (an agent you register gets its own account and its own welcome credit, separate from yours). What still genuinely differs is the ledger it lands in first: the Mini App's claim credits its own separate ledger rather than your main NightWatch balance directly. If that same Telegram identity later links to (or signs up on) your main NightWatch account, the pending Mini App credit moves into your main ledger instead of granting a second 10 🍒 on top of it - you still end up with one welcome credit per account, just possibly parked in the Mini App ledger until that link happens.

Promotional, purchased, and earned Cherry

Every Cherry credit is tagged as one of three kinds, and they behave differently:

Spending draws promotional Cherry first, then earned, then Cherry converted from Obsidian Cherry last. Cherry is not money; it is how you use the NightWatch protocol, whatever its kind; only Obsidian Cherry is redeemable. A tip or other transfer to another account works differently: it can only draw on promotional or earned credit, never purchased credit, so purchased Cherry can't be moved to someone else's balance. A transfer has a minimum amount and a separate flat fee on top of it — see GET /prices (cherry_transfer_min, cherry_transfer) for the current numbers; both the amount and the fee are drawn together, in the same transaction, so a transfer never goes through without its fee.

Ledger discipline: append-only, one direction only

NightWatch's Cherry ledger is append-only: rows are never edited or deleted, even to fix a mistake. A correction is made by writing a new, compensating entry (a matching credit or debit that cancels the error out), never by rewriting history. This is the same no-retroactive-restatement principle NightWatch applies to its published grades and reports, applied here to money.

On-chain Cherry (the CHRY token) is always treated as a withdrawn subset of this ledger, never the other way around. Value only ever flows one direction: ledger, then a signed voucher, then an on-chain mint. The blockchain never writes back into the ledger. If the two ever disagree, the ledger is treated as correct, and the system simply stops issuing new vouchers until someone reconciles the difference; no on-chain state ever needs to be unwound. The key that signs those vouchers is required to live only on NightWatch's own server, never in any frontend code a browser could read, because whoever holds that key can authorize new Cherry up to the token's fixed 1 billion cap.

One more detail worth knowing if you run an AI agent on NightWatch: an agent does not hold Cherry in its own name. Whatever Cherry an agent earns is always credited to its human owner's linked wallet, not a wallet the agent itself controls.

Earned Cherry is for using NightWatch, by design

Accumulating and spending earned Cherry inside NightWatch never requires a wallet or an SBT. Cherry is not money; it is how you use the NightWatch protocol, and turning earned Cherry into USDC is not a planned future feature — decision 28 applies this to every kind of Cherry (promo, earned or purchased). An older payout-request screen (Earn -> Payouts, GET /payouts/mine) may still be reachable; nothing it lists ever pays out, for anyone, regardless of wallet or SBT, and it is not where NightWatch's money path runs.

The actual money path is Obsidian Cherry, described above and in chapter 06: anyone holding Obsidian Cherry — bought with USDC, or received — may redeem it for USDC at its current share, never below $0.01, any time, with no wallet gate beyond the one your own wallet already needs to hold tokens. A royalty payout pays as Cherry, the same as a task reward; what an SBT eventually gates is whether a royalty share is paid to you at all rather than escheated to the treasury (the previous chapter, The Knowledge Economy, walks through that 30-day countdown), not whether it becomes cash.

Paying per read: x402, live, but in testnet mode

When a paid data read runs out of free quota, NightWatch's server can ask for payment directly over HTTP using a standard called x402: it responds with status code 402 ("Payment Required"), describing exactly how much USDC is owed, and a compatible client pays it with a single gasless, signed authorization. This is live today, but it runs in testnet mode: the network is Base Sepolia, not Base mainnet, so the USDC being asked for has no real-world value yet. Live payments on Base and Arbitrum mainnet are not in this version; planned for v1.1. Two of NightWatch's own metered routes (token intelligence and the cross-venue pair-gate check) are currently priced at $0, so there's no charge for them at all; reading a file from NightWatch's playbook knowledge library charges $0.01 in USDC over x402. Reading a Forge vault's live signal or turning one into a plan for your own account (chapter 27) is priced in Cherry instead (GET /prices: signal_read, currently 10🍒 each).

The order NightWatch actually checks, for any caller, is: does a registered agent still have free reads left today (up to 100 per day)? If not, does it have a Cherry balance to spend? If not, can it pay through x402? Only if none of those apply does the caller get the 402 challenge. That means holding a registered agent API key does not make you immune to ever seeing a 402; it just moves you to the front of the queue. An agent that has already used its 100 free reads for the day and holds no Cherry balance gets exactly the same 402 challenge as a completely anonymous, unregistered caller.

Cherry Store and upgrading your subscription

Once signed in, the Cherry Store lets you spend a Cherry balance on a small set of paid products: a deeper research report, a liquidity depth score, and a priority monitoring slot that scans a token once a minute instead of on the normal schedule. Prices are shown per item in Cherry on the page itself, and SBT holders get a noted discount. If your balance is at zero, the store shows a "Start mining" link into the Earn hub instead. Separately, your Account page has its own Upgrade flow for moving between subscription tiers.

The epoch-0 problem: cleaning the ledger before pegging it to real money

A direct audit of the Cherry ledger on 2026-09-10 found 10,945,749 Cherry spread across 19 accounts, and a striking anomaly inside that: 98% of it, sitting in 205 ledger rows across just 5 accounts, carries no record at all of where it came from (no source_type), consistent with old test or seed data predating today's ledger discipline. NightWatch's plan is to classify those specific balances first, either zeroing them out as test data or formally absorbing them as backdated "house vesting," and to disclose that decision publicly, before any real on-chain claim path opens up for actual users. That classification hasn't happened yet. (This has nothing to do with pegging Cherry to a dollar value — Cherry has no guaranteed cash value to peg, under NightWatch's current rules; see "USDC is the money, Cherry is a credit" above.)

Mainnet: paused on purpose, not stalled by accident

Both the Cherry ERC-20 contract and the SBT contract are deployed only on Base Sepolia, a public test network; the same addresses on Base mainnet are empty. This is a deliberate decision, not a forgotten step: the team's stated position is that deploying Cherry to mainnet before there's real external demand to trade or transfer it would only add custody and regulatory exposure for no benefit, since the entire design point of Cherry is that its value is never supposed to depend on being found on an open market. Identity pieces (the SBT and a planned registration under the ERC-8004 standard) are treated separately from that pause, since they represent who you are rather than a tradeable token, but neither is live on mainnet yet either.

---

What you can do now

• Sign up through whichever of the five paths fits you best; if it hands you a recovery code or an API key, save it immediately. It is shown exactly once, but it is not merely decorative: POST /auth/agent/recover (API only, no web screen yet) will re-issue your API key using your agent name plus that code. Recovery is limited to 5 attempts per agent name per hour (every attempt counts); past that the call answers 429 with a retry_at time, and an unknown name and a wrong code give the same answer.
• Link a second identity from your Account page, not by logging in fresh again; logging in a second time while already signed in is deliberately blocked to stop you from accidentally splitting into two accounts.
• Manage every agent, key, wallet, and message channel in one place: Account -> Agents (your agents, the ways your AI talks to NightWatch, trading keys, key scopes) and Account -> Settings (sign-in methods, wallets, messaging, feeds, billing). An agent you create there is owned by your account from birth, so its Cherry and history roll up to you, not a standalone identity - rename it or revoke its keys any time. "Adopt an existing agent" is not in this version; planned for v1.1.
• Narrow what an agent may do on Account -> Agents -> Key scopes: pick from read, spend, trade, sign and tx, and set a per-order and per-day USD limit. With none set, the agent keeps full access.
• See everything you hold in The Forge on Account -> My Forge — deposits, withdrawal queue, bids, funds.
• Grab the public knowledge vault from Settings: the Knowledge card's Download vault (.zip) button pulls the current public commons straight from GitHub, no account or plugin required. You'll find the same card, smaller, on the Earn hub next to Playbooks.
• Buy Cherry from the header button if you want to try it (or "＋ Buy" on your Account wallet's Cherry row — same popup): connect a wallet, type an amount, and press "Buy Cherry" — two confirmations, buy then convert, on Base Sepolia, a public test network today. Never send USDC straight to the pool's contract address outside the panel's own Buy/Redeem/Convert actions.
• Treat your Cherry balance as spendable, not investable: see GET /prices for what it buys. Cherry — task reward, royalty, promo or purchased — never converts to real USDC for anyone, no matter what wallet or SBT you hold; that is permanent under decision 28, not a version gap. If you want a redeemable, money-backed balance, that is Obsidian Cherry, not Cherry.
• Know which Cherry balance you're looking at. The Telegram Mini App, the web app, and the on-chain token are three separate balances today, not one number in three places - linking your Telegram account on Account -> Settings delivers alerts and reminders, it doesn't merge the Mini App balance into your web account.
• Spend promotional Cherry within 3 days; purchased and earned Cherry (tasks, royalties, and Cherry converted from Obsidian Cherry) never expire.
• Don't send real money through x402 expecting it to move on Base mainnet yet. The one live paid-read endpoint asks for testnet USDC on Base Sepolia; nothing you pay there today has real-world value, and live mainnet payments are planned for v1.1. And don't assume a registered API key exempts you from ever seeing a 402: it only grants a 100-reads-per-day head start.
• If you're a contributor owed a royalty, know that it pays as Cherry, never as cash — that is permanent, not a version gap. Link a wallet and request an SBT anyway: once monthly distribution starts, a share missing either is held pending rather than escheated to the treasury after 30 days (previous chapter).