Capability Trees is a protocol for delegating authority in decentralized systems without access control lists, revocation lists, or central administrators. A delegation chain is a series of signed records, each on its issuer's sovereign storage. Revocation is deletion. Verification is live resolution of each link from its authoritative source.

For this to work, the underlying data substrate has to meet a specific bar. This post names that bar explicitly — not as a description of any particular protocol, but as a target for protocol designers. The more protocols that meet it, the more broadly Capability Trees can be deployed, and the more useful it becomes as shared infrastructure.

The requirements fall into two clusters: sovereignty and verifiability. Sovereignty is about whether control is real. Verifiability is about whether the network can confirm it. Verifiability presupposes sovereignty — there is no point building a verifiable authorization system on top of control that is merely nominal. Sovereignty comes first logically, not just rhetorically.

Sovereignty

Credible exit. A user's control over their data is only as real as their ability to leave a host that violates their trust. If identity and data are locked to a provider, "you control your data" is a courtesy extended by that provider, not a protocol guarantee. Credible exit means the user can migrate their identity and their records to another host — or to self-hosting — without losing continuity. For Capability Trees specifically, it means that no delegation chain breaks merely because a user changed hosts; the chain follows the identity, not the server.

Credible exit is worth having independently of any capability system. It is the answer to the objection that sovereign deletion is only as good as your host's goodwill. A host that refuses to delete a record you want deleted is violating your trust; credible exit is what makes that violation costly to the host rather than to you.

Sovereign deletion with authoritative 404 semantics. The protocol must support deletion that is definitive and attributable. When an issuer deletes a record, the authoritative source for that record must return a 404 — not a tombstone, not a soft-delete marker, not a redirect. A 404 is a statement: this record does not exist here. Combined with live resolution, it is how revocation works in Capability Trees. The issuer deletes their delegation record. The chain breaks immediately, without coordination, without notifying downstream delegatees, without maintaining a revocation list.

The independent value of authoritative deletion is data sovereignty in the literal sense. A system in which you cannot truly delete your own records does not give you control over your data; it gives you control over its visibility, which is a weaker and more fragile thing.

Live, authoritative resolution. The protocol must guarantee that the authoritative source for a record can always be queried, and that its answer supersedes any cached state. The principle is burden of proof: permission must be demonstrable at the authoritative source, not merely recorded in a cache from a prior state. A cached authorization that has since been revoked is an authorization that should no longer exist; a protocol that allows cached results to be treated as permanently sufficient inverts the burden of proof.

This does not mean caching is prohibited. Verifier services may and do use caches for performance — returning a cached result immediately while resolving authoritatively in parallel. The application can choose how much weight to give the cached result before the authoritative answer arrives. What the protocol must guarantee is that a definitive answer is always obtainable, and that an authoritative revocation always reaches the verifier given sufficient time. The cache is a performance layer; the authoritative source is where the burden of proof is settled.

The independent value is the same principle security systems apply broadly. A credential that cannot be promptly revoked is a liability. Live authoritative resolution is how the substrate ensures that permission must be justified at the moment it matters, not just at the moment it was granted.

Verifiability

Cryptographically signed records. Each record must be signed by its issuer, not merely stored by a server the verifier is asked to trust. The distinction matters because verification in Capability Trees is performed by third parties who have no prior relationship with the issuers in a chain. A server-attested record requires trusting the server; a cryptographically signed record requires only the issuer's public key. Signatures make attribution ambient — any party can verify who issued what, independently, without contacting anyone.

The independent value is integrity and non-repudiation. Signed records cannot be silently altered by a host. The issuer's statement is preserved as issued, verifiable by anyone, indefinitely.

Ambient public key infrastructure. Public keys must be resolvable from identity through the protocol itself, without out-of-band exchange. If a verifier must obtain a key through a separate channel before verifying a signature, verification requires a prior relationship with every issuer it might encounter. That is not compatible with open, decentralized delegation chains where issuers are arbitrary. Ambient PKI means that given an issuer's identifier, any verifier can retrieve the corresponding public key through the same protocol used to retrieve records.

The independent value is that it makes cryptographic trust composable. Systems built on ambient PKI can verify claims from parties they have never interacted with, which is the foundation of any open, interoperable trust network.

Individual record addressability. Each record must have its own stable, resolvable URI — not just the store it lives in. A delegation chain is a series of individual links. Each link must be independently resolvable at its authoritative source. If records are only addressable at the container level, a verifier cannot resolve a specific delegation without retrieving and parsing an entire dataset, and cannot distinguish the absence of a specific record from the absence of a response.

The independent value is that it makes records first-class objects on the network. Individual addressability is what allows records to be cited, linked, crawled, and verified in composable ways by systems that were never designed to interact.

The current landscape

These six requirements, taken together, describe a substrate where authority can be delegated without intermediaries, revoked without coordination, and verified without trust in any particular server. Each requirement is justified independently; together they make Capability Trees possible.

As of this writing, ATProto is the only deployed protocol that meets all six. Its PDS architecture provides credible exit and sovereign deletion. Its record model provides cryptographic signing and individual addressability. Its DID-based identity layer provides ambient PKI. Its crawling and verification infrastructure is designed around live resolution from authoritative sources.

This is not an argument that ATProto is the only protocol that could meet the bar, or that Capability Trees is an ATProto-specific system. It is an existence proof: all six requirements are achievable together in a real, deployed protocol. The verification service that Capability Trees specifies is not ATProto-specific either — it is designed around a protocol-agnostic core, resolving each link in a chain via whichever resolver is appropriate for that link's scheme. As more protocols meet the bar, the verifier can be expanded to support them, and delegation chains can span protocols as naturally as they span servers. Protocol designers working on data sovereignty, decentralized identity, or open social infrastructure are encouraged to treat this list as a target. The more substrates that meet it, the more widely Capability Trees — and systems like it — can be deployed as shared infrastructure rather than protocol-specific solutions.