Both of my contracts are implemented with maximal versatility in mind. There's many options to tweak, and contracts' code can be extended to support even more features (both contracts support code upgrade).

Below are the short descriptions about each of the contracts. You can find more details in their READMEs on Github.

The first one is a platform to conduct auctions or just simple trades. The owner can create any number of open or blind auctions (or just items to sell), and everyone can participate in them.

There's three types of auctions supported: one open (English auction) and two blind (first-price and second-price sealed-bid).

Auctions can have an initial price, a minimum bid difference, a buyout price, a bidding fee and a time limit. For simple trading, there's a stock size option.

The second contract is intended to be a gaming platform (like a virtual casino). For now, there's two game types: a lottery and a Blackjack, but many more can potentially reuse the base code. Similarly to the auction system, the owner can create any number of games with different parameters and start/end times.

For lottery, you can fine-tune the exact number and probabilities of the prizes, as well as the amount of tickets to be sold. Blackjack supports configuring "hit on soft 17" rule.

In the future, this contract can be extended to support off-chain player-dealer interactions and inter-player interactions (with later on-chain validation).

There were some bug reports (below in the issues section), which were fixed after the contest end. To prevent any confusion, all those fixes are committed to separate branches named "post-contest-fixes":
https://github.com/deNULL/ton-auction/tree/post-contest-fixes
https://github.com/deNULL/ton-gamble/tree/post-contest-fixes

Be sure to check them out before writing new issues.

How come the auction is blind if all transactions and contract state are perfectly visible on the blockchain?

So there is reserved_balance variable where you track grams that cannot be withdrawn because you need to return them back to participants.

During check_blind_bids where you check the state of blind auction, and send money back to those who lost you do not decrease reserved_balance for winner (only by difference with second place). In case of english auction you did that in external message handler.

So reserved_balance will be higher than it should be preventing owner from withdrawing the money.

Am I right?

PS: I think it was a mistake mixing several types of auctions into a single contract.

There is an option to buyout auction item. In that case other participants of blind auction do not get their money back, because dictionary with their bids is reset (or auction removed if nothing in stock).

Nothing prevents me from sending bid disclosure message several times (incrementing seqno) to drain contract out of funds.

When returning money to previous bidder of english auction (during next bid or cancelation) you load uint for worchain id instead of int. Masterchain will be deserialized as workchain 255 and will crash later in send_money when attempted to be stored back into int.

But during completion it's correctly loaded as int, and so bid from masterchain automatically wins the auction blocking everyone else from overbidding it.

About lottery game.

Dictionary of participants is indexed by public key. The authenticity of that public key is taken for granted. Public key isn't required to make a move (lottery_raffle can be performed by anyone) or to withdraw (that is done automatically).

It is allowed to increase stake later with additional message. When participant's entry_amount is stored back it uses address of current internal message, which might not be the same that was stored previously.

So to steal money, all I need is to send second internal message with same public key as someone else.

About that overwriting address. I meant that I can steal lottery tickets, and although I couldn't raffle lottery then. I can use another address + key (also controlled by me) to raffle it.

> Also, can you elaborate, why do you think supporting multiple types of auctions is a bad idea? I can imagine a platform wanting to conduct both open and blind auctions at the same time, which would be impossible with a single-type auction contract.

Platform can direct users to different contract addresses depending on auction type. I would go as far as single contract per auction item.

> That's true. Added a check verifying that a bid is not yet decrypted before accepting the message.

That isn't enough. I can send actual_amount that is higher than received_amount. Bid will not be decrypted, and I can replay that message again.

Great submission. I believe in both, gambling and auctions!