Theme
It exists for one situation: a creator walks away, the token keeps trading, and their share of the tax piles up in a wallet nobody is watching.
Who can execute one
Only the platform, from a key kept for this and nothing else. Not the creator, not a holder, not a vote. The contract refuses a new recipient that is the key doing the takeover, the treasury, the factory, the token itself, the token of any pair, or the wallet already receiving — so the platform cannot point a token's fees at itself, and fees cannot be sent to a token contract where they would be stuck. The contracts names that key and the one method it may call.
When a token is eligible
A community applies, in public. Every one of these has to be true before an application can even be opened.
| Gate | Rule |
|---|---|
| Age | launched at least 30 days ago |
| Creator silence | the fee wallet has not claimed or traded for 30 days |
| Still alive | the token has traded within the last 14 days |
| Stranded fees | at least 50 NEAR's worth of creator fees sitting unclaimed |
| Cooldown | no takeover on this token in the last 90 days |
| One at a time | no other application already open |
On a coin in another pair the fees are in that pair, so they are valued in NEAR at the pair's current price. If there is no price for the pair, the check fails and no application can be opened until there is.
The applicant has to hold some of the token and cannot be the creator or the current fee wallet. An application carries a written plan and at least one piece of evidence, both published.
The waiting period
An approved application waits 72 hours before it can be executed, the wait is published on the token page, and an approval can still be withdrawn inside it. A creator who reappears in that window is exactly what it is for. The wait is the platform's own rule, not something the contract enforces: the contract checks who executes a takeover and where the fees may go, not when.
Executing it re-points future creator fees only. Fees earned before the takeover stay with the old wallet, which can still claim them. Executing it writes an event on chain naming the old wallet, the new wallet, the key that acted and a hash of the published application, so evidence cannot be swapped between approval and execution.
Tokens it can never reach
The contract also accepts a fee wallet that can never change, and then no takeover is possible on that token, ever. The create screen always launches with takeover possible; the token page says which of the two a token was launched under, so read it rather than assuming.
