# ForgeGuard: competitive research and engineering priorities

Research date: **23 September 2026**. ForgeGuard is the new product name for the project previously called SentinelForge; its source directory may retain the old name for compatibility.

## What this research establishes

ForgeGuard has a useful evidence and review foundation. Its audited starting point is an observation alpha, substantially behind established products in movement simulation, combat coverage, supported environments and field experience. A new name, dashboard or large check count cannot establish market leadership. The route to a stronger product is broader verified coverage, fewer harmful interventions, understandable evidence and dependable operation.

This is a primary-source review of eight prominent anticheats, plus two relevant complementary/reference projects. It is not an exhaustive census of every commercial, private or historical anticheat. Product documentation establishes what a vendor documents, not independent proof that a detector succeeds against every cheat. No competitor binary was purchased or benchmarked for this report, and no competitor implementation was copied.

The distinction used throughout is:

- **Documented:** the linked owner-maintained source describes the capability.
- **Documented limitation:** the owner explicitly describes an exclusion, requirement or restricted behavior.
- **Not established:** the reviewed public material does not establish a capability. This does **not** mean the competitor lacks it.
- **Proposal:** a ForgeGuard design target, not a feature delivered by this research document.

Search results can confuse product names and unofficial domains. Grim's repository links to `grim.ac`; that repository is used as the authority here. Old Intave documentation includes dated caveats, so current repository descriptions take priority. Exact client/server combinations must be verified against a specific released artifact before deployment.

## The current ForgeGuard baseline

This section records the code and validation inspected at the beginning of this work, before the concurrent rebrand/dashboard changes. Consult the current [README](../README.md) and [validation record](../VALIDATION.md) for the final delivered build.

| Area | Audited starting point | Consequence |
|---|---|---|
| Runtime | Java 21, Paper 1.21.11, PacketEvents 2.13.0 | A Paper plugin; it does not load into a Forge/NeoForge mod server despite the product name. |
| Checks | Non-finite movement validation; experimental movement-rate, horizontal envelope, air trajectory and timer-window observations | Five check IDs do not constitute a complete prediction engine. |
| Coverage | Native Java 1.21.11, simple full-block ground/clear air, normal movement conditions | Liquids, vehicles, elytra, unusual collisions, custom physics and uncertain client identity are excluded. |
| Evidence | Bounded case files, 120 movement-packet trace, engine checkpoint, deterministic replay, audits | A good foundation for debugging and review. Reproduction of a finding is not proof of cheating. |
| Enforcement | OBSERVE by default; MITIGATE only cancels non-finite movement packets; manual case-linked kick with confirmation | Experimental movement/timing findings cannot automatically ban or kick. |
| Integrations | A bounded, session-scoped movement-grace API | Grace suppresses observation; it does not model an authorized dash or grapple. |
| Verification | Previously recorded 36 passing tests and one short generated-client Paper fixture | Not a live-player false-positive study, load certification, broad bypass audit or market comparison. |

The source inspected includes `core/CheckId.java`, `core/ObservationEngine.java` and `resources/config.yml`. Combat reach, aim, placement, inventory, an acknowledged world timeline and broad collision simulation were absent from that starting point.

## Product comparison

### GrimAC

**Documented strengths:** open-source movement simulation, client-version-sensitive collisions, per-player world replication, latency/inventory compensation and asynchronous processing. Its repository describes Spigot, Paper, Folia and Fabric environments and provides a plugin API. **Documented constraints:** Geyser players are exempt; ViaVersion belongs on the backend rather than the proxy; additional premium heuristics are described as planned. These are deployment/coverage limits, not evidence of weak Java movement detection. [Official repository](https://github.com/GrimAnticheat/Grim), [official FAQ](https://github.com/GrimAnticheat/Grim/wiki/FAQ).

**ForgeGuard lesson:** invest in the player's acknowledged view of the world and explicit version adapters. Do not call broad per-packet speed limits prediction. Preserve the distinction between exempt crossplay clients and clients whose movement is actually checked.

### Vulcan

**Documented strengths:** PacketEvents-based analysis, broad combat categories including aim, reach, velocity and click behavior, configurable operation and a developer API. **Documented constraints:** Floodgate-based Bedrock exemption; the vendor focuses on blatant cheating and warns about subtle modifications, unusual clicking and some modified clients/plugins. Its FAQ explicitly says Vulcan executes configured punishment commands but does not retain the punishment count needed for a rule such as banning after repeated kicks; that needs another plugin/API integration. Configuration options can be updated automatically. [Official product page](https://vulcanac.net/), [official FAQ](https://vulcanac.net/wiki/faq/).

**ForgeGuard lesson:** provide sensible defaults and clear check descriptions. A case-linked action history, including reversed actions and expiry, is a concrete operations improvement over simply emitting a console command. It should support staff judgment rather than turn repeated weak signals into an automatic verdict.

### Matrix

**Documented strengths:** movement, combat, inventory/delay and world-interaction categories; configurable check modules, violation decay and action thresholds. Its configuration demonstrates combining multiple combat signals and optional NPC checks. It explicitly favors maintainable Bukkit integration over a fully asynchronous packet-only design. **Documented constraints:** Bedrock players are identified and ignored; Forge/Fabric modded servers are unsupported. The vendor warns that cheat categories are not a guarantee of catching every variant. The homepage links a web panel, but that alone does not establish live server control or its authorization model. [Official homepage](https://matrix.rip/), [coverage/platforms](https://matrix.rip/docs/), [check configuration](https://matrix.rip/docs/configuration/checks), [Geyser behavior](https://matrix.rip/docs/extension/geysermc).

**ForgeGuard lesson:** make configuration understandable and separate detection from response. Corroboration is useful, but correlated signals from one underlying movement error should not count as independent evidence. Avoid making a first-generation product depend on fake-player detection.

### Spartan

**Documented strengths:** broad combat, movement, world and inventory categories; advertised Geyser detections and Folia support; staff GUI, per-check prevention/punishment switches, temporary bypass and a panic command. **Documented limits:** its owner-maintained listing labels elytra and entity coverage as very basic and X-ray analysis as statistical. The listed free distribution is limited to five or fewer players. Feature names and platform badges do not independently establish detection quality for every combination. [Vagdedes' official CurseForge project](https://www.curseforge.com/minecraft/bukkit-plugins/spartan-anticheat).

**ForgeGuard lesson:** an immediate return to observation mode and granular staff controls are valuable. Broad category coverage needs equally prominent limitations. Statistical mining observations should remain leads for review and should not be presented as direct observation of an X-ray client.

### Intave

**Documented strengths:** movement simulation, local behavioral heuristics and optional paid cloud machine learning. The current repository describes replaying recorded movement scenarios during every build, multi-tick simulation and double latency compensation. Local checks work without the cloud service. **Documented constraints:** source availability is not permission to rebrand or reuse its implementation in a competing product; the repository explains its restrictive license. Its superiority statements and broad version claims are vendor claims, not comparative measurements from this study. [Official repository and project description](https://github.com/intave/intave).

**ForgeGuard lesson:** every reproducible bug should become an original regression fixture. Maintain a useful local detector if optional hosted analytics are ever introduced. Replay testing, simulation and cloud analysis already exist in the market; none should be marketed as a new invention by ForgeGuard.

### Polar

**Documented strengths:** a hybrid service with local checks for time-critical movement corrections and hosted analysis; movement, protocol, combat, inventory and world categories. It separates mitigation from punishment, and documents adjustments such as movement correction and combat restrictions. **Documented constraints:** recurring service and uninterrupted internet requirements; Bedrock exemption; experimental Folia support; proxy-side Via plugins unsupported. Some violation thresholds are intentionally not configurable, while movement leniency is. The vendor itself explains that a mitigation can result from normal glitches or other plugins and is not necessarily evidence of cheating. [Architecture and requirements FAQ](https://docs.polar.top/faq.html), [detection/mitigation model](https://docs.polar.top/detections.html), [configuration](https://docs.polar.top/configuration.html).

**ForgeGuard lesson:** a validated correction can prevent an advantage before a ban would help. Every correction still affects the player, so record its reason, context and reversibility. A useful local core plus an optional control service avoids making dashboard availability a prerequisite for observation.

### Themis

**Documented strengths:** actual Bedrock/Geyser checking through Floodgate, movement-oriented coverage plus reach, per-check actions and support through the separate Anti Cheat Replay plugin. **Documented constraints:** the author acknowledges additional Bedrock false-positive challenges and describes a movement focus. Version 0.17.7's release notes distinguish experimental Spigot 1.21.11 support from Paper support through 1.21.10 at publication; the broad project version badge is insufficient to promise a particular current runtime. Its old timing example is explicitly not a fair full-feature comparison. [Official Modrinth project](https://modrinth.com/plugin/themis-anti-cheat), [0.17.7 release notes](https://modrinth.com/plugin/themis-anti-cheat/version/0.17.7).

**ForgeGuard lesson:** treat Bedrock as a distinct tested model, not a Java tolerance tweak. Show verified client identification, Geyser/Floodgate topology and per-check coverage in the dashboard. Do not claim to be the first anticheat to check Bedrock or to provide replay integration.

### Updated NoCheatPlus

**Documented strengths:** a maintained continuation of the long-standing NoCheatPlus project, open-source checks spanning movement, fighting, block actions, inventory and spam, plus documented configuration/API and compatibility integration. **Documented constraints:** server/build compatibility must match; some checks need a compatible ProtocolLib, otherwise they are disabled. Integration with custom plugins may require CompatNoCheatPlus. The reviewed README does not establish a hosted control panel, Bedrock physics certification or a player-exportable deterministic case system; those remain unverified rather than asserted absent. [Official continuation repository](https://github.com/Updated-NoCheatPlus/NoCheatPlus).

**ForgeGuard lesson:** compatibility diagnostics must expose disabled checks and missing dependencies. A broad catalog is useful only if staff know which checks are active for the current player, server and mechanics.

## Additional references and scope limits

**Negativity:** the public repository documents proxy integration, localization and alert suppression under adverse ping/TPS, but explicitly says the free branch is no longer supported. Its claims cannot simply be transferred to the separate premium branch. ForgeGuard can learn from clear operational degradation signals and translation support; skipping analysis under load must be visible as lost coverage. [Owner's repository](https://github.com/Elikill58/Negativity).

**Paper Anti-Xray:** this is complementary information hiding, not a general movement/combat anticheat. Paper documents three obfuscation modes and caveats around exposed ores, range and seed reconstruction. ForgeGuard should report compatible server obfuscation settings and validate interaction distance independently before attempting its own chunk rewrite system. It should never promise universal X-ray prevention from mining statistics. [Paper's Anti-Xray guide](https://docs.papermc.io/paper/anti-xray/).

Private server systems, historical products and other commercial options are outside this bounded review. There is no factual basis here for a ranked claim such as “better than every anticheat,” “unbypassable,” or “zero false positives.” A fair broader study needs lawful access to exact releases and repeatable, matched test environments.

## What is missing, and what can actually differentiate ForgeGuard

The clear documented gaps are **product-specific**: Bedrock exemptions in several Java products; Vulcan's lack of built-in punishment counting; limited advertised elytra/entity coverage in Spartan; Themis' movement focus; and the service/deployment dependencies described by Polar. This review did not find a universal missing feature shared by every competitor.

The following is an original product direction inferred from operator needs and the evidence above. The reviewed sources do not establish whether every competitor already supplies each complete workflow, so these are differentiation hypotheses to test with users, not exclusivity claims.

| Priority | ForgeGuard proposal | User-visible result | Acceptance condition |
|---|---|---|---|
| 1 | Coverage ledger per player/check | “Native movement observed,” “liquid unmodelled,” “stale snapshot,” or “Bedrock unsupported,” with the time spent in each state | No unsupported session displayed as protected; every suspension has a machine-readable reason and contributes to coverage totals. |
| 1 | Evidence review with explanation | A case shows observed/allowed values, version, configuration revision, timeline gaps, uncertainty and any staff action | Export and replay reproduce the finding under the matching build; incomplete evidence is marked incomplete. |
| 1 | Validated, revisioned configuration | Preview changes, reject invalid values, detect concurrent edits and restore a known previous revision | Failed validation or write leaves the active settings unchanged; apply and rollback both create audit entries. |
| 1 | Immediate observation control | An operator can stop interventions without stopping evidence capture | Server acknowledges the effective mode; UI never reports success based only on a local toggle. |
| 2 | Custom ability contracts | DungeonForge dashes, launch pads and ForgeClasses movement modifiers carry explicit time/velocity/attribute allowances | Contracts originate from trusted enabled server plugins, are scoped to a session, bounded and auditable; ordinary checks resume at expiry. |
| 2 | Shadow evaluation | Compare a new detector/configuration to the current one on identical evidence before enabling interventions | Report changed findings, changed coverage and reasons; shadow output cannot punish players. |
| 2 | Action and appeal history | Staff can see the evidence behind a decision and whether it was reversed | Identity/session checks, attribution and reason are retained; a reversal does not erase the original record. |
| 3 | Independently qualified Bedrock model | Operators know which Geyser/Floodgate/client combinations actually receive checks | Separate real Bedrock fixture suite and clean-player trial pass; exemptions stay explicit until then. |

Avoid accumulating cosmetic check names, silent default cloud uploads, self-adjusting thresholds with no review trail, arbitrary remote-console commands, permanent IP-based guilt scores and automatic punishment of statistical aim/mining anomalies. More aggressive settings trade false negatives for player disruption; they do not make an uncertain model accurate.

## Phased engineering roadmap

These phases describe remaining development. A phase is delivered only when its code and qualification evidence exist.

### Phase 1: trusted operations and evidence

Complete the ForgeGuard name and hand-authored vector identity; provide the Netlify-deployable interface and a narrowly authorized server connection. Support health, cases, coverage, current settings, supported setting updates and an observation-mode control. Label local demo data and offline state clearly. Keep the secret needed to contact the server out of public JavaScript and downloaded configuration examples.

Use a server-side gateway with authentication, scoped permissions, request-size limits, method/path allowlists, audit attribution and configuration revision checking. Netlify serves the dashboard/control gateway; the anticheat executes inside the Minecraft server. A static upload alone cannot grant remote control. Test invalid credentials, expired sessions, revision conflicts, malformed settings, unavailable servers, restarts and evidence-storage failure. This is the nearest deliverable to the audited alpha.

### Phase 2: one excellent native Java movement model

Implement an ordered acknowledgement timeline for world changes, abilities, attributes, teleports and velocity. Add version-specific collision shapes, ground transitions, steps, fluids, block effects, input possibilities and bounded multi-tick uncertainty. Allocate a known CPU/memory budget per player and stop claiming coverage when the budget or timeline is insufficient. Keep all new checks in observation until their individual fixture sets pass.

Build original clean traces for sprint/jump, slabs/stairs, ice/slime/honey, piston and block changes, knockback, swimming, elytra, vehicles, moving entities, custom abilities and reconnect/teleport boundaries. Treat each supported mechanic as its own coverage milestone, not one broad “1.21 supported” badge.

### Phase 3: combat and interactions

Add bounded, latency-compensated entity history for reach/hitbox and interaction-ray observations. Model version, pose, attributes, world obstruction and uncertainty. Add placement and inventory state-machine validation. Evaluate automation heuristics separately from mechanically impossible interactions; skilled aim and unusual clicking patterns need adversarial clean-player fixtures. Only combine signals after checking their correlation and calibration.

### Phase 4: controlled mitigation

Introduce check-specific reversible corrections only after qualification. Record both the predicted benefit and the actual effect. Use a shadow cohort, a small canary rollout and automatic return to observation on anomalous intervention rates, lag or lost evidence. Staff must be able to inspect and reverse actions. Ban automation remains a separate, higher-bar policy decision rather than an incidental side effect of a detector.

### Phase 5: additional platforms and network operations

Build and certify separate Bedrock, translated-client and Folia support. Native Forge/NeoForge needs a separate runtime adapter and mod-mechanic strategy; a Paper JAR cannot supply it. Add network-wide case correlation and role-based review after single-server correctness is proven. Optional hosted analytics must have a useful offline/local mode, explicit data boundaries, retention controls and a visible outage state.

## Qualification gates for any leadership claim

The numbers below are **proposed release targets**, not measured results or promises. Set them before evaluating a candidate, then publish failures as well as passes.

| Dimension | Proposed gate | What to publish |
|---|---|---|
| Coverage honesty | 100% of unsupported or suspended check states surfaced; missing data never presented as clean evidence | Covered player-time, excluded player-time, reasons, and client/server/plugin matrix. |
| Reproducibility | Every complete retained case reproduces its finding in its matching engine/configuration; corrupted, truncated or incompatible cases fail clearly | Case schema, build hashes, config revisions, fixture manifest and replay results. |
| Clean-player interventions | At least 3,000 diverse clean-player hours before claiming a very low intervention rate; no unexplained severe action | Events per player-hour, session-clustered uncertainty, cohort diversity and adjudication protocol. Zero events is not proof of zero risk. |
| Detection | Pre-register a labeled, authorized scenario matrix; detect at least 95% of the explicitly supported blatant scenarios, with p95 finding latency at most 2 seconds for scenarios where that window is appropriate | Per-scenario recall, time to detection/mitigation, failure examples and unsupported categories; no misleading single overall accuracy percentage. |
| Server cost | Sustain 100 representative concurrent clients on a named machine with incremental p99 server-thread cost below 2 ms/tick and no sustained analysis loss in a 60-minute steady run | Baseline and enabled MSPT, worker CPU, queue delay/drops, heap, allocation/GC, disk and client workload. Synthetic core timings do not substitute. |
| Network resilience | Exercise 0/50/150/300 ms added latency, jitter, burst delivery, stalls, disconnects and reordering where the protocol permits it | Coverage and interventions for every impairment profile; no interpreting lag alone as intent. |
| Integrations | Every advertised custom ability passes positive and negative fixture pairs with expiry, reconnect and plugin-disable cases | Exact plugin versions, ability contract and replayable regressions. |
| Control security | Reject unauthorized, stale-revision, replayed or out-of-scope mutations; retain operator audit attribution; never expose server credentials publicly | Threat model, automated gateway/bridge results and independent review before public multi-tenant operation. |
| Rollback/outage | Last valid local policy and observation continue through control-service outage; interrupted writes preserve recoverable configuration | Fault-injection results, recovery steps and visible degraded state. |

For matched competitor trials, pin every JAR, dependency, setting, server build and machine. Run identical clean workloads and isolated authorized adversarial scenarios, alternate run order, and compare detection at a comparable intervention budget. Respect vendor licensing and test-access terms. Do not publish a speed/accuracy ranking from an unmatched promotional test server or from check counts.

An eventual defensible claim should be narrow and reproducible: for example, “On the published native Java movement suite, build X caught Y of Z scenarios with N harmful interventions over H clean-player hours.” Expand the claim only as coverage and independent evidence expand.