For RWA issuers & tokenization platforms

Your token standard decides who may hold. It does not decide who authorized.

Last updated: 30 August 2026

Token‑2022 extensions and ERC‑3643 answer one question well: may this account hold this asset? Neither answers the question a fund administrator, an auditor or a regulator actually asks after the fact — who authorized this transfer, under whose mandate, was that mandate still valid at the time, and can you show me without handing over the investor’s identity?

SPT‑Txn is that layer. It is open source, it verifies offline, it puts no personal data on the wire or on the ledger, and you run it — it never sits in your money path and it never calls home.

The gap, concretely

Question	Token standard	SPT‑Txn
May this account hold the asset?	Yes — identity registry, default account state, transfer restrictions	— we do not replace this
Under whose authority did this key act?	No	A privacy‑preserving commitment to the accountable person, carried unchanged through every delegation hop
Was that mandate still valid at transfer time?	No	Short‑lived, transaction‑bound tokens; expiry and revocation re‑checked at every hop
May an agent act, and how far?	No — a key is all‑or‑nothing	A delegation chain that can only ever narrow, bounded in depth
Why was it permitted?	A transfer log, and nothing else	A signed decision receipt for every decision, hash‑chained and Merkle‑committed
Can a verifier check without calling anyone?	Usually not	Offline. No issuer contact, no network call

This matters more as execution moves away from a human at a wallet. When a portfolio system — or increasingly an AI agent — submits the transfer, the signing key stops being evidence of intent. Something has to carry the mandate.

What “can only narrow” looks like

Three real tokens, minted by the reference implementation while this page was written. The chain is human → agent → sub‑agent, and these are the decoded capability_scope claims exactly as they appear in each token. Nothing below is illustrative. go run ./cmd/agentdemo reproduces it offline, with no network and no keys of ours.

CAT: the human’s mandate delegation_depth_max 3

{"action":"payment","currency":"USD","max_amount":10000}

CT: agent A, issued by the organisation delegation_depth_remaining 2

{"currency":"USD","max_amount":8000}

CT: sub‑agent B, delegated by agent A delegation_depth_remaining 1

{"currency":"USD","max_amount":5000}

The ceiling falls at every hop, the depth counter falls with it, and the human_anchor claim is byte‑identical in all three: the same accountable person, carried unchanged to the last delegate. Widening is not rejected at spend time; it is refused at mint, so a token granting more than its parent never exists. In the same demo, sub‑agent B asking for 6,000 against its 5,000 ceiling is refused before any token is issued, and revoking agent A’s delegation key kills B’s authority while leaving A’s own capability working.

One property of Token‑2022 worth checking early

Confidential Transfer and Transfer Hook cannot both be enabled on the same mint. A transfer hook enforces on the amount it is handed; a confidential transfer encrypts the amount and moves through a different instruction path, so the hook is never invoked. For a regulated asset this is a real architectural choice: encrypted allocations, or programmatic transfer enforcement — not both, on one mint.

There is a quieter one alongside it. Even on a hook‑enforced mint, a live mint authority or freeze authority can move or immobilize value without the hook ever running. A compliance mint therefore has to set both to None, and something has to verify that at deploy time rather than in a design document.

Neither of these is our invention — they are properties of the standard, and you can confirm both in an afternoon. We mention them because they shape the design before any authorization layer is chosen.

Post‑quantum, stated precisely

We would rather be exact here than reassuring:

Shipped: a hybrid X25519 + ML‑KEM‑768 key encapsulation on the escrow envelope — the part that would otherwise be exposed to harvest‑now‑decrypt‑later.
Shipped: a published CycloneDX CBOM, so every algorithm in use is inventoried rather than asserted.
Not yet: token signatures are classical today. The ML‑DSA (FIPS 204) hybrid path is designed and the algorithm identifier travels in every token, so acceptance is a registry decision rather than a flag day — but the migration has not been made.
Scope of FIPS: the classical cryptography can run through the CMVP‑validated Go Cryptographic Module on a validated operating system. SPT‑Txn itself is not FIPS‑validated, and running it on a validated module does not make it so.

What is deployed, and where

Stated at the level it actually exists, because the difference matters to anyone doing diligence:

Ethereum mainnet: an on‑chain zero‑knowledge verifier, live — it demonstrates a threshold predicate (a hidden value satisfies a bound).
Public testnets: the compliant‑token eligibility gate (issuer‑bound and replay‑safe), the escrow program, and attestation anchors across several chains.
Everything else — the gateways, the delegation layer, the Travel Rule exchange — runs on a hardened reference host and in tests, not in production anywhere.

You run it. That is the point.

The control plane belongs with the regulated entity that already carries the obligation — the issuer, the transfer agent, the VASP, the bank. We publish the software under Apache‑2.0; you deploy it, you hold the keys, you set the policy, and no transaction detail reaches us or anyone else. We do not operate a facilitator, we do not take a fee per transaction, and we are never in your money path.

That is a deliberate choice. It is also why the software can be adopted by an institution whose compliance function, not its innovation budget, is the one that has to sign off.

Honest boundaries

SPT‑Txn is a proof of concept and a specification effort. Nothing in it has been externally audited or certified, and it is not in production use. Our security reviews are our own. On‑chain footprints are on public testnets except where stated above. An independent review of the zero‑knowledge circuits and the protocol is wanted and has not happened. We say this plainly rather than implying assurances we have not earned. One more, since an institution will ask it first: key reconstitution is designed but not settled. If an issuer loses its signing key, the revocation cascade and a cross‑organisation quorum are specified, but the ceremony shape is an open decision. Who holds what, and what it takes to stand an issuer back up without invalidating the delegations beneath it, is not a runbook we can hand you today.

If this is useful to you

Everything is public and reproducible: the reference implementation, the specification work, and the tests that back each claim above. Start with the repository, or write to us.

Reference implementation on GitHub →
Framework paper and IETF Internet‑Draft →
rudi@violetskysecurity.com