# SPT-Txn — Sovereign Policy Token Transactions

> SPT-Txn is an open-source, privacy-preserving, blockchain-agnostic authorization framework for the FATF Travel Rule (Recommendation 16) and accountable AI-agent (agentic) payments. It lets regulated participants and autonomous agents prove that a transaction is authorized, in-scope, and compliant without exposing the customer's identity on the wire, using zero-knowledge scoped disclosure, a token-based authorization chain, and human-anchor escrow that is recoverable only under lawful process. Built by Violet Sky Security SEZC (Cayman Islands); reference implementation in Go on hardened OpenBSD, live at https://foss.violetskysecurity.com.

## What it is

- A privacy-preserving FATF Travel Rule (Recommendation 16, the "crypto travel rule") compliance layer for VASPs and CASPs.
- An accountability and authorization layer for agentic / AI-agent payments that composes with x402 (HTTP 402 machine-to-machine payments): it decides whether an autonomous agent may pay, within what scope, and who the accountable human is, before settlement.
- Blockchain-agnostic: a ledger is a target behind an adapter, never a dependency.
- Defined in its own Internet-Draft, `draft-coetzee-oauth-spt-txn-tokens` (revision -03), which extends the OAuth Transaction Tokens work (draft-ietf-oauth-transaction-tokens) and aligns with the OAuth 2.0 Security Best Current Practice (RFC 9700).

## Core concepts

- Token authorization chain: Compliance Attestation Token (CAT) then Capability Token (CT) then SPT-Txn Token, with monotonic scope attenuation ("scope can only narrow") verified by an eight-step offline engine.
- humanAnchor: a zero-knowledge commitment to the accountable person, carried on-ledger (transaction Memo / SourceTag) with no personally identifiable information on the wire.
- Escrow and lawful deanonymization: the real identity is sealed to an escrow authority and recoverable only via a signed request stating a lawful basis. Today a single escrow key opens an envelope and the lawful-basis check is structural; threshold (t-of-n) custody is designed, not built.
- Zero-knowledge proofs: Groth16 over BN254, ZK-friendly Poseidon2 hashing, and Baby Jubjub in-circuit signatures for agentic delegation chains.
- Post-quantum hybrid cryptography: X25519 + ML-KEM-768 (FIPS 203) for both TLS transport and escrow encapsulation, resistant to harvest-now-decrypt-later attacks; signatures are on a defined ML-DSA migration path.
- Trust Registry: issuer keys, roles, and algorithm assignments as a signed, locally-cached snapshot; algorithm selection is registry-governed, giving downgrade resistance.
- Decentralized naming and identity: zkDID commitments, and zkDNS — a proposed capture-resistant name-to-key resolution root (design-stage; not yet implemented or endorsed).

## Multi-chain transaction binding (implemented; mostly testnet)

The framework binds an authorization token to a specific ledger transaction via a canonical context hash. Supported ledgers: XRPL, Hedera, Solana, Stellar, Ethereum, Starknet, Aptos, Sui, Polkadot, XDC, Algorand, Arc (Circle), and EVM Layer-2 rollups (Arbitrum, Optimism, Base, BSC, Morph, X Layer).

Four footprints reach mainnet: Ethereum (on-chain ZK verification and anchoring), XRPL (the complete x402 loop: authorize, settle, verify), Arc (a USDC payment checked against its authorization before signing, plus checkpoints of the signed decision log), and Algorand (a paid x402 verification service at https://foss.violetskysecurity.com/x402, first mainnet payment 30 September 2026). Every other footprint is a test network.

## Compliance evidence

- Every decision emits an Ed25519-signed receipt with the timestamp inside the signature (verifier clock; RFC 3161 trusted timestamping is not yet supported).
- Receipts are appended to an RFC 6962-style Merkle log; log checkpoints have been anchored on Arc mainnet (a five-entry demonstration log).
- Receipts export as evidence mapped to NIST SP 800-53, EU DORA and SOC 2 controls. This is not certification; no auditor has assessed it.
- An OPA-compatible decision API is built. Adapters that call an existing engine (OPA, Notabene, Elliptic) are planned, not built.
- SPT-Txn does not perform KYC, KYB or KYT (sanctions and transaction screening); those stay with the operator's providers. Jurisdiction policy packs are on the roadmap; today the jurisdiction is recorded in the signed receipt.

## Papers and specifications

- [For RWA issuers and tokenization platforms](https://foss.violetskysecurity.com/for-rwa-issuers.html): what a token standard decides (who may hold) versus what it does not record (who authorized, under whose mandate, whether it was still valid, and why it was permitted). Includes two properties of Token-2022 worth checking early — Confidential Transfer and Transfer Hook cannot both be enabled on one mint, and a live mint or freeze authority bypasses the hook entirely — plus a precise statement of what is post-quantum today and what is not.
- [For VASPs and CASPs](https://foss.violetskysecurity.com/for-vasps.html): meeting FATF Recommendation 16 without disclosing a customer's identity to a counterparty VASP. A two-party Travel Rule exchange over OpenVASP TRP in which the required predicates — identity commitment, amount over threshold with the amount hidden, beneficiary-VASP registration with which VASP hidden — are proven in zero knowledge, each bound to a transaction-context hash. Also covers lawful access without standing surveillance, and what is deliberately not provided.
- [For banks and EMIs](https://foss.violetskysecurity.com/for-banks.html): giving an AI agent a short-lived, transaction-bound token that names the human behind it, can only narrow as it is delegated, and leaves a signed record of each decision. Describes the strictly-narrowing token chain (CAT → CT → SPT-Txn) and a single decision engine across ledgers. The oversight mechanism is a building block, not a compliance certification, and no claim is made that it makes any deployment compliant.
- [For identity providers and KYC vendors](https://foss.violetskysecurity.com/for-identity-providers.html): consuming an existing verified identity over OAuth 2.0 Token Exchange (RFC 8693) and turning it into a reusable, selectively-disclosable attestation. SPT-Txn consumes identity and never reissues it. Proven end to end against Keycloak and PingOne (including a PingOne AI Agent); Auth0 is covered by hermetic conformance tests (no live tenant). Designs for Microsoft Entra ID and Google are published but not built. Okta has not been tested. Includes registry-governed algorithm agility without a flag day.
- [For agent builders](https://foss.violetskysecurity.com/for-agent-builders.html): middleware that computes a binding over the exact payment an agent is attempting, returns ALLOW or a typed DENY, and refuses to sign anything that differs from what was authorized — so a prompt injection cannot redirect a payment. Covers sub-agent delegation without sharing keys, offline verification with no phone-home, and a signed receipt per decision.
- [PQChecker — post-quantum posture across a transaction chain](https://foss.violetskysecurity.com/PQChecker.html): offline-verifiable TLS posture check across every hop a transaction traverses. Separates the two clocks PQ migration runs on — key agreement is retroactively at risk, authentication is not — and reports the weakest hop rather than one host. Diagnostic, not assurance.
- [SPT-Txn framework paper (PDF)](https://foss.violetskysecurity.com/papers/spt-txn-framework-expanded-v2.pdf): the comprehensive framework — token chain, zkDID and zkDNS, the cryptographic design (Poseidon2, BN254 vs BLS12-381, Groth16 vs PLONK), the post-quantum migration plan, the FATF Travel Rule deployment, and a CycloneDX CBOM. DOI 10.5281/zenodo.20870193.
- [SPT-Txn Internet-Draft — draft-coetzee-oauth-spt-txn-tokens (revision -03)](https://datatracker.ietf.org/doc/draft-coetzee-oauth-spt-txn-tokens/): extends draft-ietf-oauth-transaction-tokens, adding algorithm agility and a post-quantum migration path.
- Public technical comments to NIST SP 800-133r3 (Recommendation for Cryptographic Key Generation).

## Project

- Author: Rudolf J. Coetzee (ORCID 0009-0009-6557-8843).
- Organization: Violet Sky Security SEZC, Cayman Islands.
- Reference deployment: https://foss.violetskysecurity.com (live; post-quantum hybrid TLS, group X25519MLKEM768).
- Status: reference implementation and multi-chain footprints are on public test networks; the framework, papers, and cryptographic design are public and open source.

## Trademarks and attribution

- SPT-Txn is independently developed by Violet Sky Security SEZC. Integration with .zkdid™ and .zkdns™ is proposed and not yet implemented or endorsed.
- .zkdid™ and .zkdns™ are trademarks associated with Toby Bolton's public-interest protocol initiative. Where this project uses the generic terms "zkDID" and "zkDNS" (for example "zkDID commitment"), they denote the generic zero-knowledge decentralized-identifier and naming primitives, and are distinct from the .zkdid™ and .zkdns™ protocol and marks.
- Scope of the current implementation: the human-anchor identity material is a placeholder / deterministic test principal. Proof-of-personhood, one-human-one-identity uniqueness, the decentralized identity root, key rotation/recovery, and private name-to-key resolution are explicitly out of scope for the present implementation and are the intended role of a future .zkdid™ / .zkdns™ integration. The Ethereum-mainnet on-chain proof demonstrates a zero-knowledge threshold predicate (a hidden value satisfies a bound), not proof of personhood.

## Keywords

FATF Travel Rule, FATF Recommendation 16, crypto travel rule, VASP compliance, CASP, MiCA, zero-knowledge proof, privacy-preserving compliance, selective disclosure, agentic payments, AI agent authorization, autonomous agent compliance, x402, HTTP 402, machine payments, post-quantum cryptography, ML-KEM, X25519MLKEM768, hybrid key exchange, transaction tokens, OAuth, delegated authorization, capability tokens, blockchain-agnostic, decentralized identity, zkDID, zkDNS, XRPL, Ethereum, Solana, Hedera, Travel Rule solution.