Michele Esposito

> Alternatively, we could update the keyring API to add a method that returns the next account address without adding it. That would solve the problem as well. @Gudahtt This...

@Gudahtt Regardless of the test I think we can close this and simply remove the method: `addNewAccountWithoutUpdate` never worked as intended since calling `persistAllKeyrings` also updates the controller state along...

## Hold Keyrings The first responsibility listed is already effectively implemented: `KeyringController` holds all keyring instances in its `#keyrings` array.

## Locking and Unlocking The second responsibility, /providing functionalities to lock and unlock the wallet/, is also already implemented, but we can probably do some refactoring to make it easier...

## Keep in sync its state with the state of each keyring This is were things become a little more tricky. Currently, every time one of the “keyring actions” provided...

## Route action calls for a specific account to the corresponding keyring As already disclosed in the previous paragraphs, not all keyrings have the same features, and some of them...

## Proposed solutions ### Lock / Unlock - [ ] Remove `isUnlocked` method - [ ] Refactor `submitPassword` and `submitEncryptionKey` into one single `setUnlocked` method --- ### State syncing ####...

Thanks for taking a close look @mcmire! > Instead of setLocked and setUnlocked, what do you think about calling these methods lock and unlock? To me, "setXXXX" implies a simple...

Except for `test-unit-jest-main` (which should become green after the above-suggested changes), other failures seem unrelated to this PR

@metamaskbot update-policies