> For the complete documentation index, see [llms.txt](https://documentation.block-ops.fun/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.block-ops.fun/game-economy/tokenomics.md).

# Tokenomics

BlockOps uses a token-holder reward model. Free players can play the game, but SOL rewards are reserved for eligible token holders.

<figure><img src="/files/gM5fhpumvK6rXmLbWVOk" alt=""><figcaption></figcaption></figure>

## Token Utility

| Utility                 | Description                                                           |
| ----------------------- | --------------------------------------------------------------------- |
| **Reward eligibility**  | Token holders can earn claimable SOL from eligible real-player frags  |
| **Player identity**     | Wallets connect player stats, characters, and reward history          |
| **Game access layer**   | Token ownership can unlock reward participation                       |
| **Community alignment** | Players, holders, and the game economy are connected through activity |

## Free Players Vs Token Holders

| Player Type  | Can Play? | Can Earn Credits?                 | Can Claim SOL?              |
| ------------ | --------- | --------------------------------- | --------------------------- |
| Free player  | Yes       | No, or practice-only stats        | No                          |
| Token holder | Yes       | Yes, from valid real-player frags | Yes, after the claim window |

Free players are important for matchmaking and growth, but they do not receive SOL rewards.

## Reward Requirement

The planned reward rule is:

> **Free players receive no SOL rewards. Token holders earn SOL per eligible kill from the trading-fee reward pool after the 24-hour claim window.**

Eligibility should be checked server-side before credits become claimable.

## Pump.fun Tokenomics

BlockOps expects to use a simple pump.fun-style token launch structure.

| Category        | Notes                                                                 |
| --------------- | --------------------------------------------------------------------- |
| Token launch    | Pump.fun-style fair launch mechanics                                  |
| Trading fees    | A portion of available trading-fee revenue funds the game reward pool |
| Reward pool     | Distributed to eligible token holders based on valid frags            |
| Liquidity       | To be finalized                                                       |
| Mint / contract | To be added after launch                                              |

## Developer Token Supply

This section is intentionally left as a formal placeholder until final launch details are confirmed.

| Item                          | Status  |
| ----------------------------- | ------- |
| Developer token supply bought | **TBD** |
| Developer token supply locked | **TBD** |
| Lock platform / proof         | **TBD** |
| Lock duration                 | **TBD** |
| Public wallet address         | **TBD** |

When finalized, this section should include:

* The developer wallet address.
* The amount of supply bought.
* The amount of supply locked.
* The lock duration.
* A public proof link.

## Reward Credits

Credits are the in-game accounting unit used to track eligible activity.

| Event                                             | Credit Impact                   |
| ------------------------------------------------- | ------------------------------- |
| Kill against real player by eligible token holder | Adds reward credits             |
| Kill against bot                                  | No reward credits               |
| Invalid kill or suspicious event                  | No reward credits               |
| Free-player kill                                  | No SOL-claimable reward credits |

Credits are not the same as SOL. Credits represent a claim against the future daily reward calculation.

## 24-Hour Claim Window

Rewards unlock after a session has ended and the 24-hour review window has passed.

This delay exists so the system can:

* Count eligible kills across the full daily period.
* Check the available SOL in the reward treasury.
* Detect suspicious activity.
* Exclude bot kills and invalid events.
* Calculate proportional payouts fairly.

## Proportional Daily Pool

SOL rewards are distributed proportionally.

Example formula:

```
player_reward = daily_pool * (player_eligible_kills / total_eligible_kills)
```

Example:

| Metric                | Value   |
| --------------------- | ------- |
| Daily reward pool     | 10 SOL  |
| Total eligible kills  | 1,000   |
| Player eligible kills | 50      |
| Player share          | 5%      |
| Player reward         | 0.5 SOL |

The actual claim amount depends on the daily pool and the total number of eligible kills.

## Treasury And Claims

The reward treasury should be treated as a controlled payout wallet.

Key requirements:

* Treasury keys must not be exposed client-side.
* Claims must be server-authorized.
* Payout records should be stored.
* Duplicate claims must be prevented.
* Suspicious sessions should be reviewable before payout.

## Economy Metrics

The front end should display clear economy metrics.

Useful metrics include:

| Metric                 | Description                                     |
| ---------------------- | ----------------------------------------------- |
| Daily reward pool      | Current SOL available for the reward cycle      |
| Eligible kills today   | Total server-validated reward kills             |
| Estimated SOL per kill | Daily pool divided by eligible kills            |
| Claimable rewards      | Player rewards available after the claim window |
| Pending rewards        | Rewards still inside the 24-hour window         |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://documentation.block-ops.fun/game-economy/tokenomics.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.