Do the additional wallets other than the original client wallet (i.e. the one for Admin) need a peers file?

Q: We do not have to run sync --nostop for other wallets we create such a for Shareholders, right?
For those wallets we just need to run standard sync, right?

I am guessing that only the admin client wallet needs to use the peers file created by sync --nostop.
right or wrong?

Just to reiterate. The smart-contract CLI (smartcontract) is only meant for testing. You should have a real wallet implementation for all parties involved with a smart contract.

The smart-contract daemon (smartcontractd) only uses a “wallet” (collected UTXOs) for special operations and just uses bitcoin provided in the requests to post the responses.

That being said. Each instance of smart-contract CLI is designed to be independent with their own files, including the peers file. This should be completely separate from any instance of smartcontractd. If you are using the CLI to create a contract offer then that is the admin wallet.

OK I think a trick I can use, to avoid needing to run sync --nostop to find peers for a new wallet,
is to just copy the peers file from the original CLI wallet (i.e. the admin wallet) to the folder of the new wallet, such as for a shareholder’s wallet.

A problem I can see is that for a more robust wallet such as an HD Wallet implementation,
if a new HD child address is used for each transaction (to keep it most secure)
the BSV funds left over after the transaction (the change due) will have to keep moving up to be in a fresh block so as to minimize sync time. So a P2PKH tx would have to be run to move it to a fresh block. Otherwise each wallet address will overtime fall farther and farther back from the tip of the blockchain and so will take longer and longer to sync after each Tokenized Action Tx. So it would be a lot of work to keep track of all those HD child addresses.

I don’t think I am understanding what you are saying.

This CLI wallet is not HD and is not designed to be robust. It was a quick implementation for testing. Much more software is required for a fully functional robust wallet.

All new payments and change will go in the latest block. You should never have to sync from before the point of the last sync. Sync will just update from its last point in the blockchain to current.