Definition
A scope is created when a developer signs in for the first time. Each subsequent registration — API keys, schemas, circuits, generators, documents, proofs — carries that scope as a foreign key. The dashboard, the workers API, and on-chain hooks all filter by scope before returning data.
Scope is distinct from issuer identity. A single legal entity can run multiple scopes (production / staging / partner-x). Conversely, a single scope can sign documents under multiple issuer DIDs as the operational context shifts.
Resource CRUD isolation is enforced at the workers API layer, not just the UI. A request that authenticates against scope A cannot read or mutate resources under scope B even by constructing a direct API call — the bearer-token check resolves to a scope_id before any route handler runs. The one intentional cross-scope path is attributes.query, a read-only query surface that resolves verified attributes across scopes by design.
Lemma implementation
The scope is the join key on every D1 table. x402 service routes, MCP tool access, and the dashboard's "my-resources" view all narrow by scope_id. The first key minted at sign-in carries the scope; rotating keys never changes the scope.
Scope-level controls — rate limits, billing aggregation — are designed so a developer can move between scopes the way a workspace user switches teams: same identity, different boundary. The boundary bounds resource CRUD; verified-attribute queries are the deliberate cross-scope read path.
For multi-tenant deployments, the scope is also the privacy unit. Selective disclosure and BBS+ presentations are evaluated within a single scope before they cross outward.