The GLaDOS utility token
Status: planned. Nothing is deployed. There is no contract, no contract address, no chain chosen and no date. Anything claiming to be this token today is fake. This page describes an intended design so it can be argued with before it is built. It is not an offer, a solicitation, or investment advice of any kind.
The constraint that shapes everything
A kernel cannot gate itself. The images on this site are public, the machine runs in ring 0 with one address space and no process isolation, and the operator is by construction the most privileged thing on it. A balance check compiled into the kernel is one edit away from being deleted, and anyone who wanted it gone would have both the source and the motive.
It would also cost the project the property that makes it credible: you can download an image, boot it, and watch it do what the documentation says. A system that refused to run without a wallet would be asking to be taken on trust. Everything else here is arranged to avoid that.
So the rule is that the token gates what a machine must be given. It never gates what the machine does once it has it. Enforcement lives where the bytes come from. Every item below is on the list because it survives that test.
What it would gate
| Use | Why it is enforceable |
|---|---|
| Experimental kernel builds | The update service is live. A machine asks a channel what it offers, checks the answer against a signing key compiled into the kernel, downloads the image, and stages it for the next boot. The stable channel is public and always will be, including every security fix. The experimental channel needs a device code before the server will answer at all. Feature kernels, branch builds and anything that does not fit a release go there. |
| Model weights | The larger checkpoints, and any finetune trained against the machine's own corpus, are files that somebody distributes. Gating distribution is enforceable because it is distribution. |
| Hosted inference | The kernel has DNS, TCP and a TLS 1.3 client it negotiates itself, so a larger remote model that the in-kernel one escalates to is reachable. The key is issued and checked server-side. It is also a real feature, since a 0.6B model in a kernel has obvious ceilings. |
| Ledger anchoring | The interesting one, and it is a use of the token that gates nothing at all. See below. |
What the gate cannot do
Worth stating plainly, because the opposite claim is the easy one to make and it would be false.
An experimental image that leaks installs and runs on any machine. It carries the same signature as a stable release, and the only question the kernel asks is whether that signature is good. There is no per-machine binding and there could not be a meaningful one, since the source is published and any local check is a check the machine's owner can delete.
The gate is that the server declines to answer. That is the whole of it, and it is the only claim this page will make for it.
Anchoring the self-modification ledger
This system already modifies itself. It proposes changes to its own routing, trains an adapter over its own decision layer, and adopts a change only when four independent judges agree. Each verdict goes in a ledger, and because the search walks a declared grid with no random seed anywhere in it, every verdict is re-derivable bit for bit by any later run. Storage is content-addressed, so a snapshot is one root hash.
None of that was built with a chain in mind, and all of it is already the shape of a chain commitment. Anchoring each root and each ledger entry gives something that does not otherwise exist: a public, timestamped, tamper-evident record of an AI system rewriting itself, where a third party can take a root, re-derive the verdict independently, and check whether it holds. The token pays for anchoring, and can fund a challenge bond, so that disagreeing with an anchored verdict and being right is worth something.
That is the honest reading of the phrase "tokenized operating system". The software checks no balance. Its history of changing itself becomes a public record that somebody other than its author can verify.
What it deliberately would not do
| Refused | Why |
|---|---|
| Gate boot, or any local feature | Unenforceable, for the reasons above, and it would cost the project the thing that makes it worth looking at. |
| Paywall the stable channel | Security fixes reach everybody. The stable channel is a public object with no authentication in front of it, so there is nothing to rate-limit and no way for the gated path to take the free path down with it. |
| Let holders override the judges | Governance can steer which proposals get tried. It must not decide which get adopted. The judges are the measurement discipline this whole project rests on, and a vote that could overrule one would adopt changes nobody measured. |
| Put a key-holding wallet in the kernel | One address space, no process isolation, and a language model with function-call access to raw memory and I/O ports. That is the worst available place to keep a private key. Signing stays off the machine. |
Where it stands
The ticker is not finalised. The design above is settled, in the sense that it is what the project would build, though nothing has been deployed and no date is set.
The update service that would carry the first gated use is running today. Both channels publish through the same pipeline and the same signing key, and the stable one has been verified end to end from a booted kernel. What is missing is the half that decides who holds what, which waits on a decision about custody: a token held inside a custodial exchange app gives its holder no key to sign with and no address of their own, so proving a holding needs a different mechanism from proving control of a wallet. That decision changes one function on the server and nothing else.
When something exists, its contract address will be published here and on the source repository, and nowhere else.