ServingRateLimitSet

Event Re-added v101 → v127, v133 → v219, v233 → v247, v252 → v265, v273 → v277, v290 → current #35

Emitted when serving rate limit is changed.

Useful for: minersvalidatorssubnet ownersdevelopersanalytics

The Big Picture

Miners and validators advertise their network endpoints (IP, port) via 'serving info' so others can connect to them. The serving rate limit prevents spam by limiting how often this info can be updated. This is important because each update costs chain resources. A lower limit means neurons can update endpoints more frequently (good for dynamic IPs). A higher limit reduces chain load but means endpoint changes take longer to propagate.

Why This Matters

If you need to change your miner's IP address (server migration, dynamic IP, etc.), the serving rate limit determines how long you must wait between updates. Plan your infrastructure changes around this limit to avoid being stuck with outdated endpoint info.

Example Scenario

Subnet 10 had a 1-hour serving rate limit. The owner wants to reduce chain spam and increases it to 4 hours. ServingRateLimitSet fires. Now if you update your axon endpoint, you can't change it again for 4 hours. If you're migrating servers, you need to get the IP right the first time.

Common Questions

What happens if I try to update before the rate limit expires?: Your transaction will fail. You'll need to wait until the rate limit period passes before your next serve info update is accepted.
Does the rate limit apply to all neurons or per-neuron?: Per-neuron. Each neuron has its own rate limit timer based on when it last updated serving info. Your timer is independent of other neurons.
What's in serving info besides IP and port?: Typically IP address, port, protocol version, and sometimes additional metadata about your axon capabilities. The exact fields depend on the serve_axon call format.

Use Cases

Monitor serving infrastructure update policies
Plan axon endpoint migrations
Track subnet serving configuration changes
Optimize serving info update strategies

How to Use This Event

→ Check rate limit before planning infrastructure changes
→ Monitor changes affecting your update flexibility
→ Track rate limits across subnets for operational planning

From Chain Metadata

setting the prometheus serving rate limit.

Triggers

Preconditions

Caller has admin/sudo privileges
New rate limit is within valid range

Effects

Postconditions

ServingRateLimit updated for subnet
Axon info updates must respect new rate limit

Side Effects

Limits how often neurons can update serving info
Affects axon endpoint update frequency

Event Data

#	Name	Type	Description
0	arg0	u16	Event field #0 (u16)
1	arg1	u64	Event field #1 (u64)

Code Examples

import { ApiPromise, WsProvider } from "@polkadot/api";
import { stringCamelCase } from "@polkadot/util";

const provider = new WsProvider("wss://entrypoint-finney.opentensor.ai:443");
const api = await ApiPromise.create({ provider });

// Subscribe to ServingRateLimitSet events
api.query.system.events((events) => {
  events
    .filter(({ event }) =>
      event.section === stringCamelCase("SubtensorModule") &&
      event.method === "ServingRateLimitSet"
    )
    .forEach(({ event }) => {
      console.log("ServingRateLimitSet:", event.data.toHuman());
    });
});

Version History

Version:

v101 block 1 2 args

v133 block 1,404,224 2 args

v233 block 4,920,350 2 args

v252 block 5,163,656 2 args

v273 block 5,659,032 2 args

v290 block 5,947,548 2 args Current

Runtime Info

View Source

Pallet Index: 7
Event Index: 35
First Version: v101
Current Version: v393

Back to SubtensorModule Events