Brote architecture: practice ledger and guardian-controlled real SOL Two separate paths. Practice Brotes are stored in a browser-local ledger with a Web Locks single writer. For real SOL, a Phantom or Solflare guardian signs System Program instructions for a seed-derived profile account on Solana mainnet. Brote saves the signed transaction in a local journal before broadcast, then confirms or reconciles its status with RPC. No child private keys, custom deployed program, or Brotes token. How Brote works One friendly interface, two clearly separate kinds of money. React + TypeScript · client only PRACTICE PATH Fictitious Brotes · no monetary value Profiles + Brotes Goals, requests and practice spending One writer tab Web Locks coordinate local edits Browser-local ledger Saved in localStorage on this device BROTES ARE NOT A TOKEN AND NEVER CONVERT TO SOL REAL SOL PATH Solana mainnet · guardian approval required Guardian wallet Injected Phantom or Solflare Only the guardian signs System Program CreateAccountWithSeed · deposit TransferWithSeed withdrawal Profile account Derived from guardian + seed On mainnet · no child key TRANSACTION SAFETY SEQUENCE 1 Wallet signs 2 Save signed journal 3 Broadcast to RPC 4 Confirm / reconcile Unknown outcome stays pending · withdrawal goes to a chosen address · no custom deployed program Brote architecture · practice and real SOL remain separate

Swipe horizontally to explore the full diagram.

Practice remains local

Brotes are fictitious entries in this browser’s practice ledger. Web Locks lets one tab edit at a time; other tabs follow saved changes in read-only mode.

Real SOL needs the guardian

The guardian signs mainnet System Program transactions. Brote stores the signed bytes locally before broadcasting; an uncertain RPC result stays pending for reconciliation.