A bitcoin, officially named UTXO, is represented by an address of a unique coin amount. A transaction is simply a record where a set of inputs bitcoin is destroyed and a new set of outputs bitcoin is created. This is why some people identify the coins by the transaction id and the coin's output position id. It is convenient to define the coin ticker based on its recordability among the alive chains by the financial principle that the same ticker has the same price: BTCC for coins only recorded in bitcoin core chain, BCHN for coins only recorded in BCHN chain, BSV for coins only recorded in BSV chain, BCHA for coins only recorded in BCHA chain, BCH for coins only recorded in BCHN and BCHA and BSV chains, BTC for coins recorded in all alive chains. Each block chain may have its preferred ATM. For keys management, it is advised to have different Hierarchical Deterministic key for coins of different ticker because no one wants to mix up coins of different price. Obviously, the price of BTC is the highest and the mining power moving from BCHN or BCHA chain to BSV chain will have zero impact on BCH price.

For all chains

ScriptTxComposer is the TXs composer following the above doctrine which creates the TXs for the user so that he can copy the TXs back to his personal wallet to sign and broadcast the TXs. Note only coins with more than 10 sat are collected in the composer because theoretically 1-sat coin cannot be spent by itself due to the smallest fee being 1 sat; given the energy per coin numbers, currently I decide not to care about coins less than 100 sat. The amount in previous coins of its output is sat. Remember to manually change the number based on the unit setting of the signing tools. Then, the prevtxs (prevcoins) can be fed to other signing tools such as bitcoin-tx where, privatekeys.json and prevtxs.json being the files in json format (array of the private keys and array of the previous coins), the command lines of core chain and cash chain (also sv chain, bcha chain) are:

bitcoin-tx raw-hex-string-of-the-transaction load=privatekeys:privatekeys.json load=prevtxs:prevtxs.json sign="ALL"
bitcoin-tx raw-hex-string-of-the-transaction load=privatekeys:privatekeys.json load=prevtxs:prevtxs.json sign="ALL|FORKID"

After signing the tx in a safe device with the above command lines, one can review and assure the result by command line "bitcoin-tx -json hex-string-of-the-signed-transaction" then move the signed tx to a public device and find some public services to broadcast this signed tx .

ATM for core chain

https://coinb.in

This is a public domain open source java script implement. It is concept-simple and less user operation error possibility.

The "wallet" tab is in fact a deterministic way to generate a private key based on your input about the email and password which is not necessary to be a true email and password (you can arbitrarily to fake an email and the password); it is just easier for a user to memorize an email and password than to memorize the private key directly. However, if you keep your private key safe, say, on a paper and input that private key in usage such as sign or new a transaction, this "wallet" tab is not necessary.

Being java script, it means you can operate it directly in the browser. Further, if you insist a high security for your private keys, you can download the whole source code from github mentioned in its page and inspect the source code line by line and signing on a standalone offline browser with no any private key info leaking possibility. After signing, then turn online and broadcast the signed transaction into the bitcoin network.

You can also use this tool to verify correspondent address or public key for an encoded private key; see here. But as mentioned, any private key info shall not be transmitted on the internet so you shall do this task in a local copy version of the tool.

ATM for BCHN and BSV chains

https://ccoin.cash/

Almost the same as the ATM for core chain above. Thanks to replay benefit between BCHN and BCHA and BSV chains, no need for separate ATM for the three chains to craft a typical transaction. However, its default broadcast channel of this software will deny the transaction if the inputs of the transaction is not valid in BCHN chain. Therefore, BSV users need to broadcast the transaction via other BSV-friendly nodes such as blockchair.com.

When there is no replay benefit between core chain and other chains or a user plans to take advantage of cheaper fee, a user may need to craft/sign the same transaction multiple times. Ideally without bothering of tribalism of the authors of those wallets, it is possible for a software that is capable to craft the transactions in one stop and broadcast them afterward.