- cross-posted to:
- monero
- cross-posted to:
- monero
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.
You must log in or # to comment.
Interesting concept!
The use of bounty and deposit interchangeably is a little confusing on the website.
A infographic explaining the process would be helpful.
When funding a wager can the deposit be used as part of the funds? (Instead of refunding the deposit, I just fund 90% into the wager wallet and the house moves my 10% into the wager wallet?)
Rug-pull scenario: is there a way to verify the counterparty wallet signatures? If someone was going to rug-pull they would simply just use their own keys for one side of the bet. Then they would control 3/4 of the multisig wallet keys
I don’t see where the active bets are listed on the website
Great points, thank you!
We will work on a infographic right the way. Agree that deposit/bounty distinction is not clear. -"When funding a wager can the deposit be used as part of the funds? " – this is an interesting suggestion, we will consider adding it at least as an option. One possible downside is that users would need to constantly “top up” their balances with Sigmanero to make additional bets and this can add extra time to the overall process. But if people prefer it, why not.
-“Rug-pull scenario: is there a way to verify the counterparty wallet signatures?” – the only conceivable “rug-pull” scenario is if us “Sigmanero” decide to place bets as counterparty to users and therefore control 3/4 keys from the start. The incentive to rug-pull is very small because it would tank reputation instantly and the gains from the rug-pull would be limited to one bet at a time that gets stolen. We don’t expect any “wales” to start placing very large bets on the website that would economically justify such an incentive.
Additionally, we expect each bet to be of modest size because whoever places a new bet also needs to consider that the counterparty needs to be able to match the opposite side. If there are two genuine counterparties in a bet plus Sigmanero, then a rug-pull is impossible.
Small note: If a user decides to be both parties of the bet (creating 2 accounts in Sigmanero), then he/she would still only have 2/3 necessary keys for the signature in the 3/4 multisig set up. If a user wants to verify that the new multisig wallet is indeed 3/4 set up, then he/she can always recover the wallet locally using Monero CLI and verify that it is indeed 3/4.
-“I don’t see where the active bets are listed on the website” – at this point only open bets are shown, that is, bets waiting for a counterparty. We will add “total bet volumes” shortly.
Thanks!
Hey, this is a great idea.
I’ve been brainstorming how to create a political betting site using Monero - would Sigmanero ecosystem be easily adaptable to politcal events (eg/ elections) as well as sporting bets?
For me the main point of influence is the ‘oracle’ - who decides that the event is over and what the result is. If the lakers win 20-5 then it’s easy but if there’s extra time or the game is abandoned then the oracle becomes arbiter. Likewise in an election if the result is unclear or disputed then it is hard to definitively say who won within a given time frame.
At no point in time will Sigmanero have controls of funds
If Sigmanero is the oracle in this scenario - the could falsely declare that the Celtics won and could thereby designate funds (along with the losing bet-signer who wouldn’t mind winning some xmr). Therefore there is still a corruptible element.
Whilst I agree that for small amounts there isn’t a temptation to cheat - that argument doesn’t scale. Many betting facilities in crypto gain traction due to their ease of use - and in XMR it could get big too as it’s private. Then we can envision a superbowl-tier event where there are big bets going down and the temptation and facility to rugpull is there. I’m not doubting you / Sigmanero’s character just the game theory. As I say I’m keen to see your project work.
Sidenote: Does Sigmanero take donations? Or is it voluntarily hosted? The funding question helps users understand the motives behind the project. I would donate but be suspicious of a ‘free’ betting website.
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.
Great stuff!
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.
Doesn’t holding two keys in 3/4 multisig instead of one in 2/3 increases complexity? Why wouldn’t you let users settle the outcome between themselves and make Sigmanero a necessary party in the every transaction?
**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). **
Would you consider sharing this work? I imagine that can help other developers less familiars with the lover-level parts of the stack to develop against Monero.
Best of luck!
Thank you!
– “Doesn’t holding two keys in 3/4 multisig instead of one in 2/3 increases complexity?” Yes, however since we launched we changed the scheme from 3/4 to 2/3 multisig. This means that users can indeed have full control of funds and settle the bet in any way they agree. In Sigmanero you can’t contact the opposite counterpart, however, we you can always create a “private bet” that can only be accepted with whomever you wish. If Sigmanero disappears and leaves funds in multisig wallets, it is also possible for users to coordinate to get the funds back since both users will know the main address of the multisig, so they could in theory ask around, “who also has this main address?” and agree between them where to transfer the funds. Hope this makes sense and its not too much detail.
– “Would you consider sharing this work?” yes, especially the front end code which relies on the outstanding monerots library. There isn’t much more to add to it besides getting coordination sequence steps right. On the back end the code is unsurprising to be honest. Again just a matter of handling the steps of the multisig generation.
