This change to the hierarchy is confusing. If I understand correctly you needed new storage type without a reference to an actual storage. But why introducing new traits if you could implement previous for a new type?

removed

The grammar is broken in this sentence and the meaning is not super clear.
Also, since it's a copy-paste, the original should be updated too.

updated, hopefully it is more clear now

I suppose this is a workaround for that weird lifetime-related issue you posted in the chat recently.
But I thought you've managed to solve it by boxing some futures. So it didn't work after all?

The boxed future is used in the Synced Controller, this was a prior workaround for the lifetimes to not pass the account as a reference but as a value. I have not tried if a boxed future will solve this as well or not, but also not sure how expensive boxed futures are?

As I've said during the daily, I guess I missed it during the initial review, but this looks like a nasty foot-gun:

1. StoreLocalReadWriteUnlocked accumulates modifications inside the opaque operations collection, so it's possible to modify something, then read this value back (either via StoreLocalReadWriteUnlocked itself or its "parent" transaction) and get the old value instead of the modified one.
   If we want to go this route, we should probably do it on a lower level, where the underlying key-value store is available, so that we can store deltas instead of opaque operations, which then could be applied on the fly when reading.
2. It's possible to create multiple StoreLocalReadWriteUnlocked and the result of their application is unpredictable.

P.S. I've also played with the code for some time trying to come up with something else.

1. Passing a shared reference across an await point requires the referenced object to be Sync, which is not a reasonable restriction for a db transaction object. But this can be worked around using mutable references. E.g.
   • Signer methods could accept the tx by value: db_tx: impl WalletStorageReadUnlocked + Send;
   • We could have impl<T> WalletStorageReadLocked for &mut T where T: WalletStorageReadLocked, so that &mut db_tx could be passed to the signer.
   • Inside private code the mutable references could be passed around directly, for simplicity.
2. There is still the problem of sqlite::DbTx not being Send, this is because it contains a MutexGuard.
   At the first glance it looked like there should be no need to hold the mutex for the entire lifetime of DbTx and that we could lock the mutex inside its individual methods. Unfortunately, this didn't work, as multiple tests started failing in the wallet due nested sqlite transactions being created. I didn't investigate it much, but it looks like there is some code in the wallet that can create a sqlite::DbTx when another one has not been dropped yet, so it depends on the presence of the mutex lock.
   (Btw, we don't have a mutex inside lmdb transaction objects, so it looks like the backends are not interchangeable, unless I'm missing something.)

At this moment it seems to me that the correct approach would be to have a separate set of storage-related traits (Backend, transactions etc) where all the methods are async. And then have an implementation of AsyncBackend for sqlite. The implementation will be able to use tokio::Mutex whose MutexGuard is Send.