# Contracts with many to many payouts — is this unrealistic?

I'm thinking of writing a contract in which the payoff is proportionately split amongst N recipients. Is this intractable in ethereum since as the number of recipients grows, this would require N transactions instead of 1, and the gas price would be linear in N?

As a contrived example, let's say I have a virtual boxing match. There are two boxers, A and B, and you can choose to join the pool for each one as a backer with a certain amount of tokens. After the fight, currency is taken from all the supporters of the loser, and then distributed to all the supporters of the winner in proportion to their stakes.

If there were N participants in the loser pool, and M participants in the winner pool, then this would be (N+M) transactions beforehand, and then M transactions after the fight.

## 1 Answer

After the fight, a fixed amount is taken from all the supporters of the loser

It's better not. Nobody will bet for the loser after the game. The contract should collect the bets before, and distribute payouts to the winners after.

If there were N participants in the loser pool, and M participants in the winner pool, would this be N+M transactions on the chain

Given that you agree on the first comment, you need N+M transactions before the game. After the game is finished, you have two options:

1. One transaction to "activate" the payouts, which require at least `N * 21,000` gas. This would place the burden of all the payouts to a single user, so I would not recommend this.
2. Every user sends a second transaction to collect their payout. This is, of course, if they are in the winning pool. In this case, you need N more transactions after the game.
• Ah, yes, I get what you're saying. Makes sense for everyone to deposit currency with the contract first, then get paid out after. Edited the original post. – Eric Sporel May 28 '17 at 22:28
• How do you compute the gas cost of 21000? – Eric Sporel May 28 '17 at 22:28
• When you say 'every user sends a second transaction to collect their payout', is it not possible for the contract to 'push' this out automatically? – Eric Sporel May 28 '17 at 22:29
• 21000 is the cost of `send()`. Smart contracts usually need to be invoked to operate. – jeff May 28 '17 at 22:37
• Can you think of a better way of doing this though? Is it possible to 'cache' these transactions in some way? So each individual user can bet on lots of fights through one contract with a subset on his funds on each one, and just get back one settling transaction at a much later point? I want to minimize transactions cost as much as possible. – Eric Sporel May 28 '17 at 22:40