The search lead me to your comment, because I was thinking about animated QR codes too.
I did not consider scanning sender and receiver simultaneously, which makes a lot of sense in a real world payment situation. There is still the waiting time for the confirmations though, so the payment does not happen instantaneous.
I found this project for transferring data with animated QR codes:
The demo looks nice. Pretty much like scanning a normal QR code.
Depending on the scanner, this could also be used to scan a series of printed QR codes. Just so that transactions can also be sent with letters.
Animated QR also could make sense for communicating with a cold storage device.
If in an animated QR code the data for each frame starts with ‘grin://’, a normal QR code scanner would offer to open the app that is registered for that.
I tested that with an animated QR code that I created myself and my phone offered to open ironbelly.
https:// aws1.discourse-cdn.com/standard10/uploads/grin/original/2X/f/f0510f7b61cf71acabad5c8027cc0d585dc74603.gif (apparently murderous gif. Copy link and remove space after //)
This is a send file in 16 QR codes in one animated gif (11 fps, 56kb, responses are larger) where each frame starts with ‘grin://’, some metadata (frame number, total frames, shortened hash), followed by a slice of the data.
Scanning this file entirely takes at least roughly 1.5 seconds. If a frame is missed, a scanner needs to wait until the frame is shown again, which takes another ~1.5 seconds.
If you have ironbelly installed, your standard scanner might offer to open it. Ironbelly itself of course has no clue what to do with this code, but if it had, it could detect animated QRs and start itself in scanning mode.