Sovereign Policy Token Transactions (SPT-Txn) extends the IETF OAuth Transaction Tokens work with cryptographically scoped capability grants that propagate human-origin identity across delegation chains, without exposing PII.
The one-sentence differenceAn AI agent or partner system is handed a role, and keeps that authority over every action it takes, with no record of who approved what. When it is manipulated or compromised, the blast radius is everything it could ever touch.
Everyone else authorizes agents and workloads by role. SPT-Txn authorizes the specific transaction the actor declared, conditioned on what the actor is and how fresh its attestation is, and emits a cryptographic receipt proving the decision.
As of August 2026, no shipping product completes that sentence.
Sovereign Policy Token Transactions (SPT-Txn) is not part of any chain, and not bolted onto any single Travel Rule transport. It is an independent authorization layer: a KYC provider or platform issues a compliance attestation once, and any VASP, wallet, or AI agent verifies it anywhere, offline, with no issuer contact and nothing to join. It binds into any Layer 1 or Layer 2 through a single adapter interface, yet depends on none. That independence is the deliberate design choice. It sidesteps the lock-in of building inside one chain, and the two-sided-adoption stall of bolting onto one transport.
Existing authorization frameworks enforce policy within a single trust domain. Cross-organizational, agentic, and regulated transaction chains need something stronger.
A token issued at the edge of one organization carries no cryptographic guarantee that its scope was not widened before it reaches the next. Scope inflation is undetectable at the protocol layer.
AI agent chains execute on behalf of humans, but the human-origin signal dissolves within one or two delegation hops. Regulators and auditors cannot reconstruct who authorized what.
Revocation checks require live issuer contact. In regulated cross-border transactions, latency, availability, and jurisdiction constraints make live verification operationally fragile.
When a transaction is disputed, there is no privacy-preserving mechanism to produce the authorized human principal under lawful process without exposing PII to every intermediary in the chain.
Each token type operates at a different scope and lifetime. Scope can only narrow as the chain propagates, never widen. Every hop is verifiable offline.
The verify-once credential. Issued by a KYC / compliance provider after verifying the user: KYC level, jurisdiction, accredited-investor status. Holds zkDID-bound, selectively-disclosable compliance claims; the user reuses it across every platform without re-submitting documents. No PII on the wire.
The scoped authorization. A platform evaluates a zero-knowledge proof of the CAT against its policy and, on a match, issues a CT (for example, "trade up to $50k/day until 2026-12"). A root CT sets the maximum scope; delegated CTs (to an AI agent) are strict subsets with bounded depth. Carries the humanAnchor forward.
Ephemeral, transaction-bound token minted at execution time. Binds the authorization to one transaction-context hash for ~30 seconds; the eight-step engine verifies the full chain here, and it carries the Travel Rule attestation. Auditable without PII exposure.
Attributes are evaluated once, at issuance; capability is enforced on every token afterward. Identity and PII never travel; only proofs do.
The enforcement engine operates identically offline. It reads only the token and a locally cached Trust Registry snapshot. No issuer contact, no live registry or chain read in the hot path, no trust-on-first-use. Each step fails closed.
Measured, not asserted. On a modest 2012-era server (Intel Xeon E5-2630, OpenBSD, pure-Go, cgo-free), token verification completes in ~0.35 ms and the cached Trust Registry lookup in ~1.1 µs; the on-chain anchor root syncs out-of-band and never enters the transaction path. That is sub-millisecond authorization against multi-second on-chain settlement, on a conservative hardware floor. Post-quantum migration does not change this: the escrow key is hybrid X25519 + ML-KEM-768, but token signing stays classical, so hot-path latency and the ~759-byte token are unaffected: the PQ cost lands only on the escrow envelope, off the transaction path.
Verify token signature against the issuer's registered public key. Algorithm resolved from the Trust Registry, not the token header, which makes it downgrade-resistant.
Verify issued-at and expiry bounds, and that expiry is strictly after issued-at. Clock skew tolerance is bounded by deployment policy and applied asymmetrically: it may cause a verifier to reject early, never to accept late. Expired tokens fail unconditionally.
Confirm the token names this enforcement point. A capability minted for one executing domain cannot be presented at another, so a token that leaks sideways is inert rather than useful.
Check revocation status against a cached, signed status list. A snapshot past its own validity window is treated as unavailable, not as valid — stale revocation data is never trusted. Online check available but not required for core enforcement.
Confirm the presenter possesses the key the token was bound to, by DPoP proof of possession (RFC 9449). A token captured in transit is useless to anyone but its holder, and each proof is single-use within its freshness window.
Walk the entire chain from the root CAT — there is no fast path for a “trusted” intermediate. Every hop's issuer must be registered in the Trust Registry (a locally cached, signed snapshot whose root is anchored on-chain) with the correct role and active status at that hop's issued-at time; delegation depth must stay within the bound the CAT declared; no hop may outlive its parent; and the humanAnchor commitment must be identical at every hop. That commitment is a one-way zkDID value carrying no name or PII, freshly randomized on every issuance, so it is unlinkable across transactions. Nothing that identifies a person is ever placed on-chain.
Evaluate the request against the chain-intersection of every scope from root to leaf. A dimension a hop declines to restate is inherited, not relaxed. Widening at any hop is a hard failure, so authority can only ever narrow.
Verify the transaction-context hash matches the commitment in the token. The authorization is bound to this specific transaction, so it is neither transferable nor replayable.
Run the eight-step engine against a sample chain (CAT → CT → SPT-Txn): the same check whether the holder is a VASP or an AI agent. Pick a tamper (a widened scope, an over-depth re-delegation, a broken human anchor) and watch it fail closed at the exact step. It's the containment guarantee for agents too: a compromised or prompt-injected agent cannot exceed or re-widen what it was granted. No backend, no data leaves your browser.
The problem: Authorization that phones home is fragile exactly where regulated cross-border transactions live (latency, outages, jurisdiction limits), and it stalls because both sides must adopt the same system before either sees value.
SPT-Txn is a verifiable authorization format, not a protocol both sides must install. An issuer creates value the moment it issues: a provable compliance posture, a tamper-evident audit trail, and a privacy-preserving human anchor it can produce under lawful process, whether or not the counterparty does anything. Verifying is a cheap, optional, fully offline capability any party adopts unilaterally: drop in the verifier library, hold a cached snapshot of the Trust Registry, and check the token. No handshake, no shared registry to join, no synchronized rollout.
Mint the CAT → CT → SPT-Txn chain, sign with your registered key, attach it to the transaction. You gain a provable compliance posture, a tamper-evident audit trail, and a lawful-process human anchor, with no PII on the wire and no dependency on the counterparty.
A verifier needs only the open-source verifier library and a locally cached Trust Registry snapshot (issuer keys + algorithm assignments). The eight-step engine confirms scope, humanAnchor, and transaction binding, with no issuer contact and no live registry or chain read in the hot path.
SPT-Txn sits on top of whatever Travel Rule transport you already run (OpenVASP TRP, TRISA), or none. It removes the PII-leakage problem from the transport rather than competing with it, so adoption is one-sided and incremental.
The problem: Complying with the crypto Travel Rule today means shipping your customer’s full name, account, and exact amount to every counterparty, turning a compliance obligation into a standing data-breach and privacy liability.
SPT-Txn carries a payload-level zero-knowledge attestation over the inter-VASP Travel Rule Protocol (TRP). Plain TRP and TRISA encrypt in transit, but still deliver the full originator/beneficiary PII to the counterparty to receive and store. SPT-Txn discloses the FATF-required fields, proves the rest in zero knowledge, minimizes what else leaves the VASP (including hiding the exact amount where the jurisdiction permits), and exposes nothing on-ledger or to third parties. Which fields must appear on the wire is a regulatory question set per jurisdiction: FATF Recommendation 16 requires institutions to obtain, hold, and transmit specified originator/beneficiary information, and acceptance of reduced or zero-knowledge disclosure is jurisdiction-specific and not assumed here.
No names on the blockchain. When a payment settles on a public chain (for example an agentic x402 payment on Solana, where the anchor rides on-chain in an SPL Memo), the only human-related value written to the ledger is the humanAnchor: a rotating, one-way commitment, never a name and never PII. Because it is freshly randomized per issuance, on-chain observers cannot even link a person’s payments to one another. Identity stays off-chain; the ledger records accountability, recoverable only under lawful process, not who.
Originator and beneficiary identity expressed in the interVASP IVMS101 standard and carried as a selectively-disclosable SD-JWT. It discloses exactly the FATF-required fields (name, account, an identifier) to the counterparty, nothing more and nothing on-ledger, and the exact amount stays hidden. IVMS101 is designed to travel within ISO 20022 cross-border and trade-finance messaging, so the attestation slots into existing institutional payment rails.
Identity-commitment, amount-over-threshold (amount hidden), and beneficiary-VASP registration (which VASP hidden), each bound to the specific payment via its transaction-context hash.
Originator and beneficiary run as separate services; the beneficiary holds only the verifying key. Cleartext-only transfers are refused; privacy is mandatory, not optional.
The problem: When a person hands a task to an AI agent, the human-origin signal dissolves within a hop or two: a hijacked agent can act beyond its mandate, and auditors can’t prove which human authorized which action.
When a person authorizes an AI agent, SPT-Txn issues the agent a strictly narrower, delegation-depth-bounded Capability Token carrying an immutable humanAnchor back to the accountable person. An agent can only attenuate what it holds, never widen it, and revoking a delegator's key denies its sub-agents while the delegator's own authority stands. Every check runs offline.
Each delegated Capability Token is a strict subset of its parent with a bounded delegation depth. An agent literally cannot exceed, or re-delegate beyond, what it was granted.
An immutable humanAnchor, a zero-knowledge commitment to the authorizing person, threads every hop unchanged. It is producible under lawful process and never exposed to intermediaries.
Cut a delegator's key and every capability it handed downstream fails closed, offline, at the chain step, while its own authority is untouched.
POC-built and tested: multi-hop CT→CT delegation, an offline N-hop verifier, and a granular revocation cascade, and now provable in zero-knowledge: a Groth16 chain proof that verifies each hidden hop's registered-issuer signature in-circuit (Baby Jubjub EdDSA), with a live verify endpoint at :4446/agent/health. Complements agent-to-agent payment rails (e.g. x402): SPT-Txn governs what an agent may do and who is accountable, not how it pays.
The humanAnchor is a commitment format; the root that establishes the person behind it is a swappable interface. SPT-Txn consumes any verified personhood or uniqueness attestation through one provider seam: it ships reference adapters that verify Civic Pass and Solana Attestation Service credentials, with .zkdid™ proposed as a privacy-superior swap-in. The issuance and offline-verification path is unchanged when the root is swapped, so no single identity provider is a dependency. A one-command demo (cmd/civicdemo) verifies an attestation, resolves a context-specific nullifier, and seals the anchor into a CAT.
x402 is the HTTP-native agent-payment standard (Coinbase, and Google's AP2, build on it). x402 settles the payment; SPT-Txn gates it: before the agent pays, the gate checks it holds a human-anchored capability whose scope covers the spend, stamps a privacy-preserving humanAnchor into the on-ledger transaction, and the merchant re-runs the full eight-step verifier offline before delivering, trusting the authorization, not just that money arrived. No PII on-ledger; for regulated transfers it carries a FATF R.16 (Travel Rule) attestation. The complete loop (authorize → settle → verify → deliver, with an over-scope payment cryptographically DENied before anything is signed) is demonstrated end-to-end on XRPL (through mainnet), and designed to run unchanged on the other supported chains (Hedera, Aptos, Ethereum, Base, Solana, NEAR) behind the same gate, verifier, and attestation; only a ~200-line ledger submitter differs per chain.
A live PingOne-registered AI Agent token (machine / M2M identity, no sub, keyed on its verified client_id) was verified against PingOne’s live discovery and JWKS and exchanged, over standard OAuth 2.0 Token Exchange (RFC 8693), into an offline-verifiable, holder-bound, human-anchored capability token — the same flow already shown unchanged against Keycloak and Auth0. SPT-Txn consumes the identity provider’s agent token and adds what the IdP does not issue: a per-transaction, intent-bound, human-anchored, offline-verifiable authorization the merchant re-checks with no issuer contact.
A dry-run path runs the full pipeline — attestation verify, audience, freshness, scope intersection, delegation-depth and TTL clamp — and returns the exact decision it would make (would_issue + the granted scope, or would_deny + reason and decision class) while minting no usable token. It is the safe analog of a monitoring product’s “test mode”: observe outcomes before enforcing, with no fail-open toggle anywhere in the system. Demonstrated against a live PingOne-issued agent token, returning would_issue: true with the resolved scope and no credential emitted.
Because MCP requires each server to drop the caller’s token and mint its own upstream (passthrough is forbidden to prevent confused-deputy attacks), the human-origin signal is lost at exactly the hop that matters. SPT-Txn restores it: an MCP server becomes the policy-enforcement point, running the full eight-step verifier offline before it executes any tools/call that moves value or touches a regulated action: checking that the caller holds a human-anchored capability whose scope covers the request, and that the immutable humanAnchor survives the very hop MCP’s own rules would otherwise sever. This is a proposed binding, not a standardized slot: the SPT-Txn token rides in the request _meta, an auth header on the Streamable HTTP transport, or tool arguments, none blessed by the spec today. It is distinct from agent-identity and agent-authorization work (OAuth 2.1 MCP auth, AAuth): SPT-Txn is the transaction- and jurisdiction-binding layer governing what a delegated agent may do and who stays accountable, which those layers structurally do not carry.
SPT-Txn extends the IETF OAuth Transaction Tokens line and fills the gap its own authorization spec admits: OAuth 2.1 bearer tokens carry no delegation chain and no holder-side scope attenuation, and MCP requires every server to drop the caller’s token and mint its own upstream (passthrough is forbidden by design, to prevent confused-deputy attacks), a sound audience boundary that also severs the human-origin chain at every server hop.
SPT-Txn is the drop-in layer that adds verifiable, attenuating, human-anchored delegation across MCP and A2A hops: offline-verifiable, with no central authorization server. It reuses SD-JWT, DPoP and Token Exchange where they exist, and adds what they don’t: zero-knowledge selective disclosure, holder-side attenuation, a propagating human anchor, and cross-ledger binding.
Each layer is independently auditable. The enforcement engine operates at the top; cryptographic roots anchor trust at the bottom.
Deployments differ by sector. This map shows which components each industry uses, from a basic setup to the full stack, and colours every box by who controls it. SPT-Txn is open-source software you install and run in your own infrastructure; nothing calls home, and Violet Sky operates, sees, and approves nothing.
The companion to the map above: where each component physically sits, and which side of the trust boundary. Everything inside the dashed boundary runs in your own infrastructure — nothing calls home. Click any component to see its role. Hypothetical reference placements.
Hypothetical reference placements to illustrate the architecture — not a description of any specific customer deployment. Verification is offline; the on-chain anchor is a periodic write, never in the hot path; no PII touches the ledger.
SPT-Txn verifies offline, in the adopter's own infrastructure. A VASP, wallet, chain, or agent embeds the open-source verifier library plus a locally-cached Trust Registry snapshot, and verifies in-process, with no call back to any SPT-Txn server, and nothing of ours in the transaction path. The reference host on this domain is an issuer and a demo, not the runtime. Because each verification is a stateless pure function, throughput scales horizontally with cores, the same profile as the JWT checks large platforms already run at scale.
Full three-hop delegation-chain verifications per second on a 10-core laptop, scaling linearly with cores. Each check is signature + hash, and fails closed.
Ed25519 action-token issuance per second (10 cores). Minting is per-participant: each adopter issues from its own infrastructure, never through ours.
Groth16 N-hop proof verification (~6.7k/sec on 10 cores). Proof generation (~159 ms) happens once per delegation chain and amortizes over every action, never a per-action cost.
Deployment is portable, and FIPS-ready. The reference host is hardened OpenBSD (pledge/unveil, privilege separation), a security-by-design choice, not a requirement. The same Go binary runs in a FIPS 140-3 environment for regulated buyers: enable Go's native FIPS mode on a FIPS-validated Linux (RHEL / AlmaLinux / Rocky) so the classical cryptography runs through the CMVP-validated Go Cryptographic Module (certificate #5247), or route issuer keys to a FIPS 140-3 HSM over PKCS#11: signing already goes through a standard crypto.Signer interface, so it is a configuration swap. The zero-knowledge predicate layer sits outside FIPS by nature and stays a distinct, opt-in component.
Measured on a 10-core Apple-silicon laptop, no hardware acceleration. These are per-core costs; production throughput is those costs × horizontal replicas, because verification holds no shared state. Method and full table are in the open-source repository.
All publications are open access. The IETF Internet-Draft is an individual submission presented to the OAuth Working Group for technical review.
Individual Internet-Draft extending the OAuth Transaction Tokens work and aligning with the OAuth 2.0 Security BCP (RFC 9700), presented to the OAuth Working Group for technical review. Revision -03 is the current published version; datatracker is the authoritative source for what it contains.
IETF Datatracker ↗Formal security model. Defines transaction binding (TB), EUF-CCA, and unlinkability (UNL) game-based notions. Proves TB strictly implies EUF-CCA. Tight reduction, no rewinding. DOI 10.5281/zenodo.19299787.
Zenodo ↗The comprehensive framework paper. Token chain, zkDID and zkDNS, the measured cryptographic design (Poseidon2, BN254 vs BLS12-381, Groth16 vs PLONK), a lifetime-triaged post-quantum migration plan, the privacy-preserving FATF Travel Rule deployment, and a CycloneDX CBOM aligned to US EO 14028. Supersedes the v1 framework preprint (zenodo.18917439). DOI 10.5281/zenodo.20870193.
Zenodo ↗Two technical comments submitted to NIST's public comment period for SP 800-133r3 (Recommendation for Cryptographic Key Generation). Addresses threshold DKG scope and heterogeneous HNDL exposure within a single trust domain.
NIST CSRC ↗The reference implementation in Go on a hardened OpenBSD host: the token chain, eight-step verifier, ZK circuits, and the live privacy-preserving Travel Rule services.
GitHub ↗The POC validates the protocol architecture end-to-end. Classical cryptography with algorithm-agility dispatch. Pledge and unveil sandbox. File-backed persistent Trust Registry. Two-domain cross-organizational demo. A single ledger-adapter interface binds the authorization to a transaction across twenty ledgers, and the agentic layer adds multi-hop CT→CT delegation with an offline N-hop verifier, now also provable in zero-knowledge.
unveil, and confirmed by our own review. No part of this system has been externally audited.
SPT-Txn binds an authorization to a specific transaction without depending on any chain. The binding is implemented and tested behind one Go adapter interface for twenty ledgers (a single EVM adapter serves the EVM chains), and the attestation-anchor footprint is live across seven chains (Ethereum through mainnet; Arbitrum, Starknet, Aptos, Sui, Hedera, and Solana on their test networks). Two footprints reach mainnet, and they do different things: Ethereum carries on-chain ZK verification and anchoring, and XRPL carries the complete x402 loop — authorize → settle → verify. Every other footprint is a test network. That split is deliberate rather than incidental: chains are integration targets, never dependencies, and the authorization verifies offline with no chain at all.
Reading the live on-chain anchor…
transaction-binding implemented & tested · one adapter interface
A selective-disclosure proof (amount ≥ threshold, with the amount itself hidden) is verified on Ethereum mainnet (and on Ethereum + Arbitrum Sepolia) by a gnark Groth16 verifier (BN254), and the attestation is anchored only if the proof checks out. A tampered proof reverts and anchors nothing. Verify a predicate without revealing the data, enforced on-chain.
Beyond on-chain proofs, the agentic delegation chain is itself provable in zero-knowledge: a Groth16 proof that every hidden hop carries a registered issuer's signature over its scope, verified in-circuit (Baby Jubjub EdDSA), so an AI agent proves its authority chain is valid without revealing the intermediate scopes.
The same primitive gates real-world-asset compliance: a permissioned, ERC-3643-aligned token whose transfers succeed only between holders who proved eligibility in zero knowledge, with no PII on-chain. Eligibility is bound to the holder's address and to a trusted claim issuer's signature verified in-circuit (the ERC-3643 trusted-issuer role, made privacy-preserving), so a stolen proof replayed from another address is rejected on-chain (ProofInvalid), demonstrated end-to-end on Ethereum Sepolia.
msg.sender and verifies a trusted issuer's EdDSA signature over the holder's address in-circuit, so a proof cannot be replayed by another address. On Ethereum Sepolia: two holders registered via issuer-bound proofs, a compliant transfer confirmed, a replayed proof rejected ProofInvalid, and a transfer to an unproven address reverted NotEligibleThese footprints demonstrate three distinct on-chain capabilities, not one: attestation anchoring per chain; on-chain ZK verification of a selective-disclosure proof (live on Ethereum mainnet); and compliance-gated RWA transfers: a replay-safe, issuer-bound eligibility gate proven end-to-end on Sepolia. Broader mainnet anchoring and chain-native compliance bindings (for example, complementing confidential-transfer standards with the cross-VASP Travel Rule) are per-chain integration work.
OAuth Transaction Tokens preserve authorization context across hops; Identity Chaining carries it across domains; SD-JWT minimizes disclosure. SPT-Txn is the profile that adds the three things none of them do: zero-knowledge predicates, offline decentralized verification, and cross-ledger context binding, with a human anchor threaded through all of it. It reuses roughly ten OAuth primitives unchanged, and innovates only in the gaps.
Reuse is not theoretical. An existing identity provider issues SPT-Txn credentials over standard OAuth 2.0 Token Exchange (RFC 8693), with no rip-and-replace. Demonstrated end-to-end against Keycloak (open-source), Auth0 (commercial), and PingOne, including a PingOne AI Agent registered in Ping’s Agent IAM Core (run end-to-end in a Ping test environment): an IdP-authenticated identity (a human, or a machine / M2M agent that carries no sub and is keyed on its verified client_id) is exchanged into a human-anchored capability that then verifies offline (with no identity-provider contact) and delegates to a sub-agent with attenuating, revocable authority. Where PingOne’s own agent model enforces by online token introspection at a gateway, SPT-Txn verifies the same delegation offline, at the edge, emitting a tamper-evident receipt. The same flow targets Okta unchanged. A reference integration (internal/oidc, cmd/idp-bridge), not a proprietary connector.
SPT-Txn extends the Transaction Tokens line (Tulshibagwale et al., 2023) and is contemporaneous with the 2025–26 agent-context drafts, but is the first to add zero-knowledge selective disclosure, offline capability attenuation, a human anchor, and cross-ledger binding to that line. It does not claim to have originated transaction tokens, agent context, or selective disclosure: it extends an established line of work and contributes a specific new layer back as open source. That is the honest position, and it is security-by-design in practice: peer-reviewed primitives, verifiable claims, no proprietary black boxes.
Build the general primitive. Sell the specific painkiller.