> For the complete documentation index, see [llms.txt](https://docs.trac.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.trac.network/documentation/developers/mainnet/dapp-developer-guide/bootstrap-checklist.md). # Bootstrap checklist ## Bootstrap Checklist (Local Dev) This is the single “canonical” checklist for getting a working local setup: * MSB network running * `trac-peer` connected to that MSB network * subnet deployed and usable * demo tx executed and state query verified It’s written to be copy/paste friendly and to remove ambiguity about “which value goes where”. *** ### Values you need (fill these in) | Name | What it is | Where you get it | | ------------------ | -------------------------------------------------- | ------------------------------------------------------------------------------ | | `MSB_BOOTSTRAP` | 32-byte hex (64 chars) identifying the MSB network | From your MSB node logs/`/stats` (often shown as `msb.writerKey`) | | `MSB_CHANNEL` | discovery string for MSB | From your MSB node logs/config | | `SUBNET_CHANNEL` | discovery string for the subnet/app | you choose (e.g. `my-app-v1`) | | `SUBNET_BOOTSTRAP` | 32-byte hex join-code for the subnet | generated by peer1 and persisted to `stores//subnet-bootstrap.hex` | Recommended defaults: * `SUBNET_CHANNEL=my-app-v1` *** ### 0) Install `trac-peer` ```sh cd trac-peer npm install ``` *** ### 1) MSB: confirm the network parameters On your already-running MSB node: 1. Confirm MSB is running and note: * `MSB_BOOTSTRAP` * `MSB_CHANNEL` 2. Confirm you can fund a new address (you’ll do this for each peer) using MSB CLI (example): ```txt /transfer ``` If you don’t know how to run MSB locally, start with: * `MSB_LOCAL_SETUP.md` *** ### 2) Start peer1 (creates the subnet) Pick store names (so you can run multiple peers on one machine): * `--peer-store-name=peer1` * `--msb-store-name=peer1-msb` Run: ```sh npm run peer:run -- \ --msb-bootstrap="$MSB_BOOTSTRAP" \ --msb-channel="$MSB_CHANNEL" \ --peer-store-name=peer1 \ --msb-store-name=peer1-msb \ --subnet-channel="$SUBNET_CHANNEL" ``` Peer1 prints: * `Peer MSB address: trac1...` ← fund this on MSB * `Peer pubkey (hex): ...` ← used for subnet admin Peer1 also creates (and persists) the subnet bootstrap join-code: * `stores/peer1/subnet-bootstrap.hex` Read it with: ```sh cat stores/peer1/subnet-bootstrap.hex ``` *** ### 3) Fund peer1 on MSB (required for txs) On your MSB funded/admin node, transfer TNK to peer1’s MSB address. If peer1 is not funded, tx submission will fail with errors like: * `Requester address not found in state` * insufficient fee balance *** ### 4) Deploy the subnet (one-time per subnet) In the peer1 terminal: ```txt /deploy_subnet ``` This registers the subnet in MSB (so settlement and MSB preflight checks work). *** ### 5) Become subnet admin (recommended) In peer1: ```txt /add_admin --address ``` Verify: ```txt /get --key admin --confirmed false ``` *** ### 6) Execute a demo contract tx (Tuxemon) The demo app supports: * `catch` In peer1: ```txt /tx --command "catch" ``` Read your tuxedex (unconfirmed is fine for dev): ```txt /get --key app/tuxedex/ --confirmed false ``` *** ### 7) Start peer2 (join the subnet) Get `SUBNET_BOOTSTRAP` from `stores/peer1/subnet-bootstrap.hex` and run: ```sh npm run peer:run -- \ --msb-bootstrap="$MSB_BOOTSTRAP" \ --msb-channel="$MSB_CHANNEL" \ --peer-store-name=peer2 \ --msb-store-name=peer2-msb \ --subnet-channel="$SUBNET_CHANNEL" \ --subnet-bootstrap="$SUBNET_BOOTSTRAP" ``` Fund peer2’s printed `Peer MSB address` on MSB as well. *** ### 8) Writers/indexers (optional for multi-writer subnets) If your subnet is gated (default), peer2 may replicate reads but won’t be allowed to append writes unless admin approves it. On peer2, get its writer key: ```txt /stats ``` On peer1 (admin), add peer2: ```txt /add_writer --key ``` Optionally also add it as an indexer: ```txt /add_indexer --key ``` If you want an open subnet instead: ```txt /set_auto_add_writers --enabled 1 ``` *** ### 9) Enable RPC (wallet/dApp connectivity) Start a peer with HTTP RPC: ```sh npm run peer:run -- \ --msb-bootstrap="$MSB_BOOTSTRAP" \ --msb-channel="$MSB_CHANNEL" \ --peer-store-name=peer-rpc \ --msb-store-name=peer-rpc-msb \ --subnet-channel="$SUBNET_CHANNEL" \ --subnet-bootstrap="$SUBNET_BOOTSTRAP" \ --rpc \ --rpc-host 127.0.0.1 \ --rpc-port 5001 ``` If you want wallets/dApps to be able to submit txs over HTTP, add: ```txt --api-tx-exposed ``` Quick check: ```sh curl -s http://127.0.0.1:5001/v1/health | jq curl -s http://127.0.0.1:5001/v1/contract/schema | jq curl -s http://127.0.0.1:5001/v1/contract/tx/context | jq ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.trac.network/documentation/developers/mainnet/dapp-developer-guide/bootstrap-checklist.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.