SafePal sets a 31 October deadline for Gravity Alpha balances

The deadline concerns balances on Gravity Alpha

SafePal's 22 September update tells users holding assets on Gravity Alpha Mainnet to migrate by 31 October 2026. It warns that transfer access may be lost afterward and links Gravity's migration documentation. The notice supplies no cutoff timezone. The linked guide explains how to withdraw from the legacy network; it is not an automatic transfer into the new Gravity L1.

Choose the route by the asset, not just the network name

Gravity's guide identifies the legacy Alpha network as chain ID 1625. G, DAI and WBTC use the official Gravity Bridge to Ethereum. USDC, USDT and ETH/WETH instead use Stargate: the guide says the canonical bridge cannot withdraw those assets. Stargate labels the USDC balance USDC.e. Users should retain some G for transaction fees.

Canonical withdrawals have an approximately seven-day challenge period before the funds can be claimed on Ethereum. Gravity explicitly advises starting well before the deadline. Its guide describes Stargate transfers as taking minutes, but that is documentation guidance rather than a guaranteed completion time for an individual transfer. Follow the linked official instructions for the asset actually held.

Start with an inventory of what is actually there

An effective migration plan begins with a small inventory. For each balance, record the network, asset, amount and intended destination. Keep balances on different networks as separate rows, even if their displayed tickers match. The purpose is to prevent a familiar name from substituting for the information that determines which instructions apply.

Imagine a wallet displaying three assets and another similarly named balance on a different chain. Looking only at the portfolio's total value gives no useful migration plan. The owner needs to establish which entries belong to the affected network, then match each to the relevant documented route. This example is a way to organize the work, not a claim that every token in a wallet is supported by a particular bridge. An unmatched asset is an unresolved question for official support, rather than a reason to improvise a route.

Allow time for completion, not only submission

A calendar deadline can be misunderstood as the last moment to begin. A process with a waiting stage needs a different plan: the start date, waiting period and final action all have to fit. Submitting an initial transaction shortly before a cutoff does not establish that the destination funds will be available before it. Keep the expected completion stage visible in the plan instead of marking the whole task complete after the first confirmation.

For an illustrative schedule, a person might reserve separate sessions to review the asset inventory, initiate the applicable withdrawal and return to complete any required claim. Leaving additional time also allows a mistaken assumption to be discovered while there is still room to resolve it. This is scheduling analysis, not a promised safe last-start date. The absence of a stated cutoff timezone is another reason to avoid building a plan around the final hours.

Keep evidence of each stage

Record the source transaction and the intended receiving account before moving on to the next asset. Afterward, check the result on the destination network. A record that says only sent can hide several different states: submitted, confirmed on the source network, waiting for a later action or received at the destination. Using more precise labels makes it easier to know what remains to be done.

Consider a person migrating several balances across two sessions. A short log with one row per asset lets them resume without guessing which item is unfinished. The log can include the official route followed, transaction reference and observed status. It should not contain recovery words or signing secrets. The useful evidence is the transaction trail and the planned destination, not the private information that controls the wallet.

Decide on any later move separately

Finishing the exit from an affected network answers one question: where the assets are now accessible. Choosing whether to use them on another network is a separate decision with its own supported routes and costs. Keeping those decisions distinct prevents the phrase migration to a new chain from becoming an assumption that one action completes every step. The immediate practical task is to identify the affected balances, follow their documented exit routes and verify the outcome in time.