What would be the best way to design a Hongbao (Redpacket) game using AlphaWallet?

Can we make a Hongbao TokenScript game / dapp that people can play with ?

I'm thinking of a game similar to the one commonly used in WeChat:

  • Group chat where a red packet can be shared
  • Amount of cryptoc can be splitted into random (or at least uneaven) fractions of the total.
  • Finite number of group participants would be able to claim those fractions on a first come first serve basis

I see it as a game that can really generate traction because of the FOMO.

Maybe using eth2 , Linkdrop.org or AlphaWallet MagicLink / ERC875?

It's likely best to be used in-chat, but, if not at least with some kind of token card function or a magic link.

I recall Radi Cards worked on something, might be worth encouraging them to use TokenScript or parnter up?

Would love to hear your feedback.

mmh, very interesting ideas you have.

For those who didn't follow, HongBao is an envelope with money in it. Apparently, you have to open it to see how much money is in it because it's coloured (and it wouldn't be good gist for the receiver to open one and return it for another with more money). HongBao (Chinese) literally means "envelop coloured red".

Let me make a simple game with it. Let's say Bob & Carol & Ted & Alice are good friends, and Alice wants to host the game because she is kind and rich.

A game:

Starts with Alice preparing:

  1. Alice provides ℎ₁, ℎ₂, ℎ₃ to the smart contract, where ℎ₁ is the hash of the amount in the first envelope, ℎ₂ is the hash of the amount in the second envelope, ℎ₃ is the hash of the amount in the third envelope. All amounts are decided by Alice. The below picture shows the creation and the result of the created smart contract.

  2. Alice sends a HongBao to Bob, Carol, Ted, in the form of a magic link (signed message usable by a smart contract), the instruction on how to use the message is provided by the TokenScript of that smart contract. The links are different each as each needs to contain the public key of a recipient.

4b

  1. Each one of Bob, Carol, Ted sends a transaction to the smart contract with their choice of the envelope. The first to do so can choose from 3 envelopes; the second can only choose from 2 envelopes and last has only 1 envelope to choose from.

  2. Alice sends a transaction to the smart contract with the actual amounts in the envelops, as well as attaching some ethers. The smart contract is, therefore, able to tally how much of these ethers to emit to Bob, Carol, Ted individually.

3b

There is the problem that Bob, Carol and Ted will not be able to "open" the envelope as soon as they have made their choice. Instead, after having made their choices, they have to wait for Alice in step 4. But amending that would require a server which makes the game not much different than centralised ones.

A new game

If not being able to open the envelope represents a game design issue, we can design an alternative game which Alice does not pre-define the amount in each envelope. The new game would be too long to elaborate here, but the gist of it is:

  • Each of Bob, Carol, Ted, instead of choosing an envelope, choose from empty envelops and provide to the smart contract the number of shares they want in it(!). He may get exactly that amount of shares in the end, except 𝑎) the money in it is not redeemable till the end; and 𝑏) the amount has a chance of flipping - changing to an unpredictable number - every time when someone else after him made his choice.

  • If the game ends when the last person made his decision, he would have too much control over his share since there is no other person after him. Therefore Alice still needs to show up with the money in the final step before everyone gets his money.

There is a new problem that Alice has great control over the distribution if 𝑎) she can hack the TokenScript installed on her wallet and 𝑏) she meticulous chooses her input to make someone's number of share flip and some others' not. So there goes the fairness, but it's her money at the outset and everybody are having good fun, so she probably isn't motivated to do so.


Technically, both game requires a high level of <object> support in TokenScript but we can choose to go for this level of support if we can rationalise the need.