Merge a Nuke Progression Guide

Verify the current loop before calculating

The official Roblox description confirms the broad systems: merge bombs into larger nukes, earn cash every second including while offline, launch nukes at enemy bases, steal cash, and lock your own base. It does not publish a full tier roster, prices, production rates, offline caps, or every merge condition. Before using any number, open the current game and confirm how the next visible merge works. The owned calculator models a pairwise same-tier ladder, so that model is valid only when the current client still shows two identical inputs combining into the next step.

• Confirm the official universe is 10199301628.
• Read the next visible merge requirement in the live client.
• If the merge is not pairwise and same-tier, do not use the exponential worksheet.
• Record the Friday-update state before a long plan.

Calculate same-tier inputs conditionally

When the current game confirms a two-for-one same-tier merge, each additional target step doubles the starting requirement. One step needs two same-tier inputs, two steps need four, three need eight, and so on. Enter the number of target steps and compare the required amount with the same-tier bombs you actually own. The result is a planning count, not proof of tier names, prices, or acquisition routes. If an update changes the rule, discard the worksheet immediately rather than adjusting it until it looks plausible.

• Required starting inputs equal two raised to the target-step count only under the verified pairwise rule.
• Remaining inputs equal required inputs minus owned same-tier inputs, with no negative result.
• Do not mix different tiers in one starting count.
• Do not infer purchase cost from the merge count.

Estimate offline cash from visible inputs

The official description says nukes earn cash every second and while offline. To make a bounded estimate, enter the cash-per-second value shown by your current arsenal and multiply it by the number of seconds you plan to be away. Add that estimate to current cash only for personal planning. The checked sources do not establish an offline cap, collection penalty, bonus, server rounding rule, or whether every nuke contributes identically. Treat the output as a straight-line estimate and compare it with the actual amount collected next time.

• Use the visible cash-per-second value.
• Convert hours to seconds for the estimate.
• Label the result projected, not guaranteed.
• Compare projected and collected cash after returning.
• Retire the model if repeated results show a current cap or different rule.

Choose the next progression action

If the merge requirement is met, make the visible merge and recheck production before planning another step. If inputs are missing, decide whether ordinary cash production or a safe acquisition route is the current task. If the projected cash does not reach the next visible goal, continue the current loop instead of starting a risky raid just because progress feels slow. The official description provides one creator-backed code string, BOOM, but it does not establish the reward in the checked release. You may try the exact string in the current redemption flow, but do not budget an assumed reward.

• Inputs ready: merge and verify the result.
• Inputs missing: farm toward the known requirement.
• Cash target short: continue a bounded cash loop.
• BOOM: official code text, reward not claimed here.

Protect the base before leaving progress unattended

Base locking is not optional flavor in the official listing; the creator explicitly warns players to lock before someone nukes them back. Before leaving for offline cash, entering a raid, or holding a large cash balance, confirm the lock state in the current client. A guide cannot read that state for you. If the base is not locked, fixing that is a higher-priority progression action than another speculative merge. Do not assume a permanent lock duration, immunity window, or protection formula because those details are not present in the checked sources.

• Check the current lock indicator.
• Lock before going offline or launching a raid.
• Recheck after returning or after a server/update change.
• Do not promise immunity or a duration not shown by the game.

Reconcile the plan after every Friday update

The official description advertises new updates every Friday. That cadence is a refresh trigger, not a changelog. After a Friday update, verify the merge rule, visible cash-per-second behavior, offline result, raid wording, base-lock control, and code text before reusing saved assumptions. Keep a small log with the date, same-tier count, target steps, projected offline cash, actual collected cash, and lock state. This makes the next recommendation reproducible and prevents an old calculator result from becoming false confidence after the game changes.

• Recheck merge inputs.
• Recheck cash-per-second and offline collection.
• Recheck base-lock state and raid wording.
• Recheck creator-backed code text.
• Date the new observation before publishing a changed recommendation.

What this guide does not assume

Roblox supports merging, cash generation, offline earning, raids, stolen cash, base locking, BOOM, and Friday updates. The pairwise ladder and cash projection are owned planning models that require current player-entered values. Exact tiers, costs, caps, bonuses, commander effects, rebirth rules, and raid formulas are not claimed.

Refresh trigger: Refresh after every substantive Friday update, official description change, or repeatable first-hand result showing that the pairwise merge or straight-line offline estimate no longer matches the current client.

Continue with Merge a Nuke