The GLaDOS utility token
Status: deployed. Launched through flap.sh on Robinhood Chain. Any address other than the one below is not this token.
| Contract | 0x3d609ecafc6aa7dba67dd7ad1d10b49c52d57777 |
|---|---|
| Chain | Robinhood Chain, id 4663 (0x1237) |
| Name | GLaDOS |
| Symbol | GLADOS |
| Decimals | 18 |
| Total supply | 1,000,000,000 |
Every figure in that table was read off the chain rather than copied from
anywhere, and you can read it the same way: eth_call against
rpc.mainnet.chain.robinhood.com for name(),
symbol(), decimals() and totalSupply().
Do that rather than trusting this page.
The deployed contract is an EIP-1167 minimal proxy. Its own
bytecode is 45 bytes of forwarding stub and every rule the token follows lives
in the launchpad's shared implementation at
0x7777c8743c88b3aff3cf262135bef2c8b2e83333. That is normal for a
launchpad deployment and it is worth knowing, because reading the proxy tells
you nothing about the behaviour -- the implementation is what to read.
This page is not an offer, a solicitation, or investment advice of any kind, and nothing on it is a prediction about price.
Tax, and who gets it
The rates are 1% on a buy and 3% on a sell, and you do not
have to take that from this page. They are public reads on the token contract,
and so is the fact that owner() is the zero address:
curl -s -X POST -H 'content-type: application/json' \
--data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[
{"to":"0x3d609ecafc6aa7dba67dd7ad1d10b49c52d57777","data":"0x691f224f"},
"latest"]}' \
https://rpc.mainnet.chain.robinhood.com
buyTaxRate() data 0x691f224f -> 0x64 = 100 = 1.00%
sellTaxRate() data 0x24024efd -> 0x12c = 300 = 3.00%
owner() data 0x8da5cb5b -> the zero address
Read at block 59,463,301. What this page deliberately does
not claim is that the rates therefore cannot ever change: that would
need the verified source to show the setters are gated on owner,
and the block explorer for this chain is behind a bot challenge. The reads
above are facts; the inference is not one this page is entitled to yet.
The tax is split four ways:
| 40% | Dividends to holders |
|---|---|
| 30% | Creator wallet |
| 25% | Liquidity |
| 5% | Burned |
Dividends need a balance of at least 1,000,000 GLADOS, which is one tenth of one per cent of supply. The threshold is a token count and not a currency amount, so what it is worth moves with the price and this page does not quote one.
None of that is enforced by anything in this repository. The split, the distribution and the threshold are the launchpad's contract, they execute on Robinhood Chain, and the kernel has no part in any of it and cannot. What this project controls is described below, and it is a much smaller thing: whether a server hands over a build.
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 token is deployed. The gate it is meant to open is not, and the two are worth keeping apart.
The update service that will 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 still missing is the half that decides who holds what.
The custody question that was blocking it is answered by where this launched. A token held inside a custodial exchange app gives its holder no key to sign with and no address of their own, which would have made proving a holding impossible by the obvious route. On Robinhood Chain it is an ERC-20 in a self-custody wallet, so holders have keys, so they can sign. The mechanism that was waiting on that decision is ordinary: a server-issued nonce, signed by the wallet, the address recovered from the signature, and the balance read against the contract above. The signature proves the address; the chain answers for the balance.
Two properties of that flow, because they are the parts people get wrong. The balance is read server-side -- a client that reports its own holdings is one devtools console away from reporting whatever it likes. And it is re-read at each download rather than cached at link time, because a holding is not a permanent fact about a person.
Link a wallet → The page shows the exact message before asking for a signature, and shows both the address your wallet reports and the address the server recovered, which must match. Nothing there will ever ask for a seed phrase or a private key.
What has not changed is anything below the line in the section above. The gate is still distribution and only distribution, a leaked build still installs on any machine, and no key of any kind goes on a machine running this kernel.