TxRateLimitSet

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

Emitted when general transaction rate limit is changed.

Useful for: developersvalidatorsminerswalletsanalyticssubnet owners

The Big Picture

Transaction rate limits prevent any single account from spamming the network with too many transactions in a short time. This protects the chain from denial-of-service attacks and ensures fair access for all users. The limit sets how many blocks must pass between transactions from the same sender. Lower limits allow faster transaction sequences. Higher limits reduce spam but slow down power users who need many transactions.

Why This Matters

If you're running automated systems (validators, miners, trading bots), you need to know how quickly you can submit transactions. The rate limit sets this ceiling. Hitting the limit means your transactions get rejected until the cooldown passes.

Example Scenario

The network had a 1-block rate limit (one transaction per block per account). To reduce spam during high congestion, the admin increases it to 3 blocks. TxRateLimitSet fires. Now you must wait 3 blocks between transactions. Your batch processing script that submitted every block needs to slow down.

Common Questions

Does the rate limit apply to all transaction types?: The general TxRateLimit applies broadly. Some specific operations (like set_weights) may have their own rate limits. Check the specific rate limit for operations you use frequently.
What happens if I exceed the rate limit?: Your transaction is rejected before execution. You don't pay fees for rejected transactions, but you need to wait and resubmit.
Can I check my current rate limit status?: Track your last transaction block and compare to the rate limit. If current_block - last_tx_block >= rate_limit, you can submit. Otherwise, wait.
Is this limit per account or per hotkey?: Typically per signing account (coldkey). Each coldkey has its own rate limit counter. Multiple hotkeys controlled by the same coldkey share the same rate limit.

Use Cases

Monitor network-wide transaction policies
Plan transaction batching strategies
Understand spam prevention mechanisms
Build rate-limit-aware applications

How to Use This Event

→ Monitor rate limit for application design
→ Track changes affecting your transaction patterns
→ Build applications that respect rate limits

From Chain Metadata

setting the transaction rate limit.

Triggers

Preconditions

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

Effects

Postconditions

TxRateLimit updated
Transaction throttling uses new limit

Side Effects

Affects general transaction throttling for all users
May change how quickly you can submit sequential transactions

Event Data

#	Name	Type	Description
0	arg0	u64	Event field #0 (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 TxRateLimitSet events
api.query.system.events((events) => {
  events
    .filter(({ event }) =>
      event.section === stringCamelCase("SubtensorModule") &&
      event.method === "TxRateLimitSet"
    )
    .forEach(({ event }) => {
      console.log("TxRateLimitSet:", event.data.toHuman());
    });
});

Version History

Version:

v101 block 1 1 args

v133 block 1,404,224 1 args

v233 block 4,920,350 1 args

v252 block 5,163,656 1 args

v273 block 5,659,032 1 args

v290 block 5,947,548 1 args Current

Runtime Info

View Source

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

Back to SubtensorModule Events