Scopes and verification tiers
Scopes and verification tiers are the machinery behind and the : the scopes describe what a user has authorised, and the tier describes how hard a verifier has to work to trust that authorisation. A scope is an -format capability string carried on a signed Stamped Mandate. A verification tier is how much work the verifier has to do to trust the resulting credential. The scopes on the mandate drive the tier. A Stamped Mandate is delivered on the wire as aPINT (header x-sumvin-pint-token); the scope and tier vocabulary below is the same whether you read it as a Stamped Mandate or as its underlying PINT.
Two tiers, one rule
| Tier | What the verifier checks | When |
|---|---|---|
| Standard | SIS-issued JWT only — signature, audience, expiry | The mandate carries only Standard-tier scopes |
| Enhanced | JWT plus the original PINT’s EIP-712 signature against the user’s Safe | Any Enhanced-tier scope is present |
What triggers Enhanced
In the MVP catalogue, exactly one scope triggers Enhanced:sr:us:pint:spend:execute. That scope authorises on-chain movement of value on behalf of the user — the tier exists so that a merchant accepting a spend-authorising mandate can verify it without trusting SIS as a single point of failure.
All other scopes (identity attestations, account reads, transaction reads, card reads, Errands, ramp) are Standard.
Why a verifier should care
- Standard is a one-call check. Fetch JWKS once, cache it, verify JWTs locally. No per-request call to Sumvin.
- Enhanced is a two-piece check. You additionally fetch the original PINT payload from
X-Pint-Payload, the signature fromX-Pint-Signature, and verify the EIP-712 hash against the user’s Safe via EIP-1271. The JWT alone is not sufficient for an Enhanced credential.
See also
- Scopes reference — full 14-scope catalogue with tier mapping
- Verification tiers — the verifier-side handbook
- Purchase Intents — what a scope sits on top of