They have 3 possibilities depending on their use case:
- they don’t because they let the client handle that
- or if they build the raw transaction with
createrawtransaction then they have to
- first create a transaction without the fee,
- calculate the required fee from the size of the generated transaction and the
paytxfee field of getinfo (the exact formula is in the source, it’s (1 + floor(size_in_bytes / 1000)) * paytxfee),
- and run
createrawtransaction again with the fee included (and possibly do this process again in the rare situation where the new fee increased the size and it made the required fee change)
- or if they build the raw transaction themselves then they do the same as above but with their own generator.
There’re currently no way of seeing the raw transaction before it is sent by the client. We could add an RPC to do that. You can however inspect already sent transactions with getrawtransaction, so you can verify the fee calculation on any past transaction. But I am not aware of any report about the client miscalculating the fee.
The problem with exchanges is they usually want to build the transaction themselves so they also have to calculate the fee themselves and sometimes they fail to do that correctly.
That’s probably because in other coins most simple transactions are below 1000 bytes, so they wrongly assumed the fee is constant. But in most coins with a minimum fee it depends on the size, and if they make the same assumption on other coins they probably also generate invalid transactions from time to time when they have to take multiple inputs because they have a lot of small outputs to spend. In NSR it’s almost always bigger though, because of the split (especially if they don’t disable it on the output, but if they build the transaction themselves the split is not done anyway).
We do have a documentation for exchanges that mention another important change they usually want to make (disabling avatar mode, but it’s really only useful if they let the client generate the transactions) : https://docs.nubits.com/integrating-nubits-or-nushares-with-an-exchange/
It doesn’t mention the share split though.
It’s not very easy because you have to know the transaction size (which may be seen as a chicken and egg problem). But as you can see above it’s not very difficult either (that’s how the client does it btw). You have to be able to query paytxfee frequently though, because it was decided our fee would be able to change over time.
Note that paytxfee is actually not the actual current fee, but is the maximum fee that will be effective in the next 10 blocks, so that you’re almost certain the transaction can be included in a block if you send it now.
