How certification works

1. You submit a build

Register the project once, then upload the compiled .jar exactly as you distribute it: the artifact players will actually download, not a dev build and not a deobfuscated one. 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. Malformed archives and decompression bombs are rejected outright. What is left gets scanned 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 why this stage decides nothing on its own.

3. Someone reads it

A reviewer works through 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, and you get those notes whichever way the decision goes.

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 the certificate as invalid.

5. It stays under review

Certificates lapse after 365 days. They can be revoked at any point: on an abuse report, on a new indicator, or at your own request. Because badges are served from here, a revocation is visible everywhere the badge appears.