There is no emergency stop
Most platforms can pause trading, block a wallet or push a fix to a live contract. LOOT cannot do any of those things. That is a deliberate design choice, and it cuts both ways, so we would rather you read it here than discover it during an incident.
Last updated 27 July 2026The short version
- There is no pause button. Nothing anyone can do will stop trading on a launched pool.
- There is no kill switch and no upgrade path on the contracts that hold money or run the game. They cannot be changed after they are deployed. Not by us, not by anyone.
- The two limits that do exist stop protecting you at graduation, which is exactly when a pool is at its largest.
- The launch gate fails open. If our launch service goes down, launching does not stop. It becomes permissionless.
- Exactly one key exists, and it governs where our own fee revenue goes. It cannot reach your funds. Details below.
- Your losses are limited only by what you put in. There is no circuit breaker underneath you.
No admin keys on the money contracts
The contracts that run trading, the loot game, fees, prizes and launches are deployed once and are permanently immutable. They have no owner, no admin, no pause function and no upgrade mechanism. There is no privileged address, because no function checks for one.
We do not ask you to take that on faith. A read-only drill calls the nine admin functions a “contained” protocol would have (owner, admin, pause, paused, unpause, upgradeTo, transferOwnership, setImplementation, renounceOwnership) against every contract in the live generation. All of them revert, on all of them.
| Contract | What it does | Admin surface |
|---|---|---|
| Hook / locker | holds pool liquidity, cranks fees | none |
| Factory | deploys tokens and pools | none |
| Router | routes your buys and sells | none |
| Fee splitter | splits the trading fee into its lanes | none |
| Ledger | boxes, keys, zones, the game state | none |
| Rails | prize claims | none |
| Purse | the hourly draw | none |
| Launch gate | admits launches | none |
| Boost | paid visibility | none |
| Referrals | referral credit | none |
The practical consequence: a bug in any of these is permanent. We cannot patch it, pause around it, or migrate you out of it. We can only tell you about it.
The two limits, and when they stop
A new token carries two restrictions. Both are enforced by the token contract itself, and both switch off permanently the moment the token graduates.
| Limit | What it does | Ends at |
|---|---|---|
| Max wallet · 2% | no wallet can hold more than 2% of supply | graduation |
| First-hour buy cap · 2.4% | one origin wallet cannot buy more than 2.4% of supply | graduation, or one hour after launch, whichever comes first |
Graduation is a one-way latch inside the token contract. Once a token has graduated there is no path, for us or anyone, that puts the limits back.
The launch gate fails open
Launching through the site normally needs a ticket signed by an off-chain service we run. That service publishes a regular heartbeat on-chain. If the heartbeat stops for five minutes, the gate stops requiring signed tickets and a permissionless launch path opens instead.
So switching our service off does not stop launches. It opens them. The lever is inverted: to slow launches down we have to keep the service alive and stop issuing tickets. If we are knocked offline, we lose that option entirely and launching continues without us.
There is also a one-way function that permanently retires the signing key. It only ever makes admission more open, and it cannot be undone.
The one key that exists
One contract is upgradeable: the splitter that divides our own share of the trading fee among the people entitled to it. It has an owner, and that owner can replace its logic.
What that key cannot do: touch a pool, move or lock your tokens, change a balance, stop a trade, alter the loot game, reach the pot, or change any payout owed to you. It sits at the end of the fee path, not in it.
We are naming it because “we hold no keys” would be false, and a claim you can disprove is worse than the truth. This is the entire mutable surface of the protocol.
What we can actually do in an incident
Everything we can reach is our interface, the website and the services behind it. None of it touches the chain.
- take the website down, or close it to new visitors
- roll the site back to an earlier version
- hide a token from our feed and search
- stop issuing launch tickets
- stop our own automated services
- stop trading on any pool that already exists
- stop new launches
- pause the loot game, box accrual, opens or claims
- reverse, block or refund a transaction
- move, lock or recover anyone’s tokens
- fix a bug in a deployed contract
One deployment, no second try
On the main network LOOT is a single, permanent set of contracts. There is no staged rollout, no upgrade window and no mechanism to deploy a corrected version and move everyone over to it. Whatever is deployed on day one is what runs, for as long as the chain runs.
Audit status
The deployed contracts have not been audited by an independent security firm. They have been reviewed in-house, tested and fuzzed, but no external firm has signed off on them. Weigh that against the fact that nothing above can be paused or patched.
A quiet launch is not a safety control
Launching without much noise reduces how many people are exposed. It does not reduce what can go wrong for the people who are here. We will not describe restraint in marketing as though it were a security measure, because it is not one.
Check it yourself
Every contract is deployed on a public chain and every claim on this page is a public read. Call owner(), paused() or upgradeTo() on any address in the table above and watch it revert. Read the token contract and find no mint, no pause and no blacklist. You do not need our permission and you do not need to trust this page.
The rest of the risk picture is on the risk disclosure, and how the protocol works is in the docs.