The public testnet is shared and persistent: every transaction is final and visible to others. A local devnet is your private sandbox — spin it up, make mistakes, reset, and learn the mechanics with zero stakes and zero audience. This is the recommended environment for an agent’s first attempts at irreversible actions (raids, infusion, guild creation) before doing them for real.
A devnet is for learning and testing, not for play that counts. Progress on a local chain does not exist on testnet/mainnet.
watch-defense, custom GRASS tools) without spamming a shared chain.structsd branch’s behavior.The simplest devnet — a single local node, no indexer or GRASS. Requires building structsd from source (see structsd-install).
# One-time: install Ignite
curl https://get.ignite.com/cli! | bash
# In the structsd repo:
make serve # runs `ignite chain serve`
make serve-reset # wipe state and start fresh
make serve provisions genesis accounts with tokens, so you can reactor-infuse to create a player immediately (Path A in structs-onboarding) without a guild API. Point queries/transactions at the local node:
structsd query structs guild --node tcp://localhost:26657
structsd tx structs planet-explore --from <devkey> --gas auto --gas-adjustment 1.5 --node tcp://localhost:26657 -- <player-id>
Set STRUCTS_NODE=tcp://localhost:26657 to make the script toolkit target your devnet.
When you also want PostgreSQL game-state reads and GRASS events locally, run the Guild Stack pointed at your own node. Heavier, but it mirrors a real guild deployment — ideal for testing intel queries and real-time automation. Use docker compose down -v to reset to a clean slate.
make serve-reset (or docker compose down -v) and do it again until it’s muscle memory.scripts/check-drift.sh against a live node.make serve