When sending a transaction, ethers wallet does not have the "Authorize with Firefly Wallet" button, only "Send Payment".

[AmazingZ-sys]

my device is iPhone 13 pro

[AmazingZ-sys]

I would really appreciate your help. I followed the code and circuit provided in the repository, but I wasn't able to reproduce the hardware wallet.

[ricmoo]

This old version of the hardware wallet hasn’t been updated in quite some time. Not exactly sure what the problem could be, but if you would like to try out our new wallet, check out the firefly pixie (it’s in the same org on GitHub).

Message me@ricmoo.com and I can mail you a device too, if you want to start experimenting with it. ;)

[AmazingZ-sys]

This old version of the hardware wallet hasn’t been updated in quite some time. Not exactly sure what the problem could be, but if you would like to try out our new wallet, check out the firefly pixie (it’s in the same org on GitHub).

Message me@ricmoo.com and I can mail you a device too, if you want to start experimenting with it. ;)

Thank you very much. I’m currently trying to replicate the older version of the hardware wallet. May I ask if you have tested the compatibility of the Ethers Wallet on iOS 18 and iPhone 13 Pro? I’ve tested two sets of Arduino Nano and NRF24L01+ modules, and both sending and receiving messages are functioning properly, so I suspect the issue might lie in the app’s compatibility. Would you be able to help me with this?

[ricmoo]

I haven’t tested on any recent hardware or software. I would expect it to still work, because it mimics the standard of BLE advertising data in a way that would break a lot of existing technology if they stopped supporting it.

Keep in mind the original wallet used BLE advertising data to get a tx or message from the phone to the device, but the other direction was performed using the phone camera to scan QR codes in the device.

The 2.4GHz radios in the NRF24L01+ only had (I believe?) 29 bytes of available overhead that could be exploited, which I recall being 3 bytes too small for a “legitimate” advertising packet, but it was something that could still be read. And I know other companies also used the same chip in knock-off cheap BLE iBeacons.

It has been a while, and I don’t recall all the technical details specifically, but you should also try out the app “LightBlue” as it is an excellent debugging tools when reverse-engineering the BLE protocol. It will tell you at least if your hardware is broadcasting the advertisements.

The protocol basically rapidly changes its advertising packets to shuttle data along using a circular buffer which includes the chunk offset. So if a packet is missed it will be discovered on another run around the loop. Each packet is also encrypted with a checksum, to identify packets that belong to the protocol compare to random background packets. You just need to make sure those key fields are aligned on the device and phone and it should work…

But it will take some debugging to find the issue. :)