Skip to main content
Locked 2026-06-18. Technical background: Finality and refunds.

​
The policy

There is no on-chain refund mechanism on either rail. Refunds are merchant-initiated, off-chain, and manual. One path covers every case — overpayment, underpayment, wrong token, and cancellation:
1

Customer requests a refund

Through the merchant’s own support channel. The platform is not in this loop.
2

Merchant collects a self-custody address

Supplied by the customer at refund time. Not stored in advance, not inferred.
3

Merchant sends the funds

From their own wallet, after the payment has been distributed and claimed.

​
The rule that must never be broken

Never refund to the inbound sender.CEX withdrawals originate from a shared omnibus hot wallet, not the customer’s own address. Returning funds there is unattributable and almost always a permanent loss for the customer.
This holds even when the sending address looks like a normal wallet. The refund target must always be an address the customer supplies and controls.

​
Why there is no window

The binding constraint is the refund target, not a timer. Because a large share of deposit-rail payments have no safe on-chain refund target, an on-chain window would have added attack surface and audit scope without protecting the users actually at risk. It also created a free-option exploit — pay, watch the market, reverse within the window — which dies by construction once the window is gone. Removing it also shrank the audited contract surface and sped up settlement, since funds sweep as soon as the deposit confirms.

​
Practical consequences

​
Open gaps

Underpayment has no exit path. With refund() removed, a partial payment sits in a forwarder with no way to complete or return it without manual intervention. The designed answer is a customer top-up prompt plus a merchant sweep-and-refund action. Not built.
Refund fees are undecided. A refund requires distribute and claim to have run first, so the platform fee has already been taken. Whether it is returned, and how that is disclosed to merchants and customers, is an open commercial decision.

​
What the platform never does

  • Never fronts refund money.
  • Never claws back a settled payment.
  • Never holds funds pending a dispute.
These are not service limitations to be worked around. Each one, if added, would give the platform custody — see MiCA position.

​
Merchant-facing wording

Terms and privacy pages were refreshed to state the general-checkout framing, the deposit rail, and the no-refund-window reality explicitly. Merchants must not be able to discover this policy for the first time during a dispute.