Share the Name, Not the Bits
A CRID gives a resource a stable name derived from its public key. Keep the name when the resource moves, grant access separately, and check the key yourself. It is a new foundation for how people and agents refer to private infrastructure.
Part of the qURL™ 2.0 launch. See the September release notes for shipped capabilities and integration guidance.
A URL is a promise about a location. It says: go here, and the thing you want will be there. DNS and redirects can preserve that location through many changes, but the address is still a reference you must maintain. When it stops being maintained, a runbook, an agent's config, or a partner's integration can point at where the thing used to be.
We just stopped making that promise. Resources protected by qURL now get a CRID — a Cryptographic Resource ID. Sixty lowercase characters that name the resource itself, not the place it happens to be running today.
ae4jqpd7eaoslq7jinmjv4yikgzmcxgpjfsuobiniqnko32lpw743ivbeyha
That's not a link. It doesn't take you anywhere. It's a name — and that's the point.
A URL tells you where to go. A CRID commits to a resource's public key. You can check that relationship yourself.
A name, not a secret
A CRID is derived from the resource's public key: a version byte, a domain-separated SHA-256 hash of the key, and a checksum, base32-encoded into sixty lowercase characters. If that construction sounds familiar, it should — it's the same shape as a Bitcoin address. Version, hash of a key, checksum. A format designed to be pasted into chats, printed on paper, and read over the phone, by people who assume everyone is listening.
So treat it that way. Put a CRID in your docs, your source code, your MCP config, a Slack channel, a support ticket. Holding it grants no access — a CRID is the resource's name. Access still requires authorization. As with any stable identifier, share it only where revealing that resource's identity fits your needs.
And when the resource's owner — or an agent holding the owner's credential — needs access now, the name becomes access in one call: POST /v1/resources/{id}/share takes a CRID and mints a fresh, short-lived qURL access link — the disappearing kind we've always issued. The link is the secret, with its own expiration and access rules. The CRID is the name you keep.
Share the name, not the bits.
It never moves, because it isn't anywhere
A CRID commits to the resource's key, not its coordinates. Redeploy the resource, move it across regions or clouds, put it behind a different domain — the CRID doesn't change, because nothing it's derived from changed. The name in the runbook you wrote today still names the same resource after every migration between now and the day you delete it.
And when you do delete it, the name dies with it. A retired CRID is never re-minted and never points at anything else — nobody inherits your name the way they can inherit your expired domain, your recycled S3 bucket, or your old IP. A CRID has exactly one referent, forever. Dangling references fail closed instead of resolving to whoever moved in after you.
Verified by math, not by a middleman
Here's the property we care about most. When infrastructure delivers a public key for a CRID you hold, you don't have to trust the channel that delivered it — or the platform behind it. Hash the delivered key, compare against the name. Match: it's the committed key. Mismatch: reject. No certificate authority is needed for this name-to-key comparison. A CRID makes key substitution detectable by arithmetic when the client compares the delivered key against a CRID it already trusts. The initial name must come from a trusted source; comparing two values supplied by the same untrusted response would not establish the intended identity.
This is a specific, useful reduction in trust. It does not replace verification of the qURL issuer signature or TLS, and it does not authenticate the application response body. Client implementations must perform the CRID-to-key comparison explicitly; a valid qURL signature alone is a different check.
The checksum, meanwhile, is doing humbler work: it catches typos and truncation before anything touches the network, the way an address checksum stops you from sending funds into the void. It's a convenience, not the security — the hash is the security.
None of this asks you to take our word for it. The full derivation is pinned by public, cross-language conformance vectors — qurl-crid-v1-vectors in layervai/qurl-conformance — so an independent implementation in any language can prove, byte for byte, that it derives and validates CRIDs according to the published format. Every intermediate value is in the fixtures. Check our math; that's what it's for.
Live today
CRID is live now on the qURL API:
- Resource responses carry a
cridfield when available; older records can omit it. - Resource-management routes accept the CRID as the resource identifier. Use the API reference for each route's accepted identifiers.
POST /v1/resources/{id}/shareturns a CRID into a fresh short-lived access link, for the resource's owner.
You can even tell environments apart at a glance: production CRIDs start with a; the names you mint in your sandbox start with q. The name itself says which environment it came from, so a sandbox name can never be mistaken for a production one — not by you, not by a script, not by an agent.
What a CRID is not
A CRID identifies a resource key. It is not access control: minting a qURL still requires an authorized credential. It is not DRM: it cannot control what recipients do with delivered content. It is not a signature from the producer over that content. And it does not remove LayerV's access infrastructure from the path.
What it gives you is a stable name and a way to check the key against that name without asking a third party to certify the relationship. Identity can remain fixed while location and permission change. That is the foundation the rest of qURL 2.0 builds on.
The next step: verify the response
We are working toward using CRIDs as the identity anchor for response-content verification. A client would first check the resource key against its trusted CRID, then verify a producer signature covering the response bytes. That would let the client detect changes to signed content after the producer signed it.
This is future work, not part of the current release. A CRID alone does not provide it, and a valid content signature would establish origin and integrity rather than factual truth. The goal is to extend the same principle from the resource's name to what it returns: verification the recipient can perform.
Take the Next Step
- Read the API reference — the
cridfield, dual-accept addressing, andshare - Install the qURL CLI — publish a resource and share a private link in minutes, free
- Read how qURL works — invisible by default, access that disappears
- Check our math — the public conformance vectors
The location is temporary. The name is forever.