Payment Mandate

​

What it is

Crypto has no direct debit — no card-on-file, no network that lets you pull funds from a wallet on a schedule. Payment Mandate is the missing primitive: a payer authorizes once — “you may charge me up to X per period until Y” — and that authorization is post-quantum signed, offline-verifiable, revocable, and enforced on every charge against its per-period cap. Last updated: 21 August 2026. It turns “I agreed to a subscription” into a cryptographic, machine-checkable authorization that any platform can verify with nothing but the issuer’s public key — and that an agent or billing system checks before every recurring pull. It is self-contained: bundled Falcon-1024 signing, a pluggable store (in-memory and SQLite included), and an injected signing key. It holds no funds and moves no money — it produces and enforces the authorization; your execution layer does the on-chain pull.

​

What you get

• The recurring-authorization primitive. A signed mandate binds a payer, a payee, a per-period cap, a period, an optional scope, and an expiry — the authorization a platform needs before it can pull a subscription or let an agent spend.
• Enforcement, not just a claim. Most “mandates” are a signed statement of intent. This one is evaluated on every pull against the per-period cap, with idempotent accounting so a retry can’t slip a second charge through.
• Quantum-resistant and offline-verifiable. Falcon-1024 signing means the authorization stays verifiable past the migration to post-quantum cryptography, and any party verifies it with just the public key.
• Instant revocation. Withdraw a mandate the moment authority should end; it appears on a cacheable revocation list and fails closed thereafter.
• One thing to integrate. A uniform issue / verify / authorize-charge / revoke surface with a pluggable store, so it drops into your backend and persists where you already persist.
• A content-addressed authority. Each mandate exposes a stable content address derived from the payer, the cap, the period, and its live revocation state, the same address the Spend Guardrail binds into a decision, so a revoked mandate addresses differently from the same mandate while live, and the spend authority reconciles across the whole chain.
• Optionally Substrate 2-bound. Fold a mandate and each authorized charge into a Substrate 2 receipt for a signed, audit-ready record of what was authorized and what was pulled.

​

How it works

​

Cryptography

• Post-quantum signing. The mandate is signed with Falcon-1024 (NIST Level 5) and verifies offline, so the authorization itself stays unforgeable after the migration to post-quantum cryptography. Each charge is then enforced against that signed mandate through an idempotent, per-period charge ledger. (For a Falcon-1024-signed receipt on every individual ALLOW/DENY decision, pair it with Spend Guardrail.)

​

Why commercial

The authorization and verifier layer was never published as open source — there is no free tier to fall back on. It is offered as a commercial product because the value is in a maintained, enforced, payments-grade authorization layer:

• Embed without attribution overhead. A commercial OEM licence lets you ship it inside your own product with no open-source notice obligations to carry through distribution.
• Enterprise terms. Support, warranty, and a defined relationship — the terms procurement and risk teams expect for an authorization-critical dependency.
• Maintained crypto suite. Post-quantum primitives, key rotation, and revocation hosting are ongoing work, bundled into the licence rather than inherited.

​

Who it’s for

• Crypto-subscription and stablecoin-billing platforms that need recurring pulls but have no direct-debit equivalent to rely on.
• Agentic-commerce and autonomous-procurement systems that must authorize, cap, and revoke an agent’s recurring spend.
• PSPs and billing platforms adding stablecoin rails that need a standard, enforceable authorization artifact across merchants and chains.
• Anyone who needs enforceable recurring authorization without building a post-quantum mandate stack themselves.

​

Frequently asked questions

​

What is a Payment Mandate?

Crypto has no direct debit, no card-on-file or network that lets you pull funds from a wallet on a schedule. Payment Mandate is that missing primitive. A payer authorizes once, up to a set amount per period until an expiry, and that authorization is post-quantum signed, offline-verifiable, revocable, and enforced on every charge against its per-period cap.

​

How is each charge checked against the mandate?

Before every pull, the charge amount is evaluated against the per-charge and per-period caps through a store-backed, idempotent ledger. The ledger records the charge and returns the remaining headroom, or declines. Because the accounting is idempotent, a retry cannot slip a second charge through.

​

Can a mandate be revoked?

Yes. You can withdraw a mandate the instant authority should end, and it then appears on a cacheable revocation list so every further charge fails closed. Anyone can confirm the mandate’s signature, terms, expiry, and revocation state from the issuer’s public key, offline.

​

How is Payment Mandate licensed?

It is a separately licensed add-on that binds to Substrate 2, not part of Substrate 2 itself. It is available self-serve as a Starter licence (perpetual one-time or annual) from the AlgoVoi store, paid in USDC, and as a commercial OEM SDK, and it is included in the Enterprise and On-premise plans. It is not distributed on public package registries.

​

Get Payment Mandate

Payment Mandate is an additional, separately-licensed package — an add-on that binds to Substrate 2, not part of Substrate 2 itself. It is available self-serve as a Starter licence (perpetual one-time or annual) (see below) and as a commercial OEM SDK — frequently paired with Agent Passport as an authorization stack — and is included in the AlgoVoi Enterprise and On-premise plans. It is not distributed on public package registries.