Pi Network is moving more rewards onchain. When can holders sell?
A second migration can move another portion of a Pioneer’s balance onto Pi Network’s Mainnet. From there, wallet access, lockups and exchange deposit policies determine whether the coins can actually reach the market.
- Pi Network’s gradual second migration rollout gives eligible Pioneers who have already migrated once another route to transfer accrued balances onto Mainnet.
- Eligible referral bonuses can form part of the second balance, and Pi requires wallet two-factor authentication before either first or second migration eligibility.
- Pi’s documentation describes a 14-day pending period after migration, and lockup commitments can keep part of a wallet balance unavailable for longer.
- Even transferable PI can only reach an exchange order book if the holder has access to a venue accepting deposits over Pi Mainnet.
- Completed migrations, transferable balances, exchange deposits and actual sales measure different stages, so none by itself captures how much PI holders are selling.
Pi Network has opened a route for eligible Pioneers to move a second transferable balance to Mainnet, giving users who have already migrated once another opportunity to bring accrued PI onto the chain.
Pi’s second migration update describes a gradual rollout and says eligible balances may include referral bonuses. The project requires wallet two-factor authentication through Step 3 of the Mainnet Checklist before eligibility for a first or second migration.
The route from a balance in the mining app to a sale has several stages. It matters which stage a figure describes, particularly when traders are trying to infer selling pressure from a rise in migrations.
Which balance is moving?
Pi’s earlier KYC and wallet fixes addressed barriers before transfer. The second migration concerns the additional eligible balance that reaches the wallet.
A second migration is for a Pioneer who has already completed one migration. It concerns the portion of a subsequent balance that the project considers transferable, including eligible rewards under its verification rules.
The amount a user sees in an app is therefore a different measure from the amount credited to a Mainnet wallet. A user’s ability to move one portion of the balance does not establish that every remaining reward is eligible on the same date.
Why a referral reward can take longer to verify
Pi’s migration roadmap says first migrations included categories such as verified base mining rewards and some other rewards, while second migrations also handle eligible referral bonuses. The difference concerns the records used to calculate a balance. A referral reward can depend on another participant’s verification and on whether the two were mining concurrently.
The second migration announcement says the referral calculation incorporates the KYC status of team members and varies by mining session. It is therefore possible for a user to complete verification and still find that the referral portion of the balance changes as the project establishes which rewards are eligible.
Two users with the same displayed amount can have different outcomes. One might have a balance made up mostly of rewards already verified. The other might rely more heavily on referral bonuses associated with people whose checks are incomplete. A comparison of app balances would miss that distinction. A comparison of transferable amounts would capture the result of the verification rules.
The project’s longer-term plan envisages periodic migrations after it has worked through the first and second migration queues. The roadmap leaves the future frequency open. A forecast that assumes a fixed schedule would need an announcement giving a cadence or enough completed migrations to measure an observed pattern. The project’s published plan establishes the sequence without supplying that timing.
Why a queue total cannot give a release date
The queue measures work the network still has to process. It does not follow that two users entering it on the same day will receive the same amount or be able to move it at the same time. Eligibility, completion of wallet steps and restrictions after migration all matter to the outcome a user sees.
One useful distinction would be between accounts waiting to migrate and accounts whose funds have already entered the pending period. The second group has passed an observable milestone, although its balance may still be restricted. Reporting both groups as waiting for an exchange sale would collapse several decisions into one number.
A count of eligible accounts also weights everyone equally. A user with a small balance and one with a large balance each count once. To estimate possible exchange supply, an analysis would need the quantity attached to completed credits and a distribution of the dates on which those units become transferable.
The same principle applies to comparing first and second migrations. A second migration represents additional eligible rewards for someone with a previous Mainnet balance. If the same wallet receives both credits, counting two transactions as two new holders would overstate the change in the number of holders. The project’s roadmap separates migration rounds, while a wallet-level dataset would need to distinguish the number of credits from the number of people receiving them.
Why the second migration changes the calculation
The first transfer to Mainnet established an onchain balance for eligible users. The second can add rewards that were harder to calculate, including referral bonuses. Pi’s own explanation says those rewards depend on verification status and the mining sessions in which people took part. The programme therefore concerns both the ability to receive a transfer and the amount a user ultimately receives.
A person can clear their own checks without knowing how much of a referral balance will qualify. The referral component depends on other accounts. If several people in a team are verified at different times, the eventual amount may differ from the estimate visible earlier in the app. That is why a displayed reward balance should not be added to onchain supply figures as if the two described the same stock of coins.
The consequences differ for individual holders. One might receive another substantial credit because many of their referral rewards qualified. Another could have completed the same wallet checklist and receive a smaller credit because their rewards were made up differently. The number of people eligible tells readers how widely a process could reach, while the quantities moved tell them how much PI entered wallets.
The project’s description of future periodic migrations is also relevant. It places them after the initial rounds and leaves the frequency to be determined. That gives a reason to separate a schedule announced by Pi from an estimate drawn from recent transactions. Users planning around a future credit would need the dates relevant to their balance, while traders following supply would need evidence of credits at the network level.
What happens in the wallet
After migration, the relevant record for a user is the Mainnet wallet balance and its availability. Where a lockup applies, the holder can see value associated with the wallet while waiting for the conditions on transfer to be met.
Wallet access also matters. Two-factor authentication concerns the migration process. The holder still needs control of the receiving wallet to authorise a later transfer.
A locked balance can still be visible onchain
Two users could receive the same amount on the same day and reach the market at different times. Both can see the transfer in their wallets. During the pending period, the funds may remain unavailable. Once that period ends, a lockup commitment can still restrict part of one balance while another user is able to transfer more immediately.
An example can make the difference concrete. If two users each receive 1,000 PI and one has committed 800 to a longer lockup while the other has committed 200, the two credits add 2,000 PI to wallet records. Once pending restrictions are cleared, the balances in this simplified example would make 200 and 800 PI available respectively. It would be wrong to describe either the 2,000 credit or the 1,000 available as an observed sale.
Release dates matter more than a single aggregate when many users have different lockups. A balance that becomes transferable over several months can reach venues in a different pattern from an equal balance released together. Timing can affect the market’s ability to absorb orders, while the total number of coins would be the same. Any analysis of potential selling pressure would need the distribution of releases as well as their sum.
The pending period also has a different purpose from a voluntary commitment. The project describes it as part of the migration process and a window for checks. A lockup applies to some of a user’s holdings under the conditions they accepted. Treating both restrictions as one duration would make it harder to tell which date a holder should look at.
The wait that begins when the coins arrive
Pi’s developer documentation describes a 14-day pending period in which migrated funds can appear in a wallet before they can be used. The project has described that period as time to check migration accuracy and security before it becomes irreversible.
An optional lockup can restrict some of the same balance for longer. Pi distinguishes lockups applied during migration from those a user makes directly in the wallet after acquiring transferable PI. An observer counting all balances credited in a particular week would therefore capture funds with different availability dates.
A migration cohort can be compared across three dates: when users saw the credits, when the pending period ended and when any applicable lockup expired. Exchange inflows around those dates would offer a better test of whether a cohort brought new supply to trading venues than the original migration count.
The stages from a credit to a transferable balance
A user can see three different records over the course of a migration. The app shows an estimate or breakdown of rewards. A migration creates a Mainnet wallet record. The wallet then shows whether funds are available for use, pending or locked under the rules attached to them.
Pi’s two-factor authentication update distinguishes the displayed transferable estimate from the final migration calculation. It also describes the pending period as an opportunity to check security and accuracy before migration is irreversible. A balance appearing on the ledger can therefore represent progress for a user while still being unavailable for immediate sale.
Take a simplified example of 1,000 PI credited during a migration. Suppose 600 are subject to a longer lockup and the other 400 become usable after the pending period. The ledger could show the full credit while the holder can transfer none during the pending period and only 400 immediately afterwards. The example illustrates the accounting stages and does not estimate the project’s average lockup rate.
Pre-migration and post-migration lockups also have different timing. Pi describes the first as a commitment applied as transferable rewards migrate, while the second can be made directly with assets already on Mainnet. A newly locked wallet balance can therefore come from someone who has held transferable PI for a while. Treating every lockup as evidence of a fresh migration would overstate the link between the two.
When an exchange enters the picture
A transferable balance can be sent to a venue only if that venue accepts deposits over Pi Mainnet for the relevant account. A market listing, a displayed price and an open deposit channel are three distinct checks.
A useful comparison would record the venue, jurisdiction, network selected, minimum deposit and deposit status at a specified time. A venue that displays a price while deposits are paused may still have buyers and sellers trading balances already there.
What a venue has to support before a sale is possible
A seller needs a wallet they control and a market that accepts the asset on the correct network. A trading page showing a PI pair does not by itself establish that the holder can deposit. Deposit availability can differ by venue, region and account. It can also change during operational maintenance.
The first practical check is the network the venue lists for deposits. The second is whether deposits are enabled for that account and whether the venue requires a memo or other reference to associate incoming funds with a customer. The third is the venue’s deposit minimum and any waiting period before funds become available to trade.
A holder can be eligible for migration, have control of the receiving wallet and still fail at this last stage. A venue may accept only customers in certain jurisdictions or require separate identification. It can also have an active trading market while customers trade balances already held there during a deposit pause. The displayed order book and deposit status are evidence of different capabilities.
A business verification list can help establish which companies Pi identifies as having completed its process. It is a separate check from verifying a specific venue’s support for deposits on the date of a story. A feature looking at available supply should treat each route as open only where the relevant venue’s own information supports that conclusion.
Deposits can resume before a market becomes deeper
An exchange can enable a deposit channel without adding buy orders. A venue’s custody team may be ready to receive PI while its market still has a narrow range of bids. The user’s ability to get funds onto the venue and the amount they can receive for a sale are separate questions.
The reverse can happen too. A venue can display active trading among users with balances already in custody while it limits fresh deposits. A market snapshot could show trades throughout a pause. Someone holding PI in a private wallet would still be unable to use that order book through the deposit route until the venue reopened it for their account.
The useful reporting check is to record the time, the market pair and the deposit network together. If an exchange reports a temporary restriction, its opening and closing dates help put later wallet activity in context. A surge in deposits after reopening could include PI that became available days earlier. The reopening might explain the timing without implying a fresh surge in migrations.
For an individual user, the exchange has to recognise the deposit in the correct account before a sale can happen. A memo requirement or minimum amount could affect that step. For a market observer, the relevant evidence would be deposits credited and orders filled. A wallet explorer can show a transfer to the venue’s infrastructure without establishing how that deposit was handled.
Why order book depth matters
A displayed price usually describes a recent trade or an available quote. A holder selling more than the quantity bid at that price may have to accept lower bids for the remainder.
For illustration, suppose 1,000 PI could be sold at eight cents and the next 1,000 only at seven cents. Selling both lots would return $150 before fees, equivalent to 7.5 cents per PI. The example illustrates price impact. It is not a snapshot of an actual Pi market.
The displayed price can conceal the cost of a sale
Pi’s market price is easiest to quote as a single number. The amount a holder could receive depends on which venue they can use, the size of the trade and the price and quantity offered by buyers. A market with a bid at eight cents can still return much less on a sale that exhausts the quantity offered at that price.
One way to compare venues is to specify a trade size before looking at their order books. For example, record the proceeds a seller could obtain for 500, 5,000 and 50,000 PI at a single observation time, then compare the implied average prices. Those are different questions from what price the last person received for a trade of unknown size.
The distinction matters when interpreting a migration wave. A small amount of newly available supply can move a shallow order book if it arrives quickly, while a much larger amount spread across several weeks may be easier to absorb. The useful variables are the timing of transfers and the available bids when holders try to execute, rather than the number of wallet credits in isolation.
Earlier coverage of PI near its recorded low discussed the difference between project activity and exchange demand. The migration question makes that distinction concrete. A holder who spends PI with a merchant, locks it again or keeps it in their wallet has used the new balance differently from someone who places a sell order.
What a trading-depth check could establish
Trading volume records transactions that already happened. The order book records bids and offers available at the moment it is observed. A busy session can still have thin bids after prices move, and a quiet session can have an order book that would absorb a modest sale without a large price change.
The comparison should state the order size in PI and measure how many bids it would use. For an example of the arithmetic, 2,000 PI sold in one order can receive a different average price from a 100 PI trade quoted at the same moment. The larger order may take the best bid and continue at lower prices. The result depends on the actual quantities buyers have posted.
That is also why one exchange’s price cannot stand for everyone’s experience. A venue may serve customers in one jurisdiction and exclude others. A seller may have access to only one of the markets included in an aggregate quote. The better comparison uses prices available to eligible accounts with open deposits, and explains any differences in the trading pair or currency used to quote them.
The observation still has a limit. Orders can change between the time a snapshot is taken and the time a deposit clears. A comparison gives readers an estimate of execution conditions at a stated time, while the trader’s fill record gives the amount actually received. Keeping those two measures distinct prevents a simulated sale from becoming a claim about money someone already obtained.
How to test the supply claim
A useful measure of selling pressure would distinguish the number of completed migrations from the amount immediately transferable. The next check would look for deposits to attributable exchange addresses, then compare them with volume and bid depth.
An exchange deposit is also not a sale. Some users may transfer PI for custody, while others may trade an existing exchange balance without creating a new deposit. Order book data and wallet movements answer related questions with different limits.
A migration and an exchange sale use different records
| Stage | Evidence | What the evidence establishes |
| Rewards accrued | App balance and eligibility breakdown | An estimate before migration |
| Wallet credited | Mainnet transaction and recipient | Coins appeared onchain |
| Pending period cleared | Wallet or ledger status | The pending restriction has ended |
| Lockup expired | Lockup status and release time | Funds can become transferable |
| Venue receives funds | Deposit record and venue credit | Funds are available on that venue |
| Sale executes | Filled order and settlement record | Quantity sold and proceeds received |
A useful study would start with a group of wallet credits on known dates and follow the same group. Measuring one week’s wallet credits and another week’s exchange volume can give a misleading comparison when the pending period places the relevant dates apart. The calendar needs to follow the coins, including the possibility that a single migration leaves different parts of a balance available at different times.
The same timing question matters when a venue reopens deposits. An increase in deposits immediately afterwards could include balances that became transferable earlier but had nowhere to go on that venue. The venue’s operational timeline helps distinguish newly available PI from PI already waiting in private wallets.
Any order-book comparison also needs to use prices and quantities from the same moment. A large reported daily volume can coexist with thin bids at a particular instant. For a user deciding whether a newly transferred balance could be sold, the relevant observation is the price available for their order size after the exchange credits the funds.
How a supply test could avoid counting the same coins twice
A wallet credit, an exchange deposit and a trade can all involve the same units of PI. Adding the three amounts would count one balance several times as it moves through the market. A useful dataset would instead follow distinct stages and retain the dates at which each became observable.
The first line would capture confirmed migration credits. The second would estimate what portion could become transferable after pending periods and lockups. The third would track movements to attributable exchange wallets. A final line could compare exchange volume and bid depth, without assuming every deposit became a sale.
Wallet labels create a limitation. A transfer to a known exchange deposit address is easier to classify than movement to an address that may serve several purposes. A transfer between exchange-controlled accounts can increase visible onchain activity without bringing fresh coins to the venue. Any estimate should describe how it distinguishes deposits from internal wallet activity.
Timing can offer a stronger test than totals alone. A cluster of deposits shortly after a well-defined release date would make the release worth investigating, especially if order books weakened at the same time. A steady migration count without corresponding changes in exchange inflows or bid depth would support a different reading. Both outcomes can be assessed without relying on a price forecast.
What the November summit could add
Pi’s developer updates ahead of the summit give holders a way to distinguish tools under development from services already available to use.
Pi’s first Ecosystem Summit is scheduled for 17–19 November. A demonstration can show how an application is supposed to work. Evidence of activity on Mainnet and recurring payments would help establish whether an application creates another reason for holders to use their balances.
That gives the summit a specific test for this story. Are developers showing a feature under development, opening a live service or reporting repeat activity from users?
What a summit announcement would have to show
The earlier feature on Pi’s reported Mainnet app count asked how many apps people actually use. A new release raises the same question about repeat payments.
The November summit preview identifies 17–19 November as the scheduled event. A live application that accepts PI from users on Mainnet would offer a concrete way to assess what some holders can do with their coins after migration. A test environment would demonstrate a different stage of development.
The useful details would be whether the application is accessible, what it charges in PI and whether customers return after the first use. A merchant might keep the coins, spend them elsewhere or convert them through a venue. Each route would matter differently for demand and exchange supply.
The summit and migration programme therefore offer two distinct dates to follow. One is when funds become available to a particular wallet. The other is when a service becomes available to use those funds. Pi’s published roadmap places first and second migrations ahead of a future periodic process, while the summit gives developers a separate date to show what is available on Mainnet.
How the summit could provide a different kind of evidence
Pi scheduled its first Ecosystem Summit for 17–19 November and described developer demonstrations, platform announcements and application showcases. The programme makes it possible to ask which applications a holder can use with a transferable Mainnet balance. That is a different demand question from whether a trading venue has open deposits.
A live service can establish what a holder is able to pay for. Repeat payments would provide stronger evidence about how often that option is used. An application demonstrated in a test environment would show a stage of development without giving a direct measure of Mainnet demand. The date and availability of the release would therefore matter more to this feature than a list of concepts shown on stage.
The most useful data would follow the same sequence for supply and use. Count completed credits, distinguish balances that can move and observe where transferable balances go. A wallet transfer to an exchange, a payment to a merchant and an optional new lockup would provide evidence of different choices. Pi’s roadmap explains how new credits can arrive, while its summit programme gives developers a date to show what users could do with those funds.
The point at which a balance can reach the market
Eligibility opens the way to migration. A transferable Mainnet balance and an open exchange deposit route can put those coins within reach of an order book. The project’s published rollout describes the first step and the wallet requirements attached to it.
Pi’s roadmap sets out when different categories of rewards become eligible to move. Its summit agenda covers the tools and applications that could use those balances once they arrive. For a holder, the practical test is whether their own funds are transferable and whether the service or exchange they intend to use can accept them.
What to Watch
- Completed migrations: The PI actually credited to Mainnet wallets, separated from balances or accounts eligible for a second migration.
- Transferable PI: The portion of each credit that can move once the pending period ends and any longer lockup expires.
- Exchange access: The venues accepting Pi Mainnet deposits for eligible accounts and the bids available once deposits are credited.
- Summit releases: The applications announced for 17–19 November that holders can use on Mainnet, distinguished from test demonstrations.
FAQs
What is a second migration?
A second migration lets an eligible Pioneer who has migrated once move another balance onto Mainnet. The amount depends on which accrued rewards qualify for transfer.
Can referral bonuses be included?
Pi says eligible referral bonuses can be included. The calculation takes account of referral team members’ verification status and can vary by mining session.
What does Pi require before migration eligibility?
Pi requires wallet two-factor authentication through Step 3 of the Mainnet Checklist. Completing that step addresses a prerequisite for migration eligibility.
Can all migrated PI be transferred immediately?
Pi describes a 14-day pending period after migration. An applicable lockup can keep some coins unavailable for longer, even while the credit appears in the wallet.
Does an exchange listing guarantee deposits are open?
A listing identifies a trading market. Holders still need to check whether the venue accepts deposits over Pi Mainnet for their account and whether deposits are open.
Does an exchange deposit prove a sale?
An attributable deposit can show coins reaching a venue. A completed trade requires separate evidence, since a user can leave the coins in their exchange balance.
Why do bids matter?
A seller can only execute at a price while buyers are offering enough quantity at that level. A larger order may take several bids and receive a lower average price.
What would help establish market impact?
Track when migrated coins become transferable, then compare attributable exchange deposits and the bids available at those venues. Together those measures can help test whether new credits are reaching the market. This is educational analysis, not investment advice.
Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures are based on sources available at the time of writing and may change with new disclosures. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is current as of 6 November 2026. Legal questions should be discussed with qualified counsel.
