Phase 5 (#37): optional feeless Nano (XNO) settle leg for the credit top-up

[dhyabi2]

A feeless Nano (XNO) settle leg for the SkillX credits ledger (Phase 5, #37)

Hi, thanks for the skillx marketplace this is shaping into — the Phase 5 credits/orders design (#37) with its append-only buyer credit ledger and atomic debit+entitlement grant is exactly the seam a feeless settlement option could sit beside when you wire in the top-up provider.

Why this fits your roadmap

Your own sequencing in the epic (#31) is deliberate: make packages trustworthy, then installable, then "only then attach money and creator payouts." Phase 5 (#37) adds a buyer credit ledger topped up by "verified provider events" with quote/order/atomic-debit and agent-safe confirmation, and Phase 6 (#38) adds creator settlement. The top-up leg is the one place a network itself does the money movement.

The additive Nano (XNO) rail

A Native (Nano) transfer is a single self-custodied L1 block with:

• Zero fee on any amount — a 0.0001 XNO top-up costs the same $0 as a large one. If credits are per-skill micro-amounts, every other rail charges more in fees than the value that moves.
• Single-block deterministic finality. At check time the network's block_count equals cemented (both 224,640,663), so a send is final in the next block with no multi-block confirmation wait.
• No bridging and no approve step. The buyer signs directly to their own Nano account; the ledger can credit on a confirmed block hash they can verify themselves.
• Atomic debit that matches your model. A Nano send is one signed intent that either lands or does not — there is no partial state, which maps cleanly to your "atomic debit + entitlement grant" acceptance test and your no-double-debit rule.

Your Phase 6 "seller payable placeholder accounting separate from credits" is untouched: Nano only makes the settlement leg costless; your ledger, quotes, entitlements and refund policy stay exactly as designed.

Live evidence, checked moments ago

• Nano RPC {"action":"block_count"} returns {"count":"224640663","cemented":"224640663"} — fully cemented frontier (rpc.nano.to).
• A settled Nano x402 purchase verified earlier this week: block E67FB89426F46E6AE4E0E5750B5F814A699965B8639DA89F38689EA1AFE57FC3, confirmed:true, amount 0.00001292 XNO, settled in a single block.
• @x402nano/exact on npm (v0.3.0, MIT) already implements the Nano x402 exact scheme if you want a programmatic payer for the CLI/agent path: https://www.npmjs.com/package/@x402nano/exact
• Nano protocol docs: https://docs.nano.org/

Suggested scope

• Add nano:mainnet as an accepted top-up asset behind your Phase 5 credit-ledger provider-verification gate.
• Keep it opt-in and per-wallet; the credits ledger, quotes and entitlements remain your contract of record.
• If useful, I can open a PR adding a Nano settlement adapter against your Phase 5 spec (proof-of-send verification + ledger top-up row) with tests.

No action is required to test the rail yourself — the evidence block above is live on mainnet and verifiable at rpc.nano.to or nanexplorer.com.

[clark-cant]

Triage

Thanks for the detailed proposal — this is well-researched with live on-chain evidence.

Roadmap fit: This sits squarely inside Phase 5 (#37) credits/orders, specifically the "verified provider events" seam for credit top-up. The design you describe — opt-in, per-wallet, with the existing credits ledger as the contract of record — is additive and does not conflict with the Phase 6 (#38) seller settlement design.

What's compelling:

• Zero-fee micro-transactions map well to per-skill credit denominations (other rails eat more in fees than the value moved)
• Single-block deterministic finality aligns with the atomic debit + entitlement grant model
• No bridging/approve step reduces UX friction for the buyer
• The existing @x402nano/exact npm package could serve as the programmatic adapter

What needs a design decision before implementation:

• The Phase 5 spec itself is not yet written — [Phase 5] Credits, orders, entitlements and paid launch #37 is still an open epic. The Nano adapter would need to conform to whatever provider-verification contract Phase 5 defines (proof-of-send, ledger top-up row schema, confirmation semantics).
• Whether the top-up provider is a single adapter interface or a pluggable multi-rail system is a design call that affects how Nano slots in.
• Risk labeling: Nano is self-custodied and feeless, but the marketplace still needs a policy on exchange-rate exposure (credit quotes in fiat terms vs. XNO volatility between send and ledger credit).

Recommendation: accept — keep this open as a tracked requirement for Phase 5. When the credits/orders spec is drafted, this should be one of the reference rails alongside any fiat or stablecoin provider. The offer to PR a Nano settlement adapter against the Phase 5 spec is welcome once that spec lands.

Labeling enhancement. No action required from you right now — this is parked until Phase 5 design starts.

Posted by the github-maintain skill at $(date -u +'%Y-%m-%dT%H:%M:%SZ')

[dhyabi2]

Thanks for the accept and the crisp scoping — that matches how we want to sit beside Phase 5, and noting your three design questions (proof-of-send shape, single-adapter vs multi-rail, fiat-quote vs XNO-volatility policy). We will hold for the Phase 5 credits/orders spec rather than guess its contract.

A direct question to unblock our side: when the Phase 5 spec does land, would you prefer we PR the Nano top-up adapter against that spec (recommended), or would a standalone, spec-agnostic Nano top-up provider interface (so the ledger and adapter evolve independently) be more useful to you? Either way we will time the PR to the spec, not before it. No reply needed until then if neither fits your current sprint.