SRI-format scope catalog for Stamped Mandates (PINTs)
Scopes declare what a authorises. Each scope is an -format capability string carried in the signed PurchaseIntent.scopes array and surfaced to partner integrations as the scopes claim on the exchanged .A Stamped Mandate is delivered over the API as a PINT (header x-sumvin-pint-token); the scope catalog below carries the same identifiers whether you read it as a Stamped Mandate or as its underlying PINT.The scope grammar is a specialisation of the broader Sumvin Resource Identifier family — same sr:{region}:… scheme, different shape. Scopes support per-scope parameters (amount caps, asset, provider, time windows) as URL query strings, giving partners fine-grained capability envelopes without expanding the scope vocabulary.
Every scope in this catalog maps one-to-one to an existing authenticated user-facing capability in the Sumvin API. When a Stamped Mandate carrying a scope is exchanged for a JWT, the scopes claim is exactly what the partner sees.
SYMBOL@context where context is a chain slug or fiat
asset=USDC@sei, asset=USD@fiat
Provider choice
Lowercase alphanumeric, drawn from a fixed enum
provider=meld
Timestamps
Unix seconds
from_date=1720000000
Time windows
Unix seconds (window length)
time=2592000 (30 days)
Values containing &, =, or whitespace must be percent-encoded. The scope string is always signed verbatim as part of the Stamped Mandate payload, so any encoding applied at sign time is preserved end-to-end.
Standard (Tier 1) — JWT alone is sufficient. Partner validates JWT signature, audience, expiry.
Enhanced (Tier 2) — JWT + the original Stamped Mandate signature and payload headers (X-Pint-Signature, X-Pint-Payload).
In the MVP catalog, only sr:us:pint:spend:execute triggers Enhanced tier. All 13 other scopes are Standard. If a Stamped Mandate carries any Enhanced-tier scope, the entire JWT is issued at Enhanced tier.
Attests the user’s current KYC verification status. The JWT’s kyc_status claim carries the canonical value (pending, verified, rejected, …) for partners to read directly.
Grants SIS partners dual-authenticated read access to the user’s KYC applicant PII and document images. See Getting User KYC Data for the full SIS flow.
Authorises on-chain spend on behalf of the user. This is the only scope that triggers Enhanced verification — partners must verify the original Stamped Mandate signature, not just the JWT. When max + asset are set, the API enforces them against the actual transaction amount and asset at execution time.
Authorises the creation of an Intelligent Purchase Authorisation (IPA) and enrolment into Errand strategies. The time param is required on the scope string. API-side enforcement of time against the IPA’s lifecycle window is deferred pending the IPA schema gaining an explicit window field — today the scope’s presence is validated but the window is not yet bound.
Read the user’s linked bank accounts and current balances. Used by delegated agent flows that need account context without the ability to initiate movement.
Reserved. The registry entry and parser support are in place so partner clients can begin requesting this scope, but there is no enforcement site in the current release — the transfer route is not yet live.
Read transaction history and receipts. When from_date / to_date are set, the API enforces them by rejecting any listing or detail request for a transaction outside the declared window.
Read AI-generated insights, user-defined rules, and budgets. No parameters — scope presence alone grants access to the full personalisation read surface.
Read card details (last4, brand, status, funding wallet). Does not expose the card PAN or CVV — those are only surfaced via a separate, short-lived session.
State-change operations on an existing card. Excludes card creation and excludes any spend flow — sr:us:pint:cards:manage is strictly about card lifecycle, not value transfer.
Creation time (schema). When a Stamped Mandate is created at token exchange, every scope string is parsed and validated. Malformed grammar, unknown scope names, and malformed params are rejected before the Stamped Mandate is persisted.
Enforcement time (semantic). When a request carries a PINT token, the gated endpoint enforces per-param limits (amount caps, asset match, provider match, date range, …) against the actual request.
Validation at both layers prevents malformed scopes from entering the system and prevents legitimate scopes from being used outside their declared envelope.
The resulting JWT will carry both scopes in its scopes claim, and the verification tier is the highest tier present — if any scope is Enhanced, the entire JWT is issued at Enhanced tier.Two scopes with the same name but different params (e.g. sr:us:pint:spend:execute?max=100000000 and sr:us:pint:spend:execute?max=200000000) are treated as distinct capability envelopes — both are retained in the signed array. Exact duplicates are collapsed.
These scopes are in the registry — requesting them parses successfully and they appear in the issued JWT — but no API endpoint consumes them yet.
Scope
Status
sr:us:pint:accounts:transfer
Registered, enforcement pending route landing (fiat → wallet transfer route not yet live)
Scope definitions are versioned alongside the EIP-712 specification. See EIP-712 & Purchase Intents for the canonical type definitions and SRI for the underlying URI family.
