Add a feeless settlement leg (Nano / XNO) for sub-cent per-call usage

Thank you for submitting a feature request! Please fill in the template.

Preflight Checklist

• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Problem Description

OpenMeter meters and bills usage for AI/API/DevOps products, and usage-based billing is its core strength. But the settlement rails it drives today — Stripe and other card/MoR gateways — have a structural floor that OpenMeter's own use case keeps running into:

• Card rails carry a ~30¢ + ~2.9% fee and a minimum-collection floor. A single AI agent call priced at $0.0005 or a sub-cent metered unit cannot be collected as a standalone charge. Teams either batch usage until it clears the floor, delay billing, or quietly swallow the micro-charges.
• In agent-to-agent commerce the buyer is a machine that meters its own consumption and expects to pay per call. The batch-then-settle card model adds latency and a collection floor that the metered price already knows exactly.

So there is a class of usage that OpenMeter measures to the exact unit but that no card rail can settle on its own, at its own unit price.

Proposed Solution

Add Nano (XNO) as an additional settlement leg next to Stripe, for the per-call / sub-cent case.

Nano is a commit-chain (block-lattice, not a UTXO or account model) that settles a payment without a merchant account, without a card scheme, and without a chargeback window. Its defining property for this use case: it has no minimum-collection floor. Every price settles standalone — a $0.0001 call settles instantly and fee-free, because there is no scheme, no interchange, and no MoR taking a cut. That is exactly the profile of the per-call usage OpenMeter already meters.

The integration pattern is the one OpenMeter already uses for metered billing, but with the settlement step delegated to a pay URI:

• OpenMeter computes the billed amount for a metered charge (integer micro-dollars, the same grid OpenMeter's own accounting uses).
• Instead of (or alongside) pushing that amount to a Stripe invoice line, it mints a standard nano:<address>?amount=<raw> pay intent.
• The agent/human buyer pays the URI through any Nano wallet; the payment lands as a verified block on a public ledger — the payment itself is the receipt, so no separate webhook callback is required for reconciliation.

I've built and tested a dependency-free, integer-only reference for the arithmetic core (the exact concern that must not lose value on sub-cent amounts): microDollarToRaw() converts a metered micro-dollar amount into an exact Nano raw amount (ceil-rounded, so no value is ever lost) and buildNanoPayIntent() mints the standard nano: URI. Full node test run passes (7/7). I'd be glad to open it as a PR shaped to OpenMeter's conventions.

Alternatives Considered

• Batch to Stripe until the floor clears — this is the current state; it adds latency, delays the seller's revenue, and cannot price an individual call, which agent buyers need.
• Another card/MoR rail (Polar, Paddle, etc.) — same collection floor; the problem is the rail, not the provider.
• x402 / USDC on a sidechain — a real protocol, but it still carries a fee and a facilitator for the sub-cent case; Nano's fee is zero and needs no facilitator or merchant account.

Additional Information

• Nano has 30 decimal places, so sub-cent pricing maps cleanly to integers (1 XNO = 10^30 raw). No floating point is involved.
• The sign-and-send step is deliberately left to a wallet/RPC — OpenMeter's server never holds a private key; it only mints the intent.
• Happy to adapt the reference implementation to OpenMeter's provider-abstraction layer as a PR if this direction is welcome.