I'm not sure I understood the question right, so feel free to set me straight if I didn't get some details right.
It sounds like you want to be able to charge up a bunch of paper wallets with a particular token, and then let them spend this token inside of an event. Gas should not be paid by the participants. You also mention that the wallet should be "locked from other tokens".
Let's talk about the different facets of this.
One easy solution that might not work
As a potential alternative to your scenario, you may want to consider using a testnet as opposed to mainnet. The ETH on testnets is free (the major testnets all have faucets that give out freely), and the gas is low. Even if your particular event has an entrance fee, it doesn't necessarily preclude using a testnet for your token. If you could use a testnet, you could also load up the paper wallets with enough test ETH for gas.
If you are going to build on mainnet you'll need a different approach if you aren't going to top off everyone with some gas money. There is a concept called sponsoring gas. Without going into technical details here, the basic idea involves setting up a proxy contract that holds ETH that will pay gas for other transactions. Two frameworks for this are GSN and Biconomy. OpenZeppelin (3.x, I'm not sure about 4.x) has GSN integrated in their contract suite, so if your ERC20 is being built using OpenZeppelin's contracts (advisable), you may want to check OpenZeppelin's posts on how to make use of GSN. (Here's one, but they have more.) This will still mean that the event organizer is paying the gas, though.
Your question seems to also touch on preapproving the event organizer. If the organizer is preprinting these wallets, the organizer would have full control of the wallets before handing them out, and could approve themselves before giving them out to participants. This does open up a vector for the organizer to make all transactions using
transferFrom on behalf of the participants, but would likely be difficult to execute from a technical perspective - the participants would need to contact the organizer to make any transactions.
Depending on the nature of the situation, participants might also not enjoy the fact that the organizer has complete control of their funds.
Some things not mentioned yet, but that might bear mentioning:
- If there are a limited number of addresses that can receive the token, and you're concerned with attendees sending tokens to incorrect addresses, you may want to extend the
transferFrom functions to refer to a whitelist of approved addresses, and have any transfer revert if it isn't going to a preapproved address.
- You mention locking the wallet from other tokens. I do not know of any way to do this. You can lock a contract from receiving ETH, but that would involve all of the paper wallets being linked to contract wallets (not traditional EOAs, or Externally Owned Accounts), and on a practical level, I'm not sure it'll be worth the trouble. (Though that is your decision.) I'm also not sure why this would be strictly necessary - you may want to consider letting attendees continue to use their accounts after the event, even though the event's token will no longer have utility.
Hope that helps!