1. Revocation

UCAN's struggle: Revocation requires a centralized revocation list that every verifier must check. This reintroduces a centralized dependency into a decentralized system. If the revocation list is unavailable, revocation fails. Worse, offline verification succeeds even for revoked capabilities because the self-contained token can't be checked against an unavailable list. UCAN fails dangerously when offline.

Capability Chains: Alice deletes her root record. The chain is broken instantly, without coordination, without a list, without Bob's cooperation or even his awareness. The next verification attempt hits a 404. Bob being offline is irrelevant to Alice's ability to revoke. If the AppView can't reach Alice's PDS, verification fails safely rather than succeeding dangerously. Revocation is sovereign, immediate, and offline-compatible from the revoker's side.

2. Capability Leakage

UCAN's struggle: Possession is sufficient authorization. If Bob leaks a raw capability token to Carol, Carol can use it. UCAN has no cryptographic mechanism to prevent this — it relies on social convention and trust. The capability is unforgeable in the sense that it can't be fabricated, but it can be freely transferred to unintended recipients.

Capability Chains: Alice encrypts Bob's capability with Bob's public key. Only Bob can decrypt it. Carol receiving the raw ciphertext gains nothing — she can't decrypt it. If Bob decrypts and leaks the plaintext reference, Carol still can't use it because she can't produce a valid delegation chain showing legitimate receipt. Leakage is cryptographically prevented at two layers — encryption prevents reading, chain requirement prevents use.

3. Chain Bloat

UCAN's struggle: The entire delegation chain is bundled into a single growing token. Every delegation adds another layer. A ten-link chain is a large token. A deeply nested delegation tree produces tokens that are expensive to pass around, store, and verify. The size scales with depth because the token must be self-contained for offline verification.

Capability Chains: The chain is distributed across records on PDSes. Each link is a separate record. The terminal reference you present doesn't grow with chain depth — you always present the same size reference regardless of how many delegations preceded it. The AppView walks the chain by resolving records. The size of what you carry is constant. Chains are also independently inspectable at every link — anyone can verify any specific delegation without seeing the whole chain.

4. Offline Revocation

UCAN's struggle: Revocation requires the revoked party to check a list they may not be able to reach. If Bob is offline he can't check the revocation list. If Alice's revocation service is offline, nobody can check it. Revocation is only effective when both parties and the revocation infrastructure are online simultaneously.

Capability Chains: Alice deletes her root record unilaterally. Bob's online status is irrelevant. The deletion is effective immediately on Alice's PDS. The next time anyone tries to verify a chain including Alice's deleted root, they get a 404 regardless of Bob's status. The revoker is always in control. The revoked party's cooperation is never required.

5. Implementation Complexity

UCAN's struggle: UCAN requires implementing a custom token format, custom chain bundling, custom verification algorithm, custom revocation infrastructure, and compatibility across heterogeneous clients. The spec has evolved multiple times. Implementations have had compatibility issues. The complexity exists largely outside any existing infrastructure, requiring everything to be built and maintained from scratch.

Capability Chains: ATProto already provides signed records, public keys in DID documents, PDS sovereignty and deletion, AppView crawling and validation, and record addressing. The additional implementation surface is minimal — encrypted payloads addressed to recipient public keys, chain requirement in AppView validation logic, and a capability record lexicon. The right kind of complexity: each piece is there because the terrain demands it, not because the design painted itself into a corner. Every improvement ATProto makes benefits Capability Chains automatically.

Summary

UCAN solved hard problems in a context without existing infrastructure to build on. Capability Chains solves the same problems and several UCAN couldn't solve, by building on ATProto's existing primitives rather than alongside them. The result is more secure, more decentralized, easier to implement, and better suited to the open protocol environment where runtime control cannot be assumed.

The right kind of complexity, doing the right kind of work.