Spike: Reconcile STELLAR_NETWORK naming ('MAINNET' vs Stellar's 'PUBLIC') across config and docs

[meshackyaro]

Description

STELLAR_CONFIG.networkPassphrase (src/stellar/stellar.config.ts) is computed as process.env.STELLAR_NETWORK === 'MAINNET' ? 'Public Global Stellar Network ; September 2015' : 'Test SDF Network ; September 2015' — but Stellar's own SDK/tooling and most Stellar documentation refer to the production network as PUBLIC, not MAINNET (e.g. Networks.PUBLIC/Networks.TESTNET constants in @stellar/stellar-sdk). .env.example sets STELLAR_NETWORK=TESTNET, giving no signal either way about which literal value is expected for production. If an operator deploying to mainnet reasonably sets STELLAR_NETWORK=PUBLIC (matching Stellar's own convention) instead of the app's undocumented expectation of MAINNET, networkPassphrase silently resolves to the testnet passphrase while every other config value (Horizon URL, RPC URL, contract ID) points at mainnet infrastructure — a subtle, dangerous misconfiguration with no validation to catch it.

Component

Backend

Difficulty

Spike

Tasks

• Decide on the canonical accepted value(s) for production (MAINNET, PUBLIC, or both accepted as aliases) and align STELLAR_CONFIG, .env.example, and any deployment docs
• Add explicit validation that rejects an unrecognized STELLAR_NETWORK value instead of silently falling through to the testnet passphrase
• Cross-check @stellar/stellar-sdk's own Networks enum for the exact expected literal(s) rather than inventing new ones

Acceptance Criteria

• A single, documented, validated value (or explicit alias set) is required for STELLAR_NETWORK, and an unrecognized value fails fast rather than silently defaulting to the testnet passphrase
• .env.example and any deployment documentation reflect the agreed convention

Estimated Time

1 day