grandpa_roundState - Bittensor RPC Method

Returns the state of the current GRANDPA finality round on Bittensor when the endpoint exposes validator-round internals. GRANDPA (GHOST-based Recursive ANcestor Deriving Prefix Agreement) is the finality gadget used by many Substrate-based chains to provide deterministic finality, but some public endpoints do not surface grandpa_roundState and instead return a method-not-found style error.

Why Bittensor? Build on the decentralized machine intelligence network built around subnets, TAO staking, and validator-miner coordination with Yuma Consensus, subnet-based specialization, dual Substrate and EVM surfaces, and onchain incentive coordination.

When to Use This Method

grandpa_roundState is not currently exposed on Dwellir's public Bittensor RPC. If you need finality status for production monitoring, use chain_getFinalizedHead for the latest finalized block hash or chain_subscribeFinalizedHeads to stream finalized heads as they arrive.

• Finalized block tracking -- Use chain_getFinalizedHead to snapshot the current finalized head
• Realtime finality updates -- Use chain_subscribeFinalizedHeads when your service needs push-based finalized-head updates
• Operational monitoring -- Prefer finalized-head health checks over validator-round internals on the shared endpoint

Code Examples

Supported Alternatives

• chain_getFinalizedHead for the latest finalized block hash
• chain_subscribeFinalizedHeads for streamed finalized-head updates

Supported Monitoring Patterns

Because Dwellir's public Bittensor endpoint does not expose grandpa_roundState, build finalized-head monitoring around the supported RPCs below.

1. Snapshot the latest finalized head

Use chain_getFinalizedHead when you want the current finalized block hash on demand:

async function getLatestFinalizedHead(api) {
  const finalizedHead = await api.rpc.chain.getFinalizedHead();
  return finalizedHead.toHex();
}

2. Stream finalized heads in real time

Subscribe to finalized-head updates when your service needs push-based finality signals:

async function subscribeFinalizedHeads(api) {
  return api.rpc.chain.subscribeFinalizedHeads((header) => {
    console.log(`Finalized block #${header.number.toString()} (${header.hash.toHex()})`);
  });
}

3. Measure finalized lag against the best block

Compare the latest finalized head with the newest block header to track confirmation lag:

async function getFinalityLag(api) {
  const [finalizedHash, bestHeader] = await Promise.all([
    api.rpc.chain.getFinalizedHead(),
    api.rpc.chain.getHeader(),
  ]);

  const finalizedHeader = await api.rpc.chain.getHeader(finalizedHash);

  return {
    bestBlock: bestHeader.number.toNumber(),
    finalizedBlock: finalizedHeader.number.toNumber(),
    lagBlocks: bestHeader.number.toNumber() - finalizedHeader.number.toNumber(),
  };
}

Understanding GRANDPA Rounds

GRANDPA achieves finality through a two-phase voting protocol:

1. Prevote Phase -- Each authority broadcasts a prevote for the highest block they consider best. Once prevotes reach the thresholdWeight (supermajority), the protocol derives the highest block that is an ancestor of all supermajority prevotes.

2. Precommit Phase -- Authorities that observe a supermajority of prevotes issue precommits for the block derived in the prevote phase. When precommits reach the threshold, that block and all its ancestors are finalized.

3. Authority Sets -- The setId increments each time the authority set changes (e.g., after a session rotation). A new authority set starts a new round sequence from round 1.

Error Handling

Common errors and solutions:

Related Methods

• chain_getFinalizedHead -- Get the hash of the latest finalized block
• chain_subscribeFinalizedHeads -- Subscribe to new finalized block headers
• grandpa_proveFinality -- Get a finality proof for a specific block number
• beefy_getFinalizedHead -- Get the latest BEEFY finalized block (if BEEFY is enabled)
• system_health -- Check overall node health including sync and peer status