FPL (Fantasy Premier League) on Solana

This project implements a Fantasy Premier League (FPL) application on the Solana blockchain. It allows users to create and enter contests, select a team of players, and win rewards based on their team's performance.

Architecture

The project follows a standard Anchor-based architecture with an on-chain program and a TypeScript client for testing.

On-Chain Program

The on-chain program is written in Rust using the Anchor framework. It defines the core logic of the FPL application and is responsible for managing the state of the game, contests, and entries.

The program is organized into three main components:

• Instructions: These are the entry points to the program that can be called by clients. They define the different actions that can be performed, such as creating a contest, entering a contest, and casting a vote.
• State: These are the data structures that store the state of the application on the blockchain. The program defines four main accounts: GameAccount, Player, ContestAccount, and EntryAccount.
• Error: This defines the custom errors that can be returned by the program.

How it Works

The FPL application works in a series of steps:

1. Game Creation: A game is created with a specific start time and a list of players.
2. Contest Creation: A contest is created for a specific game. The contest has an entry fee, a protocol fee, and a winners percentage.
3. Entering a Contest: Users can enter a contest by paying the entry fee and selecting a team of players.
4. Game Completion: Once the game is completed, the final scores of the players are updated.
5. Settling the Contest: The entries are settled off-chain and the winners are written to the EntryAccount.
6. Voting: A voting period is started to allow users to approve or dispute the results of the contest.
7. Claiming Winnings: If the approve votes are greater than the dispute votes, the claiming is unlocked and users can claim their winnings.

Instructions

The on-chain program exposes the following instructions:

• init_game: Initializes a new game.

• add_player: Adds players to a game.

• update_start_time: Updates the start time of a game.

• set_game_cancelled: Sets a game as cancelled.

• refund_entry: Refunds the entry fee for a user if the game is cancelled.

• create_contest: Creates a new contest.

• enter_contest: Enters a user into a contest.

• edit_entry: Edits a user's entry in a contest.

• exit_contest: Exits a user from a contest.

• set_game_completed: Sets a game as completed and updates the player scores.

• write_winnings: Writes the winnings for an entry.

• claim_protocol_fee: Claims the protocol fee for a contest.

• settle_contest: Settles a contest and unlocks the claiming of winnings.

• claim_close_entry: Claims the winnings for an entry and closes the entry account.

• close_contest: Closes a contest account.

• close_game: Closes a game account.

• The instructions that are going to be heavily used are enter_contest, write_winnings and claim_close_entry

  • enter_contest will be the one with time restriction. CU: 66,501
  • Per Block Transaction Write Limit is 24M CU, so we can have around 360 entries per block if only enter_contest is being called. However, in practice, there will be other instructions being called as well, so the actual number of entries per block will be lower.
  • If this ever becomes bottleneck, re write the whole contract in pinochio this will decrease the CU by 10x, let's say we occupy 50% of the block space that leaves with 1800 entries per block.
  • we can futher optimize this by having multiple token vault, this is complex for now, there are two accounts that are being written to in enter_contest, the ContestAccount and the Contest Token ATA, we can have multiple token ata, but contest ? need to re think the whole architecture

State

The program uses the following accounts to store its state:

• GameAccount: Stores information about a game, such as its start time, players, and status.
• Player: Stores information about a player, such as their name, credits, and final score.
• ContestAccount: Stores information about a contest, such as the entry fee, number of entries, fee and mint address.
• EntryAccount: Stores information about a user's entry in a contest, such as the players they have selected and their final score.

The Problem We Are Solving

Fantasy sports is a massive market in India and globally, but it suffers from three fundamental issues:

• Regulatory Risk & Centralization Platforms can be restricted or banned by governments at any time, instantly cutting off access for users.

• Lack of Transparency & Trust Users must trust centralized operators for:

  • Fair contest creation

  • No late entries after match start

  • Accurate reward distribution

  There is no verifiable guarantee—only trust.

• Custody & Fund Control : User funds are held by platforms, exposing them to risks like withdrawal limits, delays, or misuse.

• one liner: on-chain fantasy sports platform (basically dream 11 on solana network)