Extrinsics
Extrinsics are chain actions that ask the Bittensor runtime to process an operation (Subtensor extrinsics, Transaction Fees in Bittensor).
The term belongs to the action side of Subtensor interaction. It is separate from chain reads, which observe public state without asking the runtime to process a state change.
Runtime Action Context
The Subtensor extrinsics reference lists runtime methods exposed as chain actions (Subtensor extrinsics, Inspecting the Chain with Polkadot.js).
A clear extrinsic example should name the requested runtime method before describing whether the request changed chain state, produced events, or failed validation (Subtensor Events).
A method name identifies the action family. Fees, selected network, and surrounding chain context help explain how that action should be read in a particular example (Transaction Fees in Bittensor, Bittensor Networks).
Read and Write Boundary
Transaction-fee documentation separates free chain reads from state-changing actions (Transaction Fees in Bittensor).
That distinction is the main boundary for extrinsics. Reading public chain state observes the network, while an extrinsic asks the runtime to process an action. Storage and inspection references belong to read-focused claims, while the extrinsics reference belongs to action-focused claims (Subtensor Storage, Inspecting the Chain with Polkadot.js, Subtensor extrinsics).
Signing Boundary
An extrinsic still needs the right authority before it can be submitted as a signed action. The BTCLI permissions guide separates actions that require no private key from actions requiring hotkey or coldkey authority, so the extrinsic name alone does not prove which wallet key should sign it (Bittensor CLI: Permissions Guide, Subtensor extrinsics).
For readers, this keeps the action surface separate from custody. Extrinsics describe what the runtime is asked to process, while wallet permissions describe who can authorize that request.
Method Reference Scope
The Subtensor extrinsics reference can identify supported action families, but it is not a complete explanation of every interface, condition, or network context that may affect an action (Subtensor extrinsics, Subtensor Error Codes).
That keeps method names tied to what was requested. Claims about success, failure, emitted records, or resulting state need the relevant event, storage, error, fee, or mechanism source.
Outcome Evidence
An extrinsic names the requested runtime action. The outcome may involve changed storage, emitted records, transaction fees, or a rejection when the runtime does not accept the action (Subtensor Events, Subtensor Storage, Subtensor Error Codes).
Those surfaces answer different questions. The extrinsic identifies the action surface; events, storage, and errors provide surrounding evidence about what happened afterward.
Signer Boundary
Submitting an extrinsic requires signing authority from the relevant wallet context, but the extrinsic term still names the runtime action rather than the key material itself. Wallet documentation explains the coldkey and hotkey roles, while fee documentation explains that state-changing transactions can carry costs (Wallets, Coldkeys and Hotkeys, Transaction Fees in Bittensor).
For readers, that keeps the action and authorization layers separate. The extrinsic describes what is submitted to the runtime; the wallet context explains who can sign for that submission.
Block and Mempool Context
Extrinsics are adjacent to block and mempool vocabulary. The mempool is the pending-transaction area before block inclusion, while a block is the ordered chain unit that can contain accepted transactions (Glossary: Mempool, Glossary: Block).
This boundary keeps timing clear. An extrinsic can name the action being processed, while mempool and block vocabulary describe pending and included chain contexts.
Submission Lifecycle
An extrinsic is easiest to read as one stage in a chain-action lifecycle. It begins as a submitted runtime action, can pass through pending transaction context, and then needs block, event, error, or storage evidence before stronger outcome claims are made (Subtensor extrinsics, Glossary: Mempool, Glossary: Block).
| Stage | What the stage names | Useful neighboring source | | ----------------- | ------------------------------------------------ | ------------------------------ | | Action surface | The method submitted to the runtime | Subtensor extrinsics reference | | Pending context | The transaction waiting before block inclusion | Mempool glossary | | Included context | The transaction recorded in a block | Block glossary | | Runtime record | A named event emitted while processing activity | Subtensor Events | | Rejection context | An error explaining why a call was not accepted | Subtensor Error Codes | | State surface | Public state inspected after processing | Subtensor Storage | | Cost context | Transaction fees attached to state-changing work | Transaction Fees |
This lifecycle keeps the action name from doing too much work. The extrinsic name tells readers what was submitted, while the block or mempool context tells them where the transaction sits in chain timing (Subtensor extrinsics, Glossary: Mempool, Glossary: Block).
Events and errors add runtime evidence. Events are named records emitted by the runtime, while error codes explain rejected or failed runtime paths; both are later evidence around the submitted action, not replacements for the extrinsic surface itself (Subtensor Events, Subtensor Error Codes).
Storage answers a different question again. A storage value can show public chain state after processing, but it is not the submitted action and it is not the pending transaction stage (Subtensor Storage, Subtensor extrinsics).
Fee context also belongs beside, rather than inside, the action name. Transaction-fee documentation describes costs for state-changing work, while the extrinsics reference identifies callable runtime methods (Transaction Fees in Bittensor, Subtensor extrinsics).
For readers, the practical sequence is: name the extrinsic when describing the requested action, name mempool or block context when describing timing, and use events, errors, storage, or fees when describing evidence produced around the action.
The same sequence helps avoid overclaiming success. A submitted extrinsic can identify intent and method, but success language should wait for the runtime evidence that belongs to the selected network and block context (Subtensor Events, Bittensor Networks).
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. Extrinsics are interpreted inside the selected Bittensor network environment where they were submitted (Bittensor Networks).
Localnet extrinsic examples can test action wiring in isolation. Testnet examples add shared non-production chain history. Mainnet extrinsic interpretation concerns production Subtensor records on the active network.
Reader Boundary
Extrinsics do not name an operator guide, interface tutorial, chain-read surface, or proof that an action succeeded (Subtensor extrinsics, Transaction Fees in Bittensor).
Extrinsics identify runtime action vocabulary, while chain reads, storage, events, errors, fees, mempool, blocks, and network context describe neighboring parts of the system.
Calls Originate Outside the Runtime
The Subtensor Pallets and Extrinsics overview explains that runtime modules expose callable functions that execute when the caller has the required permissions. Those calls begin outside the blockchain runtime, which is why Bittensor documentation names them extrinsics rather than internal runtime steps.
When a participant submits one of these calls through a client interface, the request travels to the chain as an extrinsic. The Subtensor runtime then checks permissions and decides whether to accept the action (Subtensor extrinsics).
That outside origin keeps extrinsics distinct from passive observation. Chain reads inspect public state without asking the runtime to process a new action, while an extrinsic names the submitted request itself.
References: Subtensor Pallets and Extrinsics, Glossary: Subtensor
The Extrinsic Catalog Follows Runtime Spec
The Subtensor extrinsics reference is generated from the Subtensor runtime spec rather than maintained as a standalone prose list. Its grouped entries describe the dispatchable action types the connected runtime exposes at generation time.
Runtime upgrades can change that exposed surface by adding, renaming, or retiring action types. Inspection guidance notes that runtime metadata must be refreshed after a Bittensor runtime upgrade so connected tools still describe the live chain accurately (Inspecting the Chain with Polkadot.js).
That generation link separates catalog vocabulary from block history. A listed action type names what the runtime can accept, while an extrinsic observed in a particular block is evidence from that moment in chain history on the connected network.
References: Subtensor extrinsics, Inspecting the Chain with Polkadot.js
Parameters Complete the Submission
The Subtensor Pallets and Extrinsics overview lists both a call method and its arguments for each dispatchable action. Official documentation also directs readers to the generated Subtensor extrinsics reference for the complete parameter specification on the connected runtime.
A method name therefore identifies an action family, but the filled-in arguments select the intended target and amount within that family. Staking, registration, and subnet-scoped actions often need a netuid or account identifier attached before the submission fully describes what was requested.
Without those arguments attached, two submissions can share a method label while requesting different subnet markets or account targets. Parameter fields therefore belong in the same reading step as the action name when precision matters.
References: Subtensor Pallets and Extrinsics, Glossary: Netuid