SELL Fees & Forwarding

SELL transactions (buying coin from customers) can be confusing. There are many considerations involved.

Initially, the transaction seems pretty straight forward: the customer sends coin to you, you dispense fiat to the customer. The implementation however, is not that simple. There are many points to ponder.

1. How do you know that the transaction has cleared/confirmed?

2. How do you handle under & over payments?

3. How long should the transaction take?

4. What factors affect your profit?

5. How do you prevent fraud?

Firstly, not all coins support BATM SELL transactions. This is not so much a factor of software, but of compatibility & versatility within the specific crypto system, and other significant hurdles.

Bitcoin can be sent by anyone at anytime to any wallet. By design, the sending wallet should not be known in advance. So, how do we know that a certain payment to a certain wallet is from a certain customer? In CAS we operate a mini-node that issue unique receiving wallet addresses, and then we watch for that coin to confirm in a transaction to that address. We then FORWARD the coin to it’s destination wallet; the Hot Wallet or Exchange that you’ve setup in Crypto Settings.

That forwarding transaction costs you a network mining/confirmation fee. So, the customer pays a mining fee to send the coin to the temporary CAS wallet, then YOU pay another fee when the coin is forwarded. This impacts your profit, and is a cost to be considered in your pricing structure.

Some Hot Wallets permit a “no-forward” option. In this instance, the coin is sent DIRECTLY to your Hot Wallet. This option requires a Hot Wallet that issues a unique wallet address on-demand. Not all Wallets enable this. When supported, the transaction skips the CAS mini-node & you save a (network mining) forwarding fee.

The SELL Crypto Settings have a host of options to control forwarding. These options don’t apply to “no-forward” choices. Note: the strategy must implement the relevant “no-forward” Hot Wallet to avoid the CAS mini-node. SELLs sent directly to Exchanges still use forwarding, even if you skip a Hot Wallet.

During heavy network loads, this forwarding may take a while. If you catch the beginning of a network load spike, it could possibly take days to confirm (and post to your end wallet). This is a very good reason to use a no-forward Hot Wallet for SELLs; the coin is under your control from the moment the customer sends it (using normal network fees).

More about the Mempool: The Mempool (Bitcoin) - General Bytes Knowledge Base - Confluence

View a great chart of the mempool (network load): https://jochen-hoenicke.de/queue/

Invalid Payments

When the customer sends the coin to you, they are instructed to send a precise amount within a certain time period. This SELL “offer” expires after that period, because the price of a coin may fluctuate dramatically and the offer is negotiated at a certain price. Still, the customer needs time to send the coin, and the transaction must be confirmed before it’s considered valid.

This is a mandatory security measure. Tradition holds that 3 confirmations are recommended, but those extra confirmations require an additional 20+ minute delay, which some Operators may find unpalatable and unnecessary. Change the required confirmations with this setting:

Open

What happens when the customer send the wrong amount?

It happens. Sometimes the customer sends coin from an Exchange or Wallet that fails to send the precise amount, or the customer manually enters the wrong amount, or it takes too long to confirm. At this point another setting is considered:

Open

• If the amount falls within this tolerance amount, the payment will still be considered “valid”.

• If the payment amount exceeds this tolerance, or is sent after the offer expires, it is INVALID.

• The Invalid Payments Address has no effect when a “no forward” option is employed, otherwise:

  • the invalid payment sent to you by the customer will be forwarded to the address you specify:

• Payments forwarded to the Invalid Payments Address will incur a network mining fee.

What happens when the payment is detected after the offer expires?

Again: it happens. Sometimes the customer, Wallet, or Exchange will take too long to send the payment. During heavy loads, the mempool may be unreasonably deep, and the transaction doesn’t get submitted in time. This act of nature is unavoidable, given enough time. So what happens?

• Keep it shorter to reduce the impact of price volatility.

• Too short will cost you lost sales, grief, mining fees, and customers.

Why are the forwarding fees so high?

Eventually (during heavy network load), the mining fees will skyrocket. Forwarded transactions may become very expensive. These settings permit you to fine-tune your forwarding transaction mining fees.

Minimum Mining Fee Per Byte is zero by default, which means that an average fee will be calculated.

• when set to non-zero, you will always pay at least this fee (never less).

• Higher amounts ensure that any forwarded transactions are submitted more urgently (at a cost).

Maximum Mining Fee Per Byte is zero by default, which means that an average fee will be calculated.

• when set to non-zero, you will NEVER pay more than this fee (always less).

• Lower amounts may cause your forwarded transactions to get stuck in the mempool, but prevents unexpectedly high fees from consuming your profit.

• Higher amounts ensure that any forwarded transactions are submitted more urgently (at a cost).

Sell Confirmations On Exchange: this setting is Exchange-sensitive and determines when a payment sent to your Exchange (if implemented) is considered valid (on the Exchange).