The network documentation explicitly classifies Moonriver as a mainnet on Kusama with MOVR, while Moonbase Alpha is a separate testnet using DEV. This distinction explains why experimentation on Moonriver carried real financial consequences. Its applications and assets were not disposable test balances. Moonriver's Ethereum chain identifier also differed from Moonbeam's. Sharing a codebase and development team did not merge the ledgers, token balances or relay-chain security relationships of the two deployments.

The July 7, 2026 announcement changed that setting. MOVR was to move one-for-one to an ERC-20 on Base through a route that first represented it as xcMOVR on Moonbeam and then crossed the migration bridge. The notice warned about positions left in old applications and set a July 31 deadline. This is historical guidance, not a claim that the portal remains available. A token's new representation does not automatically move the applications or the economic purpose that originally gave it utility.

The May 2021 crowdloan plan allocated three million MOVR to contributors supporting Moonriver's Kusama auction bid. The Foundation framed broad participation as part of the network's identity. A crowdloan contribution, its temporary lock and the resulting MOVR reward were different assets and obligations, not a simple purchase of ownership in a company. The distribution strategy helps explain why early participants felt personally invested in Moonriver's future, while saying nothing by itself about whether their later market returns would match those expectations.

The Foundation's later lease announcement dates full public launch to August 26, 2021 and distinguishes that milestone from earlier block production. It also records the January 2023 acquisition of a third consecutive Kusama slot lease. Continuing a parachain required concrete resource commitments, not just an initial launch celebration. These dated records explain the original operating history. Their descriptions of integrated projects or connected assets are snapshots from that period and should not be treated as a current list of functioning services after the 2026 transition.

The April 2021 Nimbus and staking-pallet announcement describes how the system selected eligible block producers and limited production attempts. Stake determined entry to an active candidate set, while additional selection rules reduced the advantage of simply having the fastest connection. The stated goal was broader participation and less concentrated control over ordering transactions. These are properties of the proposed and developed mechanism, not proof that ownership among every later active operator was independent or evenly distributed.

The staking guide explains delegation as support for a collator candidate and separates scheduling an exit from executing it after the required delay. That separation became especially consequential when a migration had a deadline. A displayed balance could be economically owned by the user while not yet freely transferable. Historical staking documentation also makes rewards conditional on operator and network circumstances. It should not be presented as an offer of continuing Moonriver staking returns after the original chain's wind-down.

The account-balance documentation explains that Ethereum and Substrate interfaces read the same underlying account storage, even though they expose different operations. An Ethereum-style wallet therefore showed only one view of a richer runtime. Native staking or governance restrictions could matter to a balance even when an application focused on EVM calls. Interpreting historical accounts requires both views. A wallet failing to show an old position is not, by itself, proof that the position was transferred, destroyed or successfully migrated to another network.

The security documentation warns that precompiles can reach native functionality outside an ordinary Solidity call path. Assumptions that appear sufficient on Ethereum can therefore fail when a contract allows loosely controlled calls into those interfaces. This is a design-review issue rather than evidence that every Moonriver application was exploitable. The broader point is that reusing familiar tools reduces development friction without eliminating the need to understand the host runtime's permissions, account behavior and special contract interfaces.

The XC-20 transfer guide describes reserve-based transfers: an asset remains under the relevant sovereign-account arrangement while another chain records a representation. That helps explain why Moonriver's Ethereum-style token interfaces could expose Kusama-connected assets. It does not justify treating every bridge or wrapped token as the same security system. Identifying the reserve, destination asset and accepted message path remains necessary. The historical mechanism also does not prove that a particular channel stayed open after either participating chain changed its operating status.

The XCM integration template asked other networks to disclose administrative control, sudo status, audits and testing before an integration proposal. Those questions acknowledge that connectivity alone is not a security guarantee. A technically valid route can join systems with different upgrade authorities or operational risks. The template is evidence of the information the integration process sought, not proof that every partner answered perfectly or that every integration stayed safe. It is a useful record of how the ecosystem attempted to make cross-chain trust assumptions visible.

Dwellir's 2026 request itemized the costs of public archival RPC services and described support across Moonbeam, Moonriver and Moonbase. Later replies discussed payout problems and identified July's payment as the final one. This documents the practical work behind a public endpoint: servers, historical data, monitoring and operator time. A previously published RPC URL or a grant for an earlier quarter is not evidence that the endpoint still supports new activity. Service commitments have dates, budgets and dependencies on the network they serve.

The node-operations guide distinguishes a parachain node from a simple standalone execution service: its software also tracks the relay chain and maintains the communication needed between the two. That architecture is useful for understanding historical synchronization and operational costs. The guide's installation instructions predate the shutdown and cannot establish current peer availability. Running the right binary is not sufficient if the network it expects has stopped providing peers and block production.

Documentation may remain online after the operational setting it describes has changed.

The community-delegate guidelines required a profile, a voting report, reasons for decisions and disclosure of conflicts. They also expected participation in most proposals and advance notice before a delegate stopped serving. These rules describe a norm of accountable representation rather than a claim that every participant always complied. They make the surviving forum unusually useful as historical evidence: the reader can compare a technical proposal with a delegate's explanation instead of inferring community motivation from promotional material alone.

SvPatrik's Moonriver delegation report records support for runtime fixes, later migration measures and the orbiter workaround. The reasons emphasize timely maintenance, security and an orderly exit. The report is evidence of that delegate's decisions, not an independent audit of each upgrade or a referendum result for the whole network. It also shows how a participant's practical priorities changed: preserving the chain's operation was followed by helping holders leave it. Community commitment can attach to protecting users even when the original operating model ends.

The April 2024 call for input proposed using the parachain bond reserve for a concentrated-liquidity exchange and activity incentives. Participants connected this to rebuilding after problems with bridge availability, while disagreeing about which teams should receive support. In May, the committee announced its selection of Beamswap. That choice establishes a grant decision, not that all promised usage followed. The discussion records both enthusiasm for a revival and objections from people who wanted a broader or different allocation of scarce ecosystem funds.

The June MR58 request translated the strategy into allocations for development and liquidity in Beamswap and Moonwell, with staged development payments tied to milestones. Liquidity incentives and software delivery were separate parts of the budget. Subsidizing deposits can make trading or lending more usable, but the existence of a grant does not establish demand once those subsidies end. The milestone structure at least made parts of the proposed delivery inspectable, rather than treating a broad promise to revive an ecosystem as a single completed outcome.

Beamswap argued that Moonriver needed a liquid native trading venue and better access to supported external assets. In the same discussion, legendnodes objected to dismissing Moonriver as merely a testnet and wanted its independent role recognized. That is a documented community identity, not proof that one exchange design could restore the network's fortunes. The proposal's projected efficiency and usage claims belong to the applicant's case for funding and are not repeated here as independently established results.

Enosys offered a different angle: connecting Moonriver with Songbird as part of a wider canary-network development environment. Its proposal combined infrastructure, DeFi and a bridge, while Foundation reviewers questioned its fit with the chosen Axelar direction and its commitment to Moonriver. This was a disagreement about strategic alignment as well as features. The proposal is useful evidence of an alternative path supporters imagined; it is not proof that the proposed cross-canary system was subsequently built or adopted on Moonriver.

Solarbeam's 2024 proposal sought funding for improved exchange functionality and additional products. TheOyster supported better trading infrastructure but questioned whether a perpetuals venue had enough real demand to remain sustainable. The team replied that existing users wanted more capabilities. This exchange puts the user-demand problem in plain view: an application can be technically feasible and frequently requested without generating enough sustained use to support its costs. Neither side's forum argument establishes the final economic outcome.

Derek Fitzgerald-Poe's 2025 monetary proposal worried that low fee activity could leave burns too small to offset issuance. It suggested adjusting emissions and considering additional burn mechanisms. Those suggestions record an investor's scarcity thesis, not an enacted policy or a reliable explanation of MOVR's price. Their historical setting also matters: they addressed the old parachain's incentives. A later token migration requires a new account of utility and supply mechanics rather than mechanically carrying over a desired reform from the previous network.

The June 2026 treasury thread requested transfer of Moonriver's remaining treasury balance to the Foundation, arguing that the expected shift of infrastructure costs to community treasury governance had not occurred. A council reply records execution and payout blocks on June 19. The discussion also asked who controlled the receiving wallet; the response described Foundation custody without public operational key details.

This is a concrete transition in accountability, not merely an accounting rearrangement: future spending would rely on institutional management and reporting rather than the previous on-chain treasury process.

The July 17 orbiter proposal identified a specific exit bug: an operator alone in its orbiter pool could not leave. The proposed workaround set pool size to zero. This technical edge case shows why a deadline-driven network migration involves more than an uncomplicated token-transfer button. Different classes of participants can face different locks and runtime conditions. The proposal documents the discovered issue and intended fix; a forum post alone does not establish that every affected account completed its exit successfully.

In August 2026, a MOVR holder reported that their former staking workflow no longer showed the expected coins. SvPatrik directed the user to a case-by-case late-claim process and emphasized that private keys and seed phrases should never be shared. The thread does not record a completed recovery. It is evidence of a support problem and the response offered at that time, not a promise that a claim window is still open or that every old position has a guaranteed remedy.

A September 23 node operator reported that Kusama synchronized but their Moonriver node could find no peers. On September 27, SvPatrik replied that Moonriver had shut down after the Base migration. This dated operational discussion supports treating old node and staking instructions as historical. It remains an attributed report rather than this article's own audit of every archive endpoint. Preserving Moonriver's record now means keeping its real applications, experiments, disputes and participant experiences visible without mislabeling it as an unchanged active parachain.