A prepaid ASA QR Code

Prototyping a sort of gift card (prepaid card) for ASA. Let’s call this ASA GiftToken. Want to gauge any feedback or suggestions for how I’m handling this physical-to-digital flow.

  1. I’m printing on the physical card a QR Code containing the Public Key and Private Key for a newly created address ADDR (with min Algo balance and opt in GiftToken) with 0 GiftToken balance.
  2. When a customer purchases the card, the merchant will scan the QR Code (using just the Public Key part) and fund address ADDR with the GiftToken balance purchased.
  3. When the customer ends up redeeming the card, they will scan the QR code (using the Public and Private Key) to transfer the entire GiftToken balance from address ADDR to their own account (a separate Public Key).
  4. If any dispute happens, the merchant (as the ASA administrator) can freeze or clawback by following the transaction history of the original address ADDR.

If any of you guys have looked at different flows for this use case, please let me know :slight_smile:
I know it’s usually not recommended to expose private key like that, but I haven’t seen and can’t think of a better way of replicating the functionality of a prepaid card.

Just a thought, perhaps you could have some sort of hash/key that encrypts the configured address’ private key as a message— then you have that hashed message printed on the card and you could create a sort of front-end or scanner that rekeys that address to whichever wallet the user creates.

This way the cards on their own don’t hold any value, just spitballing here. My concern is that if you display the mnemonic or private key and have it commercially made it could get compromised in several ways before it reaches the customer. Even if you had some sort of scratch-off or tape removal features to the card it’s still somewhat risky to some degree, but you should probably judge that at your own discretion.

If you want it to be scalable I would definitely and strongly consider the most secure options. I’m not sure how developer-ready you are to handle these things, but if it seems innocent enough and there isn’t much on the line per card, and you use a disclaimer that highly recommends they don’t use it as a custodial wallet after redeeming in case there is an exploit, then none of the above should really be worth pouring resources into.

Thanks for the feedback. Rekeying at the point of sale seems like a good idea.

Could you walk me through an example of this hashing or encryption process you’re proposing? To clarify, when the address is rekeyed, I’m encrypting the 25-word mnemonic into an even smaller passphrase?

There’s a few ways you could do it, so just one way would be like:

You have the seed phrase for one of these configured wallets that have a minimum balance of Algo, and maybe even the tokens in there as well to avoid extra steps.

You encrypt each seed phrase with a fixed and very secret seed phrase using AES or fernet.

With this encrypted message, you can freely put it on a card or over email without worrying about anyone looking at it since it’s encrypted. Then when someone wants access to that wallet, they just feed this encrypted message to your app/website/program and it spits out the seed phrase for that wallet. You could also use any of the available SDKs to also present the wallet address.

If you wanted to rekey, they would just create some arbitrary wallet on any app and you can skip the presentation of the seed phrase and address for less friction and you would just send a one-time transaction on your end to rekey to their new wallet.

I’m not entirely sure if wallet apps will just recognize the rekey and display the new assets and Algorand balance even though they only have their initial wallet there or if it just allows the initial wallet to spend on the rekeyed wallets behalf—I don’t usually mess with rekeys often at all but if it’s the latter then you might just have to display the seed phrase to them to import.

I mean technically if someone knows they can just take that encrypted message to your website then it’s counterintuitive and you might as well just put the seed phrase on there. But you can take extra measures like the scratch-off and maybe a proof of retail purchase where the card activates first. Or only give them to people who do some bare minimum verification or KYC? Again, just ideas.