Say I only want to allow users that have gone through a KYC verification to opt into my smart contract. What would be the best way to do this?
My first thought was to make the opt-in check for a grouped transaction of size 2, where the second transaction is signed by my personal private key.
There are many ways to do it.
If you are ok requiring opt-in as part of the KYC process, then indeed, you can use a group of two transactions where one of them is done by the KYC authority account.
If you want more flexibility, you can have the KCY authority sign the whitelisted addresses and the smart contract will check this signature using the opcode ed25519verify.
The ed25519verify opcode is quite heavy in terms of cost, right? That might not be feasible for me if I want to write a lengthy contract.
You would need to use fee pooling, i.e., add application calls to dummy applications in the group to increase the cost limit.
Another solution is to use 2 transactions:
Logicsigs allow for a higher budget.
The above solution is actually what is used to distribute governance rewards.
If you’re interested, see GitHub - algorandfoundation/governance: Technical specifications for the Algorand Foundation governance platform
Adding something to what @fabrice suggested.
Use a KYC key/value pair into users’ local state that is False by default and could be turned True only by a KYC provider (a regular account or another KYC dApp).
Hey Fabrice,
Can you be specific as to what kind of flexibility ed25519verify could provide in this scenario?
Using ed25519verify does not require you to know the rounds where the transaction will be issued.
But actually @cusma’s solution is even better in most cases, except if you absolutely want to prevent non-KYC users to opt-in (in which case the solutions are highlighted are most likely needed - but it’s unclear why you would like such a strong restriction)