On-Chain Commitments
DataGeneral-purpose on-chain data storage where accounts commit structured fields with optional time-locks and reveal patterns.
Commitment Lifecycle
On-Chain Commitments
- Account calls set_commitment to publish or update on-chain data
- Account reveals a previously timelocked commitment
Click items to navigate to their reference pages.
The Big Picture
The Commitments pallet is Subtensor's general-purpose on-chain data store. While identity stores "who you are," commitments store "what you publish" — serving endpoints, model versions, configuration flags, or any structured data. The optional timelock feature enables commit-reveal patterns for any data type, not just consensus weights.
Why This Matters
Miners and validators use commitments to publish metadata that other participants need: RPC endpoints, model versions, availability status. Understanding how commitments work helps you read and interpret on-chain data published by network participants.
Example Scenario
A miner calls set_commitment with fields {endpoint: "https://miner.example.com:8091", model: "v2.3.1"}. Validators can read CommitmentOf for this miner to discover the serving endpoint. If the miner wants to pre-commit to a model change, they use a timelock commitment that reveals at a future block.
Common Questions
- How is this different from identity?
- Identity (Registry pallet) stores who you are (name, URL). Commitments store arbitrary data you want to publish (endpoints, configs, hashes). Identity is per-coldkey; commitments can be per any account.
- What is a timelock commitment?
- A commitment where the data is hidden until a specified block number. Before that block, only the commitment hash is visible. After the reveal block, the actual data is published on-chain.
Use Cases
- Publishing miner serving endpoints
- Advertising model versions and capabilities
- Implementing commit-reveal patterns for arbitrary data
- Querying on-chain metadata for network participants
The Commitments pallet provides a generic on-chain key-value store for accounts. Miners and validators use it to publish metadata, configuration, and commitments that other participants can read. Common use cases include publishing serving endpoints, model versions, and commit-reveal data.
Commitments support optional time-locks: a `TimelockCommitment` is stored with a reveal block number, and the data can be revealed later via `CommitmentRevealed`. This enables commit-reveal patterns for any data, not just weights.
Space usage is bounded per account by `MaxSpace` and `UsedSpaceOf`, and a rate limit prevents spamming. Each commitment requires a deposit (InitialDeposit + FieldDeposit per field).
Triggers
- Account calls set_commitment to publish or update on-chain data
- Account reveals a previously timelocked commitment
Inputs (1)
| Item | Type | Role |
|---|---|---|
| set_commitment Commitments | call | Set or update on-chain commitment data |
Outputs (7)
| Item | Type | Role |
|---|---|---|
| Commitment Commitments | event | Emitted when a commitment is set |
| TimelockCommitment Commitments | event | Emitted when a timelocked commitment is created |
| CommitmentRevealed Commitments | event | Emitted when a timelocked commitment is revealed |
| CommitmentOf Commitments | storage | Maps account → commitment fields |
| RevealedCommitments Commitments | storage | Revealed timelocked commitments |
| TimelockedIndex Commitments | storage | Index of timelocked commitments by reveal block |
| UsedSpaceOf Commitments | storage | Space consumed by each account |
Source Files
pallets/commitments/src/lib.rs Formulas
Commitment Deposit
Like identity, commitments require a deposit proportional to the number of fields stored.
deposit = InitialDeposit + (num_fields * FieldDeposit) // Deposit is reserved, returned when commitment is cleared
Space Limit
Each account has a bounded amount of on-chain storage for commitments.
assert UsedSpaceOf[account] + new_data_size <= MaxSpace // Prevents individual accounts from consuming unbounded storage