Limits

Every bound the protocol enforces, what enforces it, and what happens on the far side of it. A limit here is one of three kinds:

• Refusal. The request is rejected and the client must change what it sends. These are wire-contract bounds against hostile or runaway input.
• Pagination. The work continues on the next request or the next sync pass; nothing is refused.
• Lazy remainder. The bound is deliberately not a refusal, because refusing would block a revocation or brick a device. The remainder is left for a later writer, and a client that meets it parks rather than fails.

The third kind is the only one that trades write liveness for something else, and the last section names each such trade. For shared terminology, see glossary.md.

Values are quoted from the constants named in each table; the constant is the source of truth and the tables are a map to it.

Container hierarchy

Each cited reference is a stored manifest the API re-verifies, so the history bound is also a CPU bound. A verification marker (access_manifests.verification_mac) reduces a marked manifest to one HMAC over its stored bytes. On PGlite a reference costs about 90 µs with a marker and 2 ms without: at the bound, roughly 0.4 s, or 8 s after a rotated secret or rule revision drops the markers. That pass records markers for later requests.

Create and move preserve the reader’s structural bound. Policy rotations and revocations do not change structure and do not run these depth guards. The bounded container depth model checks the create and move guards. Readers also refuse malformed paths; the ancestor CTE accepts at most 100 containers and rejects an unclosed parent at the boundary rather than silently truncating it. A queued create whose local path is already too deep waits without a request until a local move re-arms it; one a stale local view lets through keeps retrying like other permanent server refusals.

Container keying

Lifetime container and document manifest history has no depth refusal. The API verifies retained dependencies iteratively, including ancestor lineage, and marks each accepted manifest in its row’s access_manifests.verification_mac, which loads with the row, so checking a marker costs no query of its own. A container mutation marks the manifest it stores, with any unmarked history it depends on, under its organization lock; a document mutation marks only its document’s history. A container or document projection read that verified unmarked history writes those markers back after its transaction commits, one autocommit update per marker; every read path also keeps the markers it computed in a bounded per-process cache, so no path re-verifies a history on each request. A marker’s MAC, keyed from the server-held DOCUMENT_SYNC_CURSOR_HMAC_KEY (or a per-process key when none is configured), binds the manifest hash, a digest of that manifest’s complete stored bundle, its signer’s stored public key, and the crypto and API rule revisions. Verification stops at the first valid marker, so each manifest is signature-checked about once in its lifetime. A row whose bytes changed, a changed signer key or a forged marker makes that manifest verify in full wherever the server verifies it; a rotated secret or new rule revision re-verifies each object’s history once, on its next projection read or mutation. Serving a writer projection still loads every retained manifest its key history cites, in a few batched queries, and carries each distinct manifest bundle once however many paths and histories cite it. A request may cite at most 48 manifests whose verified bundles the device holds (x-known-manifests); their bytes are then omitted, and the device keeps at most 1,024 such bundles. Neither bound limits the history a reader receives; see the incremental evidence contract. For N ancestor manifests, the request-local lineage index uses O(N log N) work and space, with O(log N) per lineage query; see the availability model.

The sealed keyring is 64 bytes per retained epoch and is never truncated, so at the epoch cap it is about 4 MB; that is why the KEK log serves at most one historical keyring per request. See keying-design.md for the cost model and protocol-specification.md for the exact-length rule.

Document sync

Database connections

Hyperdrive holds origin connections across requests; Worker sockets remain request-scoped. POSTGRES_POOL_MAX_USES=1 only retires clients in the fallback pool used by Durable Object timers. Request pools reuse clients until the request ends. The migration login connects directly from the deploy host and is never bound to the Worker. The Worker carries an aws:us-east-1 placement hint.

Blobs

Realtime

Principals

Cold verification still grows with total signed history, across resumable requests. Preparation runs outside the final mutation transaction; each final commit rechecks current authorization and exact heads. The HTTP acceptance evidence exercises revocation and cold historical decryption through version 16,385 with a 15-second deadline per response, on SQLite and networked PostgreSQL. Those fixed-cardinality tests do not bound arbitrary policy size or aggregate load across API replicas.

Limits that trade write liveness

The no-bricked-device invariant says no device may be unable to read or write because another device must write first. Reads are never affected by any limit above: a reader resolves a retired parent pin through retained history. The following exceptions can leave a writer waiting on another authorized member:

• Carried descendant rekeys past 64. Levels beyond the parent-first prefix stay stale after the rotation commits. A writer granted only below such a level cannot re-key it and must not be handed its key, so it parks under document_ancestor_repair_inaccessible until a member with access at that level writes there.
• Documents linked across access boundaries. A writer through one link cannot always repair a stale content-key bundle after another link rotates. Repair needs every target’s current wrapping key and may require write access at a stale level. The writer waits under document_ancestor_repair_inaccessible for an authorized member to repair it; if no remaining member spans the required targets, writes stay blocked. The trade avoids exposing inaccessible folders’ grant lists. Ordinary writes need only one writable link while the bundle is current.

For the single-path case within the carried-rekey bound, the model in InaccessibleIntermediateRepair.md proves the writer is eventually unblocked with fairness only on its own step. Outside it, that model’s rotation-without-descendant-repairs-bricks-leaf-writer control is the exact behaviour, and it violates the liveness property by design. Nothing schedules the lazy repair; whichever capable member writes beneath the stale level first performs it. See NoBrickedDevice.md for the invariant and client-sdk.md for how the SDK reports the parked state.