0

Trust is not in Q here. only technicals

Imagine banquet of a company, where guests get a one purpose event wallet with tokens. One wallet(organizer) can charge (guests). Tokens wont work with "Outsiders" wallets.

My question is pointed towards the possible use of tokens in private events, where blockchain technology(if its allowed by architecture) is used, but in a small group and in a centralized manner for a certain specific pool of wallets.

Can be in this scenario transaction preapproved in a direction towards organizer?(Organizer scans guests wallet qcode and transaction happens and organizer pays gas, guests have literally only Qcodes on memmorable items – silvercoins released only for the purpose of the event)

So basicaly I would like to be able to charge paper wallets, and locking them for the token only, without them needing gas. Puting into attention, that with other type of compatible funds it would be dangerous.

3
  • your use case seems a bit specific for it to be an issue. i mean it can be easily done by coding a smart contract that uses any ERC20 but would only let a set of addresses move their funds out of it. but you might have to make your own ERC20, for it to have any meaning. May 18 at 23:04
  • @KakiMasterOfTime, so it is possible to code ERC20 custom token, so one master wallet can charge slave paper wallets for that token? So I need only digital wallet for Organizer and guests have paper wallets?
    – skriatok
    May 19 at 6:54
  • yes an ERC20 is just an interface, your contract must implement at least all the methods in the interface. the implementation is up to you, so you can make it do whatever you want. If you have to get the public to trust your contracts, you will need to disclose the code for your token and contract. in all cases what you mentioned is easily implemented. May 19 at 15:40
0

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.

Sponsored 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.

Preapproval

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.

Other details

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 transfer and 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!

2
  • 1
    In PREAPROVAL section of your stunning explanation states: - the participants would need to contact the organizer to make any transactions what that means exactly sir/madam? BTW whitelist of addresses is "locking enough"great points.
    – skriatok
    May 20 at 18:25
  • Thanks for the kind words! If you're counting on the organizer to make all the txs for the participants, then whenever the participant wants to make a tx, they'll need to tell the organizer so that the organizer can make the tx
    – Linum Labs
    May 21 at 6:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.