SilentWolf Shutdown: Godot Leaderboard Migration Guide (2026)

If your Godot project still contains SilentWolf calls, the practical task is the same regardless of the missing vendor announcement: remove a dead runtime dependency, make startup tolerant of leaderboard outages, and move scores to a backend whose identity and write-authority model you understand.

First fix: never let an optional leaderboard crash the game

The 2025 outage exposed an architectural bug in affected games: an unavailable leaderboard was able to break startup or leaderboard screens. Before migrating providers, wrap the feature so the game still launches when the network or vendor is down.

• put leaderboard loading behind a timeout;
• show an offline/unavailable state instead of blocking the main scene;
• do not assume a response body is valid JSON on HTTP/network failure;
• queue or discard non-critical score submissions according to your game design;
• keep local/Steam/platform leaderboards independent if you use them.

The important Crux difference: identity comes before the score

The old version of this guide described Crux as an API-key-only drop-in where the client could choose any player_id. That was wrong and would defeat player tenancy.

The current client flow is:

publishable Crux key
  -> POST /v1/auth/anonymous (or email/OAuth/Steam login)
  -> player token + stable Crux player_id
  -> POST /leaderboards/{board}/scores as that player
  -> GET /leaderboards/{board}/top

A publishable key is safe to ship because it does not grant arbitrary access to every player in the project. After login, the player token proves which player the client may address. A server token is the trusted path when your authoritative server must submit a score for somebody else.

Step 1: create the Crux project and board

1. Create a Crux project/environment and copy its publishable key. Do not ship a secret key or server token in the game client.
2. Create a leaderboard in the dashboard and choose the score semantics you actually need: best, replace or sum.
3. Copy the leaderboard key or UUID; the runtime API accepts either.
4. If this is a competitive board, decide now which trusted server/workflow proves a score before it is submitted. A provider migration does not make client-reported scores trustworthy.

Step 2: use the shipped Godot addon

The current Crux Godot SDK already implements the correct login and leaderboard paths. With the addon installed and autoloaded as Crux:

const PROJECT_ID := "YOUR_PROJECT_UUID"
const ENV_ID := "YOUR_ENVIRONMENT_UUID"
const PUBLISHABLE_KEY := "YOUR_PUBLISHABLE_KEY"
const LEADERBOARD := "high_scores" # key OR UUID

func _ready() -> void:
    if not Crux.init_player(
        "https://crux.supercraft.host",
        PROJECT_ID,
        ENV_ID,
        PUBLISHABLE_KEY
    ):
        return

    # The addon persists its anonymous device id in user:// so subsequent
    # launches resolve back to the same guest player unless you clear it.
    var auth := await Crux.login_anonymous()
    if auth.is_empty():
        push_warning("Leaderboard login unavailable")
        return

    print("Crux player: ", auth["player_id"])

    # Empty player id means the currently logged-in player.
    await Crux.submit_score(LEADERBOARD, "", 4200.0)

    var entries := await Crux.get_top(LEADERBOARD, 10)
    for row in entries:
        print("#%d  %s  %.0f" % [
            int(row["rank"]),
            str(row["player_id"]),
            float(row["score"])
        ])

This is deliberately not a one-to-one replacement for SilentWolf's arbitrary player_name key. Crux leaderboards are tied to stable project player identities. That is the safer basis for cloud saves, account upgrades and cross-device identity later.

SilentWolf call → Crux call

Old responsibility	Current Crux path	Important difference
Configure game API key	Crux.init_player(base, project, env, publishable_key)	Publishable key identifies the project but is not a player identity.
Identify a casual player	await Crux.login_anonymous()	Returns a player token and stable Crux player id; the addon persists the anonymous device id.
Save score	await Crux.submit_score(board, "", score)	The player token may submit for itself. A shipped publishable key cannot choose arbitrary players.
Top scores	await Crux.get_top(board, limit)	Returns ranked entries including rank, player_id, score and metadata.
Competitive trusted score	Submit from your authoritative server using a Crux server token	The server, not the player client, decides whether the result is legitimate.

What about player names?

SilentWolf's simplest leaderboard examples used a display name as the entry key. Do not make an editable display name your durable identity during migration. Preserve a stable player id and render a display/profile name separately. If you put a casual display label in score metadata, remember that a player-controlled client can forge that metadata too.

Importing old scores

A replacement backend cannot reconstruct data that disappeared with the previous service. If you have a SilentWolf export, local archive, platform leaderboard or other authoritative copy, build an idempotent import:

1. normalize the old player identifier and decide how it maps to the new Crux player identity;
2. create/link the target players first;
3. submit historical scores from a trusted server-side importer, not a client build;
4. compare row counts/top-N/checksums before switching the game UI;
5. keep the raw source export unchanged for rollback/audit.

If all you have is a screenshot or stale leaderboard cache, decide explicitly whether to start a new season instead of pretending the old board can be losslessly recovered.

Leaderboard security after migration

A player token prevents one client from addressing a different Crux player, but it does not prove the claimed gameplay score is legitimate. A modified client can still submit an impossible score for itself.

• Casual board: client-side submit may be an acceptable product tradeoff.
• Competitive board: calculate/validate the result in an authoritative game server or trusted service and submit with a server token.
• sum boards: deduplicate match/event ids in trusted game logic so a network retry cannot count the same reward twice.
• Bounds: configure min/max score bounds where they meaningfully reject malformed input, but do not call that gameplay anti-cheat.

The leaderboard integrity guide covers that trust boundary in detail.

Alternatives besides Crux

Crux is not the only sensible SilentWolf replacement. If you need only a leaderboard, a focused leaderboard service or a small service you own may be less surface area. If you also need accounts, saves, economy or multiplayer services, compare broader platforms such as PlayFab, Nakama/Heroic Cloud, Beamable, Talo and other current Godot-compatible backends on the exact contracts your game needs.

The important replacement property is not “free forever.” It is that the game can tolerate an outage and that you can export/migrate identity and data without rebuilding the whole client.

Why Crux is one possible fit

Crux's Godot path now covers guest/email/OAuth/Steam identity, durable player documents and leaderboard operations behind the same player-token model. The free Dev BaaS tier currently allows 10,000 MAU and 2 million API calls per month. The export guarantee describes the exit path; the API contract is published through OpenAPI and the client SDKs are available in the repository.

Crux Runtime is separate: it is a capacity-gated closed alpha for a narrow Godot/Linux dedicated-server workload. You do not need Runtime merely to replace a leaderboard.