Repository navigation
feat(monero): the payee picks how many confirmations a payment needs - #333
Merged
Merged
Conversation
…(exo-dcc) Feedback from the Monero community (stasher.news, 2026-10): "I don't need 10 confirmations if I'm selling somebody a 10 mXMR USB Type-C cable." Monero's 10-block rule is when a received output can be spent, not when a payment is real. Only the payee bears a reorg's risk, so the payee chooses. - A Monero request may name its confirmation depth: `confirmations`, 1 to 720, 10 when absent. It is part of the agreed effect and signed as one tagged element more. A split without it keeps its exact bytes, and only a Monero split may name one. - The payee's own wallet confirms a part at that depth (PartTransfer.confirmations; parts_xmr). The card's "seen, n of N" and its wording follow the agreed depth. - Request a payment and Send money on Monero have a field: "Counts as paid at this many confirmations (1-720)". The note under the composer names the depth, and an invalid one keeps Propose off. - The typed spec derived-exo-dcc.5 still says "at least 10" (its probes use the default, 7/7). Re-wording it goes through discuss-issue: exo-e16. Tested-Behavior: split_monero_test §6 (the rule at depths 1, 3, 20 and the default; the driver refuses 0, 721, non-canonical, and a depth on a non-Monero split; the depth is in the signed bytes; a 10 mXMR request at depth 1 final at one confirmation on the payee's own read); grade-specs exo-dcc.5 7/7; the composer field seen on a dev runner (2 and the note follows; 999 refused); module/tests/run-suite.sh 263/263; ui-lint 0 new Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Session-Id: 836705fe-fda9-501b-8ac2-1ce50b5af64a
This was referenced Oct 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This answers community feedback from stasher.news: "I don't need 10 confirmations if I'm selling somebody a 10 mXMR USB Type-C cable." Monero's 10-block rule controls when a received output can be spent. It isn't a requirement for counting a payment as received. Only the payee carries the risk of a reorg, so the payee chooses.
What changes
confirmations, from 1 to 720, and it's 10 when the request doesn't say. The depth is part of the agreed effect and is signed. A split without it keeps its exact bytes, and only a Monero split can set one.derived-exo-dcc.5still says "at least 10". Its probes use the default and still pass 7/7. Re-wording it goes through discuss-issue (exo-e16).Tested
split_monero_test§6 covers:grade-specs exo-dcc.5: 7/7.run-suite.sh: 263/263.ui-lint: 0 new findings.🤖 Generated with Claude Code