bootnode/charts/hanzo/PROVISIONING.md

Hanzo sovereign-L1 — provisioning

Deploy target: DOKS hanzo-k8s, via platform.hanzo.ai / the hanzo operator (GitOps). Namespaces hanzo-{mainnet,testnet,devnet}. Exposure: LoadBalancer → rpc.hanzo.network / explorer.hanzo.network.

This chart deploys Hanzo's own sovereign primary network — networkID == EVM chainID (mainnet 36963 / testnet 36962 / devnet 36964). Hanzo does not run on the Lux C-Chain (96369); that is Lux-network only. The C-Chain genesis embedded in genesis/<env>.json activates the 0x0300 AI-mining precompile at genesis (aiMiningConfig: {blockTimestamp: 0}) — this is what makes desktop AI-mining verifyAndMintWork claims settle on-chain.

What's in the chart (committed, safe)

• Chart.yaml, values.yaml + values-<env>.yaml — networkID=chainID, custom-network upgradeConfig (REQUIRED — 36963/62/64 have no built-in upgrade schedule), branding.
• genesis/<env>.json — platform genesis: networkID + the Hanzo C-Chain genesis (chainId + aiMiningConfig) embedded as cChainGenesis.
• templates/ — reused from the lux chart (parameterized by .Values).

What the operator MUST provision (from KMS — NEVER commit keys)

1. Validator staking keys → create the hanzo-staking Secret (per values.yaml staking.secretName) from KMS-generated keys, then populate, in genesis/<env>.json:
   • initialStakers[] — each {nodeID, rewardAddress, delegationFee, signer:{publicKey, proofOfPossession}} (PUBLIC keys only).
   • initialStakedFunds[] — the staked P-chain addresses. And set bootstrap.nodeIDs (in values-<env>.yaml) to the same NodeIDs.
2. Treasury / allocations → allocations[] in genesis/<env>.json (P-chain luxAddr
   • C-chain ethAddr funded addresses; KMS treasury). The C-Chain genesis already pre-funds the dev treasury 0x9011E888251AB053B7bD1cdB598Db4f9DEd94714.
3. Derived C-Chain blockchain ID (computed at CreateChainTx time, only known after the network is created) →
   • networks.<env>.cChainID in values.yaml.
   • templates/statefulset.yaml plugin-copy lines still carry the lux C-Chain blockchain ID (mgj786NP7uDwBCcq6YwThhaN8FLyybkCa4zBWTQbNgmK6k9A6). Replace with Hanzo's derived C-Chain plugin/blockchain ID, or parameterize via a new .Values.cChainPluginID before the second deploy.

Bring-up order

1. Operator generates validator keys (KMS) → hanzo-staking Secret + fills genesis initialStakers/allocations + bootstrap.nodeIDs.
2. helm upgrade --install hanzo ./charts/hanzo -f values-mainnet.yaml -n hanzo-mainnet (via platform.hanzo.ai GitOps, not helm by hand).
3. After first genesis, capture the C-Chain blockchain ID → set cChainID + the statefulset plugin ID → redeploy.
4. Point rpc.hanzo.network / explorer.hanzo.network LoadBalancers; verify eth_chainId == 0x9063 (36963), validators healthy, 0x0300 responds.

Why not a one-command deploy here

Validator BLS keys and the derived blockchain ID are network-creation outputs that live in KMS / are computed by the node at genesis — they are intentionally not in git. The desktop side (chainId 36963, the Rust claim signer, the C-Chain genesis) is already committed; this chart + the operator's KMS provisioning complete the loop.