Welcome back to Day 5 of my blockchain series—this is the “security reality check” episode. Up to this point, we built a Rock Paper Scissors dApp where Alice and Bob wager on the outcome… but there’s a huge vulnerability: Bob can cheat and win every single time. I show exactly how that happens when Alice publishes her wager and her hand, because then Bob can read Alice’s hand and compute his own hand on the backend (instead of pulling it from the frontend) so it always beats hers. Then I use Reach’s automatic verification engine to mathematically prove the attack works. I add a require statement that models dishonest Bob (his hand equals Alice’s hand + 1 mod 3), and an assert that the outcome is always 0 (Bob wins). You’ll see the compiler check more theorems, because Reach is proving properties at compile time—not just running tests. Finally, I show why these verifications matter by intentionally breaking the payout logic and letting Reach catch a “balance must end at zero” theorem failure (aka “don’t trap funds in the contract”). I also demo a knowledge assertion (unknowable) to prove Bob shouldn’t know Alice’s hand—and the compile fails because, in our current design, he does. The big takeaway: treat assertions like unit tests—keep them around so security bugs don’t sneak back in.