Agentic Settlements and Payments

A Federated Settlement Layer Beneath Machine-Payment Protocols

Luuk Joseph Soons · CounterProof Research

Conceptual preprint, draft v0.19 (corrected revision) · 11 November 2026

Deposited on Zenodo on 11 November 2026: 10.5281/zenodo.24146216. This web page is a reading copy of the deposited text.
Author's affiliation on the Zenodo record: CounterProof Research, a practice of Clavestra Capital Limited (Malta, C 113987). ORCID: 0009-0000-3088-6373.

A design framework and research agenda. No system described here operates. No study proposed here has been run. Not peer reviewed.

Note on this revision. Draft v0.19 corrects several statements about Fedimint in v0.18, makes seven changes prompted by two cold reads, and withdraws or narrows five of v0.18's rewrites. Appendix F lists the changes, and the points that were raised and not changed. No hypothesis was changed, apart from one addition to the evidence against H1. The claims of status and the terminology of v0.16 are unchanged. The Fedimint-contributing collaborator was not available and has reviewed no change made after v0.16, including the plain-language rewriting of v0.18 (Appendix E). The checks made on this revision are described in the Disclosure. They were not a review round by a panel.

Abstract

Software agents can now request, authorise and complete payments through open protocols: HTTP 402 schemes such as x402 and the Machine Payments Protocol (MPP), mandate formats such as AP2, and checkout and tool-calling standards. These protocols standardise the conversation about payment. They leave open where the payment settles and who answers for it. Today the answer is usually a public blockchain, which publishes payer, payee and amount, or the card networks, which are identity-forward and priced for human purchases.

Recent security analyses report two kinds of problem. In formal models of the leading protocols as specified, they find missing bindings between authorisation, settlement and fulfilment. In practical attacks on x402, they find races between a synchronous HTTP request and asynchronous settlement. They do not claim that every implementation behaves the same way.

This paper proposes a design framework for a different answer: a federated settlement layer beneath the protocols, in which independent, legally named guardians run a Fedimint-style federation whose mint module issues threshold-blind-signed bearer e-cash. We set out requirements for agentic settlement and derive a four-layer reference architecture from them. We describe a protocol-neutral attachment pattern built on three client operations of Fedimint's original mint module (spend, validate, reissue). One variant uses a signed transaction: the payee's HTTP 402 challenge carries its own blinded outputs, and this removes the bearer race when the challenge is authenticated.

Two delegation modes are stated as a trade-off. Durability rules govern the one irreversible step. A two-record model keeps an identified account of payments apart from an unlinkable record of value, and we state what it does not achieve. Function-separated federations carry sign-only attestation and bonds. Each component carries its residual risks. No component has been built to the standard the framework requires, and no figure in this paper is measured. We close with hypotheses, each with the result that would refute it, and with the evaluations that would test them.

Keywords: agent payments; settlement; Chaumian e-cash; threshold blind signatures; Fedimint; delegation; payment finality; privacy and supervision; attestation; institutional design

In brief

• Agent payment protocols standardise how an agent asks to pay and how a payment is authorised. They leave open where the payment settles and who answers for it (Section 1).
• The paper proposes a federated settlement layer beneath those protocols: independent, named guardians running a Fedimint-style federation that issues threshold-blind-signed bearer e-cash (Sections 4 and 5).
• The design keeps two records of each payment, an identified account record and an unlinkable record of value (Section 8). It keeps treasury and mandate-authoring keys off the agent (Section 6), makes the irreversible step safe (Section 7), separates judgement from custody (Sections 9 and 10), plans for its own permanent failure (Section 9.3), and is to be verified adversarially before it holds value (Section 11).
• Nothing described here operates, no study has been run and no figure is measured. The paper ends with eight hypotheses, each stated with the result that would refute it (Section 13).

Where to start

• Readers on agent payments: Sections 1 to 3, then Sections 5 and 6.
• Fedimint maintainers: Table 3 (the vocabulary map), then Sections 4.3, 5.3, 7 and 9, and Appendices B and C.
• Readers on supervision and compliance: Sections 8 and 10.
• Readers who want the evidence and the limits: Sections 11, 13 and 14.

1. Where does an agent's payment settle?

A research firm deploys an orchestrating agent to compile a market report. Over an afternoon the orchestrator spawns several hundred short-lived sub-agents. Together they make on the order of a hundred thousand calls to data services, models and search tools, most priced at a fraction of a cent. Each call is authorised and paid through a 402-style protocol.

This case is hypothetical and its figures are illustrative. Whether any federated design can carry that many settlements in an afternoon has not been measured. Prepaid sessions that meter many calls against one settlement would reduce the load, and consensus throughput is listed among the open questions in Section 13.

If the payments settle on a public chain, each sub-agent needs a key, and the firm's purchasing pattern for the afternoon is published to everyone, including its competitors. If they settle on card rails, each call is a transaction in a system whose minimum fee exceeds its value, and each agent's spending authority is a credential that can be stolen. Either way, the protocol that carried the request does not say who answers if a payment is taken twice, if the service is not delivered, or if an agent is turned against its principal.

Our central question is:

What settlement institution should sit beneath machine-payment protocols, so that agents can pay at machine tempo while their principals keep confidentiality, bounded loss, a defined finality point, accountability and resistance to unilateral seizure?

The scope is settlement and accountability, not checkout design, agent identity in general, or the economics of particular markets. The paper is a design framework and research agenda. It reports no operating results, because no system of the kind described operates.

We offer the following contributions, each developed from a body of design and review material described in Appendix B and stated here with its limits:

1. A layered reference model (Section 4). Protocols are untrusted access surfaces. Orchestration records and gates but never signs. A boundary service is the single trust boundary. Federations are the trust root.
2. Settlement beneath the protocols: a protocol-neutral attachment pattern over Fedimint's spend, validate and reissue operations, and a signed-transaction variant with receiver-authenticated challenges (Section 5).
3. Two delegation modes stated as a trade-off: a bounded bearer float, or a mandate exercised by a separate payment service that is in effect a hot wallet with limits. Humans author authority; machines enforce it (Section 6).
4. Durability rules for systems whose only irreversible step consumes a bearer instrument, with "compensation is not finality" (Section 7).
5. A two-record model, "unlinkable, not unrecorded", scoped by delegation mode, with its residuals named (Section 8).
6. Function-separated federations with coalition arithmetic for theft, halting and coercion, a pre-committed recovery path, and sign-only attestation backed by bonds (Sections 9 and 10).
7. A failure-class catalogue from adversarial review of prototype settlement code, and the argument that verification must precede custody (Section 11).
8. Falsifiable hypotheses and proposed evaluations (Section 13).

2. Authorisation is standardised; settlement is not

2.1 The protocol field

Table 1 summarises the agent payment protocols as reported in a dated sweep of public sources (30 October 2026). Several facts in it rest on vendor or press sources, and Appendix B states the provenance limits; the table describes positioning, not verified behaviour.

A note on one abbreviation. Throughout this paper MPP means the Machine Payments Protocol, an HTTP authentication scheme [3]. It does not mean Lightning's multi-part payments, which share the abbreviation. Where Lightning multi-part payments are meant, they are written out in full.

Table 1. Agent payment protocols as positioned in public sources.

Read as a stack rather than a race, the field has these layers, from the top:

• checkout protocols;
• authorisation and agent identity;
• machine-payment protocols;
• settlement substrates;
• wallet and custody services for agents; and
• at the base, the regulated institutions that answer for the money.

Most new standards sit in the upper layers. The settlement substrate is either a public chain or a card network, with two smaller alternatives. Lightning offers fast bitcoin payments with good privacy for small amounts. Single-operator e-cash mints already speak HTTP 402 [5]. Neither of the smaller alternatives offers multi-jurisdiction custody with a supervised, regulated counterparty.

A pattern recurs in the wallet layer: the agent is given a wallet. Attenuable tokens and remote signers [4], together with the session limits, policy engines and secure hardware that wallet providers offer, make the wallet safer each year. What the agent holds is still a credential tied to its principal's account.

2.2 What the security literature has found

Four analyses published in 2026 bear directly on settlement.

• Two independent studies of x402 report practical attacks. One reports payments made while service is denied [11]. The other reports duplicate settlement, which in our gloss comes from a race between the HTTP request and on-chain settlement [12]. Across the two, they report failures of replay protection and resource binding [11, 12].
• A systematic analysis of AP2 reports that valid mandate signatures do not guarantee that a purchase matches the user's intent. This happens when the context before authorisation, such as agent messages or tool calls, is manipulated [13].
• A formal analysis in Tamarin of x402, MPP, ACP and AP2 reports previously undocumented findings, among them missing bindings between authorisation, settlement and fulfilment across protocol stages. Its models are derived from the normative specifications. Its authors state that a result holds for the encoded model and trust boundary. A result does not imply that every implementation or deployment behaves the same way [14].

We have read [11] to [13] and [15] at the level of their abstracts and summary sections, and [14] also in its discussion of scope; their detailed claims are theirs. A systematisation of security for LLM agents in agentic commerce covers the wider attack surface [34].

Two further lines of work matter. A system-level analysis of deployed Chaumian mints reports that privacy fails in practice through keyset rotation, wallet recovery and multi-mint identity, even where the blind signature is sound [15]. Section 8.1 states which of those channels apply to Fedimint as it stands.

Work on delegation for agents proposes extending existing authorisation frameworks with agent credentials [16], and frames agent infrastructure around attribution, interaction shaping and remedy [17]. Central-bank analysis treats settlement finality as resting on central-bank money, and assesses private instruments against singleness, elasticity and integrity [18]. A Federal Reserve governor has described a shift in authentication: from establishing that the buyer is authorised, to establishing that the agent has the authority to pay on the buyer's behalf [19].

Our reading of this literature is that the protocols standardise the conversation about payment and leave the settlement institution unspecified. The gap is institutional as much as technical.

2.3 Chaumian e-cash as a substrate

In work presented in 1982 and published in 1983, Chaum showed how a bank could sign a token without seeing it, so that the token could later be redeemed but never linked to its withdrawal [20]. Offline variants followed [21]. A trial through a regulated bank, with real money, ran from 1995 to 1998. It did not lead to lasting adoption, and the company behind it went bankrupt in 1998 [35]. The reasons usually given are a single issuer, an absence of network effects and an internet not ready for payments. Supervision and blind signatures were not shown to be incompatible.

Two developments change the substrate:

• Threshold cryptography removes the single bank: the signing key is split among guardians, and a threshold of them must cooperate to issue.
• Bitcoin supplies a reserve asset that no issuer controls, with Lightning and other networks as rails in and out.

Fedimint is the reference implementation of the first development over the second [22, 43]. As read at the commits listed in Appendix B, a Fedimint federation is a fixed set of n peers ("guardians") running Byzantine fault-tolerant consensus (AlephBFT) over a set of modules. Table 3 in Section 4.2 maps the terms below to this paper's. The parts that matter here are:

• The mint module issues e-cash notes under a threshold blind signature scheme on BLS12-381 (the tbs crate). Each guardian signs a blinded message with its key share. A client aggregates a threshold of shares into one signature.
• Notes exist in fixed denominations (power-of-two amounts in millisatoshi). Each denomination has its own signing key. The set of denomination keys is fixed at the federation's distributed key generation and is not rotated. A note is a pair of a nonce, which is a secp256k1 public key, and the unblinded signature over it. Spending a note means signing the federation transaction with the nonce's private key, so whoever holds that private key holds the note.
• The wallet module holds the federation's on-chain bitcoin reserves behind a sorted multisig descriptor signed with separate secp256k1 keys.
• A Lightning module (ln, and the newer lnv2) lets a Lightning gateway (fedimint-gatewayd) swap e-cash for Lightning payments in both directions. The swaps use hash-locked contracts inside the federation.
• Deposits and withdrawals are called peg-in and peg-out.
• Every mint transaction has inputs (spent notes) and outputs (blinded nonces to be signed). It must conserve value: inputs cover outputs plus module fees. It is identified by its hash, the TransactionId.

Fedimint has two generations of mint and wallet modules. This paper describes the original mint module (fedimint-mint); for the wallet it says which module it means. At the later commit read, the newer modules (fedimint-mintv2 and fedimint-walletv2) are the ones enabled by default. The newer mint module differs where this paper relies on the original. Its client offers send and receive operations, with no operation that validates notes without spending them and no spent-nonce query, and its notes carry their denomination. How the primitive of Section 5.1 maps onto the newer module has not been examined.

Cashu offers the single-operator form of blind-signed e-cash. It uses a different signature scheme (blind Diffie-Hellman key exchange on secp256k1) and rotating keysets [5].

Fedimint's own documentation states its trust model plainly. A signing threshold of guardians, not a bare majority, could issue notes without backing or sign away the reserves. The mitigations are social and procedural [22]. Section 9.2 gives the threshold exactly. The sweep behind this paper found no Fedimint-based agent payment product.

3. Requirements for agentic settlement

We derive six requirements from the opening case. Each is stated with how the two dominant settlement answers fare. The assessments are arguments, not measurements.

Table 2. Requirements against the dominant substrates.

Two cautions apply:

1. Some users will reasonably prefer the defaults. A settlement layer of the kind proposed here would serve specific segments: operators whose payment flows reveal strategy, operators who will not depend on one jurisdiction, fleet operators for whom a wallet per agent is an attack surface, and Bitcoin-native commerce.
2. None of Q1 to Q6 is absolute. Q5 in particular is not exemption from law: entry and exit stay screened and lawful disclosure stays possible. What the design removes is unilateral seizure of value already held and unilateral reading of the interior. It does not remove an operator's power to refuse service at its boundary service (Section 4.3), and it leaves enforcement at the regulated boundary in place.

4. A reference architecture

4.1 Four layers

The architecture has four layers, each talking only to the one beneath it through one authenticated path:

1. Protocol surface. x402, MPP, L402, AP2, checkout protocols, MCP tools, A2A. Untrusted input; translation only; no state, no keys.
2. Orchestration. Durable workflows: records, retries, human gates, compliance screening, correlation identifiers. It never signs, never holds keys and never claims atomicity it does not have.
3. Boundary service. The single trust boundary: authentication of principals, mandates, limits, policy, and routing of instructions to the correct federation. (v0.15 called this the "gateway"; the word is reserved here for Lightning gateways.)
4. Federations. Independent guardian sets running consensus, the mint module's threshold blind signatures, and the wallet module's reserves: the trust root.

Agents and orchestrators are clients of the boundary service, never components of a federation. A compromised orchestration layer cannot forge a guardian signature or mint notes. It can originate instructions that the boundary service will execute within the authority attached to them, which is why mandates and limits are enforced at the boundary service rather than in the workflow.

4.2 Roles and vocabulary

These terms are used throughout:

• A federation is one independently governed settlement system: one guardian set, one consensus, one distributed key generation, running at least a mint module and a wallet module. The attestation federation of Section 10.4 is the exception: it runs neither.
• A guardian is a named legal entity operating one peer and holding one share of each module's signing keys.
• An operator is the accountable institution that serves customers, keeps the identified record, holds any required licence and carries the redemption liability; Fedimint has no such role, and this paper introduces it.
• A principal is the person or firm for whom an agent acts; an agent is identified as a sub-identifier of its principal, never as a customer in its own right.
• The boundary is where value enters and leaves (peg-in and peg-out, Lightning in and out) and where instructions enter (the boundary service); the interior is everything between.
• Lightning gateways and other connectors (chain backends, exchange links) are the external connections.

Table 3 maps this paper's terms onto Fedimint's, for readers who maintain it.

Table 3. Vocabulary map.

Guardians and operator have different relationships to the same protocol. Every guardian seat is equal cryptographically; legally, only the operator is intended to conduct the regulated activity. We call this cryptographic symmetry, legal asymmetry. Whether a given legal system accepts that allocation is for that system to decide; we treat each guardian's own legal confirmation as a launch condition, not a design outcome.

What guardians see should be stated exactly, because it is more than v0.15 implied. Guardians see:

• every accepted transaction: the nonces of spent notes, the blinded nonces and denominations of new outputs, the module fees, and the consensus session in which it was accepted;
• for peg-ins, the funding UTXO and amount;
• for peg-outs, the destination address;
• for Lightning contracts, the payment hash, amount and gateway; and
• the network address of whoever submitted the transaction, unless the client connects over Tor or Iroh.

What they do not see is any identity: no account, no principal, no agent sub-identifier, no correlation identifier. Blind signatures prevent them from linking an output they signed to the input that later spends it.

Guardians can refuse to sign peg-outs, consensus items such as metadata changes, attestations and slashing judgements. A threshold of them could also refuse to process transactions indiscriminately, by denomination or pattern, which would be visible censorship of the whole interior.

What they cannot do, from the protocol messages alone, is identify or target an individual payment in the interior by party. A guardian that also obtains a payee's challenge out of band, or sees boundary-service metadata, could recognise that payee's blinded outputs in a submitted transaction. What each observer can see, and with whom it may collude, are part of hypothesis H1.

4.3 Control points

Distributing signing power does not distribute every power. Two components concentrate control and are named as such.

The boundary service. In this design, guardians accept client requests only from boundary services. This is not a Fedimint feature: fedimintd exposes its client API to any holder of the federation's connection details, and only the administrative API is password-protected. The restriction is a deployment control, enforced at the network layer (firewalling or mutually authenticated proxies in front of each guardian's API) and verified as part of launch.

The boundary service cannot sign or move reserves, but it decides which instructions reach a federation, records them and enforces policy. It is where compulsion or capture would bite: an operator can be compelled to refuse service at its door, even though no one can reach a note already held. We therefore treat the boundary service as replicated, fail-closed and audited, and place it at the centre of the threat model.

The payment service. In mandated mode (Section 6.2) a payment service is a Fedimint client that holds a principal's notes and signs transactions for it. It is run by the operator or by the principal, always in a process separate from every agent. Its compromise loses everything it holds, not merely what one mandate allows, so its holdings are kept to what its mandates need.

Where the principal runs its own payment service, the payer-side record of mandated payments is the principal's, not the operator's. The operator then holds only the payee-side record for those payments, as in float mode. The detector of Section 8.4 treats them accordingly. Whether the operator may require the principal's record is a contractual term this design leaves open.

4.4 The canonical flow

One canonical path governs every payment:

Every settlement passes a boundary service. A payee who receives notes, whether a merchant, a data service, a 402 resource server or another agent's principal, reissues them through its own authenticated boundary-service session. In stock Fedimint the payee's client would submit the reissue transaction to the guardians directly; here the network restriction of Section 4.3 forces it through the door.

A resource server that validates and reissues is a payee using the same door, not a second door into the mint. Its reissue leaves a payee-side record. Where a signed transaction (Section 5.3) is submitted by a facilitator rather than the payee, the boundary service accepts it only with the receiver-authenticated challenge it pays. It records the transaction against that receiver, not against the submitter.

The record differs by delegation mode:

• Mandated payments are recorded on both sides: the payer's instruction first, by the payment service; then the payee's reissue.
• Float payments are recorded on the payee side only. The payer side of a float hand-off is known only at the moment the float was issued.

Everything later said about records, monitoring and attribution is scoped by this distinction.

5. Settlement beneath the protocols

5.1 One primitive

Every agent payment protocol ends in the same question: what does the payee receive, and when is it final? Wherever the payee accepts e-cash, the answer here is one primitive, built from three client operations of Fedimint's original mint module:

1. the payer spends: it hands over notes, or signs a transaction paying the payee's blinded outputs;
2. the payee validates without consuming: it checks the notes' signatures against the federation's public keys and queries the spent-nonce set;
3. the payee reissues through its boundary service: a transaction with the received notes as inputs and fresh blinded outputs of its own; and
4. the reissue is final when consensus accepts that transaction.

Where the payee wants fiat or Lightning instead, value leaves the federation through a Lightning gateway or a fiat connector. The payment is then final only when that exit leg settles too (Section 7.2, rule 5).

Each protocol becomes an envelope around the primitive. We call this settlement, not distribution: protocols bring customers to a settlement point; supporting a new protocol means writing an envelope, not a settlement system.

5.2 Attachments and what each binds

Table 4 gives target attachments. "Design" means specified on paper only. "Prototype" means some implementation exists in the project's material, in some cases wired into a prototype boundary service, but none has been independently reviewed, deployed or used with real value. These labels describe the project's own artefacts, not the protocols.

Table 4. Attachments.

The "leaves unbound" column is the important one. None of these attachments binds a payment to evidence that the service was delivered. The analyses reviewed in Section 2.2 report related gaps in the protocols they model, and delivery binding is listed among the open questions in Section 13.

5.3 Removing the bearer race

The simplest attachment sends spendable notes in the request: out-of-band notes, which carry the nonces' private keys. Between the moment the payee sees the notes and the moment its reissue is accepted, anyone able to observe them can race to spend them.

A stronger attachment removes the race. Chaumian transfers need a round trip, and a 402 challenge is one. The steps are:

1. The payee's challenge carries blinded outputs of its own: a list of (denomination, blinded nonce) pairs summing to the price, for which only the payee holds the blinding keys.
2. The payer, in mandated mode the payment service, builds a complete federation transaction. Its inputs are the payer's own notes. Its outputs are exactly the payee's blinded nonces plus the payer's own change outputs, covering module fees. The payer then signs the inputs with their nonce keys.
3. It returns the signed transaction rather than loose notes. Anyone may submit a signed Fedimint transaction, so a facilitator, if present, can verify and submit it. But the outputs are fixed by the signature, so the facilitator can neither redirect the payment nor take custody.
4. After acceptance the payee fetches the blind signature shares for its outputs by transaction id and output index and unblinds them; nobody else can.

A TransactionId deduplicates one transaction, not one obligation. The payment service therefore binds each challenge to exactly one transaction, recorded durably before it signs. A retry after an unknown outcome resends that same transaction rather than building a new one. A resubmitted transaction is idempotent at consensus: consensus either reports it already accepted or rejects it for spent inputs. A challenge's outputs are never placed in a second transaction. The TransactionId then serves as the idempotency key for submission. A transaction rebuilt from the same inputs and outputs would in practice have a different TransactionId, because the client's transaction builder draws a fresh random nonce for each build.

By itself this binds the payment to whoever wrote the challenge, not to the receiver the payer intended. A challenge is untrusted input, and an attacker can present its own blinded nonces under a legitimate receiver's name. The binding becomes meaningful only when two things happen before the payment service signs: the receiver authenticates the challenge, and the payment service checks it against the receivers the mandate permits.

We propose that receivers' challenge keys are first held in a receiver-key register at the boundary service. They are entered at identified onboarding, and later carried in the receiver's attestation (Section 10). With the check, payment, challenge and permitted receiver are bound together. We do not claim that this binding is absent from other protocols. The claim is only that this attachment specifies it.

On receipts: Fedimint guardians already sign the outcome of every consensus session, so a transaction's inclusion in a signed session outcome is a threshold-signed proof that it was accepted. What remains to be designed is a compact per-transaction receipt derived from that evidence, one that a payee can hand to a third party without that party learning anything beyond what the guardians already see.

6. Delegation: keys, cash and mandates

6.1 The credential dilemma

Approaches that give an agent spending power sit between two poles:

• At one, agents hold their principal's credentials, so that each compromised agent is a compromised treasury.
• At the other, each agent gets its own account and key, so that a fleet of thousands of ephemeral agents becomes thousands of pseudo-customers that no due-diligence regime can administer.

Most arrangements sit between the poles. Session limits, attenuable tokens, remote signers, and restricted mandates with deterministic validation already bound what an agent may do, as in AP2 [6] and in work on authenticated delegation [16]. They narrow the dilemma without removing it, because the agent still holds a credential tied to its principal's account.

Bearer value offers a different trade: an agent can be given bounded spending power without access to its principal's treasury or credentials. Bounded authority is not new; what this paper proposes is the settlement and institutional arrangement around it.

6.2 Float mode and mandated mode

Float mode. The agent holds a small amount of e-cash issued for a purpose, an amount and a time, and pays by handing over notes. Because a Fedimint note is spendable by whoever holds its nonce's private key, the agent necessarily holds those keys, and loss under compromise is bounded by the float. Authorising an autonomous payment becomes a question of float sizing. Its limits are real: once the agent holds the notes, any rule about spending them is advisory, and its individual payments are recorded only on the payee's side.

Mandated mode. The agent holds no notes. It holds a mandate: a signed, expiring, amount-capped grant naming principal, agent, permitted receivers and limits per payment and per period. The notes are held by a separate payment service, a Fedimint client. When the agent wants to pay, it forwards the payee's challenge to the service, which:

• checks the request against the mandate on its own clock;
• verifies the receiver's authentication;
• selects and locks specific notes for the amount plus fees;
• builds and signs the transaction; and
• settles the reservation when the federation reports acceptance.

It releases a reservation only when the federation rejects the transaction or accepts a conflicting self-spend of the same inputs, never on the agent's word. The mandate's remaining balance is computed from an append-only log. Mandated mode is only as strong as its separation: if the service runs in the agent's process, a compromised agent is the authority.

Expiry and revocation race the signed payment. A mandate's expiry stops new payments under it. It does not stop a transaction already signed and handed to a payee, because Fedimint transactions carry no expiry. On expiry or revocation the service attempts to cancel outstanding transactions by spending the reserved notes back to itself. The two transactions conflict on their inputs. Whichever consensus accepts first settles, and the other is rejected as a double spend. Cancellation is confirmed only when the self-spend is accepted. Until then the reservation stays open and the payment is treated as possibly settled.

The race also has a payee side: a principal could revoke at the moment of hand-off to claw back a payment for which the payee has already delivered. Two rules close it:

• The service may not cancel a signed transaction until a window stated in the challenge has passed without the payee submitting it.
• Payees deliver only once their reissue is accepted (Section 4.4), not on receipt of a signed transaction.

Limits aggregate at the principal. A hundred sub-agents with small limits have not been granted a hundred times the principal's intent; every sub-agent's spending counts against the envelope the principal signed.

The modes trade differently. Float mode bounds loss by the float and gives up per-payment attribution on the payer side. Mandated mode bounds a compromised agent's loss by the mandate and keeps two-sided records, at the cost of a hot wallet whose own compromise loses its holdings. Which yields lower loss for which workloads is hypothesis H3.

6.3 Humans author authority; machines enforce it

A tension runs through agentic finance. Safety argues that model output should reach real authority only through a human decision. Autonomy argues that agents must pay each other without a person approving each transaction.

We resolve it by separating creating authority from exercising it. Creating or widening authority is a human act, signed with a key the agent cannot reach through a channel it cannot read. Examples are granting a mandate, raising a limit, adding a permitted receiver, issuing a float, and moving a principal to a higher identity level. Exercising authority inside an existing grant is a machine act, checked deterministically at the boundary service every time. The human writes the envelope, the machine enforces it, and the agent acts freely inside it.

6.4 Keeping the reader away from the wallet

Suppose an agent reads untrusted content (a web page, a payment challenge, a tool description, a counterparty's message) and can also call a payment tool. That agent is a payment tool available to whoever wrote the content [13]. No instruction in its prompt changes this. The architecture therefore requires that:

• an agent processing untrusted content holds no payment tools;
• no treasury, guardian or mandate-authoring key is reachable by an agent, and no agent runs on guardian hosts. (A float agent necessarily holds the nonce keys that spend its own notes, which is why the float is capped. How the client stores those keys at rest has not been checked.)
• agents are boundary-service clients enforced by the network;
• tool lists are default-deny; and
• every mandated action carries the agent's sub-identifier and a request identifier recorded at the boundary service, so that attribution does not depend on the agent's account of itself.

Prompts are never controls.

7. Durability and finality

7.1 Reissue before finality

In bearer e-cash, the reissue is irreversible: once consensus has accepted the payee's reissue transaction, the payer's notes are spent. A payment can still fail after that moment in the payee's own software: a timeout waiting for the acceptance to be observed, a wrong amount discovered late, or a crash before the receipt is written. If the system then reports a failure that invites a retry, the result is a double charge, a spurious double-spend error to an honest payer, or funds held by the payee while the payer is told the payment failed.

No attacker is needed; a slow guardian suffices. Adversarial review of the project's prototype settlement code found this failure in several independently written components (Section 11). We call it reissue before finality.

7.2 Five rules for the irreversible step

Any system whose only irreversible step consumes a bearer instrument should obey five rules:

1. Validate before custody. Every condition that can be checked before the reissue is checked first by a read-only validation:

   • the federation id prefix carried by the notes,
   • the amount and denominations,
   • expiry of the challenge,
   • the signatures against the federation's public keys, and
   • the spent-nonce query.

   The spent-nonce query is advisory: a note unspent at the query can be spent before the reissue is accepted, and only consensus decides. Fedimint's own client documentation warns that the query reduces privacy and can race. A guardian that answers it learns the nonce before the reissue, and learns it even if the note is never reissued. Rejecting underpayment after the reissue seizes the funds and reports failure. Failures that can arise only afterwards, such as a timeout on the acceptance check or a crash, are governed by rules 3 and 4.

2. Claim exactly once. Settlement is claimed atomically under a stable key; a concurrent attempt receives the first attempt's receipt. Deployment topology is declared; multi-process deployments use a fenced distributed lease.

3. Never signal a retryable failure after custody. After the reissue transaction has been submitted, the only answers are success, a rejection reported by consensus, or a distinct "submitted, acceptance pending" state.
4. Record intent before the point of no return, so that recovery can distinguish an interrupted settlement from notes spent by someone else, and never reissues blindly.
5. Make multi-step flows reconcile. A payment with more than one irreversible step keeps a durable log of each leg and a defined reconciliation for every partial state.

On the paying side, wherever a service spends for others, the exact note set and intended payment are written at one server-side gate before spending, so that a retry spends the same notes or none. Fedimint's own client persists its state machines in a local database and resubmits a pending transaction until the federation accepts or rejects it. These rules generalise that behaviour to the services wrapped around the client. A float agent spending its own notes passes no such gate. Its exposure is bounded by the float.

Outcomes that cannot yet be known are recorded as outcome unknown, not guessed as failure. One principle governs all five rules: compensation is not finality. Issuing new value to offset a consumed instrument is a new event with its own risks.

These rules are positioned against the races reported for chain-settled 402 flows [11, 12]. They do not remove the need for a finality signal; they define what a component may say before and after it.

7.3 What federated finality rests on

A federated e-cash payment is final when consensus accepts the reissue transaction: the spent nonces are recorded and can never be spent again. The blind signature shares for the new outputs are produced by each guardian after acceptance and can be fetched at any later time. Collecting them is not part of finality. It is part only of the payee's ability to spend next.

This differs from probabilistic chain finality and from card reversibility. It is a private guarantee resting on:

• the federation's solvency,
• no more than ⌊(n − 1)/3⌋ of its guardians being faulty (Section 9.2), and
• continued operation or, failing that, a working recovery path (Section 9.3).

It is weaker than settlement in central-bank money [18] and stronger than a single custodian's promise. The design's obligation is to make each dependency visible and checkable.

8. Two records of one payment

8.1 Unlinkable, not unrecorded

Privacy and accountability are often framed as a trade-off. We treat them as two records of one event.

The account record says who instructed which payment, to whom, when, through which surface and with what compliance outcome. It is identified, and it is producible on lawful request. The operator retains it, except on the payer side of mandated payments through a principal-run payment service, where the principal retains it (Section 4.3). For mandated payments it is written when the instruction arrives, before value moves, and completed at the payee's reissue. For float payments it exists at the payee's reissue and, on the payer side, only at the issue of the float.

The settlement record is the spend and reissue of blind-signed notes. What blind signatures hide, they hide from everyone: no party, including operator and guardians, can cryptographically link a note's issuance to its spend. They do not hide what the operator records for its own reasons. They also do not hide denominations, timing or the submitting network address from the guardians.

The protection is therefore specific. Guardians see no identities. Outsiders see nothing. The operator's knowledge is limited to the payments it was instructed to make and the reissues it handled, and it holds that knowledge under supervision and law. Correlation identifiers that follow a payment through the operator's systems never enter a transaction the guardians see.

This is a design claim about what is recorded, not a privacy measurement. Of the three system-level privacy failures reported for deployed mints [15], one does not arise in Fedimint as read, one does, and one depends on how the client is deployed.

• Keyset rotation does not occur in Fedimint as read: denomination keys are fixed at key generation.
• Wallet recovery does apply: Fedimint's backup-and-restore scans the federation's history to rebuild a wallet, and the pattern of that scan is observable.
• Multi-federation identity depends on deployment. As read, the client by default derives a separate root secret for each federation, so its notes in different federations do not share keys. A link between them can still arise from the network or from the application, wherever one client holds notes of several federations.

Denomination mix, timing, Lightning gateways, boundary-service metadata, challenges disclosed out of band and the payment service's own transcripts are further channels in a design like this one. The anonymity set of a real federation must be measured (H1).

8.2 Identify at the doors, not in the room

The cash economy identifies a customer at deposit and withdrawal and does not follow the banknotes between. The design reproduces this with controls physical cash lacks:

Screening at the boundary. Every peg-in, peg-out and Lightning transfer is screened before notes are issued or reserves released. Stock Fedimint has no screening hook: any client that can reach the guardians can peg in and receive notes. The control therefore depends entirely on the network restriction of Section 4.3. Value arriving over a Lightning gateway is a deposit like any other, credited only through the boundary service to an identified principal after screening.

An identified ladder. More value requires more identity, approval and supervisory sign-off. The ladder starts with an identified level. An anonymous level below it is possible only where law permits, and only with a mechanism that caps it without identifying the holder. Such a mechanism does not yet exist in this design, so the level is absent.

Monitoring where there is something to see. Mandated agents are monitored per agent. Float agents are monitored at float issue and top-up; payees are monitored at their reissues, as recipients, without attribution to the paying float, which the design cannot supply.

Tamper-evident instruction logs, chained and periodically anchored. Periodic anchoring can support independent verification of a retained instruction-log checkpoint. One option, not implemented here, is to commit a batch root to Bitcoin through OpenTimestamps [40, 41]. The limits of that option are these:

• What a completed proof supports: prior existence of the committed data, subject to cryptographic and chain assumptions and a stated confirmation policy.
• Timing: block-header time does not give an exact document-creation time [42], and a pending receipt is not a completed Bitcoin proof [41].
• Availability and privacy: records, inclusion proofs and completed timestamp evidence must remain available to authorised verifiers in access-controlled archives. Commitments do not recover missing evidence. Public commitments also need privacy protection against guessing predictable records.
• What an anchor does not establish: authorisation, payment completion, completeness of the log or truth of an oracle's statement; the authentic-but-wrong judgement in Section 10.4 remains possible.
• What remains to design: the choice of an anchoring mechanism, and the specification of checkpoint identity, timing uncertainty, privacy protections and behaviour while proofs are pending. These remain requirements to design and test. The additional value of anchoring should be compared with signed logs and independently retained checkpoints.

Identity levels and caps are boundary-service policy, not mint features. Blind-signed notes carry no metadata and the mint cannot see holders. Fedimint notes do have denominations, each under its own key, and the mix of denominations a client uses is visible to guardians. But every principal, whatever its identity level, draws on the same set of denomination keys. Keeping one keyset for all principals keeps the anonymity set whole. Issuing a separate keyset per identity level would partition it and is ruled out.

8.3 Machines as originators

When an agent initiates a transfer to another institution, we propose that the originator is the accountable legal person whose authority the machine exercises, with the agent carried as a sub-identifier. We believe this matches how automated corporate payments are commonly treated, but we have not checked it in detail against the transfer-information rules [23]. It is an interpretation and has not been tested with any supervisor.

8.4 Supervising the operator

Reserve proofs show what a federation holds, not whether that covers what it owes, and neither shows that the operator's account record is complete. Fedimint does keep an internal audit in which each module reports its assets and liabilities, so guardians can see whether the wallet module's UTXOs cover the mint module's outstanding notes. That audit is visible to guardians, not published, and says nothing about the operator's records.

We propose, as a detector and not a proof, an independent series. Guardians, who see every transaction and no identities, publish counts of settlement events by category. The operator publishes counts of instructions and reissues recorded. The series are not one-for-one even when everyone is honest, because one payment may produce several transactions, and float hand-offs and payments through a principal-run payment service produce reissues with no payer instruction in the operator's record. Comparison is therefore made against defined expected differences.

A growing residual is a signal; a matching count proves nothing, since an operator can omit one instruction and invent another. Turning the detector into a proof needs per-settlement blinded commitments that the operator cannot fabricate and guardians cannot read, which remain to be constructed.

8.5 Residuals

Three residuals apply to the design as specified, and a fourth would arise only if a lawful anonymous level were introduced later, in which case small amounts would circulate unobserved, as cash does. The three:

• Value that circulates in a closed loop escapes exit screening.
• Bearer notes held by a later-sanctioned party cannot be frozen; the control is that the holder cannot peg out or use the boundary service.
• Notes can leave through a different identified principal than the one who brought them in: the exit screen checks the redeemer, not the notes' history, which by design has none.

Account-level analysis of who receives from whom is a proposed mitigation, not a cryptographic one.

9. Federations of federations

9.1 One function per federation

A single federation doing custody, payments, attestation and markets would concentrate every risk. A Fedimint federation can run several module instances under one guardian set and one key generation, but that shares the trust root. Separation here means separate federations, each with its own guardians, legal entities, consensus and keys. We separate functions into:

• a reserve federation for long-term reserves, treasury and bonds;
• a settlement federation that issues spendable notes against its own operating reserves;
• an attestation federation that signs and holds nothing; and
• a markets federation that settles against reserves held elsewhere.

The everyday cycle of peg-in, spend and peg-out runs inside the settlement federation.

Movements between federations are batched treasury operations, implemented as two separate legs reconciled by durable record (rule 5), not by cryptographic locks. While one leg has settled and the other has not, the value in flight is an exposure of the operator that initiated the movement. The exposure is capped per movement and in aggregate, and the cap is published. A leg rejected or stranded by a halted federation is reconciled under rule 5 (Section 7.2), not compensated.

What Fedimint offers today for moving value between two federations is a Lightning gateway standing between them. There is an outgoing contract in one federation and an incoming contract in the other. Both are locked to the same payment hash, with timeouts. That gives hash-time-locked conditional atomicity, which depends on the gateway's liquidity and the contracts' timeouts. It is not a joint consensus over two interiors. This paper specifies no protocol for atomic movement between federations; any such protocol would have to preserve the separation of their keys and governance.

Separation protects against compromise of one set of keys. It does not protect against a single party holding a signing threshold in several federations. While seats are under common control, as they may be at genesis, that fact must be disclosed.

9.2 Three coalitions

Theft, halting and coercion need coalitions of different sizes. Fedimint derives everything from n, the number of guardians. At the commits read (Appendix B), fedimint-core defines the maximum number of faulty guardians as f = ⌊(n − 1)/3⌋ and the signing threshold as t = n − f. For n = 3m + 1 this gives f = m and t = 2m + 1. For other n the floor means that extra guardians add no fault tolerance until n reaches the next value of the form 3m + 1. So n = 5 tolerates one fault and needs four signatures.

The same threshold is used for the mint module's blind-signing keys and, in the newer wallet module's reserve descriptor, for peg-outs. Consensus tolerates f faults and needs n − f guardians online.

Worked values of these formulas.

We set the signing threshold at t = n − f, which is Fedimint's default. Any t of at least f + 1 would be formally safe against f faulty guardians if honest guardians signed only what consensus had accepted. But at t = f + 1 the margin is zero. One honest guardian tricked into signing, or one share released outside consensus, completes a coalition with the f faulty ones. Because the message is blinded, a note minted that way could not be identified afterwards.

At t = n − f, n − 2f honest guardians would have to fail in that way. For n = 3m + 1, that is m + 1 of them. Mint keys and wallet keys are separate, and peg-outs are never blind-signed. Stealing through the guardians' keys therefore needs t guardians; theft through a payment service, a wrong slash or the recovery quorum is treated in Sections 4.3, 10.4 and 9.3.

Halting needs f + 1 offline. With ten guardians (f = 3, t = 7), seven are needed to move funds and any four offline halt the federation.

Coercion needs whatever the coercer can reach. Independence must therefore be counted against the smaller coalition: no single site, hosting provider, legal bloc or controlling party may hold more than f seats. Counting by legal bloc rather than country matters because allied states cooperate.

9.3 Halting, recovery and claims

A federation that cannot reach its threshold should halt rather than lower the threshold or shrink the set. Fedimint behaves this way by construction. Membership and keys are fixed at distributed key generation. There is no protocol for adding, removing or replacing a guardian, or for re-sharing keys. Consensus simply stalls while fewer than n − f peers are reachable.

Replacing a guardian today means either a new federation and a migration of value, or an operational hand-over of a guardian's key material outside the protocol. Halting is safe against theft, but a permanent halt also leaves holders unable to peg out.

We therefore propose that reserves are held behind a pre-committed, time-locked recovery path. After a long delay, a separately constituted, supervised recovery quorum can move reserves into an orderly wind-down. Fedimint's wallet descriptor has no such branch. Implementing it means a wallet module whose descriptor adds a time-locked spending path for the recovery quorum. That is a new module, not a configuration.

Moving reserves is the easier half. Paying holders requires a claims procedure:

• a current copy of the spent-nonce set readable without the failed guardians,
• validation of each presented note against it and against the mint's public keys, and
• a durable register of claims paid, so that no note is paid twice and no spent note is paid at all.

In Fedimint the spent-nonce set lives in each guardian's database as part of the consensus state. The claims procedure needs it exported and kept current by a path that does not itself become an attack surface. The operator's records cannot substitute, because after float hand-offs they do not say who holds what.

The recovery quorum is an additional party to trust. Who holds it, how its time-lock is set, and how the spent-nonce copy is kept current and protected are open design questions. We regard a rehearsal of the claims procedure, with spent notes and competing claims, as a precondition for holding value.

9.4 Lightning gateways and connectors

Every connection to the outside holds live keys or liquidity and is where a breach is most likely. In Fedimint terms these are:

• the Lightning gateways (fedimint-gatewayd, which holds both e-cash and Lightning liquidity);
• each guardian's bitcoin backend (bitcoind or an Esplora server, which the wallet module consults for block height and UTXOs); and
• any exchange or fiat connector.

Fedimint already requires each guardian to run or choose its own bitcoin backend. It reaches consensus on chain state from those independent views. Section 11.2 generalises that pattern as "derived, not reported".

Lightning gateways should be operated by several independent parties with per-operator caps, collateral above each cap and key rotation, and sized for correlated exits when many agents react to the same event.

10. Accountability: attestation and stake

10.1 Authorisation without stake

A mandate says a principal approved a payment. It does not say the agent, merchant or operator is who it claims to be, or what happens if it lies. Where spawning an agent costs nothing, identity without cost is a speed bump. The sweep found no standard bonding mechanism for agents. The nearest neighbour it found is a draft Ethereum standard for agent identity, reputation and validation registries. It defines no staking or bonding of its own, leaving incentives and slashing to separate validation protocols. It is chain-specific rather than a bond attached to payment commitments [36].

10.2 The attestation as apostille

The 1961 Hague Apostille Convention lets states accept each other's public documents by certifying who signed, in what capacity and under which authority, without certifying the content [24]. We propose an attestation federation that issues the digital analogue: a threshold-signed credential binding an agent, merchant or operator to a verified principal, a verification class and, for higher classes, a bond. Like the apostille, it proves who stands behind a claim, not that the claim is true.

Attestations need a revocation register, threshold-signed and anchored, checked by every relying party. The limits in Section 8.2 apply: an authentic historical checkpoint does not establish current revocation status. Relying parties also need a policy for identifying the authoritative record stream, checking freshness and handling missing or delayed updates.

The power to revoke is also a power to harm, so revocation is governed: it needs the attestation federation's threshold, published grounds, notice to the revoked party and a route of appeal. An emergency suspension may be faster, but needs a stated quorum, lasts a fixed short window, cannot be renewed except by becoming a revocation, and is published with its grounds.

10.3 Bonds, reliance caps and one stake per identity

Higher attestation classes carry a bond forfeited on proven misbehaviour. A bond needs a concrete anchor, which we call a reliance cap: the maximum value counterparties may have exposed to the attested party at one time. The bond must exceed what the party could gain by misbehaving up to that cap. As specified here the cap is a declaration, and nothing yet enforces it across counterparties. Each counterparty could rely within the cap, while together they exceed it. The deterrence argument holds only where aggregate exposure is enforced, for example by reservations against the cap, and that mechanism is not designed here.

A principal may bond once for a fleet, sized for the fleet's declared cap, with agents attested as sub-identifiers. What it may not do is let one stake back two independent identities. Each bond identifier is bound into exactly one attestation and listed in a public register, so reuse is detectable.

Enforcement is tiered by evidence:

• provable offences settled on submission of proof after a short window;
• contestable offences settled optimistically unless contested with a counter-bond;
• complex disputes to arbitration.

Slash proceeds go to harmed parties, reporters and a recovery fund, never to the enforcer. The project's design record contained conflicting allocations on this point, including versions that paid part of the proceeds to the attestor's reserves. The position taken here is the one in which the attestor can receive nothing.

A compromised attestor could otherwise route proceeds to nominees posing as harmed parties or reporters. So beneficiaries are paid only if identified in the account record. Proceeds of contestable and arbitrated slashes are held in escrow until the window or the arbitration closes. Identification establishes who is paid, not that they are entitled or independent of the enforcer. Escrow delays payment without deciding entitlement. Receipt of a wrong slash by an identified nominee remains a residual.

10.4 Sign-only attestation and its limit

The attestation federation signs and never holds, moves or custodies value. In Fedimint terms it is a federation with no wallet module and no mint module, running only a custom threshold-signing module. Bonds are held by the reserve federation, and a slash requires both the attestor's signed judgement and the custodian's execution. The design record also contains the reverse arrangement, with the custodian signing the slashing notice and the attestor revoking. We adopt the direction in which the attestor judges and the custodian executes. On the compliant path, neither can confiscate alone.

The limit should be stated. An honest custodian can check that a judgement carries a valid threshold signature, not that it is right. So a compromised attestor threshold could have an honest custodian execute a wrong slash. Evidence tiers, windows, a per-judgement cap and proof carried with provable judgements are the defences. And the separation is real only once no party holds a threshold in both federations.

The project's material includes a prototype attestation library: a signature envelope pairing BIP-340 Schnorr signatures with a hash-based post-quantum signature, bindings for threshold signing, and a revocation register. It is a prototype in the sense of Section 5.2.

Its in-process threshold-signing coordinator is quarantined pending remediation. Its earlier merchant issuance path is disabled. Its keys are generated by a trusted dealer rather than by distributed key generation. It is not yet a Fedimint module. The attestation federation, the bonds and their custody, slash execution and the governance of revocation described in Sections 10.2 to 10.4 are design only. Nothing in this section describes an operating institution.

10.5 Conditional payments and track records

Discreet Log Contracts make a payment depend on an oracle's signed statement [25]. Applied to agents, an agent's commitment can be backed by collateral locked against outcomes, released or forfeited on an attested result. The parties must trust a fact-verifier where the fact lies outside the federation, the oracle and its threshold, the custodian, a correct beneficiary binding and threshold signing machinery that is not yet independently audited. Contracts settled inside a federation are visible to its guardians unless their terms are blinded.

Over time an agent accumulates a verifiable contract history, but a history is not a reputation: related parties can settle trivial commitments with each other and manufacture a record cheaply. A history becomes evidence only when weighted by counterparty independence, exposure size and duration, and the substance of what was delivered. Early deployments should settle such contracts after an attested outcome rather than by pre-signed transactions.

11. Verification before settlement

11.1 Why the verifier comes first

The material behind this paper includes adversarial review records for the project's own prototype settlement code, much of it written with AI coding tools. That review found failures that would have lost money in components that had passed their own tests. The decision drawn from it, and the ordering this paper recommends, is that no component should hold value until it has been reviewed by a process designed to find what its authors missed, with findings traced to evidence and refutations recorded.

This is an internal observation from one practice. It motivates the ordering; it is not evidence of how common such failures are elsewhere.

Three features of the domain make ordinary testing insufficient:

• Most serious failures needed no attacker: a slow response, a crash at the wrong moment, a retry, a second process.
• Model-assisted code is fluent in ways that hide defects, and its comments and tests can share its mistakes. In one reviewed withdrawal path, a comment stated that a pairing was enforced elsewhere, and nothing enforced it.
• Agreement among reviewers is not independence: models that share training and conventions can agree on a wrong answer, so a panel verdict is a sample, not a measurement. Whether agreeing reports share a source is the subject of a companion paper on agentic stemmatics [38].

11.2 A failure-class catalogue

Table 5 groups the failure classes observed in that review into four families, each with the rule that would prevent it. A third column says whether stock Fedimint already enforces the rule, so that maintainers can see which failures belong to code wrapped around Fedimint rather than to Fedimint itself. The catalogue is the author's; it is not a census.

Table 5. Failure classes.

Two observations follow from the review record:

• A failure found once tends to have siblings nearby, so fixes should address the class.
• Fixes regress: the record's only count is that three of four recorded fix rounds introduced defects that later review caught. That count comes from a single model lineage and was not independently reviewed, so we do not rely on it as a rate.

11.3 The untested layer

Settlement code can be reviewed line by line; the model that decides to call it cannot. Three attacks need dedicated end-to-end testing: a malicious payment challenge crafted to steer the paying agent, a poisoned tool description, and a manipulated counterparty message. In the project's own work these have not been tested end to end. We know of no shared test suite, but our sweep did not search for one specifically. Until they are, the defences of Section 6.4 are the basis for trust: assume the agent can be turned, and limit what a turned agent can do.

11.4 Relation to the research programme

A settlement institution is an agentic institution in the sense of the companion paper [26]: its corrections, limits and invariants must survive handovers between people, models and tools. The invariants in Appendix A are written to be carried across such handovers and checked against the code that ships, not against summaries of it.

The design itself is offered as an engineering hypothesis, not a plan of record. It is a practical outcome towards which the author's research programme works. The programme is on verification, provenance and institutional continuity [26, 38]. If that programme succeeds, a settlement layer of the kind described here, governed as a commons in the sense of Section 12, is one of the things it should make safe to build. Hypotheses H1 to H8 state what would show that it is not. The order follows Popper's piecemeal engineering [39]: small steps whose failure can be detected and corrected, each tested before the next is taken.

12. Institutional precedents, read with care

Historical precedents illustrate design properties. They do not establish that the design will work, and the economic-history literature disputes several of them.

Table 6. Precedents.

The commons reading is the one we rely on most. A settlement layer for machines is a shared resource that no one should own and that free-riding would destroy unless governed. That suggests a layered governance:

• guardians govern the protocol without claim on its assets;
• a stewardship body funded by a share of boundary fees maintains standards and admits guardians;
• licensed operators run the businesses.

Whether this arrangement holds under commercial pressure is an empirical question, not a historical inference.

13. Research agenda and hypotheses

Each hypothesis is stated with evidence for and against and with the result that would refute it. None has been tested. The proposed evaluations have not been run and their protocols are not fixed.

H1. Privacy in practice. A Fedimint federation with one keyset for all principals, boundary-service-held identity and no guardian-visible correlation identifiers gives agents' principals meaningful confidentiality of commercial flows.

• For: blind-signature unlinkability [20]; the two-record design; no keyset rotation in Fedimint.
• Against: system-level privacy failures in deployed mints [15]; denomination and timing patterns; Lightning gateway and boundary-service metadata; small anonymity sets at launch; the spent-nonce query (Section 7.2).
• Refuted by: a linkage experiment on a running federation, with each adversary's capabilities, permitted prior knowledge, baseline and threshold of unacceptable advantage fixed before the experiment, in which any of the following exceeds that threshold:
  • an outsider or a guardian inferring a principal's counterparties; or
  • the operator linking a float payment to the principal that funded the float, or otherwise inferring counterparties beyond what its account record already contains.
• Evaluation: instrumented deployment with synthetic agent workloads; linkage attacks by an independent team.

H2. Regulatory characterisation. In a given legal system and deployment configuration, threshold custody with a single regulated operator and thin guardians can be supervised as one regulated activity with guardians outside the perimeter. The hypothesis is tested system by system; no target system is fixed here.

• For: the intended legal allocation; existing treatment of technical service providers.
• Against: supervisors may treat guardians as co-custodians; e-money or custody rules may attach to issuance itself.
• Refuted, for that system and configuration, by: supervisory guidance or a ruling in that system treating guardians as conducting the regulated activity, or treating federated e-cash as incompatible with prohibitions on anonymous accounts. A refutation in one system does not settle another.
• Evaluation: legal opinions in several systems; supervisory dialogue, none of which has occurred.

H3. Bearer float versus mandate under compromise. For high-frequency, low-value workloads, capped floats yield lower expected loss than mandates under compromise of the agent or of the mandate's payment service. Above a value threshold, the reverse holds.

• For: float loss is bounded by the float; mandates add a hot wallet.
• Against: floats give up payer-side attribution; mandate services can be tightly capped.
• Refuted by: a threat-model simulation or red-team exercise in which the measured ordering of expected loss, with confidence intervals, does not follow that pattern. Compromise events, exposure limits, workload distribution and the crossover criterion are fixed in advance.
• Evaluation: simulated fleets under scripted compromise.

H4. Finality and retry semantics. Components that follow the five durability rules produce no double charges and no lost payments under injected latency, crashes and retries.

• For: the rules target the observed failure class; Fedimint's client already persists and retries.
• Against: rules are only as good as their implementation; distributed leases are hard.
• Refuted by: fault injection producing a double charge, a lost payment or a retryable error after custody, in a component whose compliance with the five rules was established by a review and test plan. The plan was fixed before the fault injection began.
• Evaluation: fault-injection harness against a test federation (devimint).

H5. Binding authorisation and payment to a permitted receiver. Receiver-authenticated challenges with signed transactions bind payment to a receiver that the mandate permits and that authenticated the challenge. Which of several permitted receivers the principal intended is not something the construction can see. Binding payment to delivery is outside this hypothesis and remains an open question.

• For: the construction in Section 5.3; Fedimint transaction outputs are fixed by the input signatures.
• Against: receiver keys can be stolen or registered fraudulently; delivery evidence is domain-specific.
• Refuted by: an attack that, without compromising a receiver's key or the payment service, either (a) redirects a mandated payment to an unpermitted receiver or (b) has it paid to outputs that the authenticating receiver did not place in its challenge.
• Evaluation: formal model of the attachment, on the lines of [14].

H6. Adapter neutrality. One settlement primitive can serve x402, MPP, L402, checkout and A2A envelopes without per-protocol settlement logic. This means that each envelope only translates messages and calls the same spend, validate and reissue operations. No envelope has its own rule about when a payment is final or how it is recorded.

• For: the common spend-validate-reissue shape; method-agnostic designs in MPP and AP2.
• Against: protocol-specific finality and receipt semantics; fiat and Lightning exits.
• Refuted by: a protocol whose required semantics cannot be met by such an envelope without either changing the primitive or adding an envelope-specific rule for finality or recording.
• Evaluation: conformance tests per envelope.

H7. Agent-reasoning attacks against a payment boundary. With reading segregated from paying and default-deny tools, a malicious challenge, poisoned tool description or manipulated counterparty message cannot cause a payment outside the mandate.

• For: the separation in Section 6.4.
• Against: manipulated context can subvert authorised payments [13]; separation may leak through shared memory or summaries.
• Refuted by: an end-to-end test in which any of the three attacks produces a payment that the principal's signed mandate does not cover. Payments inside the mandate that the principal did not intend are outside this hypothesis; Table 4 records that intent is not bound.
• Evaluation: a shared test suite, proposed as a resource for the field.

H8. Recovery under permanent halt. After loss of the normal quorum, a pre-committed recovery path with a claims procedure pays every valid unspent note presented to it exactly once, and no spent note. This assumes that the reserves cover the notes outstanding, that the spent-nonce copy is complete to the moment of halt, and that the recovery quorum is available.

• For: the claims procedure of Section 9.3.
• Against: keeping the spent-nonce copy current without creating a new attack surface; holders who cannot present notes.
• Refuted by: a rehearsal, under those assumptions, in which any of these happens:
  • a spent note is paid;
  • a note is paid twice;
  • a valid unspent note presented within the claims window is not paid by a deadline fixed in advance; or
  • the recovery quorum can move reserves outside the wind-down.
• Evaluation: recovery drills with seeded spent notes and competing claims.

Further open questions, without hypotheses yet:

• binding payment to evidence that the service was delivered;
• consensus throughput under machine-tempo workloads, and how far prepaid sessions reduce it;
• a compact per-transaction receipt derived from signed session outcomes;
• enforcement of reliance caps across counterparties;
• proof of liabilities for blind notes without revealing balances;
• inter-federation atomicity;
• how Lightning gateways, which transact with the federation themselves, connect to the guardians under the network restriction of Section 4.3;
• bond calibration;
• guardian governance over time, including guardian replacement without re-keying;
• threshold oracles and audited threshold adaptor signatures;
• long-lived keys and post-quantum signing; and
• caps on an anonymous level without identifying holders.

14. Limitations

• No federation of the kind described operates. No licence has been sought, and no regulator or supervisor has been engaged.
• No throughput, latency, cost or volume figure in this paper is measured; the opening case is illustrative.
• Legal readings, including the originator interpretation and the allocation between operator and guardians, are untested.
• The project's prototype code is not production grade and has recorded blockers.
• The main sweep of external sources was conducted over one day, with limited later checks recorded in Appendix B. Protocol facts change quickly. Several of these facts rest on vendor or press sources. Security analyses were read at the level of abstracts and summaries, with one exception stated in Appendix B.
• Statements about Fedimint's behaviour describe the commits listed in Appendix B and should be re-verified against any release actually deployed.
• The paper describes Fedimint's original mint module. At the later commit read, a newer mint module is enabled by default, and how the design maps onto it has not been examined (Section 2.3).
• The internal review material comes from the author's own practice and is not independent evidence of its effectiveness.
• The paper is the work of one researcher with model assistance.
• The design positions were reviewed in two rounds, as part of a companion blueprint. The first draft of this preprint was reviewed in one further round, and draft v0.4 in a confirmation round. The changes made after that round have not been through a review round of that kind. On the day of this revision, narrower checks were made by models of other providers; the Disclosure describes them and what they did not cover.

15. Conclusion

Agent payment protocols answer how an agent asks to pay and how a payment is authorised. They leave open where the payment settles and who answers for it.

We have argued that a federated settlement layer beneath the protocols can supply properties that machine commerce needs and the dominant substrates lack. The layer is built on Fedimint's mint, wallet and Lightning modules, and wrapped in an operator's boundary service. It can do this provided it:

• keeps two records and states their scope by delegation mode,
• keeps treasury and mandate-authoring keys off the agent,
• makes the irreversible step safe,
• separates judgement from custody,
• plans for its own permanent failure, and
• is verified adversarially before it holds value.

None of this makes a payment right: a payment can be properly authorised and correctly executed while resting on a mistaken belief, and the design can only limit what such a mistake costs. Each of those provisos is a research question. The hypotheses in Section 13 are stated so that they can fail. A negative result on H1, H5 or H7 would narrow the design considerably. A positive result would justify building further, not a claim that the institution exists.

References

Source status: drawn from a literature sweep conducted on 30 October 2026 (Appendix B). Bibliographic details of references 9, 19-21, 25, 28, 30-33 and 35-37 were checked on 30 October 2026 by one model agent; no second check was made. References 19 and 25 were checked against the documents themselves; 28 and 36 against publisher or standards-body pages; 30-32 against RePEc records; 20, 21 and 33 against bibliographic databases or a library catalogue, because the publisher page did not open. For 9, Visa's page did not load and the date rests on the press release. For 35, the end of the trial and the bankruptcy rest on the 2000 article alone. For 37, the published article was not read; what Section 12 attributes to it rests on the authors' 2010 working paper.

Reference 39 was added on 2 November 2026; its edition and section title were checked by one model agent against a table of contents and a contemporary review found by web search, and the text of the section was not read. References 40-42 were added on 4 November 2026 after the targeted primary-source reading described in Appendix B. Reference 43 was added on 11 November 2026 and points to the source commits listed in Appendix B.

1. x402 Foundation. x402 specification and repository; exact EVM scheme. github.com/x402-foundation/x402. Accessed 30 Oct 2026.
2. Linux Foundation (2 April 2026). Launch of the x402 Foundation. Press release.
3. Payment HTTP Authentication Scheme (Machine Payments Protocol). IETF Internet-Draft draft-httpauth-payment-01, September 2026; mpp.dev.
4. Lightning Labs (11 February 2026). Lightning agent tools and L402. lightning.engineering.
5. Cashu. NUT-18 (payment requests) and NUT-24 (HTTP 402). github.com/cashubtc/nuts.
6. Agent Payments Protocol (AP2), v0.2. ap2-protocol.org; FIDO Alliance (28 April 2026) announcement of the Payments Technical Working Group.
7. Agentic Commerce Protocol, specification 2026-04-17. github.com/agentic-commerce-protocol.
8. Universal Commerce Protocol. github.com/Universal-Commerce-Protocol/ucp.
9. Visa. Trusted Agent Protocol. developer.visa.com/capabilities/trusted-agent-protocol; github.com/visa/trusted-agent-protocol. Announced in a press release dated 14 October 2025 (Business Wire; a regional Visa page shows 17 October 2025). Mastercard (29 April 2025). Mastercard unveils Agent Pay. newsroom.mastercard.com.
10. Model Context Protocol, specification 2025-11-25; Agent2Agent protocol, a2a-protocol.org.
11. Li, Z., Wang, Q., and Wang, Z. (2026). Five Attacks on x402 Agentic Payment Protocol. arXiv:2605.11781.
12. Ling, S., et al. (2026). Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments. arXiv:2605.30998.
13. Aviv, A., Gandh, P., Bitton, R., and Shabtai, A. (2026). Beyond the Mandate: A Systematic Security Analysis of AP2. arXiv:2608.23858.
14. Jiang, K., et al. (2026). A Formal Analysis of Agent Payment Protocols. arXiv:2609.00060.
15. Chen, H., Zhang, Y., and Cheng, Y. (2026). Blind Spots in Blind Signatures: A System-Level Security Analysis of Deployed Chaumian Ecash. IACR ePrint 2026/2174.
16. South, T., et al. (2025). Authenticated Delegation and Authorized AI Agents. arXiv:2501.09674.
17. Chan, A., et al. (2025). Infrastructure for AI Agents. arXiv:2501.10114.
18. Bank for International Settlements (2025). Annual Economic Report 2025, chapter III.
19. Waller, C. J. (2026). Payments in the Age of AI Agents. Remarks at Sibos 2026, Miami, 29 September 2026. Board of Governors of the Federal Reserve System, federalreserve.gov/newsevents/speech/files/waller20260929a.pdf.
20. Chaum, D. (1983). Blind Signatures for Untraceable Payments. In D. Chaum, R. L. Rivest and A. T. Sherman (eds.), Advances in Cryptology: Proceedings of Crypto 82, Plenum, 199-203. doi:10.1007/978-1-4757-0602-4_18.
21. Chaum, D., Fiat, A., and Naor, M. (1990). Untraceable Electronic Cash. In Advances in Cryptology: CRYPTO '88, LNCS 403, Springer, 319-327. doi:10.1007/0-387-34799-2_25.
22. Fedimint documentation, docs.fedimint.org; "Privacy and trust", fedimint.org.
23. FATF (June 2025). Revision of Recommendation 16 on payment transparency; Regulation (EU) 2023/1113 on information accompanying transfers of funds and certain crypto-assets.
24. Hague Conference on Private International Law (1961). Convention Abolishing the Requirement of Legalisation for Foreign Public Documents.
25. Dryja, T. (2017). Discreet Log Contracts. MIT Digital Currency Initiative, undated preprint. adiabat.github.io/dlc.pdf.
26. Soons, L. J. (2026). Agentic Institutions: Organisational Memory, Correction and Continuity Across Successive AI Agents. Conceptual preprint v0.3. doi:10.5281/zenodo.23727633.
27. Harreld, D. J. (ed.) (2015). A Companion to the Hanseatic League. Brill.
28. Aslanian, S. D. (2011). From the Indian Ocean to the Mediterranean: The Global Trade Networks of Armenian Merchants from New Julfa. University of California Press. doi:10.1525/9780520947573.
29. Greif, A. (1993). Contract Enforceability and Economic Institutions in Early Trade: The Maghribi Traders' Coalition. American Economic Review, 83(3), 525-548.
30. Edwards, J., and Ogilvie, S. (2012). Contract enforcement, institutions, and social capital: the Maghribi traders reappraised. Economic History Review, 65(2), 421-444. doi:10.1111/j.1468-0289.2011.00635.x.
31. Milgrom, P., North, D., and Weingast, B. (1990). The Role of Institutions in the Revival of Trade: The Law Merchant, Private Judges, and the Champagne Fairs. Economics and Politics, 2(1), 1-23. doi:10.1111/j.1468-0343.1990.tb00020.x.
32. Greif, A., Milgrom, P., and Weingast, B. (1994). Coordination, Commitment, and Enforcement: The Case of the Merchant Guild. Journal of Political Economy, 102(4), 745-776. doi:10.1086/261953.
33. Ostrom, E. (1990). Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge University Press.
34. Mao, Q., et al. (2026). SoK: Security of Autonomous LLM Agents in Agentic Commerce. arXiv:2604.15367.
35. American Banker (23 October 1995). DigiCash to test live internet cash system with Mark Twain; American Banker (6 April 2000). DigiCash idea finds new life in more flexible ecash.
36. De Rossi, M., Crapis, D., Ellis, J., and Reppel, E. (2025). ERC-8004: Trustless Agents. Ethereum Improvement Proposal, draft, created 13 August 2025. eips.ethereum.org/EIPS/eip-8004.
37. Quinn, S., and Roberds, W. (2014). How Amsterdam got fiat money. Journal of Monetary Economics, 66, 1-12. doi:10.1016/j.jmoneco.2014.03.004. Earlier version, the one read: Federal Reserve Bank of Atlanta Working Paper 2010-17.
38. Soons, L. J. (2026). Agentic Stemmatics: Collation, Provenance, and Conservation for an Emerging Machine Textual Tradition. Version v1.41. doi:10.5281/zenodo.23458161.
39. Popper, K. R. (1957). The Poverty of Historicism. Routledge and Kegan Paul. Section 21, Piecemeal versus Utopian Engineering.
40. OpenTimestamps. Project documentation: How it works. Accessed 4 November 2026.
41. Todd, P. (2016). OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin. Sections on evidence authenticity, commitment operations, aggregation and public calendars. Accessed 4 November 2026; historical implementation examples are not current operating instructions.
42. Bitcoin developer reference. Block Chain: Block Headers. Header commitment and time-field descriptions. Accessed 4 November 2026.
43. Fedimint. Source repository, github.com/fedimint/fedimint: crates fedimint-core (NumPeers), fedimint-mint-*, fedimint-wallet-*, fedimint-ln-*/fedimint-lnv2-*, fedimint-gatewayd, fedimint-client, tbs. Read at commits 50a12b3 (0.11.0-alpha) and 5242f22 (0.13.0-alpha) from a fork mirror; see Appendix B.

Appendix A. Invariant set (summary)

The companion blueprint states these in full; they are summarised here so the paper can be checked on its own.

Settlement durability.

• D1 validate before custody, treating the spent-nonce query as advisory;
• D2 claim exactly once, topology declared;
• D3 no retryable failure after custody;
• D4 intent recorded before the point of no return;
• D5 reconcile multi-step flows;
• D6 compensation is not finality;
• D7 services spending for others persist the note set before spending, and unknown outcomes are recorded as unknown.

Agent authority.

• A0 prompts are never controls;
• A1 no treasury, guardian or mandate-authoring key reachable by agents, a float agent's nonce keys being bounded by the float;
• A2 agents are boundary-service clients only;
• A3 default-deny tools;
• A4 machine-enforced mandates;
• A5 attribution that survives compromise;
• A6 humans author authority, machines enforce it;
• A7 reading segregated from paying;
• A8 limits aggregate at the principal;
• A9 receiver-authenticated challenges;
• A10 expiry stops creation, not settlement, and cancellation counts only when the self-spend is accepted;
• A11 the payment service is a bounded hot wallet.

Federation and attestation.

• F1 signing threshold equal to Fedimint's default, t = n − ⌊(n − 1)/3⌋;
• F2 halting is safe failure, with a recovery path and a rehearsed claims procedure;
• F3 named guardians in independent legal systems, holding no customer identity data;
• F4 sign-only attestation with proof-carrying, capped judgements;
• F5 slash proceeds never to the enforcer;
• F6 no common threshold across separated functions, or disclosure;
• F7 no failure domain holding more than ⌊(n − 1)/3⌋ seats;
• F8 governed revocation and suspension;
• F9 one stake, one identity.

Records and reserves.

• R1 two records, scoped by delegation mode;
• R2 no unscreened path in, Lightning gateways included, and no anonymous path out;
• R3 identity levels are boundary-service policy over one keyset;
• R4 reserves derived, not reported;
• R5 conversion is an identified instruction with conservation checked inside one transaction.

Proposed, not yet an invariant: the signer-side count detector.

Appendix B. Source access statement

The design positions derive from the project's internal design documents, white papers and code repositories (read from local mirrors) and from the author's review records, summarised in twelve dated dossiers on 30 October 2026. Those summaries were model-written and are treated as secondary.

External facts derive from a one-day sweep of public sources on the same date, using primary pages where reachable (specifications, repositories, standards-body pages, arXiv and IACR abstract pages); several protocol facts rest on vendor or press sources, and the argument relies on them only for how the protocols are positioned (Table 1), not for how they behave. Security analyses [11-13] and [15] were read at the level of abstracts and summary sections; for [14], the discussion of scope and limitations was also read, on 1 November 2026. Historical works are cited for the limited properties attributed to them, not on the basis of whole-book reading.

Fedimint source. Fedimint's threshold (Section 9.2) was read from its source code in a fork mirror. At two commits, versions 0.11.0-alpha (50a12b3) and 0.13.0-alpha (5242f22), NumPeers::threshold() in fedimint-core returns n − ⌊(n − 1)/3⌋, with max_evil() returning ⌊(n − 1)/3⌋. Its use in mint key generation and in the reserve descriptor of the newer wallet module was read at the later commit only; the original wallet module takes its threshold from a caller that was not read. The released v0.11.1 tag was not available offline. No private repository content, design document or review record is reproduced.

The following further statements about Fedimint, introduced in draft v0.16, are made from the contributor's working knowledge of the codebase at those commits and should be verified against the pinned commit before any of them is relied on:

• that consensus is AlephBFT;
• that the mint module's blind signatures are BLS12-381 via the tbs crate with per-denomination keys fixed at key generation and not rotated;
• that a note's nonce is a secp256k1 public key whose private key signs the spending transaction;
• that OOBNotes carry the nonce private keys and a federation-id prefix;
• that fedimint-server rejects any transaction whose inputs do not cover its outputs plus fees;
• that the original mint module exposes a spent-nonce query;
• that guardians sign session outcomes;
• that the client API is unauthenticated apart from the administrative endpoints;
• that there is no protocol for changing membership or re-sharing keys;
• that each module reports assets and liabilities to an audit visible to guardians;
• that lnv2 contracts are hash-locked with timeouts; and
• that the client persists state machines and retries submission.

Source check for draft v0.19. On 11 November 2026 the statements about Fedimint that Appendix F lists as corrected were checked against extracted copies of the two commits above. A model advisor (Claude, Anthropic) searched and read the source and cited file and line for each finding, and the drafter (Claude) re-read the cited lines behind each correction. The same day a model of another provider, Kimi (Moonshot; the tool did not report the model version), was given 19 statements about the two source trees without being told what they were for: 14 drawn from the advisor's findings, and five false ones planted as a test. It confirmed the 14 at both commits and rejected the five, citing file and line. The 14 cover the corrections of Appendix F, items 1, 2, 4 and 5, and what item 3 says about the newer modules; that the original mint client has spend and reissue operations rests on the advisor's and the drafter's reading only. It added that the per-federation root secret is the client's default and can be bypassed with a custom root secret, and that two builds of a transaction differ in their identifier with overwhelming probability, not with certainty; Sections 8.1 and 5.3 are worded accordingly. Codex (OpenAI) and Gemini (Google, through the Antigravity tool) were given the same task and could not read the files, so they gave no verdict. Not checked: the consensus library that Fedimint depends on, how applications share network connections across federations, and whether the client as it stands can build the payer-signed transaction of Section 5.3. This check does not replace the verification that the list above asks for.

For draft v0.15, Codex (OpenAI) read the primary-source passages on prior existence and local hashing in the OpenTimestamps project documentation [40]; evidence authenticity, commitment operations, aggregation and pending versus completed proofs in Todd's 2016 account [41]; and block-header commitments and the time field in the Bitcoin developer reference [42], on 4 November 2026. This was a targeted documentary check of the anchoring clarification, not a fresh check of all earlier sources. No timestamp request was submitted, no Bitcoin transaction was made, and no node experiment or anchoring implementation was run.

Appendix C. Changes from v0.15 to v0.16

Renamed terms (throughout).

Corrected or made precise.

1. Abstract, Section 2.3. "A colluding majority of guardians could steal or over-issue" became "a signing threshold", with the threshold given in Section 9.2. A bare majority is below the threshold for n ≥ 5; at n = 4 the two are equal.
2. Section 2.3. Fedimint is now described concretely: AlephBFT consensus, modules, BLS12-381 threshold blind signatures (tbs), fixed denomination keys, nonce-as-public-key notes, wallet descriptor, Lightning gateway and lnv2, peg-in and peg-out, transaction conservation, TransactionId. Cashu's scheme is distinguished.
3. Section 4.2. What guardians see is stated in full: nonces, blinded outputs, denominations, fees, peg-in UTXOs, peg-out addresses, Lightning payment hashes, and the submitting network address unless Tor or Iroh is used. v0.15 said "identity-free events only: issuance, redemption and each reissue".
4. Section 4.3. "Guardians accept requests only from gateways, enforced by the network" is now stated as a deployment control outside Fedimint, since fedimintd client endpoints are open to any holder of the connection details.
5. Section 4.4. The payee's reissue "through its gateway session" is now explained: in stock Fedimint the client submits directly to guardians; the design forces it through the boundary service by the network restriction.
6. Section 5.1. The primitive is restated in Fedimint operations, with the finality point named.
7. Section 5.3. The signed-transaction variant is restated with Fedimint objects: (denomination, blinded nonce) outputs, inputs signed with nonce keys, change and fees in the same transaction, anyone-may-submit, payee fetches blind signature shares by output index. The claim that "a threshold-signed receipt remains to be designed" is corrected: guardians already sign session outcomes; what is missing is a compact per-transaction receipt.
8. Section 6.2. "Reserves the amount" became "selects and locks specific notes for the amount plus fees". Release of a reservation is tied to rejection or acceptance of a conflicting self-spend. "Cancellation is confirmed only when the self-spend is final" became "accepted".
9. Section 7.1, 7.3. The finality point is consensus acceptance of the reissue transaction; fetching blind signature shares is not part of finality. v0.15 said "consensus has accepted the spend and new notes are signed".
10. Section 7.2. Rule 1 lists the actual checks and states that the spent-nonce query is advisory. Rule 3's state became "submitted, acceptance pending". The Fedimint client's persisted state machines are named as the behaviour the rules generalise.
11. Section 8.1. Of the three privacy channels in [15], keyset rotation is stated not to apply to Fedimint as read; wallet recovery and multi-federation identity do. Denominations, timing and network address are added as guardian-visible channels.
12. Section 8.2. Screening at the boundary is stated to depend wholly on the network restriction, because stock Fedimint has no screening hook on peg-in. The "one note class" paragraph now distinguishes denominations from identity levels.
13. Section 8.4. Fedimint's guardian-visible module audit is mentioned and distinguished from a public proof.
14. Section 9.1. Separation across federations is distinguished from several module instances in one federation. The inter-federation hash-lock statement is corrected: lnv2 gives hash-time-locked conditional atomicity through a gateway, not two unrelated exits and not joint consensus.
15. Section 9.2. The threshold is given in Fedimint's general form t = n − ⌊(n − 1)/3⌋, with n = 3m + 1 as the special case and a note on n = 5. Coalition sizes are restated in f and t.
16. Section 9.3. Fedimint's fixed membership and absence of re-sharing are stated; the time-locked recovery path is identified as requiring a new wallet module; the spent-nonce set is located in guardian databases.
17. Section 9.4. Connectors are named as Fedimint components, and each guardian's independent bitcoin backend is identified as the existing "derived, not reported" pattern.
18. Section 10.4. The attestation federation is described in Fedimint terms (no wallet or mint module; a custom module).
19. Section 11.2. A column was added saying which preventing rules stock Fedimint already enforces (transaction conservation, no unbacked outputs, independent chain backends, federation-id prefix on OOBNotes, separate validate and reissue operations, persisted client state machines) and which belong to the service layer.
20. Section 13. H1, H4 and H5 gained Fedimint-specific evidence; a per-transaction receipt and guardian replacement without re-keying were added to the open questions; devimint is named for H4.
21. Section 14, Appendix B. A limitation and a verification list were added for every Fedimint statement introduced in this revision.
22. References. Reference 43 (Fedimint source) added.

Not changed. The hypotheses, the invariants' substance, the status claims ("Design"/"Prototype"), the disclosure, and every statement about the project's own prototype code.

Appendix D. Changes from v0.16 to v0.17

Layout and wording only. No hypothesis, status claim, reference, table row or technical statement was changed. A word-by-word comparison of this text with the text of v0.16 found no differences other than those listed here.

1. Added. An unnumbered "In brief" summary and a "Where to start" guide after the keywords; a pointer to Table 3 in Section 2.3; a one-line lead-in before the list of terms in Section 4.2, before the two records in Section 4.4 and before the steps in Section 5.3; a table of worked values of f and t in Section 9.2, computed from the stated formulas for n = 4, 5, 7 and 10; and the entry for v0.17 in the disclosure.
2. Replaced. The note at the head of the paper is shorter and describes this revision. The dash in the MPP row of Table 3 became the words "Not a Fedimint term".
3. Split and listed. In most sections, in the references note, in Appendices A and B and in the disclosure, long paragraphs were split and parallel items were set as lists. Each hypothesis in Section 13 is set out under lines labelled For, Against, Refuted by and Evaluation, and the open questions and limitations are lists.
4. Connecting words and punctuation. Where a sentence became a list item or a separate sentence, a few connecting words and marks changed. The Abstract's sentence on the security analyses became three sentences ("report two kinds of problem", "they find"). "And", "that" or "on" at the start of an item was dropped in Sections 3, 6.2, 6.4, 7.3, 8.5, 11.1 and 11.2, and "Of the three:" became "The three:" in Section 8.5. In Section 4.2 the clause on Tor and Iroh moved to the end of its list item. Colons and semicolons were added or exchanged where items became lists, and labels were added to the items on anchoring in Section 8.2.
5. Typography. Typographic dashes in ranges became hyphens, and the spaces inside the floor signs in formulas were removed.

Appendix E. Changes from v0.17 to v0.18

Changes of wording, six of which fixed a reading (item 3). 78 passages were rewritten in plainer English, in the Abstract and Sections 1, 2.1, 2.2, 2.3, 3, 4.2, 4.3, 4.4, 5.1, 5.3, 6.1, 6.2, 6.3, 6.4, 7.2, 7.3, 8.1, 8.2, 8.4, 9.1, 9.2, 9.3, 9.4, 10.1, 10.3, 10.4, 11.1, 11.4, 13, 14 and 15. No hypothesis, status claim, reference, table row or technical statement is intended to change. A comparison of this text with the text of v0.17 found no differences other than the rewritten passages and the three other changes noted at the end of this appendix.

1. Split. 32 passages only split sentences, changed punctuation or dropped a connecting word such as "and". Their words and word order are otherwise those of v0.17.
2. Reworded. 40 passages changed some words, usually to replace a pronoun by the noun it stood for, to put a condition first, or to set a list out item by item. The facts stated are unchanged.
3. Reading fixed. 6 passages fix one reading of a phrase that the original left open, for example what "it" referred to or how strongly a clause was meant. These are the passages that most need confirmation.

Three other changes: the version line, the note at the head of the paper, and the entry for v0.18 in the disclosure. The old and new text of every rewritten passage, with the points to check, is kept in a confirmation sheet in the review record; the author will share it with reviewers on request. The wording has not yet been confirmed by the Fedimint-contributing collaborator.

Appendix F. Changes from v0.18 to v0.19

Corrections, clarifications and withdrawals. No hypothesis was changed, apart from one addition to the evidence against H1 (item 5) and a change of layout in its refuting result (item 15). The invariants and the claims of status are unchanged; the wording of durability rule 3 was completed (item 7).

Corrected after a check of the Fedimint source (the two commits of Appendix B; the Disclosure says who checked what).

1. Section 9.2. "Until the next multiple of three" became "until n reaches the next value of the form 3m + 1". The fault tolerance f = ⌊(n − 1)/3⌋ rises at n = 4, 7, 10 and 13, so six guardians tolerate no more faults than five.
2. Section 8.1. "One applies to Fedimint less directly and two directly" contradicted the next sentence, which says that keyset rotation does not occur. The paragraph now gives one verdict for each failure. The statement on multi-federation identity is narrowed: by default the client derives a separate root secret for each federation, so a link between one client's federations would have to come from the network or the application.
3. Abstract, Sections 2.3, 5.1 and 14, Appendix B. "Fedimint's three mint operations" became "three client operations of Fedimint's original mint module". Section 2.3 now says that Fedimint has two generations of mint and wallet modules, that the newer ones are enabled by default at the later commit, and how the newer mint module differs. A limitation says that the design has not been mapped onto the newer module.
4. Table 3 and Section 5.3. The Transaction row now lists the nonce field. Section 5.3 notes that a rebuilt transaction would in practice have a different TransactionId.
5. Section 7.2 and H1. Section 7.2 now records the warning in Fedimint's own client documentation that the spent-nonce query reduces privacy, and the query is added to the evidence against H1.

Changed after two cold reads by models of two providers that had not seen the paper. Both also found the error of item 1.

6. Section 4.2. The statement that guardians cannot identify or target an individual payment by party is now limited to payments in the interior. Guardians see the destination address of a peg-out and can refuse to sign it. Both readers raised this.
7. Section 7.2, rule 3. The answers allowed after submission now include a rejection reported by consensus, which Sections 5.3 and 6.2 already describe. Both readers raised this.
8. Section 4.2. The definition of a federation now notes that the attestation federation of Section 10.4 runs neither a mint module nor a wallet module.
9. Section 13. The open questions now include how Lightning gateways connect to the guardians under the network restriction of Section 4.3. Both readers raised this.
10. Appendix B. "Not relied on for any argument" became a statement of what the argument does rely on vendor and press sources for: how the protocols are positioned, as Section 2.1 says of Table 1.
11. Appendix C, item 1. "For n ≥ 4" became "for n ≥ 5; at n = 4 the two are equal".
12. Appendix E. "Wording only" was corrected, because six of the rewrites had fixed a reading.

Rewrites of v0.18 withdrawn or narrowed.

13. Sections 5.3 and 11.1. Two rewrites that had fixed one reading of an ambiguous phrase (on the per-transaction receipt, and on the review a component needs before it holds value) were withdrawn. The text is that of v0.17.
14. Section 11.4. The rewrite was narrowed so that its last sentence keeps the wording of v0.17.
15. Section 2.3 and H1. After the meaning check described in the Disclosure, the rewrite of the sentence on Fedimint as reference implementation was withdrawn, and the rewrite of H1's refuting result was reduced to a change of layout. Of the six passages in which v0.18 had fixed a reading, two remain: on who retains the account record (Section 8.1) and on what remains to design for anchoring (Section 8.2).

Raised by the cold reads and not changed. These points need a decision on the design, or on what was meant, that this revision does not take.

• H6 is in tension with the exit rule of Section 5.1 and the fiat row of Table 4. The paper treats that rule as part of the primitive, and H6 already lists fiat and Lightning exits as evidence against it.
• The refuting result of H4 can be avoided by reclassifying any failure as non-compliance with the five rules. Both readers raised this.
• A time-locked spending path constrains when the recovery quorum can move reserves, not where to. The last clause of H8's refuting result therefore needs a stated control.
• The cancellation window of Section 6.2 is defined by the payee submitting the transaction, which the payment service cannot observe.
• "Outsiders see nothing" in Section 8.1 does not hold for a facilitator, which sees the transaction it submits.
• Table 5's entry on value created without proof of backing describes what consensus enforces, not what a colluding signing threshold could do (Section 2.3).
• "Settles against reserves held elsewhere" in Section 9.1 can be read in two ways.
• The Abstract makes the removal of the bearer race conditional on authentication, where Section 5.3 makes receiver binding conditional on it.
• "Neither can confiscate alone" in Section 10.4 is weakened by the limit stated in the sentence after it.
• Smaller points: invariant F5 against the residual of Section 10.3; Lightning's privacy in Section 2.1 against Table 1; the name "reissue before finality" against the finality point of Section 7.3; and the network address that guardians see under the restriction of Section 4.3.

Not changed, and still open from the questions put to the collaborator. Three passages can each be read in two ways and are as they were in v0.16: "covering module fees" in Section 5.3, the key and the channel in Section 6.3, and the list of trust assumptions in Section 10.5. Whether the client as it stands can build the payer-signed transaction of Section 5.3 was not examined.

Disclosure and research status

The idea and the project. The idea developed here, a Fedimint-style federation as the settlement layer for agent payments, is the author's own. The author co-founded the project with a collaborator, a contributor to Fedimint, who developed its prototype code. The author is the founder and ultimate beneficial owner of a group of companies that has planned federations of the kind described; whether the group or another party builds them is open.

They are deliberately not named, because the paper describes a pattern rather than a product. No company in the group is building such a federation at present, none operates one, and no licence has been applied for: the group set the plan aside in order first to build the verification practice that Section 11 argues must come before custody.

Interests, funding and patents. The author also has a commercial interest in CounterProof, the group's verification practice, which the paper recommends. The internal observations in Section 11 come from that practice and are not independent evidence. This work was self-funded by the author; no grant, sponsor or investor funded it. No patent application has been filed or is planned on the designs described, by the author or by the companies mentioned above; the paper is published in part to place those designs in the public domain as prior art.

How the paper was drafted and reviewed.

• The design was developed in a companion vision blueprint that was reviewed in two rounds: blind seats from separate model lineages (Codex, OpenAI; Grok, xAI) and an adjudicator from a third (GLM, Z.ai) working from an anonymised bundle, with the drafting lineage's own rulings sealed beforehand.
• This preprint was drafted by Claude (Anthropic; Opus 5.5) from that blueprint and the source dossiers.
• Draft v0.1 was then reviewed by two blind seats from lineages new to the design (Kimi K3, Moonshot; Gemini 3.8 Flash, Google, through the Antigravity harness), each working from a copy of the preprint, the blueprint and the dossiers without earlier review records, and adjudicated by GLM from an anonymised bundle; the drafter's expectations were sealed beforehand. One seat could not open the dossiers, and one made a web search outside the bundle.
• Draft v0.2 applied the adjudicated findings.
• Draft v0.3 then corrected the references against publisher, standards-body and library records and restated the rationale for the signing threshold (Section 9.2), after the threshold question was put to a further lineage (DeepSeek-V4) with both positions anonymised; that seat agreed with the adopted threshold and disagreed with the reasoning one adjudication had given for it, and the disagreement is recorded.
• Draft v0.4 added the funding and patent statements. It was then checked in a confirmation round: one seat (Kimi K3) tested whether each first-round finding had been closed, a second seat from a lineage new to the preprint (Codex, OpenAI) read it cold with the source files behind Section 9.2, and GLM adjudicated from an anonymised bundle; the drafter's expectations were again sealed beforehand.
• Draft v0.5 applies those rulings, and its changes have not themselves been reviewed.
• Draft v0.6 makes editorial changes suggested in a reading by an OpenAI model outside the review rounds (Sections 2.1, 6.1, 10.4, 11.1 and 15), and draft v0.7 narrows further claims after a second such reading (the Abstract, Sections 2.2, 5.2, 6.1, 7.2, 10.4 and 14, and Appendix B); these are unreviewed too.
• Drafts v0.8 to v0.14 correct the statement of the author's role, of the group's plans and of who developed the prototype code, at the start of this section and where the body refers to that code; draft v0.14 also adds the second paragraph of Section 11.4 and reference 39.
• Draft v0.15, prepared with assistance from Codex (OpenAI), clarifies the proposed anchoring in Sections 8.2 and 10.2, adds references 40-42 and the corresponding source-access statement, and removes an unresolved collaborator-link placeholder while preserving the credit.
• Draft v0.16, prepared with the Fedimint-contributing collaborator and with assistance from Claude (Anthropic; Fable 5.1), is a terminology and precision revision: it renames the terms that collide with Fedimint's vocabulary, corrects the statements about Fedimint's behaviour listed in Appendix C, and adds Table 3, the Fedimint column of Table 5, reference 43 and the verification list in Appendix B. It changes no hypothesis, status claim or disclosure. No external panel reviewed this revision.
• Draft v0.17, prepared with assistance from Claude (Anthropic; Sonnet 5.5), is a readability revision of v0.16, listed in Appendix D. It changes no hypothesis or status claim and adds only this line to the disclosure. No external panel has reviewed it.
• Draft v0.18, prepared with assistance from Claude (Anthropic; Sonnet 5.5), rewrites 78 passages of v0.17 in plainer English, listed in Appendix E. It is intended to change no hypothesis, status claim or technical statement, and it adds only this line to the disclosure. The Fedimint-contributing collaborator has not yet confirmed that the rewrites keep the technical meaning, and no external panel has reviewed it.
• Draft v0.19, prepared with assistance from Claude (Anthropic; Fable 5.2), corrects statements about Fedimint, makes changes prompted by two cold reads, and withdraws or narrows five rewrites of v0.18, as listed in Appendix F. The corrections to statements about Fedimint follow a check of the source at the two commits of Appendix B by a model advisor (Claude), with the cited lines re-read by the drafter. A model of another provider, Kimi (Moonshot; the tool did not report the model version), then confirmed 14 statements drawn from that check and rejected five false ones planted as a test; two further models, Codex (OpenAI) and Gemini (Google), could not read the source files and gave no verdict (Appendix B). Kimi was also given 50 pairs of original and revised passages: the 44 reworded passages still in question, and six passages that the drafter had altered on purpose as a test. It marked all six, and judged 42 of the 44 to keep their meaning; the other two were put back to the earlier wording, one in full and one as a change of layout only. DeepSeek (deepseek-v4-pro) and Qwen 4 (Alibaba; run by the author in the provider's console, and the model did not report its version) each read v0.18 cold, without the earlier review records. Both found the arithmetic error in Section 9.2, and neither remarked on the inconsistency in Section 8.1 that the source check had found. Of their 26 findings, 12 were acted on and 14 are listed in Appendix F as not changed. These were narrow checks made on the day of this revision, not a review round with adjudication: the drafter proposed which findings to act on, and the author decided. The Fedimint-contributing collaborator was not available and has reviewed no change made after v0.16.

Common input and separate providers do not establish independent errors, and this process is not journal peer review. This account of the review process rests on the author's own records (briefs, returns, adjudications, sealed rulings and run metadata). They are not deposited with this paper, because they quote private design material; the author will share them with reviewers on request. Responsibility for the argument and for any decision to deposit remains with the human author.

This is a conceptual preprint, not a peer-reviewed article, a completed experiment or a description of an operating system. The proposed evaluations have not been run.