What Happens if We Get Hacked? A Transparent Look at the Musical Chairs Security Model

In the world of Web3, trust isn't given; it's built. And a huge part of that trust comes from a project's security model. When you're building a game that handles user funds, you can't just hope for the best. You have to plan for the worst.

That's why, from day one, Musical Chairs was designed with a core principle in mind: separation of concerns. Instead of a single, all-powerful "god key," our system uses three distinct private keys, each with a strictly limited set of permissions. This architecture is designed to minimize the "blast radius" if any single key were ever compromised.

Let's be transparent and walk through what an attacker could—and, more importantly, could not—do in each hypothetical scenario.

Scenario 1: The Backend Key is Compromised

This is our "hottest" key. The backend server uses it to perform its one and only on-chain function: declaring the loser of a game round. It's the most exposed key, but also the one with the least power.

What could an attacker do?
An attacker with this key could disrupt gameplay. They could send invalid "loser declaration" transactions to the smart contract, causing active game rounds to get stuck or fail to resolve correctly. It would be a denial-of-service attack on the game's logic.

What could they NOT do?

• They cannot steal player funds locked in the contract.
• They cannot change the game's rules, like the stakeAmount or commissionAmount.
• They cannot withdraw the accumulated platform commissions.
• They cannot upgrade the contract.

Mitigation:
Because this key's only role is to be the designated "loser-picker," the contract's Owner can simply revoke its address and assign a new, secure backend key. Gameplay would be restored quickly. The damage is limited to temporary disruption, not loss of funds.

Scenario 2: The Owner Key is Compromised

This is our administrative key. It's the most powerful of the three, which is why it is kept in secure, air-gapped cold storage and is used very infrequently. Its purpose is to manage the contract's parameters.

What could an attacker do?
An attacker with the Owner key could propose changes to the contract's rules. They could attempt to:

• Change the stakeAmount or commissionAmount.
• Change the designated backendAddress to one they control.
• Propose an upgrade to a new, malicious implementation contract.
• Propose changing the owner's address and the address for withdrawing the commission.

What could they NOT do?

• They cannot directly access or steal player funds already deposited in active games. The functions for depositing, claiming winnings, or requesting refunds are permissionless and controlled by the players themselves.
• They cannot steal the platform's accumulated commission fees, as those are sent to a completely separate wallet.

Mitigation: The Timelock & Future Plans
This is our most critical line of defense. Every single administrative function controlled by the Owner is protected by a 7-day timelock.

If an attacker were to compromise this key and propose a malicious change (e.g., setting the commission to 100%), that change would be publicly visible on-chain for a full week before it could be executed. This gives the community and the team ample time to:

1. Detect and publicize the malicious proposal.
2. Encourage all players to safely withdraw their funds from the contract.
3. Take measures to deploy a new, secure version of the contract and migrate the community.

The timelock turns a potential catastrophe into a manageable (though serious) incident, ensuring player funds remain safe.

Furthermore, we plan to upgrade the Owner role to a 2-of-3 multi-signature wallet in the future. This will eliminate a single point of failure. Even if one of the three keys is compromised, an attacker would not be able to approve malicious proposals, and the remaining two key holders could securely replace the compromised key.

Scenario 3: The Commission Wallet Key is Compromised

This key belongs to a standard wallet (EOA) designated to receive the platform's commission fees. It has no special privileges in the smart contract.

What could an attacker do?
They could steal all the funds currently inside that specific wallet.

What could they NOT do?

• They cannot affect gameplay.
• They cannot steal player funds.
• They cannot change any contract parameters.
• They cannot redirect future commissions to a different wallet (that requires the Owner key and is subject to the timelock).

Mitigation:
The smart contract is designed to automatically transfer accumulated fees to the commission wallet as soon as they reach a minimal threshold (currently ~0.01 ETH). This prevents large sums from ever accumulating in the contract itself. From this commission wallet, funds are regularly withdrawn to cover operational expenses such as company registration, salaries, and marketing costs. This regular withdrawal process minimizes the amount of capital at risk at any given time. If this key were compromised, the Owner would simply initiate a timelocked transaction to designate a new, secure commissionRecipient address. The impact is limited only to the funds held in that wallet at that moment.

Conclusion: Building for Resilience

No system is 100% "unhackable," but a well-designed system is resilient. By separating the keys for gameplay, administration, and finance, we ensure that the failure of one component does not lead to the failure of the entire system.

This multi-key architecture, combined with on-chain timelocks and a clear roadmap for further decentralization, is our commitment to you. We believe that building in the open and being transparent about our security model is the only way to build lasting trust in the Web3 space.