write_pulse

Call v216 → current #0

Submits and verifies a Drand randomness pulse to be stored on-chain.

View calls on chain

Click items to navigate. Pan and zoom to explore.

Used by: validatorsdevelopers

The Big Picture

Drand is a distributed randomness beacon run by the League of Entropy. This call bridges Drand's off-chain randomness to Subtensor's on-chain state. Validators (via offchain workers) fetch pulses from Drand and submit them here. The chain cryptographically verifies each pulse against the beacon configuration before accepting it. Once stored, any pallet can consume this randomness for fair, unpredictable outcomes.

Why This Matters

On-chain randomness is hard - block hashes can be manipulated, and validators can withhold blocks. Drand solves this with threshold BLS signatures from a distributed network. This call is how that external randomness enters the chain in a verified, trustless way.

Example Scenario

An offchain worker queries https://api.drand.sh/chain_info and fetches round 12345678. It constructs a PulsesPayload with the round number, randomness, and signature. It calls write_pulse(payload, signature). The chain verifies the BLS signature against BeaconConfig. On success, NewPulse(rounds=[12345678]) fires and Pulses(12345678) becomes queryable.

Common Questions

Who can call write_pulse?
It's typically called from offchain worker context (unsigned). The signature parameter allows for signed submissions if configured. Anyone can submit valid pulses.
What happens if the signature is invalid?
The call fails with UnverifiedPulse or PulseVerificationError. Only cryptographically valid pulses from the configured Drand beacon are accepted.
How often should pulses be submitted?
Drand produces pulses every ~30 seconds. Ideally every block should have recent randomness, but the exact frequency depends on chain configuration and offchain worker setup.

Use Cases

  • Bridge external verifiable randomness to on-chain state
  • Provide unpredictable randomness for subnet operations
  • Enable fair, unbiasable selection mechanisms

From Chain Metadata

Verify and write a pulse from the beacon into the runtime

Part of: Distributed Randomness

Input Parameters

#NameTypeDescription
0
pulses_payload
PulsesPayload pulses_payload (PulsesPayload)
1
signature
Option signature (Option)

Permissions

Origin
Unknown
Required Role
Any

Permission data inferred from metadata. May be incomplete.

Requirements

  • Pulse payload contains valid round number(s)
  • BLS signature verifies against current beacon configuration
  • Round(s) not already stored (no duplicates)
  • Offchain worker context or unsigned transaction allowed

Effects

Events Emitted

NewPulse

Postconditions

  • Pulse(s) stored in Pulses storage keyed by round number
  • LastStoredRound updated if new rounds exceed previous
  • NewPulse event emitted with round numbers

Side Effects

  • Randomness becomes available for on-chain consumption
  • May trigger dependent logic waiting on new randomness

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 write_pulse call
const pulses_payload = 0 as any /* PulsesPayload */;
const signature = 0 as any /* Option */;

const call = api.tx[stringCamelCase("Drand")][stringCamelCase("write_pulse")](
  pulses_payload,
  signature
);

On-Chain Activity

Usage Frequency
●●●●●○ Core 1M–10M extrinsics

Primary protocol calls

#9 most used call

Success Rate Near-certain

Over 95% of submissions succeed

As of block 7,429,232

Runtime Info

View Source
Pallet Index
26
Call Index
0
First Version
v216
Current Version
v393
Back to Drand Calls