The last question first:
“Would there be a way to close the faucet…?”
Yes, you can opt out and close, if the TEAL code is written in such a way.
The others:
Point 1 and 2 can be done atomically, within a transaction group
Point 3 can be done by the user using the wallet
Point 4 and 5 can be done atomically
The real problem is, that there is a state stored in this process flow: how does the faucet “knows” that the unique notes sent back to it were sent out previously? I don’t know yet, how to solve this…
Thanks, interesting point about state storage.
Another option would be to forgo unique IDs and either A. try to send the ASA until it is added to wallet of recipient (for example every minute) B. ‘listen’ (somehow) to the receiving address and send the ASA when the ASA ID is added.
Are either of those options feasible?
cool, I’ll try to set it up in that way then. I assume no transaction fee is charged initially when the transaction is rejected? Or would pushing until success incur lots of transaction fees?
Also, to clarify, can the contract be setup in such a way that the end user never sees a line of code? Or would the end user need to setup some sort of smart contract as well?
You will need to write a frontend and most likely an off-chain backend depending how things are set up.
You may need to think how to prevent abuse.
Without out-of-chain CAPTCHA, you will see abuse with high probability: it’s very easy to get all the NFTs this way.