Subnets, Deployment, and Roles
This page explains how subnet registration works (MSB-side) and how admin/writer/indexer roles work (subnet-side).
1) Deploying a subnet (MSB registration)
Before contract txs can settle cleanly, the subnet must be registered in MSB.
On a running peer (typically the first node of the subnet), run:
This broadcasts an MSB operation that registers:
subnet channel (ic as a 32-byte identifier)
Peers can still replicate P2P without deploying, but MSB preflight checks and indexing behavior expect the subnet to exist in MSB state.
2) Admin role (subnet governance)
Subnet admin is stored inside the subnet state under:
On the bootstrap node, set the admin once:
/add_admin --address <peer-publicKey-hex>
Transfer admin later:
Verify:
Notes:
--address here is the peer public key hex, not a bech32 MSB address.
3) Writers vs indexers (Autobase roles)
Subnets use Autobase roles:
writers can append subnet operations
indexers participate in the linearization/indexing process
Admin commands:
Get your local writer key from:
4) Auto-add writers
Admins can allow nodes to become writers automatically when they join:
This is subnet-scoped and only affects Autobase writer admission.
5) Transactions enabled switch
Subnets have a transactions gate:
txen (transactions enabled)
Enable:
If disabled, subnet tx indexing and/or RPC tx submission will be blocked.
The built-in chat system is off by default:
Post a message:
Chat is a subnet feature. It does not move TNK; it only writes subnet state.
7) Confirmed vs unconfirmed subnet reads
When you query subnet state:
confirmed=false reads the current local view (unsigned)
confirmed=true reads the subnet’s signed view
These are properties of the subnet log/indexing, not “MSB settlement”.
Last updated
