Lock the base first. Raid only when you have a launch-ready nuke, a specific cash objective, and enough remaining production to recover if the attempt fails. The guide can organize visible inputs, but it cannot calculate hidden target defense, steal formulas, or a guaranteed outcome.
Treat base lock as the first gate
The official description explicitly tells players to lock the base before someone nukes them back. Therefore the first raid-readiness question is not target value or nuke spectacle; it is whether the current client shows your base as locked. If the answer is no or uncertain, stop and fix it. Check again after changing servers, returning from offline time, or finishing a raid. The public evidence does not establish lock duration, cooldown, shield strength, or exceptions, so this page never converts a visible locked state into a promise of complete protection.
- Locked and visibly confirmed: continue to the inventory gate.
- Unlocked: stop and lock before leaving or launching.
- Unclear: inspect the current UI rather than trusting memory.
- Never publish an unsupported protection duration.
Verify launch-ready inventory
A raid needs at least one nuke the current game allows you to launch. Count launch-ready items separately from bombs reserved for a planned same-tier merge. Spending the last useful input on a raid can delay progression even if the raid succeeds. The checked sources do not provide a full nuke roster or universal power ranking, so use the present client to identify readiness. If the item is still part of a merge chain, decide which objective matters more before clicking. A clear inventory split prevents the same bomb from being counted twice.
- Mark launch-ready nukes.
- Mark same-tier inputs reserved for progression.
- Do not double-count one item in both plans.
- If no nuke is launch-ready, farm or merge first.
Name a raid objective that can be checked
The official page says raids can steal cash, but it does not publish a guaranteed return. Set a specific objective using visible information: attempt a raid for a target cash amount, test the current launch flow, or complete a current in-game task. Avoid vague goals such as 'get rich fast.' Compare the desired amount with current cash, visible production, and the time a safer loop would take. The target creates a stop condition. If ordinary production already reaches it within the planned session, a risky raid may not be necessary.
- Write the target cash or current task.
- Compare with current and projected ordinary production.
- Do not assume a steal percentage or guaranteed target payout.
- Skip the raid when it does not solve the named objective.
Use a readiness checklist, not a hidden score
The owned calculator can summarize four visible conditions: base locked, at least one launch-ready nuke, planned merge requirement satisfied or intentionally deferred, and projected cash aligned with the target. Treat these as a checklist. A numeric score is an interface convenience, not a server success probability. If the base is unlocked, readiness fails. If no nuke is ready, readiness fails. If the raid consumes a critical merge input or leaves no recovery path, farm or merge first. Passing the checklist means the plan is coherent, not that the target cannot defend or retaliate.
- Base visibly locked.
- Launch-ready inventory confirmed.
- Progression inputs protected or intentionally spent.
- Cash objective and recovery path defined.
- No claim of guaranteed raid success.
Plan the post-raid recovery before launching
Decide what happens if the raid returns less cash than hoped. Keep enough production or inventory to resume the ordinary loop. Record the cash balance before and after, whether the nuke was consumed, and whether the base lock changed. Do not chase a disappointing result with repeated launches unless the original objective and safety gates still hold. Chasing can convert a bounded test into an unplanned drain. If the game's Friday update changed target selection, launch behavior, or retaliation, stop and research rather than extrapolating from the previous build.
- Preserve a recovery loop.
- Record pre- and post-raid cash.
- Recheck lock state after the attempt.
- Stop after an unexpected result until the cause is understood.
Keep unsupported systems outside the decision
The specialist watch tracks community interest in commanders, rockets, rebirth, base skins, and special events. The official BASE SKINS event wording can establish that customization and an event were announced, but it does not supply commander bonuses, rebirth thresholds, rocket statistics, skin effects, or a raid formula. Do not add those unknowns to readiness. Likewise, BOOM is present in the official description but its reward is not specified there, so a raid plan should not depend on receiving a particular amount. Use only visible current values and documented broad mechanics.
- Commander effects: held.
- Rebirth thresholds and bonuses: held.
- Rocket and skin performance: held.
- BOOM reward amount: not assumed.
- Current visible inventory and lock state: usable inputs.
What changed across observed Roblox snapshots
This is our own dated history of the same public Roblox fields. It shows observed movement, not a prediction or an explanation for why players moved.
Source: QuestSignal immutable release history · newest five observations shown
What this guide does not assume
The raid workflow relies on official statements that players launch nukes, steal cash, and should lock their bases, plus owned player-entered planning logic. It does not know target defenses, retaliation, steal percentages, lock duration, success odds, or hidden commander, rebirth, rocket, or skin effects.
Refresh trigger: Refresh when an official Friday update or creator-owned event page changes raid, base-lock, inventory, or cash mechanics, or when repeatable first-hand evidence establishes a currently held rule.