announce_next_key

Call Re-added v361 → v385, v391 → current Changed in v391 #0

Announces the ML-KEM public key that will become the active encryption key in the following block .

View calls on chain

Click items to navigate. Pan and zoom to explore.

Used by: validators

The Big Picture

MevShield protects users from Miner Extractable Value (MEV) attacks by encrypting transaction contents until after block ordering is finalized. Validators must announce their encryption keys in advance, and this call is how they do it. The key announced now becomes active next block, allowing users to encrypt their transactions with it.

Why This Matters

Without MEV protection, validators can see transaction contents (swaps, stakes, etc.) before including them in a block, allowing front-running or sandwich attacks. By encrypting transactions with a key only the next block author knows, we blind the current block author to transaction details.

Example Scenario

You're a validator and will produce block N+1. At block N, you call announce_next_key with your ML-KEM public key. Users see this key in NextKey storage and encrypt their sensitive transactions with it. In block N+1, you decrypt and execute those transactions. Since you announced the key before seeing the encrypted submissions, you couldn't have selectively ordered them.

Common Questions

What is ML-KEM?
ML-KEM (Module Lattice Key Encapsulation Mechanism) is a post-quantum cryptographic algorithm. Bittensor uses ML-KEM-768 which provides 128-bit security against both classical and quantum attacks.
Why announce keys in advance?
This ensures the block author is committed to a key before they see encrypted transactions. They can't choose a key that only decrypts transactions they want to include.

Use Cases

  • Validators rotate encryption keys for MEV protection
  • Establish trusted encryption for upcoming block
  • Enable commit-reveal scheme for transaction ordering

From Chain Metadata

Rotate the key chain and announce the current author's ML-KEM encapsulation key. Called as an inherent every block. `enc_key` is `None` on node failure, which removes the author from future shielded tx eligibility. Key rotation order (using pre-update AuthorKeys): 1. CurrentKey ← PendingKey 2. PendingKey ← NextKey 3. NextKey ← next-next author's key (user-facing) 4. AuthorKeys[current] ← announced key

Part of: MEV Shield

Input Parameters

#NameTypeDescription
0
enc_key
Option enc_key (Option)

Permissions

Origin
Unknown
Required Role
Any

Permission data inferred from metadata. May be incomplete.

Requirements

  • Caller is the current block author (validator)
  • Public key has valid ML-KEM-768 format and length
  • No key already announced for this block

Effects

Storage Modified

NextKeyKeyHashByBlock

Postconditions

  • NextKey storage updated with new public key
  • Key will become CurrentKey in the next block

Side Effects

  • Previous NextKey (if any) is overwritten
  • Updates KeyHashByBlock for epoch binding

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 });

// Build announce_next_key call
const enc_key = 0 as any /* Option */;

const call = api.tx[stringCamelCase("MevShield")][stringCamelCase("announce_next_key")](
  enc_key
);

On-Chain Activity

Usage Frequency
●●●●○○ Active 100K–1M extrinsics

Significant regular use

#26 most used call

Success Rate Moderate

50–80% of submissions succeed

As of block 7,429,232

Version History

v361 block 7,063,679 1 args
v391 block 7,782,857 1 args Current

Runtime Info

View Source
Pallet Index
30
Call Index
0
First Version
v361
Current Version
v393
Back to MevShield Calls