The Core Problem

Traditional object capability systems assume a controlled runtime. Possession of an unforgeable reference is sufficient authorization — if you hold it, you can use it. This works in closed systems where the runtime mediates all access.

In an open decentralized protocol like ATProto, this assumption breaks. Anyone can read records, build clients, and attempt to use references. The runtime cannot be trusted to mediate all access.

Modern distributed capability systems — including UCAN — address this with audience restriction: a capability is cryptographically bound to its intended recipient and requires a signature from that recipient at invocation time. Possession alone is insufficient; you must prove you are the intended audience.

Capability Trees extends this model with one additional property that ATProto makes uniquely tractable: sovereign revocation without a revocation list.

The Mechanism

Delegation records on the issuer's PDS. Every capability delegation is a record on the issuer's PDS. As with all ATProto records, signing and attribution are cryptographically enforced by the protocol — this is ambient infrastructure, not something Capability Trees adds.

Audience binding. Each delegation is bound to its intended recipient using ATProto's existing public key infrastructure. Only the intended recipient can accept and exercise a delegation.

Chain requirement. To use a capability, you present the full delegation chain — every signed link from the root to your receipt. Each link is a separate record on its issuer's PDS, resolved live at verification time.

Root record anchoring. Every delegation chain traces back to a root record on the issuing party's PDS. The issuer controls their PDS. Deleting the root record returns a 404 — the chain is broken immediately, without coordination, without a revocation list, without notifying downstream delegatees. Absence of the record is the answer.

Fractal accountability. Each party in the chain is accountable upward to whoever granted them access, and authoritative downward over whoever they delegated to. Governance happens as close to the terrain as possible.

Revocation

This is where ATProto's architecture does real work.

UCAN deliberately leaves revocation underspecified — it is designed to be flexible across many deployment contexts, from local-first apps to single-node resources. That flexibility is a feature for UCAN's general-purpose scope, but it means every implementation must solve revocation independently.

Capability Trees inherits a specific, consistent answer from ATProto's existing deletion semantics. The issuer deletes their delegation record. The PDS returns a 404. The chain is broken. No revocation list. No revocation infrastructure. No coordination required.

The revoker is always in control. The revoked party's cooperation is never required.

Verification

The chain is distributed across records on each issuer's PDS. Verification resolves each link from its authoritative source. Because links can be resolved in parallel, verification latency is bounded by the slowest single PDS in the chain — not by chain depth.

For practical deployment, verification is exposed as a standard ATProto lexicon endpoint. The verification service follows a single protocol: return from cache immediately, then resolve each chain link from its authoritative PDS in parallel, then issue one of three results:

• Green light — all links resolved and valid

• Abort — a link returned a definitive 404; the chain is broken

• Unresolvable — one or more PDSes did not respond

The distinction between abort and unresolvable matters. A 404 is authoritative — the record is definitively gone. A timeout is ambiguous — the delegation may still be valid, the PDS may simply be unreachable. Collapsing these into the same signal would force applications to treat a network hiccup as a revocation. Instead, the protocol surfaces the distinction and applications choose the policy.

Applications choose how to use this:

Wait for green light. The application waits for the authoritative result before proceeding. Revocation is as fresh as the PDS round trips. Maximum security.

Proceed optimistically. The application proceeds on the cached result and waits for any abort before acting irreversibly. Low latency for the common case, with revocation taking effect within the time the application allows for aborts to arrive. An application that never waits for the green light at all gets the weakest guarantees — but that is entirely its own choice, not a failure of the protocol.

Stage and commit. The application stages data updates optimistically on the cached result, holds them staged until the green light arrives, and only commits to the database at that point. This maps naturally onto standard optimistic concurrency patterns — the user sees a fast response immediately, while data integrity waits on the authoritative result in the background. No exotic error handling required. On an unresolvable result, the recommended behavior is to bounce the operation and tell the user why — the user knows it's a temporary infrastructure issue, not a rejection, and can retry when the PDS is reachable again.

Applications choose how to use this:

Wait for green light. The application waits for the authoritative result before proceeding. Revocation is as fresh as the PDS round trips. Maximum security.

Proceed optimistically. The application proceeds on the cached result and waits for any abort before acting irreversibly. Low latency for the common case, with revocation taking effect within the time the application allows for aborts to arrive. An application that never waits for the green light at all gets the weakest guarantees — but that is entirely its own choice, not a failure of the protocol.

Stage and commit. The application stages data updates optimistically on the cached result, holds them staged until the green light arrives, and only commits to the database at that point. This maps naturally onto standard optimistic concurrency patterns — the user sees a fast response immediately, while data integrity waits on the authoritative result in the background. No exotic error handling required.

The verification service is the same in all cases. The security and latency tradeoff is pushed to the application layer, where it belongs.

Offline verification. The verification service can also issue a verified snapshot — a locally-cacheable bundle of the signed delegation records, verified at the point of request. Applications store the snapshot and verify against it offline: check signatures, check audience binding, walk the chain. No network calls required. The same tradeoff applies as in any offline capability system: the snapshot cannot reflect revocations that happened after it was taken. Pairing snapshots with expiry bounds the staleness window and is the recommended practice.

Why ATProto

ATProto already provides everything this system is built from: signed records, public keys in DID documents, PDS sovereignty and deletion, AppView crawling and validation, record addressing. The additional implementation surface is a capability record lexicon and a verification service.

Because Capability Trees is ATProto-native and the verification protocol is consistent across all deployments, the verifier can be written once and shared by every project that uses it. Each project that would otherwise solve verification independently can just use the shared verifier instead. This fits naturally into the same pattern as other shared ATProto infrastructure — PDS implementations, AppViews, lexicon tooling.

The right kind of complexity: each piece is there because the terrain demands it.

Properties

• No ACLs at any layer

• No revocation lists

• No central administrator

• No coordination required for revocation

• Revocation effective within a single network round trip to the issuer's PDS

• Verification latency bounded by slowest PDS, not chain depth

• Offline verification via snapshots, with the same tradeoffs as any offline capability system

• Verifier written once, shared by every project — the ecosystem absorbs the implementation cost once

• Delegation trees fully legible and auditable

• Fractal accountability: authority flows downward, accountability flows upward