Decentralized Referees
The endgame is a network of independent referee nodes where no single operator can cheat.
How It Works
- Staking — referee operators stake $FALK tokens as collateral to join the network
- Selection — when a match needs a referee, one is selected deterministically (weighted by stake amount)
- Execution — the selected referee runs the FISE logic and submits the result on-chain
- Verification window — other nodes can independently run the same logic and challenge incorrect results
- Fraud proofs — if a challenge succeeds (the result was wrong), the dishonest referee's stake is slashed
- Rewards — honest referees earn a share of the match rake in USDC
Why This Works
FISE execution is deterministic. Given the same inputs (moves, salts, match context), every node produces the same output. This makes fraud proofs trivial — to prove a referee cheated, you just re-run the code and show the results differ.
This is fundamentally different from systems like optimistic rollups where fraud proofs are complex. In FALKEN, the verification is: "download the JS from IPFS, replay the moves, compare the output." Anyone can do it.
Referee Economics
The protocol rake (currently 7.5%) gets split:
| Recipient | Share | Purpose |
|---|---|---|
| Protocol treasury | 4.5% | Platform operations |
| Referee operator | 3% | Compensation for running infrastructure |
| Game developer | 2.5% | Royalty for writing the game logic |
Running a Node
Referee nodes run the same Falken VM software that powers the centralized referee today. The falken-vm package is already the node software — it just needs staking logic and node registration added on top.
CLI (at launch):
npx @falken/referee-node --stake 10000 --key $PRIVATE_KEY
Desktop app (later): A GUI wrapper showing node status, matches refereed, USDC earned, and stake amount.
Infrastructure Requirements
Each referee node needs its own RPC endpoint to read on-chain state and submit transactions. Options include:
| Provider | Cost | Notes |
|---|---|---|
| Alchemy / QuickNode / Infura | $50-200/mo | Managed, reliable, usage-based pricing |
| Self-hosted Base node | ~$50/mo flat | Run on Hetzner or similar — unlimited calls, no rate limits |
| Public Base RPC | Free | Rate-limited, not recommended for production refereeing |
This is by design — RPC costs are distributed across the network instead of centralized on the protocol. Each operator pays for their own infrastructure and earns USDC from the rake to offset it.
Potential Referee Earnings
Referees earn 3% of the total pot for every match they officiate. Estimated monthly USDC earnings based on match volume and average pot size:
| Matches / Month | $2 Pot | $10 Pot | $50 Pot | $200 Pot |
|---|---|---|---|---|
| 100 | $6 | $30 | $150 | $600 |
| 500 | $30 | $150 | $750 | $3,000 |
| 1,000 | $60 | $300 | $1,500 | $6,000 |
| 5,000 | $300 | $1,500 | $7,500 | $30,000 |
Pot = combined stakes of both players. A $25 buy-in match has a $50 pot.
At scale, even modest stake sizes make refereeing profitable relative to infrastructure costs. A node handling 500 matches/month at an average $10 pot earns ~$150/mo — enough to cover a managed RPC endpoint and turn a profit.
Why Not Just Use an Oracle?
Oracles like Chainlink report external data to the blockchain. FALKEN's referee is different — it's executing custom game logic, not reporting prices or weather. The computation itself is the service.
An oracle network could theoretically run FISE code, but:
- Generic oracle nodes aren't optimized for game state reconstruction
- Custom FISE sandbox execution requires specific tooling (QuickJS WASM, IPFS fetching, deck derivation)
- The referee needs deep integration with match lifecycle events
- Referee economics align incentives directly with the gaming platform
FALKEN's referee network is purpose-built for this exact workload. It's an oracle, but specialized for deterministic game logic execution.