the root cause in older versions of the Ledger Ethereum App was a race condition between what was being displayed and the transaction stored in the underlying buffer. a simplified example: 1. send transaction A to the device, e.g. send 0.01 ETH to 0x111...111. 2. Ledger parses transaction A and shows it on screen. 3. while the user is still reviewing transaction A, send transaction B, e.g. an unlimited approval to 0x111...111. 4. transaction B can overwrite transaction A in the underlying transaction buffer. the user still sees transaction A, but the device ends up signing transaction B. the actual attack involves P1_FIRST + BASIC, followed by a second P2_STORE. STORE was introduced in the previous Ledger release and made this overwrite path possible. Ledger fixed this in 1.22.3 by rejecting new transactions while an existing transaction is still being processed. why doesn’t this affect OneKey? OneKey has worked this way from the beginning. while a transaction is waiting for confirmation or signing, the device won’t accept another transaction. so there is no window for a second transaction to overwrite the one currently being reviewed. in other words, the behavior Ledger added in 1.22.3 was already the default behavior on OneKey.(Yishi)