Changes look good,

but what's the difference between this and wasmd tx?

Changes look good,

but what's the difference between this and wasmd tx?

Yes there isn't much difference right now. The main benefits now:

• encapsulating everything in the cli, which I believe will be easier for quartz developers to wrap their head around.
• better error handling - right now whenever I test with wasmd tx I often then have to do a wasmd query to see if the tx was successful
• we won't have to write docs with wasmd neutrond or our-testnet cmds, we can just run our cli and if we set the config to wasmd or neutrond it should just work. and the cli should be app agnostic, so other blockchains could leverage it, and they likely won't use wasmd or neutrond

Longer term, we can build in even better error handling, support different networks through the cli (neutron, wasmd, our testnet), and I imagine for our own testnet we would want our CLI to have this functionality, since we wouldn't be using wasmd or neutrond. We could also do better handling of the msg args, instead of having to pass messy json strings with slashes in them.

All in all it's a minor addition. Let me know if you think it is valuable enough to include. If so, I will merge main into here, and use block_commit_tx() as suggested.

Support for multiple networks makes sense! What's the difference between the neutron and wasmd tools for submitting a tx right now?

What happens if you try to submit a tx using wasmd but pointed at a Neutron node url?

Asking because I'm wondering if we should just add this network switching feature now with this pr

Theres no support for neutrond right now.
i actually dont know what would happen if you sent a wasmd tx to a neutrond node.... possible it might still work, but still not good practice

seems like we would update wasmd_client.rs to be something like blockchain_client.rs and export a wasmd client and a neutrond client, and any others, that are all very similar

i agree it would be useful to add in this PR, let me look into it and get back to you here

our discussion here would close out #75

We could just merge this as is, and work on the neutron deployment in a different PR, which is the simplest way forward

Nice idea but too porcelain for now. Also it's only good for sending txs but maybe doesnt cover all flags options. And doesn't cover querying (eg. balances) or managing keys which would still require the underlying wasmd binary anyways.

Theres a new readme instructions in here that we might want to rescue but needs to be updated and use the quartz bin instead of cargo run