Hello,
Announcing sigmanero.org, a new sports betting exchange website that uses Monero’s multi-sig wallets for each individual bet.
The use of multi-sig wallets should stop concerns about rug-pulls, exit-scams, or wallets becoming compromised by attackers.
In a betting exchange like Sigmanero, users bet against other users and the house earns a commission in each bet.
**The small innovation of sigmanero.org is that multi-sig wallets are auto-generated in the browser of each user, which hopefully significantly reduces the hassle of using multi-sigs. No need for command line interface (CLIs). **
The setup is as follows. User A places an offer for a bet in a particular event for example LA Lakers to win vs Boston Celtics. This offer will have the, side (Lakers or Celtics to win), the amount in XMR and odds that user A would like to bet.
User B can see user A’s offer and accept the offer. At this point, a new 3/4 multi-sig wallet will be created between A, B and Sigmanero.
This new multi-sig will have to funded before the start of the event by both A and B. Both A and B will also need to save their new multi-sig seed keys separately.
When the winner is known, the winning side can reclaim funds using his/her seed key to sign the transfer out of the multi-sig wallet. Important to stress that if they don’t save their seed keys, then they cannot reclaim funds, and there will be nothing Sigmanero can do about it.
At no point in time will Sigmanero have controls of funds or will any of the seed keys be shared with Sigmanero. Sigmanero will have 2 of the 3 necessary keys to sign transfers for extra security and to guarantee that it will always be a party to the transfers. Despite this, Sigmanero will always require one extra signature from one of the users.
For each bet both users will have to have at least 10% of the bet amount as a bounty deposit with Sigmanero. For example if the bet amount is 1 XMR, the user will have to have at least 0.1 XMR deposited with Sigmanero. This will be the only element of custody of funds that Sigmanero will have. However, as soon as the user funds the new bet, the 10% bounty is released which the user can withdraw back from Sigmanero.
The 10% bounty from each user will be used as an incentive for users to fund and commit to their bets with other users. If a user agrees to a new bet but does not fund the new multi-sig wallet with his/her bet amount, then that user will lose the 10% bounty, and 50% of this bounty will be given to the opposite side of the bet, provided that the opposite side has funded its side of the bet.
More details under https://sigmanero.org/info
Because the creation of multi-sig wallets needs synchronisation between users and Sigmanero, when a new bet offer is place by a user, this user cannot leave the page until the bet is accepted by another user or the user decides to cancel the new offer. This is not ideal, however the advantage for the user that makes an offer is that it can set an XMR amount and betting odd according to his/her like, as opposed to simply accepting the terms of existing offers.
To facilitate the coordination between users offering bets and users accepting bets, betting for each event starts only 6 hours before the event and closes 15min before the event start. This element of the user experience might not be ideal, but we hope that the 6 hour window is wide enough to provide flexibility for all, but also small enough to get users all in one place at the same time. The betting window closes 15min before scheduled event times to allow users to fund their multi-sigs.
Hopefully this is a good overview. Please let us know what you think. Feedback at this point is extremely appreciated.
Putting on my HFT hat, if I don't have to fund bets, and I have no reputation at stake there is a incentive (in a busy market) to propose MANY bets at different price points, and delay to the last possible second before funding the bets with the best expected value.
Perhaps that means to propose a bet you should have to fund it fully?
I suspect for the degenerate gambler of taste, they will want to deposit with you (or with a smart contract on some other blockchain that has atomic swaps to monero), and set out a wager book of acceptable wager parameter tuples (min size, max size, odds)... when a gambling counterparty accepts the wager the initial party could auto-fund the wager from a deposit with the site, or via some monstrously linked smart contract. Thus the degenerates could have a library of acceptable bets that far outsizes their funds in deposit, providing market liquidity. When the funds in deposit/contract have been exhausted, it should invalidate the outstanding wager options, and at the very least not display them as active.
I imagine in this display of the wager book tuples you would only display the top X% by odds, or bet size, but the order book could be very deep
Yes that is a possible problem and you are exemplifying very good problems to deal with :)
The way we are going to disincentivize this type of behaviour is by limiting user bets in each event. That is, only after we verify that the user has funded the bet, will we allow a new bet in the same market. If the user does not fund a bet, then we will put a temporary suspension in place for new bets across all markets.
We are also moving from allowing users to delay funding the bets until the very start of the events. Instead, we will request users to fund bets within 1 hour of the bet creation with a hard stop at the event start. For example if the bet is created 3 hours before the event, both users need to fund the multisig within 1 hour. But if the bet is created 20min before the event start, then they will have 20min to fund wallets.
We are still experimenting. It can be very well that we reintroduce bounties for each bet and in cases where A does not fund its side of the bet, then we give 50% of the bounty to side B to compensate for his/her trouble. We understand that many users will want to place multiple legit bets in a single market and therefore bounties are a good compromise. However, at this point we recognise that asking for bounties places too many steps to adoption.
We are also expecting order books to be very small at the beginning so, not that many opportunities that justify investment in HFT strategies. Also, at this point we only expect to have users using the web browser to create bets. This is important because Sigmanero will rely on each user's browser to do the work of creating the multisig wallets automatically. It is therefore somewhat different from a trader placing orders in a centralised broker that can be matched instantly. In our case, a new bet and multisig wallet generation should take ~30 seconds to be completed. The side that makes the bet "offer" will have to keep the browser open until someone "accepts" the offer. It might be that we find ways that reduce the need of such high level of synchronous actions by A and B. But multisig wallet creations do need a level of back and forward.