The problem PlayerHouse solves

The Problem:
ALL online casino apps—especially those branding themselves as "crypto casinos"—offer no meaningful security guarantees. Despite using tokens or wallets, they rely entirely on centralized infrastructure: users deposit funds into custodial wallets, play games hosted on private servers, and wait for manual withdrawal approvals that may never come. Odds are unverifiable, randomness is opaque, and user funds are vulnerable to freezing, loss, or manipulation. In short, these platforms are “crypto” in name only.

In traditional casinos, regulators like Gaming Control Boards audit machines, verify odds, and ultimately control the entire gaming industry. The casino business is owned by the state. My mission is to take that power back—by making games fully onchain.

The PlayerHouse Solution:
PlayerHouse is the first online gaming platform to fully embrace the core principles of Web3: trustlessness, transparency, and self custody.

There are no deposits. Users play directly from their own wallets—funds remain under their control until the exact moment of play.

There are no withdrawals. When you win, the backend contract sends USDC to your wallet instantly in a verifiable on-chain transaction.

There are no trust assumptions. The game logic is public, immutable, and open-source.

There is no rigging. Randomness is powered by Chainlink VRF—cryptographically verifiable and tamper-proof.

Unlike every other online slot game, PlayerHouse doesn’t ask for trust—because it doesn’t need it. Users aren’t relying on promises, policies, logos, or regulators.

Challenges I ran into

The biggest hurdle was getting the user experience high enough to be competitive with Web2 products—while still using a Web3 architecture. The first thing I knew was this: users are not going to sign a transaction every time they spin. That really dictated most of the design decisions I made.

I did explore 7702, but support across wallets and infrastructure just didn’t seem to be there yet. So I stuck with 4337 and focused on session key delegation. Also—regular people are never going to use MetaMask. It’s just not going to happen. It takes too much time to educate the user on how to use it.

Using gas is another form of friction that I just don’t think new crypto users are willing to deal with yet. It’s hard enough to get users set up with a wallet. If I also have to convince them they need to buy this thing called ETH—and send it to their wallet (and teach them how to send it)... I’m basically dead in the water right there. So I knew that using a USDC paymaster was essential—but it can also break the user experience in this type of application. Siphoning off money every spin is another way to leave uneducated (and educated) users with a bad taste in their mouth. So I found using sponsored gas to be an important part of the experience. The app will fall back to USDC gas if the sponsored paymaster is down—in order to keep the flow consistent.

Another major hurdle was getting the timing right. It breaks the user experience if they click spin—and have to wait 10 or more seconds to actually get the result. So I had to do a lot of experimenting to get the quickest response possible in the frontend. Solidity events are practically useless. And Base is a slow Layer 2 in this regard. I found that mining the transaction logs using Arbitrum was the fastest way to get the result into the frontend.