Hi Ethereum Magicians,
I would like to gather feedback on a proposed ERC, Settlement-Decoupled Nanopayment Ledger, for recording fiat-denominated nanopayments on-chain while handling fiat settlement through existing off-chain payment systems.
The proposal defines a shared accounting interface for a payment network, payer institutions, and payee institutions. It covers payments, refunds, independently signed batching, and institution statement closing.
Motivation
Metered services and agent-to-agent interactions may involve individual charges smaller than a fiat currency’s minor unit. Recording these amounts at higher precision allows them to be accumulated and reconciled before conversion into amounts that existing fiat systems can process, with rounding residuals retained.
The proposed ledger provides a common, verifiable record of transactions authorized by the participating institutions. Each institution records payables and receivables against the payment network, allowing it to use its own statement cycle and existing funds processing infrastructure.
How it works
Three-party authorization
Each Payment or Refund requires explicit authorization from:
- The Payment Network.
- The payer institution, such as a wallet provider.
- The payee institution, such as an acquirer.
All three sign the same individual EIP-712 typed request. Any address may submit a fully authorized request; the submitter’s identity does not replace a required signature.
Institution and network signing addresses may be EOAs or ERC-1271 contracts. If the payer and payee institutions are the same address, one institution signature covers both roles, while a separate Payment Network signature is still required.
Institutions remain responsible for verifying their customer relationships, customer authorization, and the underlying business transaction.
Accounting across the three parties
For a Payment of amount A, the ledger records:
- A payable of A from the payer institution to the Payment Network.
- A corresponding receivable of A for the Payment Network.
- A payable of A from the Payment Network to the payee institution.
- A corresponding receivable of A for the payee institution.
These are four accounting entries across three parties. The current outstanding balances maintain two invariants:
- Total institutional payables equal the Payment Network’s receivables.
- Total institutional receivables equal the Payment Network’s payables.
A Refund is linked to its original Payment and creates entries in the opposite payment direction. Cumulative refunds cannot exceed the original payment amount.
Independently signed batching
The core entry points are:
payrefundbatchPaybatchRefundflush
Each request is signed independently. A submitter can later assemble valid, unexecuted requests for the same institution pair into a batch without asking the parties to sign again.
Batch execution retains per-request signature verification, identifiers, state, and events. Shared accounting updates use the aggregate amount, and any failure reverts the entire batch.
Independent statement closing
Each institution can close its current statement through flush; the Payment Network can also trigger this operation.
Closing a statement emits its payable and receivable totals, resets the institution’s current aggregates, reduces the corresponding network aggregates, and advances that institution’s statement identifier. The paired accounting invariants remain intact.
Institutions do not need to close their statements simultaneously. Off-chain systems reconstruct each statement from events, reconcile its transaction details against its totals, and arrange the corresponding funds processing.
Scope and trust model
Each deployment uses one immutable fiat currency and amount precision.
The contract does not issue, hold, or transfer payment assets. Its accounting fields are not token balances. A successful Payment, Refund, or Flush records an on-chain accounting result; it does not prove that fiat funds have moved or that settlement has completed.
The protocol relies on the payment network and institutions to authorize valid business transactions and meet their off-chain obligations. It does not independently verify user intent, guarantee funding, or make external fiat processing atomic with on-chain execution.
Payment and refund identifiers support duplicate prevention. Off-chain systems still need idempotent funds processing, reconciliation, and handling of chain reorganizations and uncertain execution outcomes.
Amounts and account addresses are public in this version. Customer relationship administration, institution onboarding, user limits, and privacy mechanisms are outside the core interface.
Current status
An English working specification has been prepared, covering the ABI, authorization rules, accounting invariants, payment and refund state, batch atomicity, statement reconstruction, and security considerations.
The current four-account model does not yet have a conforming reference implementation or validated gas benchmarks. This discussion is intended to obtain feedback on the design and interoperability requirements before progressing the ERC submission.
Feedback requested
I would particularly appreciate feedback on:
- Standardization scope: Is the proposed separation between shared on-chain accounting and institution-specific off-chain funds processing a useful boundary for an ERC?
- Authorization: Are there interoperability or security issues with three-party EIP-712 authorization, ERC-1271 support, and permissionless submission?
- Accounting and reconciliation: Are the paired balances and independent statement cycles sufficiently clear, particularly for refunds recorded after the original statement has closed?
- Batching: Are there important limitations or integration concerns with assembling independently signed requests into atomic batches?
- Related work: Are there existing proposals or implementations that address a similar institutional accounting model and should inform this design?
Feedback from payment providers, wallet developers, acquirers, and smart contract implementers would be especially helpful.