Get ban status for a user

Returns whether the specified user address would currently be rejected by a platform ban — its own, or one matching the device the address is recorded on.

This endpoint is public — no authentication required. It is intended for clients to check their own ban status before attempting to connect.

Close to what token retrieval enforces, but not identical

This endpoint receives only an address, so its device term is always the address's last recorded device. Token paths prefer the device identifier the request itself carries and fall back to the recorded one only when it has none. Where a request arrives with a device that differs from the recorded one, the two can disagree in both directions.

So a user banned on one wallet who reconnects under a different wallet from the same recorded device is reported as banned here and rejected at token issuance — but treat this endpoint as the source for user-facing ban messaging, not as a prediction of whether a specific connection will be accepted. Token issuance stays authoritative for a concrete request.

The ban record is only returned for the address's own ban

matchedOn says which identifier matched. When it is device, the response contains isBanned: true and no ban object: the matching row belongs to another player, and publishing it on an unauthenticated route would disclose whose wallet is banned. The full record — reason, expiry, custom message — is returned only when matchedOn is address. Where both exist, the address's own ban is the one reported.

bannedDeviceId is never returned on this route, whatever matchedOn says: it is a stable cross-wallet machine identifier and this endpoint is unauthenticated. Moderator tooling reads it from the moderator-gated GET /bans.

A client can use matchedOn to word the notice: an address match has a reason and an expiry to show, a device match has neither.

Because the route is unauthenticated, any address can be tested for device coverage. That is an accepted trade-off for being able to tell banned players why they are blocked.

Moderator tooling that needs the full picture, including each ban's device snapshot, should use the moderator-gated GET /bans.