I like that the tokens stay on the client side until they are spent in what you described here. this way the client doesn't need to race the vendor to redeem un-spent proofs.
I think earlier versions of this idea involved over-payment with time locks and trust-less recovery of un-spent proofs, but those solutions were more focused on cash back rather than reducing traffic to the mint...
I don't want a situation where the mint needs to create millions of milli-sat tokens in advance.
I'd prefer to build a smaller set of tokens (1 millisat, 2 millisats, 4 millisats, 8 millisats, ... 1024 millisats ) in order that millions of different combinations are possible with only a small number of tokens.
At one moment in time, three of those tokens (1+2+4 = 7 millisats) "belong" to the router. Next, to move the balance up to 8, we need a way to send the 8 millisat token to the router, *where the router somehow revokes its access to the 1,2,4 -millisat tokens*. That's the challenge; the device gives access to a subset of the tokens, where the router can later 'revoke' its access (like in Lightning) in return for an updated - more valuable - set of accesses
