Identity Is Not Proof
A few people I know in real life have Sigils. I built the identity service behind the Deep Dark Abyss games, and I run it from an admin console that can search by gamertag, Sigil ID, public ID, and friend code. None of that could tell me which of a couple of hundred Sigils belonged to someone I actually know. They had to tell me which one was theirs.
That is the design working. DDAP Sigil is one identity across twelve games on iOS and Android, with no sign-up, no email address, and no password. When a system has to decide whether to believe what a user claims, the reflex is to learn more about the user. Verify an address, require a sign-in, bind the identity to a device. Sigil goes the other way. It checks the result instead of the person, so it never needs to know who that is.
Who may act, and what was done
When a result reaches a leaderboard there are three things you might want to know, and they are different questions.
May this installation act for this player? The credential answers that.
What did this play actually score? The game’s server answers that, and in the strongest cases it answers by running the game itself.
Did a person do it, unaided? Nothing in the system answers that. Attestation can establish that a submission came from an unmodified app on a genuine device. Behavioral analysis can establish that a pattern of play looks unusual. Both describe the circumstances of a submission. Neither observes the playing.
Sigil is built for the first two and says plainly that it does not answer the third. Everything else follows from keeping those questions apart.
A Sigil points at no one
A Sigil has a few parts, and none of them is a person.
The Sigil ID is a random identifier that never leaves the player’s own devices and the servers. A separate public ID stands in for it wherever another player has to refer to someone: a friend request, a block, a report. The gamertag is a display name, chosen or generated, and not unique, so a small symbol drawn from the Sigil ID, the glyph, tells two players with the same name apart. Each device holds a random credential in its secure storage, and the server keeps only a one-way hash of it.
No name, no email, no phone number, no birthday, no contacts. Every game asks before creating a Sigil, and every game plays fully without one.
That is pseudonymous, not invisible, and the edges are worth stating. The servers keep standard request logs, IP addresses included, for a limited period and unlinked to any Sigil. A player can choose their real name as a gamertag, and nothing stops them. Friendships are made by exchanging friend codes, usually between people who already know each other, so a player’s friends know who they are even when I don’t. The system holds nothing that identifies a person on its own. Sigil never asks a player to say who they are.
Identity holds no score
The separation is no longer a convention inside one app. It is the architecture. Identity is one service. Each game runs its own small service beside it, with its own data. A game reads identity through a shared library, to check a credential or look up a name, and never writes to it. The identity service, for its part, holds no score, no board, and no rule from any game.
That boundary decides what a result is. In Sprenzy, a chain-reaction puzzle, the app doesn’t send a score. It sends what the player did: a board and three spark positions.
Not { "score": 116 }, but { "boardId": "daily-2026-09-27", "sparks": [16, 44, 91] }.
The Sprenzy service loads the board from its own storage and runs the same deterministic engine the app runs. Given a board and three sparks, there is exactly one result. Identity appears in that flow once, at the top, deciding whether to proceed. It has no bearing on what the number turns out to be.
One gamertag, twelve kinds of proof
Because identity carries no proof, each game decides how much proof its own engine allows, and the answers differ.
At the strong end, the server replays the play. Sprenzy reruns the ignition. Dumpster Talk, a trash-toss game, replays every throw through the same integer physics the app uses. Abysstris replays an entire game, move by move.
Gust sits at the other end. Its physics runs natively on the phone, in Box2D, and the server can’t run it. So the app sends a level, a star count, and a score, and the server checks what it can: that the level exists, that the stars agree with the score, that the score is no higher than the board allows. That limit was not a security decision. It followed from an engine choice made for other reasons.
The gap is real. A modified Gust client could post a believable top score that passes every check. On the leaderboard, that row looks exactly like a Sprenzy row: gamertag, glyph, number. A replayed result and a plausible one look identical.
A few exceptions, such as one-time imports of records from earlier apps, take a player’s word outright. Each is written down, bounded where it can be, and approved. The rules that bind every game don’t move: one official Daily attempt, results accepted only while their date is current, and achievements granted by the server alone.
Controls no more complex than the game
The original specification has a section listing what not to build: hardware fingerprinting, root and jailbreak detection, certificate pinning arms races, device attestation, VPN detection, behavioral anti-cheat, IP reputation, machine-learning fraud analysis. Twelve games later, none of it exists. The per-address rate limits that do exist bound volume, not identity.
Those controls aren’t worthless. They’re a bad trade here. Root detection punishes people who modify hardware they own. Attestation adds a dependency on a third party’s definition of a genuine device, which moves whenever the platform does. Each is ongoing engineering rather than something you finish, aimed at an adversary whose prize is a place on a puzzle leaderboard. The controls should never become more complex than the game they protect.
What exists instead is proportionate. An absurd score stands out. Any player can report it from the row itself, I review every report, and a ban takes effect in every game within two minutes. A ban ends a Sigil, not the person behind it, and the same is true of every per-Sigil rule. Registering another Sigil is easier than cheating. The specification’s closing instruction—if somebody spends their weekend cheating at this, ban the identity and get on with your life—now has machinery behind it. That path catches the implausible score. It does not catch the careful one, and I accept that, because the prize doesn’t justify the chase.
The same restraint is what made the service easy to build on. Gust joined on the same terms as Sprenzy, because identity asks nothing of a game’s engine. Had proof lived in the identity layer, a native-physics game would have been shut out, or would have dragged the whole service up to the complexity of its hardest case. Instead, nine games joined in under three weeks in October, built from a shared game template, server library, and client package.
What the console cannot see
I run Sigil from Sigillum, a Mac app I built for the job. It shows what the service holds, which means it also shows what the service doesn’t.
Open a Sigil and the console lists its credentials, with a note that the count is not a device count. Devices that share an iCloud Keychain share a credential, and so do several DDAP apps on one Android phone. The server has never had a device count to give. The tool states what its number doesn’t establish, right where the number appears.
The dashboard has counts: Sigils active in the last day, week, month, or quarter, how many are new, how many have played each game. Beyond that, Sigil can’t tell an iPhone from an Android phone, a tablet from a phone, or a simulator from either. It doesn’t know how long anyone played, or whether a game does better on one platform than the other. An identity layer is the natural place to build a player profile, because it is the one piece that sees a person across every game. Sigil keeps what players see—leaderboards, friends, achievements—and nothing for the business behind them.
The console’s one AI feature follows the same pattern. Claude can explain a record and propose an action from a fixed list, but a proposal doesn’t run. Sigillum reads the target again, so an invented ID fails there, and then opens the same confirmation every change requires. The model claims, the system checks, and a person confirms. It is the arrangement behind the score, applied to the administrator’s chair.
Deleting a Sigil deletes it everywhere
A server-held identity with a public name counts as an account to both app stores. Apple’s Guideline 5.1.1(v) requires in-app deletion for any app that supports account creation, and Google Play requires both an in-app path and a web link. Deletion was a requirement before it was a principle.
With twelve games it is also a distributed problem. Delete a Sigil from any game and its credentials are revoked at once, everywhere. Identity then tells every game to purge what it holds, and keeps asking, every hour, until each one confirms. Only then is the identity record removed. Reports made by or about the player go with it, as the privacy policy says. Backups age out within fourteen days, and after that all that remains is a record of the deletion itself, with nothing personal in it, gone thirty days later. A Sigil nobody has used in twelve months is deleted the same way, automatically.
Then the part that costs something. After deletion, the game does not quietly make a new Sigil. It drops into offline mode. Local progress keeps working, because it was never the server’s to take, and the online features stop until the player deliberately creates a Sigil or links an existing one.
The cheaper version deletes the record and mints a replacement on the next launch. The product keeps working, the player never notices, and the row is gone. That is deletion in storage and continuity in practice, and the difference between them is the entire content of the promise.
The name was never the evidence
The things systems collect to know a person—an email, a sign-in, a device fingerprint—buy something. They don’t buy confidence in what that person did. Sigil holds nothing that says who anyone is, and its boards still mean what they say, up to the limit already admitted: the replayed row is what those moves produce, and the plausible row is plausible. Neither would mean more with an address behind it.
Somewhere on those boards are scores from people I know. I can tell you exactly how each one was checked. I can’t tell you which ones are theirs, and I built it so I couldn’t.
DDAP Sigil runs across twelve Deep Dark Abyss Productions games, all in private beta on iOS and Android. Anyone who asks gets an invitation. DDAP Sigil and its games has the details and the request forms.
Discover more from At Ground Level
Subscribe to get the latest posts sent to your email.
