A payment does not need to expose who is paying, how much they hold, or where they bank. It needs to prove that the payer has sufficient funds, that the payment executed correctly, that compliance was satisfied, and that the entire flow can be independently verified after the fact. This is proof-based commerce: every step produces a cryptographic artifact. Nothing is trusted. Everything is verified.
Each step in the payment flow produces an independently verifiable artifact. The entire settlement can be replayed by an auditor without trusting the merchant, the payer, or H33.
The merchant creates a payment request containing the amount, currency, merchant identity, and expiration. The invoice is attested with an H33-74 proof bundle -- 74 bytes carrying three post-quantum signatures (ML-DSA-65, FALCON-512, SLH-DSA-SHA2-128f). The QR code encodes both the invoice payload and the attestation. Any scanner can verify the invoice is authentic before initiating payment.
The payer's wallet generates a STARK-based ZK range proof attesting that their balance is greater than or equal to the invoice amount. The proof reveals nothing about the actual balance -- only the boolean result. No account number, no bank name, no transaction history. The proof is bound to the invoice attestation, preventing replay against a different invoice.
The payment amount, payer reference, and merchant reference are encrypted under BFV lattice-based FHE before entering the settlement pipeline. All settlement logic -- amount matching, fee calculation, ledger updates -- executes directly on ciphertext. The cleartext never exists on the processing infrastructure. This is not encryption at rest. It is encryption during computation.
The settlement engine produces an attestation binding the encrypted inputs, the computation performed, and the encrypted result. This attestation is deterministically replayable: given the same encrypted inputs, any independent party will derive the identical attestation hash. Settlement correctness is not a claim. It is a mathematical property.
OFAC screening runs as an FHE inner product between the encrypted payer identity and encrypted watchlist entries. AML threshold checks execute as ZK range proofs on the encrypted transaction amount. Both checks produce attestations proving the check was performed and the result was negative -- without ever decrypting the identity or the amount. The compliance officer sees "check passed" with a verifiable proof. They never see the underlying data.
The final receipt binds the invoice attestation, the ZK range proof, the FHE settlement attestation, and the compliance attestation into a single H33-74 proof bundle. Three independent post-quantum signatures -- ML-DSA-65 (MLWE lattice), FALCON-512 (NTRU lattice), SLH-DSA-SHA2-128f (stateless hash) -- are compressed to 74 bytes. The receipt is the entire audit trail.
Any auditor, regulator, or counterparty can independently verify the entire payment flow using the H33 Verifier CLI. No trust in H33 required. No trust in the merchant or payer required. The proof is mathematical.
# Verify the settlement receipt
h33 verify receipt settlement.json
# Replay the settlement to confirm deterministic output
h33 replay session settlement.json --iterations 100
# Diff two receipts to detect any divergence
h33 diff receipt before.json after.jsonThe @h33/agent SDK exposes the full proof-based commerce pipeline. The following example covers invoice generation, payment verification, settlement, compliance attestation, and receipt issuance.
import { H33Client, Invoice, Settlement } from '@h33/agent';
// Initialize client with merchant credentials
const h33 = new H33Client({
apiKey: process.env.H33_API_KEY,
endpoint: 'https://api.h33.ai/v1',
});
// Step 1: Generate attested invoice
const invoice: Invoice = await h33.commerce.createInvoice({
amount: 2500_00, // $2,500.00 in cents
currency: 'USD',
merchantId: 'merch_9f3k2m',
expiresIn: '15m',
attestation: {
format: 'h33-74', // 74-byte PQ proof bundle
families: ['ml-dsa-65', 'falcon-512', 'slh-dsa-sha2-128f'],
},
});
// invoice.qrCode contains the attested QR payload
// invoice.attestation contains the H33-74 bundle (74 bytes)
console.log(`Invoice ${invoice.id} attested: ${invoice.attestation.hash}`);
// Step 2: Verify payer's ZK range proof
const fundProof = await h33.commerce.verifyFundProof({
invoiceId: invoice.id,
proof: payerSubmittedProof, // STARK-based ZK range proof
});
if (!fundProof.valid) {
throw new Error('Insufficient funds proof failed verification');
}
// Step 3: Execute settlement on encrypted rails
const settlement: Settlement = await h33.commerce.settle({
invoiceId: invoice.id,
fundProofId: fundProof.id,
encryption: {
scheme: 'bfv', // BFV lattice-based FHE
profile: 'h33-128', // N=4096, 56-bit modulus
},
compliance: {
ofacScreen: true, // FHE inner product vs. watchlist
amlThreshold: true, // ZK range proof on amount
},
});
// Step 4: Retrieve verified receipt
const receipt = await h33.commerce.getReceipt(settlement.id);
console.log(`Settlement ${settlement.id}`);
console.log(` Status: ${receipt.status}`);
console.log(` OFAC cleared: ${receipt.compliance.ofac.cleared}`);
console.log(` AML cleared: ${receipt.compliance.aml.cleared}`);
console.log(` Attestation: ${receipt.attestation.hash}`);
console.log(` H33-74 bundle: ${receipt.attestation.bundleSize} bytes`);
console.log(` Replay-deterministic: ${receipt.replayDeterministic}`);# Verify a settlement receipt via the public API
curl -X POST https://api.h33.ai/v1/verify/receipt \
-H "Content-Type: application/json" \
-d @settlement.json
# Response includes:
# - signature_valid: true (all 3 PQ families)
# - replay_deterministic: true
# - compliance_attested: true
# - h33_74_bundle_size: 74These are production measurements from Graviton4 metal (c8g.metal-48xl, 192 vCPUs). Not projections. Not theoretical limits. Measured, sustained, reproducible.
A 32-user FHE batch completes in 943 microseconds. The entire pipeline -- encryption, settlement, attestation, compliance -- executes in 1,345 microseconds per batch. At scale, this is 1.67 million authentications per second sustained on a single Graviton4 instance.
Every component in the proof-based commerce workflow maps to a published specification, a machine-readable schema, or a conformance vector that can be independently validated.
| Component | Specification | Conformance Vector |
|---|---|---|
| Invoice attestation | H33-74 Proof Bundle Spec | h33-74-invoice-v1 |
| ZK range proof | ZKP-AIR STARK Spec | zk-range-funds-v1 |
| FHE settlement | H33-128 BFV Spec | bfv-settle-v1 |
| OFAC screening | FHE Inner Product | ofac-fhe-screen-v1 |
| AML threshold | ZKP-AIR Range Proof | aml-zk-threshold-v1 |
| Receipt attestation | Multi-Family PQ Sig Spec | receipt-3pq-v1 |
| Deterministic replay | Governance Replay Spec | replay-settle-v1 |
Every claim on this page links to a live demo, a specification, a benchmark, or a CLI command you can run yourself.
Answers to operational questions about verified payments, encrypted settlement, and compliance attestation on H33.
The payer's wallet generates a ZK range proof that attests "balance >= invoice amount" without disclosing the actual balance. The proof is a STARK-based arithmetic circuit that outputs a boolean commitment. The merchant verifies the proof without learning anything beyond the binary yes/no result. The proof is then attested with H33-74 (74 bytes, three post-quantum signature families) so it can be independently verified by any party using the Verifier CLI.
The payment amount, payer identity, and merchant identity are encrypted under BFV lattice-based homomorphic encryption before they enter the settlement pipeline. All settlement logic -- amount matching, fee calculation, compliance checks -- executes directly on ciphertext. The cleartext never exists on the processing infrastructure. This is not encryption at rest or in transit. It is encryption during computation. The settlement engine produces an encrypted result that only the authorized parties can decrypt.
OFAC screening uses FHE inner products to compare an encrypted identity against encrypted watchlist entries. The computation returns an encrypted boolean result indicating whether a match was found, without ever decrypting either the identity or the watchlist. AML threshold checks use ZK range proofs on encrypted transaction amounts. The compliance attestation is signed with three post-quantum families and compressed to 74 bytes via H33-74.
An auditor can replay the entire settlement flow using the H33 Verifier CLI. The command h33 verify receipt settlement.json validates: the invoice attestation was correctly signed, the ZK range proof is valid, the FHE computation was performed on the attested inputs, the OFAC/AML compliance check was executed, the receipt signatures are valid across all three PQ families, and the deterministic replay produces an identical attestation. The auditor does not need to trust H33, the merchant, or the payer.
Yes. Every component in the pipeline is post-quantum secure. The FHE encryption uses BFV with MLWE hardness (lattice-based). The ZK proofs use STARK arithmetic (hash-based, no elliptic curves). The attestation signatures use three independent post-quantum families: ML-DSA-65 (MLWE lattice), FALCON-512 (NTRU lattice), and SLH-DSA-SHA2-128f (stateless hash). Breaking the attestation requires simultaneously breaking three independent mathematical hardness assumptions.
See proof-based commerce in action. Generate an attested invoice, verify a ZK range proof, and replay a settlement receipt. Every step is independently verifiable.