Framing

UCAN is a general-purpose distributed capability system designed to work across a wide range of deployment contexts — local-first apps, p2p networks, federated services, and single-node resources. Its flexibility is intentional and valuable.

Capability Trees is not a general-purpose system. It is ATProto-native, deliberately scoped to that context, and takes advantage of properties ATProto provides that UCAN cannot assume. The comparison is therefore not "which is better" but "what does ATProto's substrate make possible that wasn't possible before."

There is also something worth noting about the design space. UCAN has evolved significantly since its early versions — moving from bundled token chains to CID references, adding audience restriction to prevent unauthorized use of intercepted tokens, and developing a revocation sub-specification. These are the right moves, driven by real pressures. Capability Trees arrives at similar conclusions by a different path: rather than engineering solutions to these pressures, it inherits answers to them from ATProto's existing architecture. The convergence is not coincidental. The design space has gravity.

1. Revocation

UCAN's approach: Revocation is deliberately underspecified in the core spec, with a separate revocation sub-specification still in development. The flexibility is intentional — UCAN is designed to work in contexts ranging from fully distributed p2p systems to single-node services, and revocation looks different in each. In practice, implementations must solve this independently: sending revocation objects to relevant services, gossiping through peer networks, or maintaining local revocation stores indexed by CID.

Capability Trees: The issuer deletes their delegation record on their PDS. The PDS returns a 404. The chain is broken.

ATProto's deletion semantics are universal and consistent across the protocol. A verifier can query the issuer's PDS directly — revocation is then as fresh as a single network round trip. No revocation infrastructure is required beyond what ATProto already provides.

The tradeoff: Capability Trees' revocation story is specific and consistent, but only works within ATProto. UCAN's approach works anywhere, at the cost of each deployment solving revocation independently.

2. Verification Latency

UCAN's approach: Self-contained tokens can be verified offline or with a single round trip to a caching service. This is a genuine advantage for latency-sensitive applications and offline contexts.

Capability Trees: Verification follows a single protocol: return from cache immediately, resolve each chain link from its authoritative PDS in parallel, then issue one of three results — green light, abort, or unresolvable. A green light means all links resolved and valid. An abort means a link returned a definitive 404. Unresolvable means one or more PDSes didn't respond — ambiguous, and kept distinct from abort so applications aren't forced to treat a network hiccup as a revocation.

Applications choose how to use this: wait for the green light for maximum security; proceed optimistically and handle any abort before acting irreversibly; or stage writes on the cached result and commit only on the green light, which maps naturally onto standard optimistic concurrency patterns. On an unresolvable result under stage and commit, 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.

The verification service also supports offline use: applications can request a verified snapshot — a locally-cacheable bundle of signed delegation records, verified at the point of request. Offline verification then works the same way as UCAN's: check signatures, check audience binding, walk the chain, no network calls required. The same tradeoff applies: the snapshot cannot reflect revocations that happened after it was taken. Pairing snapshots with expiry is the recommended practice.

Verification latency in the authoritative case is bounded by the slowest single PDS in the chain, not by chain depth. For applications built on ATProto, the firehose dependency for cache invalidation is not a new liability — it is already a fundamental part of how the protocol propagates updates.

The tradeoff: UCAN's offline verification is available out of the box; Capability Trees' is provided by the verification service on request. Within ATProto, Capability Trees offers comparable latency in the optimistic case, always-authoritative verification when the application waits for the green light, offline verification via snapshots, and a richer result protocol that gives applications precise information to make their own security/availability tradeoffs.

3. Implementation Complexity

UCAN's approach: The core spec is at version 1.0.0-rc.1, with revocation, invocation, delegation, and promise as separate sub-specifications. Implementing the full system requires building outside existing infrastructure. The spec has been through significant evolution and implementations have had to track those changes. Because UCAN's flexibility requires each deployment to adapt revocation, transport, and verification to its own context, every project tends to solve similar problems independently.

Capability Trees: Builds on ATProto's existing signed records, DID document public keys, PDS sovereignty and deletion, and AppView infrastructure. The additional surface is a capability record lexicon and a verification service. Crucially, 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 — fitting naturally into the same pattern as other shared ATProto infrastructure like PDS implementations and AppViews.

The tradeoff: Capability Trees has lower implementation complexity within ATProto because it builds on existing primitives and enables a shared verifier — the ATProto ecosystem absorbs the implementation cost once, rather than every project absorbing it independently. Outside ATProto, UCAN is the right choice — Capability Trees has no story there.

Summary

UCAN solved hard problems without an existing substrate to build on, and has been refined significantly over time. Capability Trees builds on ATProto's existing primitives and inherits answers to problems UCAN had to engineer around — particularly revocation. The result is not a better general-purpose capability system, but a better ATProto-native one.

For anyone building on ATProto and evaluating UCANs: the question is not which system is superior, but whether ATProto's architecture makes a native capability system tractable enough to be worth building. This proposal argues it does.