ludus-security-and-anti-cheat-research-2026

Ludus Security and Anti-Cheat Architecture (Research 2026)

Overview

The Vox Ludus gamification system is inherently vulnerable to exploitation because it relies on local CLI triggers and external signals (GitHub) that can be spoofed or manipulated. To ensure community trust and prevent “absurd amounts of lumens” from being generated by hackers, we must move from a Trust-on-First-Sight model to a Reputation-Gated Contribution model.

Core Pillars of Security

1. Reputation-Weighted Scaling (DevRank)

Rewards should not be binary. Instead of awarding a flat 100 XP for a PR, we apply a DevRank multiplier based on the account’s historical “gravity”:

• Account Age: GitHub accounts < 3 months old receive 0.1x rewards.
• Interaction Graph: Accounts with no followers or stars (potential Sybil bots) are capped at Tier 0 rewards.
• Stellar Score: The internal Vox reputation metric (earned via peer reviews and successful builds) acts as the primary multiplier for high-stakes rewards.

2. Proof of Contribution (PoC) Verification

We prevent “empty PR” hacking by performing heuristic validation of the claimed activity:

• Semantic Diff Analysis: The vox ludus sync-github command sends the PR diff to a lightweight analyzer (or a local ML model) to verify the “Work-to-Token” ratio. Adding 100 lines of comments earns less than 10 lines of logic.
• Build-Linked Rewards: High-value rewards (like Lumens) require a Verified Build Hash. The player must run vox build or vox check, which generates a signed artifact hash. The server only awards XP if the GitHub commit hash matches the verified build signature.

3. Distributed Peer Auditing (The Collegium)

Rather than a centralized “Anti-Cheat” server, we leverage the existing Collegium (guild) system:

• Audit Transparency: All high-stakes rewards (Arena wins, large Lumen drops) are published to a public (or collegium-private) audit log.
• Peer Challenges: Players can “challenge” a suspicious leaderboard entry. If the challenge is successful (e.g., the code was proven to be AI-generated spam or plagiarized), the cheater is “slashed” (losing Lumens/XP), and the challenger earns a “Bounty Reward”.
• Vouching: Joining a “Ranked Arena” requires a vouch from a high-reputation player. If the vouched player is caught cheating, the voucher’s reputation also suffers (transitive trust).

4. Technical Guardrails (Checksumming)

• Binary Integrity: The vox binary includes a self-checksumming routine that verifies the vox-gamify constants haven’t been patched.
• Signed Telemetry: All rewards are signed with the player’s private key (managed by Clavis) before being synced to the cloud DB. This prevents simple “man-in-the-middle” API spoofing.
• Idempotency Guards: Every GitHub event is uniquely identified by its API ID. We already implement INSERT OR IGNORE in gamify_processed_events to prevent double-claiming.

Due Process and Adjudication

To prevent “witch hunts” and ensure that punishment is only applied to genuine bad actors, we implement a multi-stage adjudication process.

1. Proof of Malice vs. Low Quality

The system must distinguish between a beginner developer and a malicious cheater:

• Low Quality (The “Tiro” Guard): Code that is functional but lacks documentation, tests, or follows poor patterns receives reduced rewards (e.g., 0.5x multiplier) but is never slashed. This is treated as a “teaching moment” rather than a violation.
• Malice (The “Hacker” Guard): Plagiarism (copy-pasting external code without attribution), “Empty Commit” spamming, or tampering with the CLI binary constants to spoof rewards. These are the only behaviors eligible for slashing.

2. The Judicial Collegium (Dispute Resolution)

High-stakes penalties (slashing > 50% of a weekly gain or account suspension) require a Consensus Vote:

• Evidence Package: When a player is flagged by the automated heuristic engine, a public “Dispute Package” is generated, containing the GitHub diff, build logs, and a “Malice Score”.
• Randomized Jury: A pool of 5–12 “Master” tier players (with zero connection to the defendant) is selected to review the evidence.
• Blind Voting: Jurors vote “Guilty” or “Innocent” independently. If a majority reaches a verdict, the penalty is applied.
• Juror Reputation: Jurors who consistently vote with the majority consensus gain “Justice Lumens”. Jurors who are proven to be voting randomly or maliciously (collusion) lose their “Master” status.

3. The Appeals Process

Players have a 7-day “Grace Period” to appeal any automated or peer-voted penalty:

• Defense Statement: The player can provide context (e.g., “I was testing a specific edge case that looked like spam”).
• Supreme Review: A second, larger jury or a trusted “Moderator/Dev” group performs a final review of the appeal.

Tiered Trust Model

Tier	Name	Requirement	Capabilities
0	Novice	None (Local only)	Basic leveling, local companions. No leaderboard visibility.
1	Linked	GitHub Verified (>6 mo)	Global leaderboards, Arena participation, basic sync.
2	Proven	10+ Verified Builds	Ranked Arena, Lumen trade, Collegium membership.
3	Master	100+ Lumens + Community Vouch	Peer auditing, quest creation, high-multiplier rewards.

Next Steps for Implementation

1. Reputation Engine: Integrate GitHub account metadata (age, stars) into the RewardPolicy multiplier logic.
2. Audit Display: Enhance vox ludus leaderboard to show “Trust Tiers” next to player names.
3. Heuristic Validation: Implement a basic CodeMaster service that checks PR sizes and file types during sync-github.

References

• Ludus Identity SSOT
• Telemetry Trust SSOT
• Anti-Cheat Research Findings 2026