Repository navigation
Phase 5 (#37): optional feeless Nano (XNO) settle leg for the credit top-up #52
Description
Activity
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/exactnpm 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')
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.
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:
block_countequalscemented(both 224,640,663), so a send is final in the next block with no multi-block confirmation wait.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
{"action":"block_count"}returns{"count":"224640663","cemented":"224640663"}— fully cemented frontier (rpc.nano.to).E67FB89426F46E6AE4E0E5750B5F814A699965B8639DA89F38689EA1AFE57FC3,confirmed:true, amount 0.00001292 XNO, settled in a single block.@x402nano/exacton 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/exactSuggested scope
nano:mainnetas an accepted top-up asset behind your Phase 5 credit-ledger provider-verification gate.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.