The Big Picture
IdentityOf is how accounts become 'known entities' in the Bittensor ecosystem. Rather than anonymous addresses, registered identities have display names, websites, and contact info. This is essential for validator discovery - delegators can research who they're trusting with their TAO. The data includes standard fields (display name, legal name, web, email, Twitter) plus custom additional fields.
Why This Matters
Would you stake 1000 TAO to '5GrwvaEF5zX...'? Probably not without knowing who it is. IdentityOf answers that question. Validators who register identities are more trustworthy because they're willing to be publicly known and accountable.
Example Scenario
You're building a validator ranking dashboard. Query IdentityOf for each validator address. Those with identities get their display name shown ('Bittensor Labs'). Those without show a truncated address. You might also filter to only show validators with registered identities.
Common Questions
- What fields are in the identity?
- Standard fields include: display, legal, web, riot, email, twitter, image. Plus additional custom fields (limited by MaxAdditionalFields constant).
- Does having an identity mean they're verified?
- No, identity registration is self-reported. The chain doesn't verify the information. Verification (if any) happens off-chain through community reputation or external services.
- What happens if an account has no identity?
- The query returns None/empty. The account works normally but has no public metadata. Display just the address or mark as 'Unknown Validator'.
- Is there a cost to register?
- Yes, a deposit is required (InitialDeposit + FieldDeposit per additional field). This prevents spam and is returned when the identity is cleared.
Use Cases
- Display validator names instead of hex addresses
- Build validator discovery and directory tools
- Verify identity before delegating to a validator
- Show contact information for subnet owners
- Build reputation systems based on identity data
From Chain Metadata
Identity data by account
Purpose & Usage
Purpose
Store human-readable identity information for accounts (display name, contact, etc.).
Common Query Patterns
- Query by account address to get their registered identity
- Iterate all to build a directory of registered identities
- Check existence before allowing identity-dependent operations
Query Keys
| # | Name | Type | Description |
|---|---|---|---|
| 1 | key1 | AccountId | key1 (AccountId) (hex -> SS58) |
Stored Value
value (Registration)
Relationships
Modified By
Related Events
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 });
// Query IdentityOf storage
const key1 = "5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY";
const result = await api.query
[stringCamelCase("Registry")]
[stringCamelCase("IdentityOf")](
key1
);
console.log("IdentityOf:", result.toHuman());Runtime Info
View Source- Pallet
- Registry
- Storage Kind
- Map
- First Version
- v136
- Current Version
- v393