Publishing and resolution
How community.lexicon.* NSIDs resolve: DNS to DID to schema record. Plus how to verify the chain and pin an offline copy your SDK can trust.

This guide is for developers who want to understand how community.lexicon.* schemas are published and resolved on the AT Protocol network, and how to verify or harden that resolution in their own libraries, applications, and services.
How resolution works
AT Protocol lexicon resolution turns an NSID into a schema document in three steps. Taking community.lexicon.calendar.event as the example:
DNS names the authority. The NSID's domain segments reverse into an authority domain (
community.lexicon.calendar→calendar.lexicon.community), and a TXT record at_lexicon.that domain names the DID that publishes the schema:$ dig +short TXT _lexicon.calendar.lexicon.community "did=did:plc:mtr7qrqtcyseedx3jyr5o7db"The DID locates a repository. That DID (
@lexicons.lexicon.community) resolves to a DID document naming its personal data server, like any AT Protocol identity.The repository holds the schema. The schema is a
com.atproto.lexicon.schemarecord whose record key is the full NSID:at://did:plc:mtr7qrqtcyseedx3jyr5o7db/com.atproto.lexicon.schema/community.lexicon.calendar.event
What Lexicon Community publishes
The @lexicons.lexicon.community identity is a dedicated, lexicon-only repository: it holds exactly the published schema records and nothing else; it never posts and never will. Every _lexicon.<namespace> record under lexicon.community points at it. The human-editable source of truth remains the lexicons repository; records are published from it when changes merge.
Verifying resolution
Three independent ways to check any community.lexicon.* NSID:
DNS:
dig +short TXT _lexicon.<namespace>.lexicon.community; expectdid=did:plc:mtr7qrqtcyseedx3jyr5o7db.Direct fetch:
com.atproto.repo.getRecordagainst the identity's PDS withcollection=com.atproto.lexicon.schemaandrkey=<NSID>.A resolver: tools like Lexicon Garden or
goat lex resolveperform the full DNS→DID→record walk for you.
Offline verification and hardening
SDK and service developers who don't want a runtime dependency on live resolution can fetch the entire published schema set in one unauthenticated request: the repository exports as a CAR file (a content-addressed archive containing the repository's Merkle Search Tree):
GET https://eurosky.social/xrpc/com.atproto.sync.getRepo?did=did:plc:mtr7qrqtcyseedx3jyr5o7dbThe CAR carries a signed commit over the tree, so an embedded copy is verifiable offline: import the CAR, verify the commit signature against the DID document's signing key, walk the MST, and extract the com.atproto.lexicon.schema records. Pin a copy in your test fixtures, regenerate types from it, or ship it with an application that must work without network access. Refresh it on your own schedule.
To make the verification chain complete, also download the PLC directory audit log for the identity:
GET https://plc.directory/did:plc:mtr7qrqtcyseedx3jyr5o7db/log/auditThe audit log is the identity's full operation chain, and it is self-verifying: each operation is hash-linked to the previous one and signed by a rotation key the earlier operations authorized, so you can validate the chain offline and derive the DID document, including the signing key, without trusting a live directory response. Pin the audit log alongside the CAR and you have a fully self-contained bundle: the log proves the key, and the key proves the CAR.
Questions
If resolution misbehaves or the docs here don't match what you observe, say so on the forum: a resolution bug is exactly the kind of report the community wants fast.