Reference
Roadmap & gaps
A frank list of what the local dev stack does, what is missing to be a public testnet, and what is not on the roadmap yet.
This page is intentionally honest. The local stack is a development tool, not a deployed network. Each row in the table below is a real gap. The timeline column is a forecast, not a promise.
Where we are
The local dev stack runs end-to-end on a single Windows + WSL2 + Docker host. A merchant can be onboarded, an invoice created, a payment received, and a sweep executed — all locally, with no public exposure.
Where we are going
timeline
title Local dev ? public testnet ? mainnet
section Local dev (now)
Single-validator PoA : CometBFT, 1s finality
4 deployable components : chain, gateway, pay, explorer
Full local stack : docker compose up
section Public testnet
HSM/KMS key custody : replace PAY_MNEMONIC
Multi-validator set : remove PoA single-key risk
Public RPC pool : gateway behind TLS + WAF
Faucet service : rate-limited, captcha
Blockscout : replace local with hosted
section Mainnet (not in scope)
Audit of pay/sweep
Audit of chain precompiles
Bug bounty
Validator delegation
Cross-chain bridge (optional)
The gap analysis (local ? public testnet)
| Area | Local dev | Public testnet | Effort |
|---|---|---|---|
| Key custody | PAY_MNEMONIC in env |
HSM or KMS with remote signing | 2–3 weeks |
| Validator set | Single PoA key | 4–7 validators, threshold signatures | 1–2 weeks |
| RPC exposure | localhost:8080 |
Public endpoint behind WAF, per-IP rate limit, DDoS mitigation | 1 week |
| TLS | None | mTLS between pay/* and chain, HTTPS at gateway |
1 week |
| Faucet | Not exposed | Rate-limited HTTP service with captcha | 1 week |
| Blockscout | Local Docker | Hosted (managed or self-hosted) | 1 week |
| Monitoring | Prometheus + Grafana on localhost | Hosted Grafana + alerting (PagerDuty / Opsgenie) | 1 week |
| Backups | None | Nightly Postgres snapshots, off-site, encrypted | 1 week |
| Logging | Docker logs | Centralized (Loki / Datadog / CloudWatch) | 1 week |
| Secrets | .env file |
Managed secret store (AWS Secrets Manager, Vault, etc.) | 1 week |
| CI/CD | None | GitHub Actions for tests, image build, deploy | 2 weeks |
| On-call | None | Pager rotation, runbook review, game days | 1 week |
| Documentation | This site (developer-focused) | Operator + merchant + end-user docs | 2 weeks |
| Testnet token | Reuse local 2BABY | New genesis, fresh distribution | 1 day |
| Bug bounty | None | TBD platform (Immunefi, etc.) | 1 week to set up |
Total estimated effort: 12–16 weeks of one engineer, plus review/audit.
What is explicitly NOT in v1 (or v2)
These are deliberate cuts, not oversights. Each is revisited annually.
- Cross-chain bridge. Bridging requires an audit partner, a separate validator set, and a different threat model. Estimated 6 months of work; not in v1 or v2.
- Stablecoin support. Requires either a centralized issuer (regulatory) or a fully algorithmic design (audit + oracle). Not in v1 or v2.
- Mobile wallet native builds. Expo covers the team''s bandwidth; native iOS/Android would 2x the wallet repo. Revisit when BabyWallet has >10k MAU.
- Multi-validator local. Local multi-validator setups are not representative of a public testnet (different network topology, different latency). We test multi-validator in the staging environment instead.
- Custom mempool / MEV-aware ordering. Not needed for retail payments; revisit if a public testnet is abused.
- Slashing. PoA does not need it; if we move to PoS, this comes back on the table.
- Confidential transactions. Requires a research effort on ZK integration with
cosmos/evm. Not on the 12-month roadmap.
How to propose a change
- Open a GitHub issue with the
proposallabel. - Use the template in
proposals/TEMPLATE.md. - The team triages proposals every two weeks.
- Accepted proposals get a number and move to Locked decisions once implemented.
