Solana Record Service (SRS): what it is and how you might use it

Solana Record Service (SRS) is a Foundation public good program for on-chain namespaced records: you define a class (a namespace / template), then create, update, freeze, transfer, or delete records under it. Docs live at records.solana.com; code at solana-foundation/solana-record-service; TS clients via srs-lib.

This is a short ideas piece — what SRS is for, how it sits next to SNS / .sol, and how a team might actually use it. ~5 minutes.

Click to zoom

The two-account mental model

Docs explicitly call out namespaces for things like social handles and ICANN-style gTLDs — not only Solana-native TLDs. Classes can be permissionless (anyone mints a record) or permissioned (authority gates creation). Freezing a class stops new records; freezing a record stops updates.

Records also support tokenization: mint a Token-2022 representation, transfer it, freeze the tokenized form, or burn it. That turns a name/record into something wallets and markets already understand as an asset, while the record account still holds structured data.

SRS vs SNS (.sol) — don’t mash them

Think of SRS as infrastructure you might build a registrar or identity product on. SNS is one mature naming product in the ecosystem (see SNS / Bonfida history and the resolution deep-dive). Domain-industry players (e.g. D3 / Interstellar-style “on-chain domains” narratives) sit closer to the SRS “bring gTLDs / names on-chain” story than to “only .sol.”

Minimal lifecycle

create_class  →  (optional freeze_class)
create_record →  update_record / freeze_record / transfer_record
              →  mint_tokenized_record → transfer_tokenized_record
              →  delete_record / burn_tokenized_record

Client entry points today: install srs-lib (with Umi / Kit / signers per docs) or Rust solana-record-service-client. Always re-check records.solana.com/docs for current instruction names and program IDs before mainnet work.

Ideas: how someone could use SRS

None of these require SRS to “be DNS.” They need a canonical on-chain map from a human key → owner + blob of data, with clear authority rules.

1. App-specific handle registry

Class handles.myapp, permissioned so only your program or authority can create. Record seed = handle; data = wallet, profile CID, or pointer to a user PDA. Transfer record (or tokenized record) when the user sells the name in-app. Freezing handles stops squatting updates during disputes.

2. ICANN / brand domain mirror

Registrar or brand ops creates a class per TLD or per brand program. Record = domain label; data = resolution targets, expiry aligned to registration period. Tokenized record for secondary trading of the on-chain claim while legal domain status still lives off-chain. SRS does not replace ICANN — it publishes a Solana-readable claim and metadata surface.

3. Org & team directories

Class per DAO or company. Records for treasury, ops, grants mapping to multisigs or Squads. Authority = governance; freezes during incidents. Cheaper than inventing a custom “directory program” for every org.

4. Credential or attestation pointer

Record name = subject id (or hash); data = URI to a verifiable credential or course completion. Expiry field doubles as “valid until.” Not a full VC stack — a discoverable on-chain index others can GPA-query by class.

5. Agent / bot nameplates

Autonomous agents need stable public names. Class agents.example; record data holds MCP endpoint, policy hash, or fee wallet. Tokenized ownership if the agent identity is transferable between operators. Pairs with graph-style agent systems that need a shared registry outside any single chat session.

When not to use it

Builder starter checklist

Resources

• records.solana.com · docs
• GitHub · npm srs-lib
• Context: SNS resolution · SNS / Bonfida history

Bottom line

SRS is a small, sharp public good: classes as namespaces, records as owned named data, with optional Token-2022 wrapping. Use it when you need a portable on-chain directory other programs can trust — handles, domain mirrors, org books, credential pointers, agent nameplates. Skip it when you only need .sol UX (that’s SNS) or a private database. Start with one class and one happy path before you tokenize the world.