Skip to main content

regent-receipt-verify

Verify a Regent Control receipt or allow token without Regent: only the token and a JWKS you saved while the issuer was reachable. Nothing calls the network. One dependency (cryptography) for RS256.

pip install regent-receipt-verify
curl -s https://control-api.regentprotocol.org/v1/control/.well-known/jwks.json > jwks-2026-09.json   # save it now, keep it with the receipts
regent-verify @receipt.txt --jwks jwks-2026-09.json --request request.json --mandate mandate-v2-reveal.json --policy policy-v3-reveal.json --counterparty-jwks get4agent-jwks.json
from regent_receipt_verify import verify
res = verify(token, jwks, request={"tool": "stripe", "action": "charge.create", "resource": None, "args": {...}},
             mandate_reveal=reveal_from_owner, policy_reveal=policy_reveal_from_org)
res.valid, res.kind, res.claims, res.args_hash_match, res.mandate_match, res.policy_match

What it proves:

check meaning
signature (RS256, kid from the JWKS) Regent's issuer signed exactly these claims
kind receipt / allow / budget a receipt (typ receipt+jwt, aud regent-receipt) can never pass as an access token
expired receipts carry a 10-year evidence period; an allow token lives about a minute, so for evidence its expiry is a note, not a failure
args_hash_match the token authorised this exact request (tool, action, resource, args) and nothing else
mandate_match the owner's revealed mandate version (snapshot + salt; terms-v2, or terms-v3 with the scope allowed_resources) opens the receipt's mandate_hash
policy_match the organisation's revealed policy version (text + profile + salt, policy-v1) opens policy_hash; starter-pack decisions need only the public text
confirmation_match the settlement confirmation the counterparty (merchant, PSP, custodian) signed over the same decision, embedded in the receipt, re-verified against the counterparty's own JWKS and compared with the receipt's figures: two signatures over the same facts, checked offline. settlement_source: agent receipts have none

Key rotation: pass --jwks several times (every JWKS you saved). Exit code 0 when the signature verifies and every supplied check matches.

Test vectors are minted by the real issuer (packages/receipt-verify-vectors), and the same file drives the Node package @regent-protocol/receipt-verify.

Evidence bundles (0.4.0)

A bundle is one JSON document from the console ("Evidence bundle" on a decision or an audit event) or from GET /v1/organizations/{org}/decisions/{id}/bundle. It carries every audit event of a decision with the exact bytes that were hashed, the Merkle proof to the batch root, Regent's signed checkpoint over that root and its chain position, the epoch proof, the OpenTimestamps proof, the retained receipt and the keys.

regent-verify bundle regent-evidence-dec_7f301d041e9f.json
regent-verify bundle regent-evidence-dec_7f301d041e9f.json --jwks jwks-2026-09.json --checkpoint-jwks audit-jwks.json
regent-verify bundle regent-evidence-dec_7f301d041e9f.json --rpc https://api.mainnet-beta.solana.com
from regent_receipt_verify.bundle import verify_bundle
res = verify_bundle(bundle, receipt_jwks=saved_receipt_jwks, checkpoint_jwks=saved_audit_jwks,
                    rpc="https://api.devnet.solana.com")   # rpc is optional
res.valid, res.events, res.receipt_valid, res.receipt_anchored, res.links_ok, res.rpc_ok
check meaning
canonical bytes sha256(payload_canonical) == payload_hash, and the bytes parse to the payload
batch proof payload hash → Merkle proof → batch root
checkpoint Regent's RS256 statement (typ checkpoint+jwt) names this batch: id, seq, root, head
epoch proof batch root → epoch proof → epoch root
receipt verifies, names the bundle's decision, and is byte-for-byte the one inside the anchored receipt event
links consecutive checkpoints chain (prev_head of N == head of N-1); one seq, one checkpoint
on-chain (--rpc) the append and anchor transactions succeeded and carry the root in an instruction to the audit program

Keys default to the ones inside the bundle, which proves consistency; pass the JWKS you saved (--jwks, --checkpoint-jwks) to prove provenance. The checkpoint JWKS is public at https://api.regentprotocol.org/v1/audit/.well-known/jwks.json.

Metadata

Release files for regent-receipt-verify 0.6.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for regent-receipt-verify 0.6.0
File Size Uploaded
regent_receipt_verify-0.6.0.tar.gz 21.4 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for regent-receipt-verify 0.6.0
File Interpreter ABI Platform
regent_receipt_verify-0.6.0-py3-none-any.whl Python 3 none any Details

Total release size: 43.1 kB

Release files / regent_receipt_verify-0.6.0.tar.gz

Download URL regent_receipt_verify-0.6.0.tar.gz
Size 21.4 kB
Tags Source
SHA-256 checksum
How to use checksums
522f37457850e279b59003d03f900f61ab63f307de8824d799671fb79ca034e6
BLAKE2b-256 checksum
How to use checksums
668cf1822abd9892712eaec4d25df8975b32f87da068597a5068a1edd8a16beb
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 15, 2026.

Transparency log

Release files / regent_receipt_verify-0.6.0-py3-none-any.whl

Download URL regent_receipt_verify-0.6.0-py3-none-any.whl
Size 21.7 kB
Tags Python 3
SHA-256 checksum
How to use checksums
9eedf315ae1ea20f3a2fbae6cff8f951eb8445302ab4f888867a8a7941d006a8
BLAKE2b-256 checksum
How to use checksums
a9f6b6ffffd0eeac222c1035658f3ddc9084b3cee58073eaeded7cd34e5aa1fa
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 15, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.6.0 This release

2 release files

0.5.0

2 release files

0.4.0

2 release files

0.3.0

2 release files

0.2.2

2 release files

0.2.1

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page