How certification works

1. You submit a build

Register the project once, then upload the compiled .jar exactly as you distribute it. Not a dev build, not a deobfuscated jar: the artifact players will actually download. We record its size, entry count and SHA-256 digest on arrival.

2. Automated static analysis

The archive is opened read-only and every entry is walked. We reject malformed archives and decompression bombs outright, then scan class files and resources for indicators:

• Process execution through Runtime or ProcessBuilder
• Runtime class definition, which hides code from the archive listing
• Paths into browser credential stores, the classic Discord token grabber tell
• Hardcoded webhook and paste-site endpoints used for exfiltration
• Bundled native executables and nested archives
• Missing or contradictory loader manifests

Plenty of legitimate mods trip the softer indicators: update checkers open sockets, and every mixin-based mod touches reflection. That is precisely why analysis alone does not decide anything.

3. A named analyst reviews it

An analyst reads the findings, opens the flagged classes, and where a source repository is published, checks that the artifact plausibly corresponds to it. They record what they inspected. Their notes go to you verbatim, whichever way the decision lands.

4. Issue and seal

On approval we mint a certificate number, bind it to that one SHA-256, and seal the record with an HMAC over the whole claim set. If a row in our own database were edited afterwards, the seal stops matching and the verification page reports it as invalid rather than quietly serving a lie.

5. It stays under review

Certificates lapse after 365 days. They can be revoked at any moment: on an abuse report, on a new indicator, or at your own request. Because badges are served from here rather than baked into your page, revocation is visible everywhere at once.