On October 31, MyNearWallet will stop operating. The migration notice circulating through NEAR's official channels is short. It lists steps. It lists a deadline. It lists an FAQ. What it does not list is a reason.
The most informative line in the entire announcement is not about the deadline. It is a technical constraint buried in the deposit instructions: the new account's deposit address is single-use and cannot be reused for a second transfer to the same destination. In a self-custody wallet, a user owns a fixed address. Addresses do not expire after one deposit. That single design decision tells me more about what NEAR is actually doing than the eleven sentences of migration guidance combined.
This is not a wallet retirement. It is a trust-model migration โ and the market is reading it as routine maintenance.
Context: what is actually being retired
MyNearWallet has served as one of NEAR's primary wallet interfaces since the protocol's early mainnet years. It is a conventional externally owned account (EOA) wallet. The user generates a seed phrase, holds the private key, and signs transactions locally. The trust model is familiar and, more importantly, verifiable. Control over assets is a function of a single cryptographic secret that never leaves the user's possession.
NEAR Foundation has directed all users to migrate to a new official account before the October 31 cutoff. The new account ships with three advertised capabilities. It can pay for transactions across 30-plus chains. It defaults to privacy. It is controlled by a passkey rather than a seed phrase.
On its face, this is an operational notice. Read against NEAR's stated strategic direction, it is something else.
Since 2024, NEAR has positioned itself less as a single Layer 1 and more as a chain abstraction hub. The pitch is that users should never need to know which chain an asset lives on. A unified account handles the routing. The technical substrate for that pitch is Chain Signatures โ a threshold MPC system that lets a single NEAR account produce valid signatures for addresses on other chains. Combined with an intents layer, where users declare a desired outcome and solvers compete to execute it, this is the architecture NEAR has been marketing for two years.
The new account's three features map onto that architecture almost exactly. Thirty-plus chains implies cross-chain signing. Passkey control implies WebAuthn-based key management rather than BIP-39 mnemonics. A one-time deposit address implies a solver or custodial entry point rather than direct user-to-contract settlement.
The shutdown of MyNearWallet, then, is not the closure of a product. It is the retirement of a trust model. And the announcement never says so.
Core: the systematic teardown
The one-time address is the load-bearing signal
In an EOA wallet, the flow is trivial to audit. The user controls address X. Funds arrive at X. The user signs from X. There is no intermediary, no per-transaction state, and no ambiguity about who holds the keys.
A single-use deposit address breaks that model. It implies the deposit path routes through a system that assigns fresh addresses โ a pattern that appears almost exclusively in custodial or solver-mediated designs. Under this model, the flow becomes: user to system-assigned address, then solver or aggregator, then the user's actual account. Each arrow is a new counterparty and a new failure point.
I have seen this pattern before. In my 2022 audit of the Terra/Luna reserve mechanics, the fatal finding was not a smart contract bug. It was that 40% of the backing assets sat in illiquid lending positions with unknown counterparties. The protocol's documentation described a simple, verifiable collateral pool. The on-chain reality described a chain of intermediaries. The gap between the documentation and the flow was the risk.
NEAR's one-time address is not Terra's illiquid collateral. The scale and the intent are different. But the structural signature is identical: the user-facing description is simpler than the actual fund path. When the documented flow and the on-chain flow diverge, the divergence is where the risk lives. I will not claim the new NEAR account is custodial. I will claim that the announcement does not let a user determine whether it is.
Passkey is not a neutral upgrade
The announcement is explicit that NEAR Foundation, MyNearWallet, and support staff will never ask for a seed phrase, recovery phrase, or private key. This is framed as an anti-phishing measure. It is. It is also a description of the new account's key architecture.
A passkey-based account does not have a seed phrase to ask for. Passkeys are WebAuthn credentials. The private key material is typically held in a secure enclave on the user's device and, critically, synchronized through the platform's cloud keychain โ iCloud Keychain or Google Password Manager. Recovery is not a function of a 24-word backup written on paper. It is a function of the platform account that syncs the passkey.
This matters for one specific reason: cold backup. A seed phrase can be written down, stored offline, and used to restore an account on any compatible device, in any jurisdiction, with no dependency on a third party. A passkey synced through iCloud cannot be cold-backed-up in the same way. The user's ability to restore access is contingent on continued access to the platform ecosystem that holds the credential.
I do not claim this makes the new account custodial. The distinction between self-custody via hardware and self-custody via cloud-synced passkey is real but subtle. What I claim is that the locus of control has moved. The user still controls the credential. But the credential's recoverability now depends on a third party's infrastructure โ Apple's or Google's keychain. That is a genuine reduction in the trust-minimized posture of the account, and it is not disclosed as such.
This is where the anti-phishing warning becomes interesting. Telling users that no one will ask for their seed phrase is correct advice for a seed-phrase wallet. Applied to a passkey account, it is also a quiet acknowledgment that the recovery model has changed. The user is being trained to protect a secret that the new architecture may not even use.
The migration window is the real attack surface
Every wallet migration is a phishing harvest. Attackers do not need to break cryptography when they can stand up a convincing migrate-now page and wait. NEAR Foundation's decision to publish an explicit warning about seed phrase requests is evidence that the team knows this. The warning is necessary. It is also an admission that the migration window is dangerous.
The problem is compounded by the deadline. Forced migrations with hard cutoffs produce two behaviors, and both are bad. Early movers migrate carefully and are fine. Late movers, facing a countdown, migrate under time pressure and make errors. The October 31 deadline converts a security process into a race.
The riskiest element is the one-time address itself. Users who are unfamiliar with the concept will attempt to reuse a deposit address. In a system where the address is single-use by design, reuse may mean the funds do not arrive. The official guidance recommends a small test transaction first. That is good advice, and it is also an admission that the process is not intuitive. A process that requires a test transaction is a process with a failure mode.
There is a second-order risk the announcement does not address. If a user misses the deadline, the old wallet stops operating. The assets remain on-chain. They do not disappear. But the access path is obstructed. The result is an asset that is visible and not movable. I have audited enough post-mortems to know that visible-but-not-movable is functionally equivalent to loss for most users.
Downstream integration is a hidden cost
A wallet is not just a user interface. It is an integration surface. Every NEAR dApp that connects to wallets through the standard wallet selector must be updated to recognize the new account. Until they are, users cannot complete transactions.
This is a forced, ecosystem-wide integration refresh with a hard deadline. The cost is borne by every NEAR dApp team, and it is not visible in the shutdown announcement. The announcement addresses users. It does not address the dozens of teams who must ship code by the same date.
I ran into the same dynamic in the 2020 DeFi stress test. The protocol's whitepaper described a clean solvency model. My Python simulation modeled 500 concurrent liquidations under volatility and found a 12% collateral shortfall. My superiors called it a theoretical edge case. Two weeks later, a modest volatility spike validated the model. The lesson was not that the protocol was fraudulent. It was that the documented system and the stressed system behave differently, and only the second one matters.
NEAR's migration will be documented as smooth. The question is how it behaves under stress โ at the deadline, with late movers, phishing pages live, and dApps still mid-integration.
Opacity is the recurring theme
I keep returning to the missing reason. The announcement does not say why MyNearWallet is closing. Cost is a plausible explanation. Strategic consolidation is a plausible explanation. A security incident or a compliance pressure is also a plausible explanation, and it is the one that would change the risk assessment entirely.
A wallet shutdown that omits its cause forces every downstream reader to guess. When I audited the 2017 GlobalCoin ICO, the tell was not the whitepaper's consensus section. It was the developer biographies. Three of the named technical staff were fictitious identities tied to previous failed projects. The document presented certainty. The evidence presented absence. Opacity in a system that markets itself as transparent is not a minor flaw. It is the primary indicator of a deeper problem.
NEAR is not GlobalCoin. But the discipline is the same. A migration notice that cannot answer why and to-what is a notice written for operational compliance, not for user comprehension.
Contrarian: what the bulls get right
The bullish reading is not wrong on everything, and pretending otherwise would be dishonest.
Chain abstraction addresses a real problem. Users lose funds to bridge errors and wrong-chain sends constantly. A unified account that handles routing is a legitimate improvement over asking users to manage five networks manually. NEAR is not inventing a need. It is responding to one.
Passkeys solve a real problem too. Seed phrase mismanagement is one of the largest categories of permanent asset loss in crypto. A user who loses a paper backup loses everything. A user who loses a device but retains cloud access can recover. For the median user โ non-technical, single-device, unlikely to maintain offline backups โ passkeys may be a net security improvement, not a downgrade.
And the migration itself is defensible. Maintaining two account models indefinitely is technical debt. Consolidating onto one architecture is what a serious engineering organization does. The alternative โ supporting the old model forever โ carries its own costs, and those costs compound.
The blind spot in the bullish reading is not that these claims are false. It is that the bullish reading assumes the new model is strictly better. It is not strictly better. It is differently risky. Passkeys trade cold-backup independence for recovery convenience. Chain abstraction trades direct settlement for solver intermediation. One-time deposit addresses trade simplicity for intermediation. Those are real trades, and the announcement does not name them.
A user can accept the trade. A user cannot accept a trade they were never told they were making. That is the specific gap between a defensible engineering decision and a disclosed one.
Takeaway
The question to ask before October 31 is not how to migrate. It is what you are migrating to, and what you are giving up. Determine whether the new account lets you export a key. Determine whether the deposit path is solver-mediated or direct. Determine what happens to your recovery if you lose platform access. The announcement answers none of these. That is the finding.
A wallet that cannot be cold-backed-up is not the same wallet, even if it holds the same assets. NEAR has not told users which one they are getting. Until the architecture is disclosed and the cause of the shutdown is stated, treat the migration as an open audit finding, not a finished task.