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.
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.
Confirm the issuer is registered in the Trust Registry (a locally cached, signed snapshot whose root is anchored on-chain), with the correct role and active status at the token's issued-at time.
Verify issued-at and expiry bounds. Clock skew tolerance bounded by deployment policy. Expired tokens fail unconditionally.
Check revocation status against a cached revocation set. Staleness policy is deployment-configurable. Online check available but not required for core enforcement.
Confirm the token's declared scope is a strict subset of its parent's scope. Scope widening at any hop is a hard failure. The attenuation graph is verified end-to-end.
Verify the delegation depth has not exceeded the maximum declared in the CAT. Prevents unbounded re-delegation chains in agentic contexts.
Verify the humanAnchor commitment is consistent across the full token chain. The ZK commitment to the authorizing human propagates unchanged from CAT to SPT-Txn Token.
Verify the transaction context hash matches the scope hash committed in the token. The authorization is bound to this specific transaction, so it is not transferable or 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.
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.
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 only the FATF-required fields, proves the rest in zero knowledge, hides the exact amount, and exposes nothing on-ledger or to third parties.
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.
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.
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 is Travel-Rule compliant. The complete loop — authorize → settle → verify → deliver, with an over-scope payment cryptographically DENied before anything is signed — runs end-to-end live on seven chains across three address families: XRPL (through mainnet), plus Hedera, Aptos, Ethereum, Base, Solana, and NEAR on their test networks. Same gate, same verifier, same attestation; only a ~200-line ledger submitter differs per chain.
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, no holder-side scope attenuation, and no provenance binding — 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.
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 — 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 -02 adds Section 11: Algorithm Agility and Post-Quantum Migration.
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 14409. 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.
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 on six public testnets. Chains are integration targets, never dependencies; 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.
verifier 0x311612…95ef ↗ · verified-anchor tx ↗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 — 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) — no rip-and-replace. Demonstrated end-to-end against both Keycloak (open-source) and Auth0 (commercial), differing only by one configuration value: an IdP-authenticated identity (including a machine / M2M client identity) is exchanged into a human-anchored capability that then verifies offline — with no identity-provider contact — and delegates to an AI agent with attenuating, revocable authority. The same OIDC + Token-Exchange flow targets Okta and Ping 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.