Quote from: NotATether on June 21, 2025, 11:07:44 AM

Why don't you charge a small percentage of the deposit like 1% to cover for network fee fluctuations?

Na mate, that’s too much to charge a user who’s withdrawing $10K — it would be $100.

Quote from: stompix on June 21, 2025, 11:11:35 AM

Quote from: nonlogs on June 21, 2025, 08:43:19 AM

However, the problem is that we need to introduce a two step process to get an accurate fee: first create the transaction, then show it to the user for confirmation to accept or reject.

It's not a two-step process, you show them what they get for 0.4 BTC for example, with the current fee included.
Why not copy what everyone else does, just add the fee in your percentage take as I don't think you're going to do this with zero fees.

Quote from: nonlogs on June 21, 2025, 08:43:19 AM

Sometimes, due to high network traffic, the price can increase unexpectedly ($10-$50).
what do you guys suggest ?

You do the median.
You charge a bit over the next block fee, and with the money you have saved when you have managed to get confirmations for 0.30 cents for a $3 charge, you offset the transactions where you have to pay $6 to bump your $3 tx.

It’s a two step process on the backend, and it might get quite heavy when 100 people are withdrawing simultaneously. It takes time to fetch UTXOs and construct the transaction, and we get the hex data that we push to the blockchain.

Now, if we wait for a certain period without broadcasting, other users trying to withdraw could end up using the same UTXOs, and the blockchain would reject those transactions. i guess you have heard about double spend problem, That creates more complications in showing the exact fee that will be charged.

Quote from: ABCbits on June 23, 2025, 09:32:18 AM

Quote from: nonlogs on June 21, 2025, 08:43:19 AM

2. Charge the user only the actual network fee, which would be very low ($1-$0.10). However, the problem is that we need to introduce a two step process to get an accurate fee: first create the transaction, then show it to the user for confirmation to accept or reject. Sometimes, due to high network traffic, the price can increase unexpectedly ($10-$50).

As customer, i would suggest this option. Aside from what @OmegaStarScream suggested, i would also recommend you to use fee rate which ensure the TX can be confirmed within next or 2nd next blocks.

Quote from: JeromeTash on June 21, 2025, 09:36:24 AM

Privacy based CEX? I am curious in knowing how it will operate.

I'd speculate it have similarity with exchange listed on https://kycnot.me/.

As I mentioned in the previous post, it’s a complicated process to create a transaction and keep it without relaying it to the network. Double spending and vByte fee changes happen depending on the number of transactions in the mempool. I think it would be best to hard code a certain vByte and consolidated utxo's to avoid increasing inputs.