...
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.
| Tip |
|---|
Bitcoin easily supports SELL transactions, so we’ll use that as a point of reference in this article. |
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 a 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 permit 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: https://generalbytes.atlassian.net/l/c/fytLpHT3
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.
...
Payments forwarded to the Invalid Payments Address will incur a network mining /forwarding 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 confirm get submitted in time. This act of nature is unavoidable, given enough time. So what happens?
...
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).