# Staking Release Plan (Stages 8–12)

This document outlines why staking should not ship in early stages (1–7) and how we’ll release it safely during stages 8–12.

Why not to release staking early (Stages 1–7)

- Security vulnerabilities: Early code hasn’t been fully audited or stress-tested; staking could expose user funds.
- Uncertain project viability: Many projects pivot or fail early; locking user funds adds undue risk.
- Protocol instability: Rapid changes during development can break reward logic or jeopardize staked assets.

Release milestones for staking (Stages 8–12)

- Stage 8 — Security audits and internal testing
  - Action: Complete rigorous internal testing and external audits by reputable firms.
  - Purpose: Ensure contracts and reward mechanics are free of critical bugs and re-entrancy/exploit paths.

- Stage 9 — Public testnet (Alpha/Beta)
  - Action: Launch staking on a public testnet with open community testing.
  - Purpose: Capture edge cases at scale in a risk-free environment; validate reward accrual and exits.

- Stage 10 — Phased mainnet launch
  - Action: Enable mainnet staking with caps (per-wallet/TVL) and progressive validator/participant ramp.
  - Purpose: Observe real usage under constraints; roll back quickly if anomalies are detected.

- Stage 11 — Public mainnet launch
  - Action: Remove/raise caps, open to all eligible holders.
  - Purpose: Provide liquidity and align long-term incentives for the broader community.

- Stage 12 — Rewards activation and maintenance
  - Action: Turn on emissions according to policy; monitor, patch, and re-audit as needed.
  - Purpose: Keep staking secure, solvent, and predictable over time.

After launch (Stages 13–15)

Delaying too long after public launch can be a missed opportunity: demand and momentum are highest near launch, and timely staking helps align holders and improve liquidity depth while attention is still strong.

Implementation notes (internal)

- Gate staking interactions in-app until Stage ≥ 10 (enable testnet demo at Stage 9).
- Publish audits and changelogs alongside contract addresses and parameters (caps, cooldowns, early-exit fees).
- Add on-chain monitoring dashboards and incident response runbooks before enabling public rewards.

---

BabyAi server

This small Express server provides helper endpoints for the BabyAi presale front-end.

Setup

1. Install dependencies

   npm install

2. Start the server

   npm start

Endpoints

- GET /health
  - Returns {ok: true}

- POST /verify-signature
  - Body: { address, message, signature }
  - Verifies the signature and returns { ok, recovered }

- POST /record-purchase
  - Body: { address, tier, amountEth, txHash }
  - Records the purchase in an in-memory array and returns the entry

- GET /purchases/:address
  - Returns purchases recorded for the given address

- GET /token-balance?token=<tokenAddr>&address=<address>&rpc=<rpcUrl>
  - Returns { balance } as a decimal string. Default RPC is an Infura placeholder. Replace with your RPC URL.

Notes

- This server is a minimal demo. For production, replace the in-memory store with a persistent DB and secure endpoints with authentication.
- You must provide a working RPC URL for `token-balance` (Infura, Alchemy, or your own node). Replace the placeholder in environment variables or pass `?rpc=`.