# next-epoch-start-block (/docs/query/next-epoch-start-block)

Chain-computed: `LastEpochBlock + tempo`, pulled earlier by any pending
owner-triggered epoch. This is the source of truth — the epoch schedule is
stateful, so the legacy client-side modular formula is wrong on subnets
whose tempo changed or whose owner triggered an epoch.

**Category:** Epochs & timing

## Parameters [#parameters]

| Parameter | Type    | Description      |
| --------- | ------- | ---------------- |
| `netuid`  | integer | Subnet to query. |

## CLI [#cli]

```bash
btcli query next-epoch-start-block --netuid <integer> --json
```

## Python [#python]

Namespace method (autocomplete, signature help):

```python
import bittensor as bt

sub = bt.Subtensor()
result = sub.epochs.next_epoch_start_block(netuid=1)
```

Or dispatch by name, as an agent would:

```python
result = sub.read("next_epoch_start_block", netuid=1)
```

Async is the same surface awaited: `async with bt.Subtensor() as client:`.

## On-chain implementation [#on-chain-implementation]

* Runtime API [`SubnetInfoRuntimeApi.get_next_epoch_start_block`](/code/pallets/subtensor/src/coinbase/run_coinbase.rs#L1183-L1197)

Every file is browsable under [/code](/code) exactly as built into the runtime.