Key Challenges

1. Matchmaking and the PvP Challenge

Since the game is PvP, the main challenge is matchmaking. If a player creates a game and no one joins — that's a blocker, especially during the early stages of the project when user activity is low.

To solve this, we're working on a matchmaking bot that plays by trading using AI. It acts as a kind of agent filling the role of an opponent.

Repo:
https://github.com/MortalCoin/mortalcoin_alith_bot

The bot constantly monitors the matchmaking lobby, joins open games, listens to the ongoing game state (real-time prices, opponent actions, etc.), and tries to make good decisions based on its assigned role.

2. Price Feeds and Market Simulation

Another major challenge is the price feed. To make the game fun, prices must move often enough and reflect meaningful market behavior — while remaining accurate.

Technically, it’s possible to integrate real asset trading instead of paper trading, but:

• It complicates the game and pushes it toward being more of a gamified trading wrapper (not necessarily bad — could be explored separately)
• It requires a liquid perpetual market to support both long and short positions
• Prices must be reliable and update on very short timeframes (e.g., per second or even tick-level)

We haven’t found a suitable decentralized solution suitable for POC (like an oracle refreshing fast enough), so for testnet we built our own market-making bot that simulates price movement on AMM DEX pairs - effectively acting as an in-house oracle.

Repo:
https://github.com/MortalCoin/mortalcoin-dex-bot

3. Gameplay Depth via Hidden Information

I wanted to make the game interesting, adding elements of partially hidden information, similar to poker. If all variables are visible — current price, realized PnL, positions (yours and your opponent's) — it turns into a deterministic equation-solving task rather than a game.

So, in MortalCoin, you only know whether the opponent has opened a position — but not the direction (long or short). This creates tension and strategy.

To support this, we implemented a system where positions are hashed with a backend key before being sent on-chain. The flow is:

• Player sends an EIP-712 object with position details to the backend
• Backend hashes the position and signs it
• Player submits the hashed version to the smart contract
• Direction is only revealed when the player closes the position

This prevents sniping and adds a layer of strategy.

4. Incomplete Games and Forced Finalization

One more big challenge: non-finished games, whether abandoned on purpose or due to connection loss.

The contract calculates PnL based on the price at the time of position closing, which opens a potential exploit where a malicious player might avoid closing their position to lock in a win or deny the opponent’s reward.

To prevent this, we added a

forceFinish

function to the contract. Our backend watcher monitors all ongoing games and triggers

forceFinish

for any game that wasn’t completed in time.

It was also tricky to implement a reliable system for storing nonces and direction data on the backend side, so we could finalize games even when one player is unresponsive.

---

Game Flow: Sequence Diagram