Integrating Pairing : Identifying if a device already is bonded about bumble HOT 2 OPEN

The keys in the file-based key store are stored per-address, and unbond.py should really only remove the keys for a single address (it you don't pass an address, it just prints all the keys but doesn't remove anything, which the help text really should document...).
With Bluetooth LE, things are a bit more complex than with Classic, because of LE privacy. The addresses that are used by LE-privacy-enabled devices (most of them) rotate regularly (typically every 15 minutes for something like a phone). Those rotating addresses can be "resolved" back to a fixed address by peers that have the IRK (identity resolving key), which is obtained when pairing.
When pairing, the paired device will share, along with the IRK, its "identity address" with the pairing peer, and that's the address that's used for key storage in the key store. When you can for devices, you will see the rotating random address (a.k.a "resolvable private address"), and if you have the IRK, it can be resolved. Having the IRK for a device, and being able to resolve a private address is what tells you that you're paired with that advertising device.
In order to resolve addresses, you have to use an AddressResolver object, which you instantiate by passing a list of resolving keys. From keystore instance, keystore.get_resolving_keys() gets you that list.
I'm working on some enhancement to make that key resolving step automatic, but in the current version, that's something you need to do for yourself when you get advertisement results.
The scan.py app is "supposed" to do that for you when your device config has a keystore or if you pass a keystore file explicitly, but I see that it's broken in the current version (because the instantiation of the keystore object have been moved to after power_on(), I will send a PR to fix that (but the code example to resolve keys with a resolver is still valid).

Finally, about encryption on LE: just being paired doesn't mean you'll have encryption enabled. In a connection, one of the peers will need to request it. That's done with connection.encrypt(). With desktop and phone OSes, that may happen automatically if you try to access a GATT characteristic that returns an error indicating that there isn't sufficient encryption. Bumble doesn't (yet) do this automatic request upon GATT error, so if you need encryption, you have to call .encrypt() to request it.

from bumble.

Thanks again for explaining.
So at a high level :

1. on_connect , check if you can resolve the keys , if not pair request.
2. on_pair or on_connect (if already paired) -> connection.encrypt()

from bumble.