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.
Hello!
"would Sigmanero ecosystem be easily adaptable to politcal events (eg/ elections) as well as sporting bets?" -- Yes we expect to add further options in the future such as election outcomes or other relevant events. Perhaps also making public the odds at which users are agreeing bets and therefore act as reference for prediction markets.
The trusted Oracle problem is always present. However Sigmanero should be 100% neutral regarding the outcomes since it will only have earn a commission after the result is known. Therefore there is no monetary incentive to decree false outcomes. If A or B wins should not matter for Sigmanero, so why ruin the reputation and future fee income just to benefit one party?
The problem that remains is indeed if Sigmanero decides to become a party in bets, including controlling 3/4 of the signing keys instead of just two. In this case if Sigmanero decides to scam users, it would not even need to change the outcome of bets in its favour, but rather just transfer funds out of multisigs. Or perhaps as you hint, a gray scenario would be if Sigmanero doe not simply run away with funds from its multisigs, but rather maintains a facade of trustworthy intermediary while decreeing an outcome in favour of the bets it placed.
One mitigation to the scenario above would be to announce from the start that for the relevant event (for example an election) it will decree the outcome as per a known non-related third party or public source. This way Sigmanero could not deviate from the declaring an outcome in line with the third-party without suspicion.
There might be a cleaver way to increase the level of assurance that users are placing bets with normal users instead of Sigmanero. Every time a new multisig is generated, both A and B will be able to see the main address of the new multisig wallet.This means that both A and B could in theory signal to each other that they are not Sigmanero. This could work in some third party forum where users could disclose this address to other users, and other users would know from reputation tracking or other sources that that user is not Sigmanero. A more simple example would be if two friends, Paul and John place a bet against each other in Sigmanero. They would be able to see that they what they share the same main multisig address, and therefore that Sigmanero cannot move funds without one of their keys. For very large bets users might want to get such a credible signal before funding their side of the bet into the multisig. However we only see this becoming a topic for larger events or bets as you mention, therefore we have not spent too much time trying to come up with solutions for these cases. We are open for suggestions though!
"Sidenote: Does Sigmanero take donations?" -- We are not taking donations at the moment. Sigmanero will charge a 1% commission on bets which we hope will be sufficient to keep the website running and provide the natural incentive for Sigmanero to actually work as intended.
Final note: We have received very good feedback so far including from other channels. The website is under maintenance to implement some of the suggestions and hopefully will be live again on Friday 12th April. One in particular, we have decided to drop the requirement for users to have to place a bounty with Sigmanero to initiate bets. This means that we will have to rely more on good behaviour from users. That is, if A agrees to make a bet with another user B, there is no monetary penalty for A not funding its side of the bet. If we see that a particular user is disruptive in this manner we will suspend the user from making new bets for a period of time. That is, if A sends the funds but B does not, we will refund back A and suspend B for a period of time. This means that there will be zero elements of custody of funds by Sigmanero and that the process whole will be much more simple for users.
Thanks!
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.