3

I have a Game-program. Several users can play a game and receive a reward afterwards. When a user starts a game, I create a Game account in which I store the game state and the sum of rewards (just a number). Every new game is a produces a new game account. The rewards (tokens) are stored in an Associated Token Account of the program. Different accounts can contribute SPL to a particular game. Such a contribution would move SPL to the associated token account and increase the rewards number for a particular game. Several games store their tokens in the same Associated Token Account.

When a user wins a game, the sum that is saved in the Game account is transferred to the Associated Token Account to the winner.

Problem: In case a game is canceled, I need to send SPL back to the contributors (there might be many contributors to the same game) and I don't have a way to find out who contributed what and to which game.

In EVM world, I would probably emit an event with game ID, contributor and a sum and then I would query all events for a particular game ID. However I haven't found a way to query log records by an ID in Solana. Is it not possible?

Another solution would be to store contributors and their sums on the Game account. It sounds complex and probably expensive. My game accounts will not have a fixed size, I will have to extend them in case there are many contributors. It would be harder to reuse them, and generally there would be a lot of state management involved.

I am curious if there is a better way of handling this situation.

Question: What is the Solana idiomatic way of solwing the problem of keeping a record of who sent SPL via a Program and how much they sent it?

I would appreciate any suggestion. Also I am new to Solana, maybe I am doing it completely wrong please let me know if there is a better architecture for such a use case.

1 Answer 1

5
+50

A way to do this would be to create a separate account for each wallet that contributes. That account would be a PDA to prevent duplicity, and would store contribution details such as the amount contributed and the wallet address.

In the case of a refund, you could easily get all accounts of that type and read the details to send the appropriate sums to the correct destination accounts.

Alternatively, you could make it such that users manually claim their refunds. Here access checking would be done in the same way with the contributor PDA.

Update

PDAs can be used to create hashmap-like structures on-chain. Check here. Here it can be used to guarantee that only one contributor account can exist for a single user's wallet.

An advantage of using the PDA approach is that you don't have to pay upfront for space you aren't already using OR update the contract when your space allocation runs out.

The difference here is that each contributor pays for creation of the contributor account, as opposed to the alternative where you alone pay for the space allocation(This could be considered either an advantage or disadvantage depending on your wants).

Also, account creation on Solana costs less than storage of a 32 character public key, another positive.

2
  • Thank you (+1). What do you mean by "preventing duplicity"? Woludn't that be too expensive to create an account per contributor? What are the disadvantages comparing to storing all contributions in a single account (in my case that might be an account of the game to which the contribution is done)? Dec 12, 2022 at 14:13
  • I'll update my answer
    – Ademola
    Dec 12, 2022 at 22:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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