SummaryExecutive summary

The message. Zettl makes every cross-border and stablecoin payment explainable: what it was for, how it moved, which rules apply and who reviewed it. It does that with two products, a compliance and analytics dashboard and Zlef, a payment decision model built to be calibrated, and with settlement that starts on Base, Arbitrum and Solana.

The problem. Businesses that pay and get paid across borders and rails, including stablecoins, have to work out what each payment was for, how it relates to invoices, refunds and other payments, which facts are missing, and which payments need review under which rules. Today that is manual work in spreadsheets and general tools, and it is hard to defend to an auditor.

Two products, in parallel. A compliance, regulatory-flags and analytics dashboard that imports payment records and links every flag to its facts, evidence, rule version, source and effective date, with human review and a complete audit trail. And Zlef, a payment decision model with typed outputs and calibrated probabilities that can say “I don’t know”. Legal and tax treatment come from versioned rules and people, never from the model.

Where it runs. Zettl starts where stablecoin and agent volume already lives. Base, Arbitrum and Solana are the first rails, in USDC, for settlement and for pay-for-result settlement for agent and API sellers. Settlement facts read from those chains enter the dashboard as authenticated; everything else keeps its source label. From there the foundation widens to receipts that travel between chains and private payouts with selective disclosure.

§ 1The problem

For a business that pays and gets paid across borders and rails, each payment raises the same questions: what was it for, how does it relate to invoices, contracts, refunds and other payments, which facts are missing, and does it need review under the rules of the places involved? People answer them today with spreadsheets and general tools. The answers are slow, inconsistent between reviewers, and rarely carry their own evidence.

Who feels it first: finance and operations teams at crypto-native organizations reconciling stablecoin payouts to contributors, grantees and vendors; accounting and tax practices whose clients hold or transact in digital assets; payment and treasury teams that pay or accept stablecoins across borders; and agent and API sellers taking x402 payments.

§ 2Two products

A compliance and analytics dashboard. A control panel for payments. It imports and normalizes payment records and supporting evidence; shows each payment’s economic purpose, its relationships (refunds, reversals, linked obligations) and its state; surfaces jurisdictional exposure, missing information and review flags, each linked to its facts, evidence, rule version, source and effective date; supports human review, corrections and exceptions with a full audit history; and provides analytics and exports that feed accounting and tax software. The first version is deliberately narrow: one buyer, one workflow, one or two jurisdictions. Pending

Zlef: a payment decision model built to be calibrated. A specialized model that answers fixed, typed questions about a payment: its likely economic purpose, its relationship to other records, whether the evidence is sufficient, how complete it is, and how urgently it needs review. It is inspired by typed decision models such as TypeSafe’s Jev and Cloudflare’s Clef: outputs are defined in advance and each comes with a probability. Zlef adds abstention: when it is not sure, it says so and a person looks. Jev and Clef serve as baselines. Researching

§ 3How we prove it

(1) Pick one buyer and one workflow, and define the payment taxonomy and the model’s questions with them. (2) Build a permissioned, labeled evaluation set, starting with synthetic or historical records under a written data agreement. (3) Build a thin dashboard and compare simple rules, an existing decision model and a general-purpose model on the same records. (4) Measure per-category precision and recall, calibration, abstention and coverage, reviewer correction rate, review time, latency and cost, and the cost of each kind of mistake. (5) Split by customer and by time, keep a held-out set, and version data, models and rules. (6) Train only where the numbers justify it; reviewer corrections are candidate labels, not truth. (7) Decide in advance what result means continue, narrow, change or stop, with thresholds agreed with the first buyer.

Evidence that counts. Willingness to pay or commit, shown in a payment, a signed pilot or a reallocated budget, and repeated use on real work. Interest alone does not count. Each track below is judged on its own gate.

§ 4Pay-for-result settlement for agent payments

Why. Agent payments are real and early: reported daily x402 settlement was about $28–42K in snapshots from March and August 2026^[1,2], at about $0.001 per settlement at the reference facilitator^[3]. Tooling vendors report three recurring problems: agents pay before they get a response, there are no native refunds, and replays and double charges are common^[3,4]. Pricing is moving to value: Cloudflare moved from charging per crawl to paying per answer on 1 July 2026^[5]. Cheap settlement is solved. Trust in the transaction is not.

How it works. (1) Bind the request: every call carries a resource_digest over the server, method, canonical URL, request body and request ID. (2) Fund a tab: the agent escrows a balance for one seller under fixed terms: a price cap per call, a challenge window, a dispute bond, an arbiter, a settlement deadline and a withdrawal notice period. (3) Pay per call, off chain: the agent signs a voucher, and the seller signs its response with HTTP Message Signatures and returns a receipt. (4) Settle net: the seller posts the latest voucher with a Merkle root over the calls; single calls go on chain only if disputed. (5) Dispute in the window: the seller signing one response and a receipt claiming another, two conflicting receipts, a signed failure, or the same request charged twice refund automatically. Everything else goes to the named arbiter, with a bond.

Receipts that travel. A receipt bundle holds the agent’s voucher, the seller’s signed response and receipt, and the payment reference: the settlement transaction plus a Merkle proof of the call. Agent frameworks, auditors and the agent’s operator can check it without trusting the seller’s database. A receipt is final once settlement and its window have passed. Verifying a bundle from a contract on another chain is Researching

What sellers buy. Drop-in middleware for x402 servers that signs responses, issues receipts, deduplicates requests, settles tabs and reconciles payments. Pricing is a take rate on escrowed volume or a per-receipt fee, plus a software tier, benchmarked against facilitator fees that range from $0.001 per transaction to 1.5%; final pricing is Pending pilot results. We compete on reliability, not on rail cost.

Rollout. Phase 0: middleware and escrowed tabs on Base, Arbitrum and Solana, in USDC. Pending Phase 1: portable receipts with settlement proofs checkable across those chains. Researching Phase 2: per-call escrow resolved by one decision, in order of precedence: a provable dispute, the arbiter, the seller’s claim after the window, a timeout refund. Researching Private payouts follow once pay-for-result has paying sellers.

§ 5The x402 rail

x402 turns HTTP’s long-unused status code 402 Payment Required into a payment protocol. A client requests a resource; the server answers 402 with the schemes, networks, amounts and assets it accepts; the client signs a payment payload and retries; the server hands it to a facilitator, which verifies and settles it^[6].

Where Zettl sits. On the seller’s side of the loop: the middleware signs responses, issues receipts, deduplicates requests and settles tabs on Base, Arbitrum or Solana. A facilitator can delay or drop a payment; it cannot fake settlement, and the receipt shows exactly what was charged for which request. An x402 binding for portable receipts is Researching

§ 6Private payouts

Public chains show who paid whom and how much. That is unacceptable for payroll, supplier payments and treasury moves. Zettl’s private payouts follow a model of privacy levels: privacy belongs to the asset, disclosure is explicit, and compliance is proven, not revealed. Proofs are transparent and hash-based, and note encryption is hybrid X25519 + ML-KEM-768, secure if either component holds. Researching

Disclosure is yours. You can give a full viewing key, an incoming viewing key for one address, a key for one quarter, a one-payment disclosure, or a zero-knowledge proof of one fact. There is no escrow key and no master key. Gated policies give an issuer a declared power to stop spends, never to move, seize or read notes.

Notes and nullifiers, in plain terms. Shielded value lives in notes, not balances. The ledger stores a commitment to each note, a hash that binds its contents without revealing them, in an append-only note tree. Spending a note publishes its nullifier, a one-time tag only the owner can compute; a note whose nullifier is in the set is spent. Observers see that some note was spent and some notes were created, not which, by whom, or for how much. The first valid spend executes and any other spend of the same note is rejected.

Post-quantum, on two clocks. No quantum computer today can break elliptic-curve cryptography. Zettl plans for the day one can, and that day threatens two things on two clocks. Harvest now, decrypt later threatens confidentiality, and that clock is already running: a ciphertext published today is public forever. Forgery threatens authenticity, and that clock starts only when the machine exists. So private payouts are post-quantum for confidentiality from the start: hybrid ML-KEM note encryption, hash-based commitments, nullifiers and note tree, and transparent hash-based proofs. Authenticity follows in a separate migration.

§ 7Compliance by design

Flags, not verdicts. The dashboard shows flags from versioned rules and leaves conclusions to people. It never automates legal or tax correctness, and no flag means only that no rule fired. For private payouts it sees only what holders choose to disclose (L3). The rules-layer research, ten jurisdictions and forty-five corridors, is on the Compliance page.

What an auditor gets. For every payment: its facts with their layers, the rule versions that flagged it, the reviewer and the time, and every prior state, since corrections add lines and never overwrite them. For settled on-chain payments, the transaction itself. For pay-for-result calls, the receipt bundle.

§ 8Who Zettl is for

Finance, operations, accounting and compliance teams, first: a dashboard that shows what their cross-border and stablecoin payments were for, what is missing and what needs review, with every flag traceable to its rule and source. Accounting and tax practices: exports that carry the source of every value into accounting and tax software. API sellers and agent platforms: pay-for-result settlement on Base, Arbitrum and Solana, with receipts their customers can check. Foundations, DAOs and protocol teams: private payouts with disclosure packs for auditors. Payment operators, issuers, custodians and exchanges: corridor-level rules with sources, and review evidence that stands up to an examiner.

§ 9Roadmap

§ 10Frequently asked questions

What is Zettl?

Payment intelligence: a dashboard and a decision model that explain every payment, plus pay-for-result settlement for agent payments starting on Base, Arbitrum and Solana. The dashboard works on imported records from any rail.

Will the model decide my taxes?

No. It predicts what a payment was likely for, with a probability, or says it does not know. Legal and tax treatment come from versioned rules written and owned by people, and a reviewer makes the call.

How do you know the model works?

Zlef is measured against simple rules and existing models on one buyer’s permissioned records: per category, calibrated, on held-out data. If it does not earn its cost, the dashboard runs on rules and review alone.

Why Base, Arbitrum and Solana?

That is where stablecoin and agent payment volume already lives, in USDC. Starting there means sellers and agents keep the rails they use today.

Does pay-for-result check whether the answer is right?

No. It catches what signatures can prove: a seller contradicting itself, a signed failure, a double charge. “Never delivered” and “wrong answer” go to the arbiter.

Which jurisdictions do you cover?

Ten are surveyed and forty-five corridors mapped. A pilot covers one or two jurisdictions, with every rule owned and reviewed by counsel before it is used.

Is it private?

The dashboard sees only what you import, under a written data agreement. Private payouts with privacy levels and viewing keys are researching.

Is there a token?

No. No token, no allocation, no sale.

ReferencesSelected references

1. [1]CoinDesk. Coinbase-backed AI payments protocol wants to fix micropayments, but demand is just not there yet. 11 March 2026.
2. [2]D. McGlynn. The x402 counter has shown the same four numbers since March. 2026.
3. [3]Wavect. x402 payments comparison 2026.
4. [4]DEV Community. x402 hit 165 million transactions: here’s what it still can’t do. 2026.
5. [5]PPC Land. Cloudflare stops charging AI per crawl and starts paying per answer. July 2026.
6. [6]Coinbase. x402 v2 specification.

Technical papers: Payment Facts, Typed Decisions and Review; Cross-Jurisdictional Payment Compliance; Zlef (PDF).

§ 1Why a corridor view

Payments in crypto-assets cross borders by default, and the rules that apply to them do not. A payment touches more than one legal system as soon as its parties, their service providers or the asset’s issuer sit in different places. The rule that bites is often not the strictest rule of either side but the mismatch between them: a travel-rule threshold of USD 3,000 on one side and zero on the other; a tax-information exchange one side has committed to and the other has not; a stablecoin that is a payment instrument at origin and an FX operation at destination; a counterparty that is lawful at home and sanctioned abroad. A per-country checklist misses these.

The ten. The survey takes ten jurisdictions from Chainalysis’s 2026 Geography of Cryptocurrency ranking of on-chain flows: the United States, India, Brazil, Japan, South Korea, the United Kingdom, Vietnam, Ukraine, Indonesia and Germany. The ranking measures volume, not regulatory importance. Germany is the EU member in the set, so MiCA, the Transfer of Funds Regulation, DAC8 and the AMLR get a full country profile through it. The hubs of Hong Kong, Singapore and the UAE are treated as overlays, because many corridors between the ten route through them.

§ 2The global and cross-border layer

A payment between two of the ten is governed by two national regimes and by rules that sit above or between them.

FATF. In force Recommendation 15 requires each jurisdiction to assess virtual-asset risk, license or register VASPs, supervise them, and apply the travel rule (R.16). The FATF de minimis threshold is USD/EUR 1,000; the standard is a floor. The seventh Targeted Update (16 July 2026) reports that only one jurisdiction is fully compliant with R.15, and that of the 91 that have passed travel-rule legislation, 55 have taken no supervisory or enforcement action, so a counterparty’s legal duty to send data is a weak predictor of whether data will arrive. FATF list statuses change at the plenary of 26–30 October 2026, so every list-based rule needs a re-check.

The travel rule across the ten. Most of the ten have gone below the FATF threshold, and one has stayed above it.

Tax transparency. In force The OECD’s Crypto-Asset Reporting Framework (CARF) and the amended CRS were released in June 2023; signatories said exchanges would commence by 2027. Sources conflict Sources disagree on when the US and India begin: the OECD list of June 2025 shows the US committed for 2028 and India not committed, while later secondary sources say otherwise. The EU’s DAC8 applies in parallel: In force Germany’s KStTG, in force since 24 December 2025, covers 2026 data, with the first report to the BZSt due 31 July 2027.

Sanctions. In force OFAC’s August 2025 action designated crypto exchanges, one a successor set up to evade an earlier designation, a cross-border settlement network used for sanctions evasion, and the issuer of a stablecoin used on it: the stablecoin itself was not listed, but dealings with its issuer are blocked. In force The UK made matching designations the same month. In force EU sanctions apply directly in Germany, where crypto-assets count as funds for freezing; 2025–26 EU measures added a sectoral ban on crypto providers established in a sanctioned jurisdiction, transaction bans on named stablecoins and on 14 third-country platforms, and a power to ban third-country crypto services outright. In force Crimea and the non-government-controlled areas of Ukraine are under comprehensive US, EU and UK embargoes. Delisting matters too: Tornado Cash left the SDN list on 21 March 2025, leaving mixer exposure an AML matter.

Stablecoins. In force The US GENIUS Act was approved on 18 July 2025. Enacted, not yet effective It takes effect by 18 January 2027 at the latest. A foreign-issued payment stablecoin may then be offered through US providers only if its issuer can comply with lawful orders and only under a comparability determination; from 18 July 2028 that becomes a gate for US-facing providers. Recognition of foreign coins elsewhere splits three ways across the ten.

Germany and MiCA. In force Germany applies MiCA’s issuer test: e-money tokens may be offered only by EU credit or e-money institutions, and non-compliant coins such as USDT may be held and transferred but not offered. Interest on e-money and asset-referenced tokens is banned. Sources conflict The MiCA transitional period for existing German providers ended on 30 or 31 December 2025, depending on the source. Enacted, not yet effective From 10 July 2027 the EU AMLR bars German providers from handling anonymity-enhancing coins.

§ 3Ten regimes, one structure

Every country profile has the same fields, so the rules layer reads the same field in the same place for each: legal status and classification, licensing and foreign-provider access, AML/CFT and the travel rule, stablecoin rules, taxation, information reporting, FX controls, and pending changes. Some profiles, notably Vietnam and Indonesia, rest on a reduced verification base and are marked Researching; the full survey lists everything still being researched.

Twelve topics compared. The paper sets the ten side by side on legal status and regulator; VASP licensing and foreign-provider access; the travel rule; self-hosted wallets; stablecoin regimes; personal tax on disposals; staking, mining and airdrop tax; withholding and transaction taxes, VAT and GST; information reporting and CARF; FX and capital-flow controls; privacy coins; and pending changes to 2030.

§ 4A versioned flag model

The payment-facts design separates six fact layers, from chain-authenticated (A) to reviewed conclusion (F). Flags live in layer E. A flag records that a versioned rule’s condition held on the inputs shown, not that a law was broken, a payment is lawful or a tax is due. It is a pointer for review: here is the rule, its source and status, the facts it used with their layers, and what would resolve it. The model holds about two hundred rule records in ten families. Identifiers look like TRV-US-01; XX marks a global rule.

The touch set. A payment can engage more jurisdictions than its two ends: a Brazil–India transfer may pass through a provider in a third country and use a stablecoin issued in a fourth. The candidate rules are the global rules plus every rule whose jurisdiction is in the touch set. Residence and provider location come from attested or reviewed facts, never from a wallet address, IP or network location. If one is missing, the touch set is marked incomplete and a data flag is raised.

Severity. Three levels, inform < review < block. Block means “hold and escalate”; the system refuses or reverses nothing by itself. Each rule version carries a nominal severity; what an instance shows is capped by the status of the law it encodes and by what its fire depends on.

Missing facts: the fail-visible rule. A common silent failure of rule engines is a check that cannot run and so returns nothing: a sanctions screen with no counterparty name finds no hit. Triggers are evaluated in three-valued logic over true, false and unknown. A rule is undetermined only when the missing fact could change the answer, and an undetermined outcome is never shown as clear and never dropped: it emits a data (DAT) instance that names the missing input and inherits the strictest severity it blocked. If a beneficiary’s name is missing, the sanctions rule is undetermined and the data flag shows at block.

Model predictions as inputs. Some triggers need facts no source attests, such as the asset class of an unfamiliar token, which Zlef may predict. A rule may use a prediction only if its input list permits it (never for residency or entity type), with two preregistered thresholds, recording the label, probability, model version and thresholds. A fire that depends on a prediction is capped at review, and a prediction alone can never clear a rule: a prediction can route a payment to a person but cannot by itself hold or clear it.

Time. Law changes while payments are still under review. Rules are evaluated with the version in force at the transaction date; sanctions are evaluated twice, at the transaction date and at review. A published version is never edited: an amendment creates a new version, and re-evaluation appends a new instance next to the old one. A reviewed conclusion that relied on the old instance is marked “stale: rule changed” and re-queued.

Conflicts. Both apply: a permission in one jurisdiction never suppresses a flag from another. Strictest first: the reviewer sees instances ordered by severity. No automatic resolution: the system never decides which law prevails. In force In Brazil a stablecoin purchase is an FX operation for the central bank and a crypto-asset for the tax authority, so one transaction raises an FXC flag and a TAX flag with different premises.

§ 5The forty-five corridors

Applying the flag model to all forty-five pairs gives a fact strip and a list of documented frictions for each corridor, generated from the same structured records as the country flags, so it stays consistent as rules change. The counts measure how much documented friction a corridor has, not how risky a payment is: a corridor with one sanctions item can matter more than one with six reporting items.

Documented corridor items per pair, all families. ^S marks a corridor with at least one sanctions item. Counts include items still being researched and are not risk scores. Source: the compliance survey.

§ 6Keeping the rules current

The regimes changed many times in the twelve months before the status date: a new licensing regime in Brazil, the end of Germany’s MiCA transitional period, travel-rule amendments in Korea, CARF and DAC8 reporting starting, several rounds of sanctions designations, the GENIUS Act, and a statute moving Japan’s crypto rules under securities law. A record moves from proposed to enacted to in force to repealed, and can carry “researching” or “sources conflict” at any point until confirmed.

Review cadence. Each sanctions list on every update; each record still being researched or conflicted before any pilot uses it; every in-force record at least quarterly; and a full re-survey of each jurisdiction annually, aligned with the Chainalysis ranking, which may itself change the set of ten. Rule owners and counsel sign-off are assigned with the first pilot. Pending

What would change the conclusions. A published CARF activation list; Ukraine adopting bill 10225-d; Vietnam licensing pilot exchanges and issuing travel-rule rules; the US finalising CARF rules; Germany enacting its §20 EStG reform, which would end the one-year exemption for new acquisitions and add platform withholding from 2028; or the EU extending sectoral or service bans to further third-country platforms or hubs.

§ 7What this is not

It is not legal or tax advice. It draws no conclusion about any person’s obligations and does not claim that any flag set is complete for any jurisdiction. Residency, entity type and the identity of a counterparty’s provider are facts to be attested or reviewed; Zlef never predicts them, and the rules never infer them from a wallet or network location.

Full survey, all ten country profiles, all forty-five corridor strips, the global flag records and the verification backlog: Compliance survey (PDF, 180 pages).

§ 1Three tracks, kept apart

Zettl’s work runs on three tracks: customer discovery, now: a specific buyer, a costly workflow, the current workaround and willingness to pay; product viability, next: value at acceptable integration effort, trust, reliability and cost; and settlement on Base, Arbitrum and Solana, alongside.

§ 2The problem

Businesses, and the professionals who serve them, send and receive payments that cross jurisdictions and rails. For many of them, understanding those payments is a costly, recurring workflow: what each payment was for; how it relates to invoices, contracts, refunds and other payments; what facts are missing, and which payments may need review under which rules. Today that is done by hand or with general tools. Zettl measures what it costs a specific buyer, and what they will pay to reduce it.

Who it is for: finance and operations teams at crypto-native organizations reconciling stablecoin payouts to contributors, grantees and vendors; accounting and tax practices whose clients hold or transact in digital assets; payment and treasury teams that pay or accept stablecoins across borders; and agent and API sellers taking x402 or MPP payments.

How Zettl proves it before anything moves money, cheapest step first:

§ 3Architecture of the applications layer

The dashboard is the workflow interface. The decision model is a reusable interpretation component. Settlement on Base, Arbitrum and Solana supplies chain-authenticated facts for the payments that run there; the dashboard works equally on imported records from any rail.

Six fact layers, never merged. Every value the dashboard shows carries the layer it comes from. There is no single “truth” column, so every number can be traced and defended.

The six fact layers. Example values are illustrative.

What the system never infers: legal jurisdiction from wallet or network location; residency or entity status from an address; legal or tax treatment from an economic-purpose label; delivery, quality or tax treatment from a signed claim; chain authentication for an imported record. Three layers are never merged: economic purpose (what the payment was for), transaction mechanics (how the money moved) and legal or tax treatment (what the law says).

Data handling. Permissioned data only, under a written agreement; minimum necessary fields; explicit retention and residency; separation of customers’ data. Whether data may leave the customer’s environment, for example to a third-party model API, is the customer’s decision.

§ 4Zlef: the payment decision model

Zlef answers a fixed set of typed questions about each payment and attaches a probability to every answer. It is inspired by typed decision models such as TypeSafe’s Jev and Cloudflare’s Clef in three respects only: outputs are typed and bounded, every output carries a probability, and decisions are not free text. Zlef adds the ability to say “unknown” or decline to decide. Jev and Clef serve as baselines. Researching

The core thesis. Legal category is a function of asset facts, jurisdiction and date. A model should predict the facts, and a versioned rules layer should compute the category, which makes legal change a rule edit, not a retraining run, and keeps the model’s errors measurable. A tokenized money-market fund share can be a security in one regime, a crypto-asset in another and unregulated in a third.

The Zlef label schema. Legal category, tax treatment and flags are never outputs.

Five design principles. Predict facts, not law. Read before predicting: a question settled by a record (a token contract in a maintained registry fixes the asset class) is answered from the record. UNKNOWN is a label about the evidence; abstention is a separate decision about the model. A hierarchy allows partial answers. Ordinal where order is real, and nowhere else.

Calibration. Probabilities should mean what they say: among items predicted at 0.8, about 80% should be right. Modern neural classifiers are often miscalibrated. The tools are reliability diagrams, expected calibration error and the Brier score, measured per category, on held-out data, and re-measured over time because calibration drifts.

Abstention. Three mechanisms are compared. M1: UNKNOWN as an explicit class, which abstains when evidence is missing but not when the model is torn. M2: a cost-based threshold: decide only when the least expected cost is below the cost of review, paired with a guaranteed bound on selective risk. M3: conformal prediction sets: decide when the set holds one answer, back off to the common parent when it holds siblings, otherwise abstain. An abstention is shown to the reviewer as “model did not decide”, a normal outcome, not an error.

Costs come from the flags. A wrong answer matters only through what the rules do with it, so each question’s cost matrix is derived from the flags that would fire under the true answer and under the predicted one. Missing a flag costs at least as much as raising it spuriously at the same severity, and a missed block flag, such as a sanctions hit, is the most expensive error. The numbers are set with the first buyer.

Explanations are kept apart from scores. The dashboard may show the facts a prediction depended on, or a short generated rationale, but a rationale is display material: never used to compute, adjust or justify a probability. Adversarial text. Memo and invoice text is attacker-controllable: a counterparty can write “refund” in a memo, or embed instructions aimed at a language model. Text fields are data, and high-cost flags never rest on a model label alone.

§ 5Rules, review and audit

Legal and tax treatment are determined by a versioned rules layer and human review, not by the model. Each rule is a versioned record with its jurisdictions, its condition over facts and predictions, the flag it produces, the source it encodes with a citation, its effective dates, version and owner. A rule match means the condition held on the inputs shown; it is not a legal conclusion. The compliance research builds this layer: see Compliance.

A reviewer sees, for each flagged or abstained item, the facts with their layers and what is missing, the model’s predictions with probabilities or that it abstained, the rule that fired with its version, source and date, and the evidence links. They confirm, correct or escalate. Exports carry the layer of every value, so downstream accounting or tax software can tell a reviewed conclusion from a prediction.

§ 6Evaluation, in seven steps

Each step decides whether the next is worth doing. (1) Scope: one buyer and workflow; define the taxonomy with them. (2) Data: a permissioned, labelled evaluation set, recording who labelled what. (3) Baselines: simple rules, an existing decision model, and a general model with structured output, on the same items. (4) Metrics per category: precision and recall, calibration, abstention and coverage, reviewer correction rate and review time, latency and cost, and the cost of each error type. (5) Splits and drift. (6) Optimization where a measured gap justifies it. (7) Decide: continue, narrow, change or stop.

Research questions. Researching Are per-category probabilities calibrated on held-out customers and later periods, and how fast do they drift? Which abstention mechanism gives the better risk–coverage trade? Does a partial-credit objective help nominal questions, and what would “adjacent” mean there? Does a specialized model beat rules and general models enough to justify its cost? How easily do manipulated memos change labels? How much do anchored corrections bias training data? Which questions can be answered with minimum fields or selective disclosures? Does chain-authenticated provenance reduce review effort?

Hosting and data permission.

§ 7What the chain contributes

Settlement on Base, Arbitrum and Solana gives chain-authenticated facts for the payments that run there: amount, asset, accounts and timing, read straight from the chain. A transaction authenticates those, not purpose, the counterparty’s identity in the world, delivery, or tax treatment. Private payouts disclose only what holders choose. Signed responses and receipts are evidence of what a party signed. Bank and processor records are layer B and are never presented as chain-authenticated.

§ 8Decisions and status

Set with the first buyer: the workflow; initial jurisdictions (one or two); the taxonomy; data sources and permissions; baselines, and whether data may go to a third-party API at all; evaluation criteria; who owns and signs off the rules; the reviewer workflow; and where the model runs. Pending

The full methodology: Payment facts (PDF), and the research document for Zlef, with the legal ontology of twelve asset classes and the label dictionary: Zlef (PDF, 174 pages).