# GrowBlocks: communities with verifiable onchain benefits

Research and architecture proposal · 20 September 2026

Status: planning, not a shipped integration or smart-contract security audit. Repository baseline: `86556a2411d461df3266f36b3356415ce027909f`. Read-only chain observations are attached in `research/chain-observations-2026-09-20.json`. No funds were moved, wallets created, transactions signed or production settings changed.

## Recommendation

Make GrowBlocks the place where a community meets, builds and earns verifiable access before a launch. Use Robinhood Chain for new launches, trading and receiving addresses. Keep eFrogs and eFroglets on Linea and verify their ownership there. A player should not have to bridge an NFT to enter a room.

Start with a verified community passport, holder rooms and a transparent UGLY launch campaign. Add external partner checkout after its real capabilities are confirmed. Investigate a personal embedded game wallet as the next onboarding improvement. Do not start by taking deposits into a GrowBlocks treasury and maintaining withdrawable balances ourselves.

The winning benefit is concrete access or a funded entitlement: a reserved allocation where the launch contract supports it, a capped fee rebate, creator privileges, or a useful holder room. Attendance alone cannot guarantee profit, a better market price or exemption from launch mechanics.

The existing no-signing/no-custody game boundary remains in force during this research. A separate trusted wallet companion is the recommended first implementation. An embedded signing experience would be a new, explicitly reviewed product boundary.

## What the audit found

| Area | Observed today | Consequence |
|---|---|---|
| Identity | Google/Telegram authentication; optional typed EVM address in `src/net.js` | A typed address is not ownership verification. Public SHAMA/name labels are not authority. |
| Markets | `server/markets.cjs`, `src/market-terminal.js`, `src/paper-model.mjs` provide indicative prices and local practice | There are no real orders to extend safely by simply adding a deposit button. |
| Published worlds | `firestore.rules:77` permits public document reads; `src/builder-store.js:17` loads scenes directly | A locked door would not protect the world data. Test mode is unlisted, not private. |
| Broadcasts | `server/broadcast.cjs:19` returns screen state publicly | Private room screens and their media need a separate authenticated path. |
| Attendance | `firestore.rules:116` permits client-created attendance records under shape restrictions | Existing attendance cannot authorize valuable rewards. No live reward payout was found. |
| Multiplayer | `server/multiplayer.cjs:2`: 24 seats, 20-second lease; authenticated server admission | Add membership authorization to admission and renewal. More instances are a separate project. |
| Voice | Accepted one-to-one calls have server admission | Gate invitations and voice credentials too, including after membership changes. |
| Ownership | Owner controls exist independently of display names | Financial administration needs separate roles; transfer of a plaza must not silently transfer a treasury. |

These are integration blockers and design findings, not a claim that current public worlds were intended to be confidential. This audit reviewed relevant code paths and public documentation; it did not perform penetration testing or verify every deployed contract implementation.

## Provider reality: useful now versus conditional

**Robinhood Chain:** official documentation identifies mainnet chain ID **4663**, testnet **46630**, and ETH gas. The read-only mainnet probe matched 4663. Deployment on this chain does not imply a Robinhood brokerage listing or endorsement. Dedicated RPC capacity should replace reliance on one public endpoint before financial operations. [Official network documentation](https://docs.robinhood.com/chain/connecting/)

**PONS:** V2 documents direct contract integration, a bonding curve followed by Uniswap V4 graduation, and version-dependent deployment addresses. Its maximum 32 opening-tax exemptions are not a general player whitelist or reserved allocation. Launcher authorization is also different from buyer eligibility. V1 uses a different trading architecture; never reuse a V2 adapter for every historical token. Confirm launch version, active configuration, fees, approved quote asset and deployment provenance before building transactions. [PONS V2](https://docs.ponsfamily.com/v2), [PONS V1](https://docs.ponsfamily.com/)

**Mosh:** the public site describes Bundle Cat and bundle funding that becomes permanent capital after launch, with variable fee participation. Several product actions were labelled coming soon during review. No usable public Mosh-specific launch API/SDK was located. UV Harness documentation is not evidence of a Mosh bundle API. Treat UGLY reservation, funding, fee sharing and refund integration as partner-dependent until contracts and commercial terms are supplied. Liquid-token buying and a bundle commitment must have different product cards and confirmations. [Mosh](https://mosh.trade/), [UV Harness](https://uvlabs.ai/docs/)

**NFT settlement:** Element documents Linea contracts, making it a candidate for external eFrogs/eFroglets checkout after collection and order support checks. Seaport is a possible settlement protocol, not evidence of an approved Robinhood deployment. Do not display executable bids until chain support, valid orders, fees and settlement addresses are independently checked. [Element deployments](https://docs.element.market/welcome-to-element/developer/deployed-contract), [Seaport](https://docs.opensea.io/docs/seaport)

## The community experience

### 1. The player passport

Players choose their avatar and public name. They can explore freely. A private account panel separates verified receiving address, optional Linea holder identity, event eligibility and benefits already redeemed. This passport should initially be a revocable server credential, not another speculative token.

Never show a player's wallet publicly by default. Offer a voluntary holder badge without exposing balance, full portfolio or account email. An address proves control only after a challenge; it does not establish a unique human or guarantee trustworthiness.

### 2. eFrogs Embassy and eFroglets workshop

Create a public gallery and separate holder spaces: an eFrogs community room, eFroglets creator workshop, and a shared room accepting either collection. Benefits can include community-approved avatar traits, booth templates, gallery display rights and creator office hours. Confirm artwork licensing before turning NFT art into wearable assets.

Linea has documented eFrogs-linked ENS identity, including `id.efrogs.eth`. This could make a distinctive optional nameplate; a resolved name still needs wallet verification and cannot establish moderator authority. [Linea identity article](https://linea.build/blog/subdomains-on-efrogs-open-the-floodgates-for-amplified-user-identity)

Candidate collections observed on Linea:

| Collection | Candidate contract | Read-only observation |
|---|---|---|
| eFrogs | `0x194395587d7b169e63eaf251e86b1892fa8f1960` | ERC-721 interface response; reported supply 2,015 |
| eFroglets | `0xa9651e1f89535d5b6ede0b818d07712d826e5dc8` | ERC-721 interface response; reported supply 10,000 |

These observations establish responses from contracts, not official authenticity or safety. Obtain project-owner confirmation before approving either registry entry. Their very short runtime bytecode also means implementation/delegation analysis is outstanding. No holdings, current floor prices or royalties were assumed. Historical project context: [eFroglets minting plan](https://paragraph.com/%40efrogs/efroglets-minting-plan).

### 3. UGLY Launch Theater

Publish an event with explicit eligibility, cutoff, capacity and benefit terms. A player attends, completes bounded participation checks, verifies a beneficiary and sees one of: eligible, waitlisted, reserved, claimed or expired. A reservation must state exactly what is reserved and by whom.

Use shared screens for the same official event state across future instances. Announcements must not expose private holder data. Give everyone access to education and public events; do not require a purchase to participate socially.

After the event, show transaction receipts and redeemed benefits. Never replace failed contract execution with a celebratory success animation. No countdown-based pressure to commit permanent capital.

### 4. Trade lounges

Friends can discuss a verified asset card while using accepted private voice. A card pins chain and contract identity rather than trusting a ticker or uploaded logo. Initial execution opens a trusted partner checkout. A future NFT swap should settle both sides atomically on one supported chain using reviewed infrastructure; never ask one player to send first.

Existing Linea NFTs remain Linea assets. Selling them is a separate Linea settlement flow. A Robinhood launch reward for a Linea holder is possible through an eligibility snapshot without moving the NFT. A pair of transactions on different chains is not automatically an atomic swap.

## Wallet verification and whitelisting

Use a server-created, one-use Sign-In with Ethereum challenge bound to the current GrowBlocks session, expected domain, URI, chain, nonce and short expiry. Reject replay, wrong origin and substituted beneficiary. Verify smart-contract signatures on the actual signature chain. Defer undeployed smart-wallet proofs until a vetted verifier supports them. [ERC-4361](https://eips.ethereum.org/EIPS/eip-4361), [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271), [ERC-6492](https://eips.ethereum.org/EIPS/eip-6492)

Account linking needs proof of both accounts. Never merge Google and Telegram identities by nickname. A Linea holder can nominate a different Robinhood receiving address, but must prove control of both. The same hexadecimal address on two chains is not sufficient proof of control for every smart-wallet configuration.

For cold-wallet holders, consider a narrowly scoped, reviewed delegation registry rather than NFT transfers or token approvals. Check current ownership and current delegation at the required block; delegation must not silently authorize asset spending. Confirm chain deployment before use. [Delegate documentation](https://docs.delegate.xyz/)

| Campaign type | What the player receives | Required enforcement |
|---|---|---|
| Verified waitlist | Recorded interest linked to a proven destination | Account/address proof; no allocation promise |
| Holder access | Room, workshop or creator access | Live or explicitly snapshotted ownership |
| Participation pass | Eligibility after a disclosed event rule | Trusted server evidence, abuse controls, appeals |
| Reserved launch allocation | Defined maximum contribution or units | Actual partner/contract reservation support |
| Snapshot claim | A funded asset distribution to approved beneficiaries | Frozen rules, root/proof validation, unique claim tracking |
| Capped reimbursement | Reimbursement up to a published ceiling | Sponsor budget reserved first; verified qualifying receipt |
| PONS opening-tax exception | Narrow launch-specific treatment | Confirm actual factory semantics and available slots |

For a fair campaign, freeze rules before registration: time window, eligible collections, participation threshold, allocation method, per-person aspiration versus enforceable per-account limits, transfer rules, expiry and appeals. One NFT must not generate unlimited entitlements by moving among wallets before claims. Snapshot token IDs and record entitlement consumption. Wallet deduplication and participation checks reduce abuse but cannot prove one human per account.

Do not call an exported CSV an enforced whitelist. CSV delivery only informs a partner; the partner must confirm how it enforces the list. Export only campaign ID, chain, verified beneficiary, allowance, rules version and snapshot reference. Avoid emails, Telegram identities and unrelated holdings. Restrict exports to designated roles; record access, set retention and revoke obsolete exports where possible.

If using a Merkle distributor, domain-separate leaves with campaign, chain, contract, beneficiary, asset, maximum amount, expiry and version/nonce using an unambiguous encoding. Freeze the root for an announced round, track claims atomically, and prevent reuse across contracts or rounds. A root published by GrowBlocks attests to GrowBlocks' eligibility calculation; it is not a trustless cross-chain ownership proof. Audit the distributor before funding.

## The proposed funded-account idea

The desired flow is strong: create character, add funds, trade easily, take funds out, with a transparent GrowBlocks execution fee. There are three materially different ways to deliver it.

| Model | Who can move assets? | Strength | Main cost/risk |
|---|---|---|---|
| External personal wallet | Player under existing wallet rules | Least new custody infrastructure | More context switching |
| Personal embedded game wallet | Depends on its actual signer/recovery configuration; target player control | No existing-wallet connection required | Authentication, recovery, provider and session-permission risks |
| GrowBlocks-controlled deposit account | GrowBlocks or contracted custodian | Familiar funded-account interface | Safeguarding, withdrawals, ledger security and regulatory obligations |

**Recommended experiment: personal embedded wallets, not a shared treasury deposit address.** Providers such as Privy expose configurable authorization and policy controls, including user-controlled and service-controlled configurations. Selecting a wallet vendor does not automatically make our specific integration self-custodial. Robinhood chain support, transaction compatibility, recovery and independent exit must be demonstrated in a proof of concept. [Privy controls](https://docs.privy.io/security/wallet-infrastructure/policy-and-controls)

Proposed flow:

1. Sign in, choose avatar, then explicitly choose Create game wallet.
2. Establish player-held authentication and recovery, preferably a passkey with a tested recovery route. Google/Telegram session compromise must not alone authorize withdrawal.
3. Show the player's own receiving address, exact network **Robinhood Chain**, supported asset and deposit status. ETH on Ethereum or Linea is not automatically Robinhood ETH; exchange withdrawals must support the destination network. Never silently bridge.
4. Show available onchain assets and pending transactions separately. Players review amount, asset, minimum received, price impact, network fee and GrowBlocks fee before signing.
5. Initially require confirmation for every trade. Later consider opt-in, revocable session authorization with short expiry, strict spend caps and approved routers, assets and functions. Exclude arbitrary transfers, arbitrary approvals and blanket signing.
6. Send funds out through explicit confirmation and stronger authentication. Provide a documented recovery/export or alternative access route that still works if GrowBlocks is unavailable, tested before claiming independent control.

Do not promise that every position can be withdrawn as ETH at any moment. Sending available ETH, selling an illiquid token and exiting a locked bundle are different operations. Network outages, gas, security checks and contract restrictions also affect completion. Preferred copy: **Send available assets to your wallet; timing and fees depend on the network.** Locked products show their actual exit conditions before entry.

**If custody is chosen later:** use an appropriately authorised partner where required, rather than improvising a treasury hot wallet. Get jurisdiction-specific legal analysis of custody, execution, exchange, order transmission and token placement before launch. MiCA's custody provisions address client agreements, positions and safeguarding; avoiding a wallet-connect dialog does not avoid these issues. [ESMA Article 75](https://www.esma.europa.eu/publications-and-data/interactive-single-rulebook/mica/article-75-providing-custody-and), [ESMA service classification](https://www.esma.europa.eu/publications-data/questions-answers/2653)

A custodial design requires a double-entry ledger, asset/liability reconciliation, pending/available/reserved balances, reorg handling, exactly-once deposit credit, withdrawal reservation and approval, destination controls, incident response, key isolation and segregation from business funds. Unique deposit addresses improve attribution but do not remove custody. A small verification deposit also does not necessarily prove control of the sending address: it may originate from an exchange.

Never keep private keys in Firestore, game localStorage, scene metadata or a general-purpose Vercel environment variable used to sweep all customer funds. No production deposit address should be published before the full model is approved and tested.

## Revenue without damaging trust

Charge a disclosed execution fee only where the settlement integration supports it and legal/commercial review permits. Include it in the pre-trade total; never hide it in a spread or add an undisclosed transfer after execution. Start with a pricing experiment rather than a committed rate. For illustration, 0.25% of a $100 trade is $0.25 before provider costs, network costs and other expenses; this is arithmetic, not revenue forecasting.

Do not take a percentage of deposits or imply ordinary withdrawal is a trade. If a provider cannot enforce and attribute a referral fee, do not claim that fee model works. Onchain receipts and fee reconciliation must show who received each fee.

Additional revenue can come from Studio subscriptions, event production and clearly marked sponsorship. Never let sponsors buy a safety badge or influence the asset risk classification. Reward building, attendance and helpful participation rather than repetitive trading volume or leveraged exposure. Keep paid financial actions separate from minors' social play, subject to the applicable legal requirements.

## Architecture and security decisions

Use the game as an untrusted presentation client. Keep wallet UI on a controlled origin without uploaded world scripts. Backend services own challenges, membership policies, campaign eligibility and immutable audit events. A chain adapter handles RPC reads, finality and independently verified receipts. A provider adapter declares capabilities; missing capabilities disable the corresponding UI.

A membership decision must authorize the actual service: scene download, private media, chat read/send, presence, voice credentials and private announcements. New private scenes belong in a server-only store; public metadata contains only approved previews. Old public copies cannot retroactively become secret. Signed media URLs expire and private responses must not use shared public cache keys.

Use canonical world/room IDs for policies and separate instance IDs for capacity. Suggested initial membership leases last 60 seconds, with version and revocation epoch checks; tune after load and chain-finality measurements. Transfer or revocation removes continuous access at the next bounded recheck. Snapshot benefits follow the published cutoff instead. During RPC uncertainty, deny new privileged access and use only a clearly bounded existing-session grace period before returning players to the public lobby.

Quoting is not permission to sign. Before any future trade, verify chain, token, recipient, spender, router, function, amount, deadline and minimum output against a reviewed registry. Simulation reduces some failures but cannot certify safety. Exact approvals are preferred; where a protocol requires broader NFT operator approval, disclose its scope and support revocation. Membership verification never requests an asset-spending approval.

Treat remote NFT metadata, artwork and project links as hostile input: sanitize text, constrain media MIME/size and proxy fetches with redirect/DNS/SSRF protections. Do not execute content embedded in a scene or NFT. Asset ownership does not establish intellectual-property permission.

Separate project owner, moderator, campaign operator, registry reviewer and treasury signer. Require independent review for contract registry changes and valuable campaign root publication. A plaza ownership transfer revokes old operational roles but does not automatically move funds or rewrite a campaign's beneficiary rules.

## Risk register and release gates

| Priority | Risk | Required evidence before release |
|---|---|---|
| Critical | Client fabricates reward attendance | Server event evidence, replay/rate tests, reward simulator rejecting legacy records |
| Critical | Gate bypass through direct world/media/broadcast read | Anonymous and nonmember negative tests against every route and storage rule |
| Critical | Wallet/account takeover drains funds | Signer threat model, strong confirmation, recovery and independent exit drills |
| Critical | Wrong/malicious contract or deployment version | Owner confirmation, source/implementation review, registry versioning and two-person approval |
| Critical | Custodial liabilities exceed safeguarded assets | Partner/legal approval, ledger invariants and reconciliation drills; no custody pilot otherwise |
| High | False promise of reserved allocation | Partner contract test proving unauthorized buyers cannot consume reserved entitlement |
| High | Cross-chain/address confusion | Chain-specific UI, smart-wallet proofs and wrong-network tests |
| High | Duplicate or reorged deposit/claim/receipt | Idempotent processing, finalized-state policy and rollback tests |
| High | Silent session-key overspending | Onchain/provider-enforced limits, expiry, revocation and malicious-calldata tests |
| High | NFT transfer farms claims | Snapshot entitlement IDs, uniqueness constraints and transfer replay tests |
| High | Private data leaks through exports/caches | Minimal exports, access audit, TTL and privacy review |
| High | Provider outage prevents exit | Independent recovery/withdrawal test; honest status and incident playbook |
| High | Illiquid/locked asset sold as available ETH | Distinct balances, exit disclosures and product-specific confirmation |
| High | Minors or unsupported jurisdictions enter financial flows | Counsel-approved audience and access controls |
| Medium | New chain checks degrade game performance | Server caching, bounded concurrency, provider fallback and real-device load checks |

## Delivery sequence

1. **Identity and registry foundation:** canonical account linking, isolated verification prototype, candidate-contract approval, RPC health and server event evidence. Deliver zero-spend wallet proof before any real-money feature.
2. **Holder-room pilot:** eFrogs/eFroglets access in an UGLY room, protected scene/chat/media/voice, transfer/revocation tests. Preserve the free public plaza.
3. **UGLY passport and campaign:** published rules, verified Robinhood beneficiary, trusted participation, minimal exports and claim simulator. Say waitlist until an actual reservation integration exists.
4. **Read-only launch cards and external checkout:** verified PONS version-specific data and Mosh capability review; receipt reconciliation. No custom custody or bridge.
5. **Embedded-wallet proof of concept:** Robinhood testnet, recovery, wrong-network handling, transaction confirmation, transfer-out and game/provider outage tests. Only then choose the production signer model.
6. **Limited financial pilot:** invite-only, capped values, vetted assets, independent security review and legal signoff; published fees and incident support. Mainnet deployment needs a separate concrete release decision.
7. **Broader trading and creator launches:** after measured safe operation; atomic NFT settlement and additional provider adapters require their own gates.

Plan work by acceptance gates rather than promising a calendar before provider access and legal scope are known. The first useful release is verification plus genuinely protected rooms, not a half-built exchange.

## Questions partners must answer

- PONS: approved current deployments/ABIs, implementation and upgrade paths, supported quote assets, active launch configuration, audits, fee attribution and whether a supported reservation mechanism exists beyond tax exceptions.
- Mosh: UGLY launch agreement, API/SDK access, exact contracts and audits, funding/claim/refund lifecycle, caps, who receives proceeds, reserved access enforcement and referral terms.
- NFT owners: confirm both collection addresses, authorized artwork uses, delegation expectations and snapshot versus continuous utility.
- Embedded-wallet vendors: Robinhood support, actual root-of-trust and recovery authority, independent access, session limits, export constraints, Telegram/mobile flows, supported signing methods, outage guarantees and pricing.
- Legal/custody partner: target jurisdictions and age policy; classification of the exact order and fund flows; KYC/AML/sanctions and privacy requirements; responsibilities and complaint/incident handling.

## Evidence limits

The attached RPC snapshot used one public endpoint per chain and a latest block at the time. It is not an independently corroborated finality assertion. Contract bytecode SHA-256 values are diagnostic fingerprints, not Ethereum keccak code hashes or audit certificates. Public API absence means not located in this review, not proof no private API exists. Provider statements have not been independently audited. Recheck deployments, terms and legal requirements before implementation.

Implementation contract and acceptance checklist: [BLOCKCHAIN-ARCHITECTURE.md](BLOCKCHAIN-ARCHITECTURE.md).