Pretty cool, seems its locked to an address. I studied the base math behind ecash, but haven't read this detail. I wonder how this is achieved. 

 check it out 
https://github.com/cashubtc/nuts/blob/main/11.md 

 Excellent, Thank you. 

 Just verified myself.  

Sender (my laptop) can't clawback the payment because I went out of my way to lock the ecash to the public key of the recipient (my phone). 

My phone (offline) has a "later" button when receiving offline.  

It shows up in my offline phone's transaction history when press the receive "later" button.  But you can see at the time how much the ecash token is worth and the fact that it is locked to your public key (can't be redeemed by anyone else before you can get to WiFi).   

Offline instantaneous receiving of sats that are tied to your public key.  Amazing.  

 https://image.nostr.build/43a115316cd1d767580d2e1a0fe52ad836c1e4220dd8b7e9efe3fbf7650c83d3.jpg 

 I test it too. I works except if you lock the ecash to a key the sending phone needs to be online to bring up the barcode? 

 Yeah, I didn't test that yet.
Just testing offline receiving to confirm that the sender couldn't pull back the funds if they got to internet first.  (Which they could not.  They couldn't claim the token to one of their own accounts since it was locked to the original recipient's public key). 

I suppose if you knew that every Saturday you would pay the local rancher 100 sats for whatever, that you could make a stack of ready to go QR codes that ONLY that person could cash in.  

You could print out a stack of QR codes that are like cash except locked to the recipient. (Who can melt them down and spend the sats anywhere they wanted) instead of locked to an establishment like a regular gift card.  

 True but why would it need an internet connection to lock it 

 It's physically impossible to prevent the sender from clawing back the funds if the sender gets internet before the recipient does.

nostr:nevent1qvzqqqqqqypzq3huhccxt6h34eupz3jeynjgjgek8lel2f4adaea0svyk94a3njdqqsfygz4xk8qcah6a3dj054dpkf3r2gzuyfmr4t4svndluuuhpm60dcs0sxfg 

 It does not matter really unless the mint punishes the sender for double-spending afterwards but imagine:

Alice has a million bucks with a mint, represented as Chaumian tokens. She now clones her device and walks into the desert to meet Bob. Bob shares his public key with Alice. Alice signs the million bucks over to Bob's pubkey.

Now if Alice destroys her device and uses her pre-transaction-clone of it, to send the funds to a different receiver before Bob could talk to the mint, what magic other than later punishment for a provable double-spend could there be to prevent this claw-back? 

 I don't think so, it's like a race. So, it requires trust. But the method referred to in other comments seems ideal.   That is, enforcing spend to particular address for situations where trust is not available.