I've been thinking a bit on this. I feel like the general approach would be to identify big/complex parts inside the client and look to move them to their own components that do the processing but don't change the client's state, this could be done separately.

Some important/complex processes in the client I identified are:

• Note creation, specifically note importing but could be joined with deriving note records form their miden_objects counterparts like Note and InputNote/OutputNote. This component could be composed to get information on all note records created.
• State synchronization, like it's mentioned in the original comment. This component would deal with making the rpc request, checking block relevance, mmr changes, updating notes' and accounts' states (just getting the new states, without applying them to the store). The part previous to the request (i.e. getting the relevant information for the sync) might also be a possible component.
• Transaction creation, this would entail the TransactionRequest to TransactionResult process. Validating the transaction, getting the relevant elements from the store, injecting fpi information, executing the transaction and building the final result.

I'm planning on creating a branch with these possible components, just moving the code around and seeing what the interfaces should be but feel free to mention if you agree with this separation or if we should head in a different direction (maybe having more smaller components).

I'm planning on creating a branch with these possible components, just moving the code around and seeing what the interfaces should be but feel free to mention if you agree with this separation or if we should head in a different direction (maybe having more smaller components).

Makes sense. I would probably implement these one component at a time and maybe start with the state synchronization one. It can be done in the PR, but if you'd like to share a sketch here - that's fine too.