PaperDuel

What is PaperDuel?

PaperDuel is a competitive backtesting platform that lets users simulate trading battles using real historical market data. The goal is to make learning and practicing trading strategies more interactive and gamified.

Players can place trades, manage stop-loss and take-profit levels, and watch their performance unfold on a live candlestick chart, all powered by a backend trading engine built in Python.'

Devpost: https://devpost.com/software/paperduel
GitHub repo: https://github.com/ZocoMacc/PaperDuel.git

Building PaperDuel

Introduction

PaperDuel was created during a 24-hour hackathon (HowdyHack 2025) with the idea of transforming financial backtesting into something social and interactive. Traditional trading simulators are often solitary and analytical, they help you test strategies, but not compete. Our team wanted to bring the thrill of competition into data-driven trading.

The result was PaperDuel, a full-stack Python and JavaScript project that lets two players trade simultaneously on historical data, competing to maximize their profit while facing realistic trading conditions like slippage, commissions, and drawdown limits.

This post covers how we built the project from scratch, how each piece works, and what we learned while connecting all the parts together.

The Idea

The inspiration came from a simple observation: backtesting tools like TradingView’s “Replay Mode” are powerful, but not very interactive between users. We wanted to recreate that sense of live trading but make it competitive, where two users could “battle” each other using historical market data and identical conditions, just like a duel!

The design challenge was to simulate the key aspects of trading, price movement, order execution, PnL tracking, while making it feel like a game. The focus wasn’t on profits but on performance, discipline, and strategy.

The Architecture

We structured PaperDuel as a lightweight web application composed of three main layers:

1. Backend (Python + FastAPI): Handles the simulation logic and trade execution.

2. Frontend (HTML + JavaScript): Displays the candlestick chart, buttons, and game state.

3. Data Layer (pandas): Reads and processes historical futures data from CSV files.

We deliberately kept the architecture simple and modular so that each team member could work independently, one on backend logic, and the other on frontend and integration.

Backend: The Simulation Engine

The backend is built using FastAPI, which made it easy to define REST endpoints for all trading actions. It also provided automatic documentation through /docs, which was extremely useful for debugging.

The backend logic is defined in two main modules:

• data_loader.py
• battle_service.py

Data Loader

This module reads historical OHLCV (Open, High, Low, Close, Volume) data for different futures assets such as ES and NQ. It also stores configuration constants like tick size, multiplier, and commission per trade.

Using pandas, we load each CSV into memory and expose helper functions to retrieve both the raw data and the financial rules for each instrument. Each candle in the dataset represents one minute of real historical data.

Battle Service

This is the heart of PaperDuel. It handles:

• Battle creation
• User authentication
• Trade execution (BUY, SELL, CLOSE)
• Bar advancement
• PnL and equity calculations

Every trade applies slippage and commission to simulate real market conditions. Each user’s session state is tracked, including position size, direction, entry price, stop-loss, and take-profit levels. The simulation advances one bar at a time, updating positions and checking for automatic exits.

We used an in-memory Python dictionary (BATTLES) to store the active sessions, which made development fast without needing a full database.

Frontend: Interactive Visualization

For the frontend, we wanted a clean and minimal look, something that felt technical but intuitive. We built it using plain HTML, CSS, and JavaScript, relying on Lightweight Charts, the same library used by TradingView.

Chart Rendering

Lightweight Charts allowed us to render real-time candlestick data that matched the backend’s output. As the backend advanced through bars, the frontend updated the chart dynamically.

Each candle corresponds to a “bar” in the historical dataset. The player can step forward manually, or press Play to auto-advance through the data at a constant speed.

Game Controls

We implemented trading controls directly in the UI:

• BUY / SELL / CLOSE buttons to execute orders.
• SL (stop loss) and TP (take profit) inputs for advanced trades.
• Next / Play / Pause controls to move through time.

Every action triggers an API call to the backend, and the resulting game state (including updated equity and PnL) is rendered immediately.

Competitive Mode

In the final version, both players share the same session (battle_id). Each has their own stats panel showing current equity, position, and unrealized PnL. While we planned to support two separate devices, the prototype runs both users on one screen for simplicity, but the backend is already structured for multi-user support.

Integration and Hosting

The backend runs with Uvicorn, a high-performance ASGI server.
For hosting, we used ngrok, which provides a public HTTPS URL that tunnels directly to the local FastAPI server. This made it easy to share our live demo with judges during the hackathon.

We also tested Cloudflare Tunnel as a backup solution in case network restrictions blocked ngrok, ensuring the app could always be reached externally.

Challenges We Faced

1. Synchronizing state:
   Keeping the frontend chart aligned with backend bar updates required precise API handling.

2. Trade realism:
   Implementing slippage, commission, and automatic exits (stop-loss/take-profit) without desynchronization was tricky.

3. UI layout:
   Balancing a chart-heavy design with text-based logs took careful CSS tweaking.

4. Hosting:
   We encountered HTTPS certificate issues when deploying through ngrok, which forced us to troubleshoot network-level blocking during the final hours.

What We Learned

PaperDuel taught us how to build a full-stack simulation system that merges real-time visualization with backend state management. We learned to structure a project cleanly under time pressure, communicate through APIs, and design with user experience in mind.

More technically, we deepened our understanding of:

• RESTful communication between frontend and backend
• FastAPI’s data modeling and routing
• pandas for time-series processing
• Lightweight Charts for live data visualization

What’s Next for PaperDuel

If there is opportunity in the future, of improving PaperDuel, here is what we would do:

• Adding true multi-device duels where players can connect remotely using a battle link.
• Supporting more time frames and data formats for user comfort.
• Improving analytics, leaderboards, and performance tracking.
• Possibly deploying a public version for educational and competitive trading.

Conclusion

PaperDuel started as a small hackathon project, but it turned into a fully functional trading simulator with a unique competitive edge. It merges finance, coding, and design into an engaging platform that lets users experience the tension of trading, not against the market, but against each other, which is fun!

Authors of PaperDuel: Esteban Di Loreto, Maximus Marin