hardfork(v4): Spam deterrence

[binarybaron]

This PR introduces a change in the atomic swap protocol to discourage spam. It does so by attaching a fee to refunds. This fee will be burnt.

Current situation

The exchange rate of each swap is set at the start and can't be changed.
A swap either completes within 12 hours (this requires cooperation by both parties), or be cancelled.
A swap might still be cancelled after both parties lock their respective currency.

In that case the taker ("Bob") can issue a refund within a 24 hours window. He will get his Bitcoin back and the maker ("Alice") will get her Monero back.

The problem

This can be abused by malicious takers in two ways:

1. A maker with significantly higher reserves than other makes might use part of it to block other maker's reserves.
   This is possible by initiating a swap and waiting for the maker to lock the Monero.
   Then not continue the swap and wait for a refund.
   This will only cost the malicious actor transaction fees for 3 Bitcoin transactions, while preventing the "small maker" from competing in the market for trading volume.
2. A malicous actor might start a swap and decide only to complete it when the exchange rates change in their favor enough.
   If that doesn't happen they can refund for the low cost of 3 Bitcoin transactions.
   This allows the malicious actor to treat the swap like a (bascially) free Monero call option.

The solution

The root problem causing both these issues is that refunds are free (for the taker).
By attaching a cost to refunds (only refunding a part of the Bitcoin) this is no longer the case.
Thus both tactics are no longer profitable.

Makers will be able to set the extend of the refund fee. Takers will know the refund fee prior to starting a swap and decide whether to trade or not.

The refund fee does not go to the maker. That would create skewed incentives. The refund fee will be "burnt". The only way to retrieve it is for the maker to sign a transaction giving it back to the taker.

However, the maker will be able to voluntarily give the taker a full refund. This is what we call "amnesty" for now. This is intended such that makers can help out clueless takers who accidentally refunded.
This path is, however, purely voluntary and takers can't 100% rely on it.

Implementation

• Add TxPartialRefund
• Add TxRefundAmnesty
• Change swap setup to transmit amnesty_amount, tx_partial_refund_fee, tx_refund_amnesty_fee, tx_partial_refund_encsig and optionally tx_full_refund_encsig and tx_refund_amnesty_sig
• Add those same fields to the necessary states
  • Alice
  • Bob
• Add new states to the Bob's state machine to handle the new scenarios
• Implement Alice watching for TxFullRefund and TxPartialRefund
• Desing + implement system for Alice to configure full refunds and amnesty
  • add config entry
  • update orchestrator wizard and add swap-controller command
• Figure out how to make it all backwards compatible with old swaps stored in the database

Important: This implementation plan does not reflect the current design of the feature, see the discussion below for details.

[binarybaron]

This issue has been assigned a bounty (💰)

Current bounty:

• 0 XMR contributed by @binarybaron and @Einliterflasche
• 0.60433 XMR contributed by the eigenwallet community

Exceptions for this specific bounties

Due to the nature of this issue (cryptographic/protocol complexity rather than implementation complexity) the bounty will also be used to fund audits.

Bounty donation address

If you want to incentivize work on this issue, you can help increase the bounty by donating to the address below.

87UHJU9GA3qHn4sX4ZZndEERmqEXx94kuS3QFZ1XGVNg28YcWX2H9AqBh5G6Uc4cfmKRbTDQ3HgsoVKW1RuPHtzLSUEHrmN

Fine print

We use bounties to incentivize development and reward contributors. All issues available for a bounty have the Bounty 💰 label.

To receive the bounty of this issue, you agree to these conditions:

• Bounties will be set and awarded at discretion of @binarybaron
• An issue is considered resolved when the patch(es) proposed by the contributor is/are merged in the appropriate repository according to terms of the issue.
• The first person who resolves an issue in its entirety will receive the entire amount of the bounty.
• If the issue is resolved collaboratively by more than one person, the reward will be distributed among the contributors
• Donating to the bounty does not guarantee that this issue will be completed and refunds are generally not issued. If they are then they are granted at the discretion of @binarybaron

[pokefan77]

Can you elaborate when partial refund will be done instead of full refund and punish?

It seems like Bob needs Alice to get 10% of his money back in case of partial refund.
Why 10% of Bobs money is at risk in case Alice doesnt coorporate, which happened before with some makers!

[Einliterflasche]

Yes. This update will essentially move some trust requirement from the maker (that the taker is not a spammer) to the taker (that the maker will refund).

However, this can be addressed as follows:

• a decentralized reputation system. Takers who didn't get the refund can publish a proof, thereby discouraging other takers from swapping with this maker
• takers might choose to only start swaps for which the maker has already provided the full refund address. Thus not requiring the maker to fully refund
• the maker does not gain anything from withholding the refund, thereby he is not incentivized to do so

Everyone would be better off if this wasn't necessary, but it is. That's the sad truth.

[pokefan77]

I am not sure if i and others understand your words "takers might choose to only start swaps for which the maker has already provided the full refund address. Thus not requiring the maker to fully refund" can you rephrase it please? sorry

"the maker does not gain anything from withholding the refund, thereby he is not incentivized to do so"
your phrasing is totally misleading, confirming your narrative. My question was why Bobs 10% are at risk, and neutrally said the truth is: "the maker does not gain anything from releasing the refund, thereby he is not incentivized to do so"
Its the same situation as btc punished. the truth is that there is even ongoing discussion on matrix because somebody lost his big amount of money because the maker did not help him, because he has 0 incentive to do so.

Can you elaborate when partial refund will be done instead of full refund and punish?

[jstark2a]

I am not sure if i and others understand your words "takers might choose to only start swaps for which the maker has already provided the full refund address. Thus not requiring the maker to fully refund" can you rephrase it please? sorry

I am also trying to understand but here is how I interpreted it: Makers will have the choice to offer full refunds or partial refunds. The taker will know the maker's refund policy before they begin a swap. The full refund policy is straightforward: If the taker cancels, they get the full refund. For the partial refund policy, if the taker cancels, they are not guaranteed to receive 100% of their money back. The purpose of this is to disincentivize malicious takers from abandoning swaps because they know there is no penalty for doing so. If you as a taker do not like the idea of a partial refund, you as a free market participant, can refuse to do business with that maker. Because partial refunds mean less risk to the maker, this will allow them to offer lower rates.

somebody lost his big amount of money because the maker did not help him, because he has 0 incentive to do so.

He lost his money due to negligence (or at least failure to understand the refund process). As the docs state "With most makers, you can still redeem the Monero even after being punished. This is, however, purely voluntary and we advise against relying on this."

[pokefan77]

That would mean either makers are ok with full refund = they automatically give it, or they are not ok with full refund, meaning they will also not help giving it. Its just 10% scam. Its not even remotely justified as fees of all makers are currently around 2%, why should a taker loose 10%?

[jstark2a]

That would mean either makers are ok with full refund = they automatically give it, or they are not ok with full refund, meaning they will also not help giving it. Its just 10% scam. Its not even remotely justified as fees of all makers are currently around 2%, why should a taker loose 10%?

It's not a scam if you know what you are agreeing to. The taker also doesn't lose anything if they simply complete the swap like they agreed to. Makers are not obligated to hand out free 12 hour XMR call options.

Adding a partial refund support will actually help honest takers. If there is not penalty, a maker can lock up the liquidity of other makers that offer lower rates than them. Then they can jack up their rate because their competition is gone. This is effectively a Denial of Service attack against makers.

[pokefan77]

If thats the worry the penality fee should at maximum be the fee that they ask from the user for a completed trade, not a flat 10%

[Franz-Hermann-GT]

If thats the worry the penality fee should at maximum be the fee that they ask from the user for a completed trade, not a flat 10%

The XMR price movement also needs to be taken into account here — it can easily move 5–8% during those 12 hours.
In most cases, takers cancel the swap when the XMR price drops during that period. As mentioned earlier, this effectively works like a free call option.

[binarybaron]

It is not a flat 10%. The 10% is purely for demonstrational purposes. The percentage can be dynamically configured by the maker.

[binarybaron]

This issue has been assigned a bounty (💰)

Current bounty:

• 0 XMR contributed by @binarybaron and @Einliterflasche

• 0.60433 XMR contributed by the eigenwallet community

Exceptions for this specific bounties

Due to the nature of this issue (cryptographic/protocol complexity rather than implementation complexity) the bounty will also be used to fund audits.

Bounty donation address

If you want to incentivize work on this issue, you can help increase the bounty by donating to the address below.

87UHJU9GA3qHn4sX4ZZndEERmqEXx94kuS3QFZ1XGVNg28YcWX2H9AqBh5G6Uc4cfmKRbTDQ3HgsoVKW1RuPHtzLSUEHrmN

Fine print

We use bounties to incentivize development and reward contributors. All issues available for a bounty have the Bounty 💰 label.

To receive the bounty of this issue, you agree to these conditions:

• Bounties will be set and awarded at discretion of @binarybaron

• An issue is considered resolved when the patch(es) proposed by the contributor is/are merged in the appropriate repository according to terms of the issue.

• The first person who resolves an issue in its entirety will receive the entire amount of the bounty.

• If the issue is resolved collaboratively by more than one person, the reward will be distributed among the contributors

• Donating to the bounty does not guarantee that this issue will be completed and refunds are generally not issued. If they are then they are granted at the discretion of @binarybaron

I wanted to specify this in a bit more in detail as they seems to be some confusion around the bounty on this issue.

In general donations to specific issues will NEVER go directly to neither me nor @Einliterflasche. Issue specific bounties are for funding work of outside contributors.

Donations to this issue will not necessarily result in me implementing this in a faster manner.

Donations will be used to potentially fund an outside contributor to give this a review to assess the security of this on the protocol level. As the funds collected here are unlikely to be enough to fund a full audit (something like TrailOfBits would do) this is going to be "light review" most likely with no attribution to the reviewer.

We are in talks with someone who is well trusted in the Monero community and is more than enough qualified.

If we don't find a reviewer, the funds will be used for other bounties.

[pokefan77]

Shouldnt a protocol change be fully audited?

[binarybaron]

Shouldnt a protocol change be fully audited?

No, not at all protocol changes necessarily require an audit. We are not introducing any new novel cryptography here.

I understand the concern here though. This will obviously be well tested.

[Franz-Hermann-GT]

In the current design (including the timelock-based, pre-signed TxRefundAmnesty / TxRefundBurn approach), does Alice have any way to decide in advance (e.g. during swap setup, potentially based on the taker’s PeerId / reputation) that a swap should only ever allow a partial refund,
or is the only point where Alice can effectively deny a full refund the short post–TxPartialRefund window (~2 blocks / ~20 minutes) by publishing TxRefundBurn?
In other words:
is the maker’s amnesty decision strictly limited to that post-refund time window, or can it be pre-committed earlier in the protocol?

[Franz-Hermann-GT]

Another question:
let’s assume a malicious maker whose goal is to continuously lock other makers’ funds (which is one of the core attack scenarios this PR is trying to address).
After these changes are introduced, such a maker could simply set their partial refund fee to 0%, since they do not fear retaliation — other makers locking their funds is not a concern for them.
This would put them at a clear competitive advantage compared to honest makers, who may feel forced to set a 2–5% refund fee to protect themselves.
How is this scenario mitigated, if at all? Or is this an accepted trade-off of a maker-configurable refund fee?

[Einliterflasche]

In the current design (including the timelock-based, pre-signed TxRefundAmnesty / TxRefundBurn approach), does Alice have any way to decide in advance (e.g. during swap setup, potentially based on the taker’s PeerId / reputation) that a swap should only ever allow a partial refund, or is the only point where Alice can effectively deny a full refund the short post–TxPartialRefund window (~2 blocks / ~20 minutes) by publishing TxRefundBurn? In other words: is the maker’s amnesty decision strictly limited to that post-refund time window, or can it be pre-committed earlier in the protocol?

The swap-controller gets a new command set-burn-on-refund <swap-id> which can be invoked at any point during the swap. The asb will remember the decision and act accordingly, once the time window to publish TxRefundBurn opens up. This can be scripted as you wish. On a blockchain level, there is no way to pre-commit, though.

Note: the transaction names are going to be renamed, in accordance with the schema I posted earlier. The command name will also change.

[Einliterflasche]

Another question:
let’s assume a malicious maker whose goal is to continuously lock other makers’ funds (which is one of the core attack scenarios this PR is trying to address).
After these changes are introduced, such a maker could simply set their partial refund fee to 0%, since they do not fear retaliation — other makers locking their funds is not a concern for them.
This would put them at a clear competitive advantage compared to honest makers, who may feel forced to set a 2–5% refund fee to protect themselves.
How is this scenario mitigated, if at all? Or is this an accepted trade-off of a maker-configurable refund fee?

This feature allows other market makers to at protect themselves from spam by attaching a cost to it. This does not prevent one maker with very large reserves from guaranteeing 100% refunds.

[Franz-Hermann-GT]

Given the constraints, these seem like the best possible solutions.
The main remaining concern for me is the 12-hour window before a swap is automatically cancelled / becomes refundable. With the current Tor/clearnet communication working reliably, all legitimate (non-spam) swaps usually complete within 20-60 mins, so 12 hours feels quite long.
The 24-hour window after that makes sense if the goal is to avoid entering a punish state whenever possible.

[binarybaron]

Given the constraints, these seem like the best possible solutions.

The main remaining concern for me is the 12-hour window before a swap is automatically cancelled / becomes refundable. With the current Tor/clearnet communication working reliably, all legitimate (non-spam) swaps usually complete within 20-60 mins, so 12 hours feels quite long.

The 24-hour window after that makes sense if the goal is to avoid entering a punish state whenever possible.

We will be reducing this massively to ~3 hours.

[binarybaron]

Bug (NaN earnest deposit)

[binarybaron]

Clicking "Select" on an offer causes a stack overflow:

2026-02-03T17:47:11.683686Z DEBUG swap{swap_id=1ccf93e3-b9ea-477a-bd61-b03ddc0939dc}:buy_xmr{buy_xmr=BuyXmrArgs { bitcoin_change_address: None, monero_receive_pool: MoneroAddressPool([LabeledMoneroAddress { address: None, percentage: 1, label: "Your wallet" }]) } swap_id=1ccf93e3-b9ea-477a-bd61-b03ddc0939dc method="buy_xmr"}: swap::cli::api::tauri_bindings: swap/src/cli/api/tauri_bindings.rs:270: Emitting approval event event=ApprovalRequest { request: SelectMaker(SelectMakerDetails { swap_id: 1ccf93e3-b9ea-477a-bd61-b03ddc0939dc, btc_amount_to_swap: 130310 SAT, maker: QuoteWithAddress { multiaddr: /onion3/z2ex467s6lgsgq76kayh7rz2yw5ec4gmaum5ipji6qdeuig7ydgaayqd:9939/p2p/12D3KooWP33cDHuWszEivRGmkpBjiBHtSCtusE6WjZBAw5TZLdsU, peer_id: PeerId("12D3KooWP33cDHuWszEivRGmkpBjiBHtSCtusE6WjZBAw5TZLdsU"), quote: BidQuote { price: 509088 SAT, min_quantity: 2000 SAT, max_quantity: 130310 SAT, refund_policy: PartialRefund { anti_spam_deposit_ratio: 0 }, reserve_proof: Some(ReserveProofWithAddress { address: Address { network: Stagenet, kind: Legacy, spend: "0xc56f4c7d3ef66c6ff0f6659e6891883953a6b68a366321d61d17df1f032341d5", view: "0x365e32d826e3026f58541af996857a679249a4d7567e4024daac9c487728b79c", (address): "59K6RPyGQvPKiyHZzjcSUoAb9ChJpC12YcpAtoTAonXacfRmpcMz8UZKdBoiMDoWpHJKmpGDjVrWB7AXrDBcXtqCJckWFKd" }, proof: "ReserveProofV21AjZru1PbimPNajXZawxsDh9B7xwMirwhBF6VTjki4cSGfWR5aUGtoBbnZhf5fhYGNAeCDGixm6YLBamSGKr1azZUumZ3VZiieSieeR9oKbUC2S5qrDcpVP2fcCXajz8CszpVeRW1Y28K6ndYAwLcdrcw3Esf1ZjHbBY7FcSDox7JNu2bL9QYVznKhCKrKjmgpTaRyNotsqGYPMs3Cy19LqbqARZX3tnXWDkrtkWD2pvzUh7ZaEJdEy2Dw8CpGpr4wTtDEBM9sKXWpxxgRNeVExEGY8TpfJLKzQ8qprJxJ9Y4pHkkGTPGgGV9YGBXKZMx3UF9RJ2qzTVm7eMsMyuFQ7qNEZXKcGW6BrkRwhDNcjGVu8X14RANSGb2PJ9mptdy2e1ngfBi7LVHuJsWrwnJgEVqJ2bLbUt3uK8yfVu5nJYPfiTPZQwDK5YHZWfNL8", message: "12D3KooWP33cDHuWszEivRGmkpBjiBHtSCtusE6WjZBAw5TZLdsU" }) }, version: Some(Version { major: 3, minor: 6, patch: 7 }) } }), request_status: Pending { expiration_ts: 1770141131 }, request_id: 4bccd7b9-3a75-4c6b-8797-fe5d828423d9 }
2026-02-03T17:47:11.684416Z DEBUG swap{swap_id=1ccf93e3-b9ea-477a-bd61-b03ddc0939dc}:buy_xmr{buy_xmr=BuyXmrArgs { bitcoin_change_address: None, monero_receive_pool: MoneroAddressPool([LabeledMoneroAddress { address: None, percentage: 1, label: "Your wallet" }]) } swap_id=1ccf93e3-b9ea-477a-bd61-b03ddc0939dc method="buy_xmr"}: swap::cli::api::tauri_bindings: swap/src/cli/api/tauri_bindings.rs:310: Emitted approval request event request=SelectMaker()
2026-02-03T17:47:13.583102Z DEBUG peer_context{peer_id=12D3KooWS1DtT4JmZoAS6m4wZcxXnUB3eVFNvW8hSPrAyCtVSSYm}: swap::cli::event_loop: swap/src/cli/event_loop.rs:352: Dialing peer peer_id=12D3KooWS1DtT4JmZoAS6m4wZcxXnUB3eVFNvW8hSPrAyCtVSSYm connection_id=168
2026-02-03T17:47:13.620198Z DEBUG peer_context{peer_id=12D3KooWHmvxYrYxZ3Eq45rS7rpJqSZBa5aH6nsueRVLW2cNXwDo}: swap::cli::event_loop: swap/src/cli/event_loop.rs:352: Dialing peer peer_id=12D3KooWHmvxYrYxZ3Eq45rS7rpJqSZBa5aH6nsueRVLW2cNXwDo connection_id=169
2026-02-03T17:47:13.900533Z DEBUG swap{swap_id=1ccf93e3-b9ea-477a-bd61-b03ddc0939dc}:buy_xmr{buy_xmr=BuyXmrArgs { bitcoin_change_address: None, monero_receive_pool: MoneroAddressPool([LabeledMoneroAddress { address: None, percentage: 1, label: "Your wallet" }]) } swap_id=1ccf93e3-b9ea-477a-bd61-b03ddc0939dc method="buy_xmr"}: swap::cli::api::tauri_bindings: swap/src/cli/api/tauri_bindings.rs:381: Returning approval response

thread 'tokio-runtime-worker' has overflowed its stack
fatal runtime error: stack overflow, aborting

[Einliterflasche]

Progress update

The implementation is almost done. There are some small todos:

• GUI dialogue explaining the partial refund system in more depth
• Guard against nonsensical deposit amounts (too low/too high)
• Calculate weights of the new transactions
• Updating the docs

We are now testing the system on Bitcoin testnet/Monero stagenet.