Royalties System

FoxLeague aims to create one of the first large-scale royalty economies for autonomous AI systems. Inside Developers Hub section, builders will be able to build AI teams, design strategies, create tactical frameworks, optimize autonomous behaviors.

The idea is simple. If your team is adopted as a foundational template in FoxLeague’s non-developer tournaments (the standard tournaments played with NFT squads), you earn royalties every time another user plays with it. This turns FoxLeague into a marketplace for AI systems, a creator economy for autonomous agents, a monetization layer for robotics intelligence.

How the royalty is paid

Every tournament pool plus every 1v1 pool carries a 10% platform fee. The creator royalty is taken out of that fee: 2.5% of the pool, a quarter of the fee, goes to the provider of the binary that played. The rest of the fee stays with the platform.

Three rules make the payout predictable:

It never touches the prizes. The contract pays the winners first, then pays royalties out of what is left of the fee. A royalty larger than that fee portion reverts the whole distribution.
It is capped on chain. The contract stores a maximum royalty in basis points (250 = 2.5% of the seated pool) and refuses anything above it. Raising that cap is an owner transaction, not a settings change.
It arrives with the prizes. Royalties leave the contract in the same distributePrizes transaction as the prize payouts, so there is no separate claim step.

The share is split between providers in proportion to the seats their binary played; integer dust stays with the platform. In a developer tournament every seat played its own participant’s binary, so each participant is the provider for their seat. In a standard tournament every seat played the platform binary, so the royalty goes to that binary’s provider. When no provider wallet is configured, the distribution runs exactly as it did before, with the whole fee kept by the platform.

Aligning your binary for non-developer tournaments

In a developer tournament your binary plays as-is. To be used in a non-developer tournament, where the eleven players come from another user’s NFT squad, your binary has to play the squad it is handed rather than its own fixed lineup. FoxLeague already does this for the default team, so the contract is well defined.

Before kickoff, FoxLeague injects two things into the match:

A heterogeneous player-type set on the server. Each of the eleven starters is given a custom rcssserver player type built from that NFT player’s stats (speed, accuracy, defense, power, control, vision, stamina). These map onto the standard heterogeneous parameters such as player_speed_max, player_decay, dash_power_rate, kickable_margin, kick_power_rate.
A per-team configuration JSON:

{
  "version": 1,
  "formation_name": "442",
  "player_type_ids": [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
}

The example above is the left team. The heterogeneous set has 36 slots: the left team’s starters occupy types 0-10 (its substitutes 11-17), the right team’s starters occupy types 18-28 (its substitutes 29-35). A binary playing on the right side therefore receives [18, 19, ..., 28], so always read the ids from the JSON on every match rather than assuming 0-10.

What the server does

The FoxLeague rcssserver loads those custom types at startup instead of generating random ones. The server reads the injected hetero.json and, for every type slot, overwrites the standard heterogeneous parameters with the FoxLeague values:

// FoxsyAI rcssserver: createFoxsyHeteroPlayers(file_path)
for (int i = 0; i < playerTypes(); i++) {
    for (auto it = j[std::to_string(i)].begin(); it != j[std::to_string(i)].end(); ++it) {
        // e.g. "player_speed_max", "dash_power_rate", "kickable_margin" ...
        foxsy_hetero_players[i].setParam(it.key(), it.value());
    }
}

So player type i is no longer a random trade-off type. It carries the exact stats of the NFT player that FoxLeague assigned to it.

What your team must do

read formation_name then line up in that formation,
have its online coach apply the assigned types by sending (change_player_type UNUM TYPE) for each uniform number, using the ids in player_type_ids, so each player picks up the FoxLeague stat-derived type instead of the rcssserver’s own defaults or randomly generated ones.

That is exactly how the default FoxLeague team plays every standard match today. A binary that follows the same contract can be offered as a template for non-developer tournaments. The full schema, including every heterogeneous parameter, will be published when the Royalties System launches.