The package currently used to support QR-based devices is external to MetaMask organization, and doesn't strictly follow our conventions and types for our Keyring classes.

Moreover, its current implementation includes functionality for managing UI modals related to pairing and signing.

We should evaluate the creation of an internal QRKeyring package with a simplified implementation (no UI management) with the following acceptance criteria:

• The package uses TypeScript
• The QRKeyring class extends the Keyring type
• The QRKeyring class supports initialization with a CBOR string compatible with QR-based devices currently supported by MetaMask clients
• The QRKeyring class can be used to derive the same accounts that are currently derivable with @keystonehq/metamask-airgapped-keyring
• The QRKeyring class must support the deserialization of a state coming from @keystonehq/metamask-airgapped-keyring
• The package must have full package-level test coverage and should be easily testable at client level with e2e
  • A Keyring Bridge is a keyring extension that can be optionally added in case the keyring structure doesn't allow easy e2e testing. This should not be needed as there is no communication transport besides QR-based messages, which can be easily mocked.