Stargaze originally ran its own proof-of-stake blockchain, with node software maintained in the Public Awesome repository. That repository identifies the chain as the base layer for the NFT marketplace and is now archived. The archive date is a software-maintenance fact, not by itself the exact last-block time. Separating the software, validator network and marketplace makes the later migration understandable: an application can keep serving creators after its original consensus system is retired.

The current migration documentation describes a move from a standalone Stargaze chain to an application on the Cosmos Hub. It explicitly discontinues the separate validator and staking system. Promises of more users, stronger security and better liquidity explain the project's rationale, but they are not measurements of the migration's commercial success. The important architectural change is the location where application transactions are executed and settled, rather than a cosmetic change to the website.

Shane Vitarana's March 2021 Bellatrix testnet announcement asked validators to perform transfers, upgrades, curation actions and IBC tests. Rewards depended on concrete tasks and operational participation, with additional recognition for documentation and support. This preserves an early conception that was broader than buying pictures: Stargaze was testing social curation, stakeholder participation and cross-chain communication. The testnet timetable was a rehearsal plan, not proof that the later marketplace already existed.

The testnet instructions also screened newly created GitHub accounts and preferred operators with an established validation record. Those were practical measures against duplicate identities, accompanied by acknowledged discretion. They illustrate the tension between an open community ideal and the need to choose participants in an incentivized launch. A points schedule can encourage useful work, but it should not be mistaken for a neutral census of every person interested in the project.

A January 2022 community announcement described an airdrop whose initial portions could be claimed through staking and voting, while later portions awaited NFT functionality. The record helps explain why token holders followed the marketplace's launch so closely. They were learning about a new creative platform while also trying to complete distribution tasks. These expired instructions belong to the chain's early history and do not establish current eligibility or a present offer of free tokens.

The March 2022 launch discussion contains a revealing beginner question. valon08 could not tell whether the minting requirement meant creating a collection or buying from a creator. ThunderTM answered from a personal purchase, while CosmosTrex distinguished primary minting from the secondary marketplace. Their exchange captures onboarding as a social activity: community members translated unfamiliar terms into actions for one another. It also shows why a launchpad release and a trading-market release should have separate histories.

In January 2024, krirby praised the interface and described minting a Kuji Kid. Other respondents valued artists, responsive engineers and the familiarity of recurring collections. AnOrdinaryChullo was less satisfied with the quality of available work and criticized the prominence of generated art. This is a documented disagreement about taste and curation, not evidence that all collectors shared a single investment thesis. A usable marketplace could attract loyalty without making every collection attractive or valuable.

The current CW721 reference separates ownership, metadata, approvals and transfers. A token can have an owner while permitting another address to act as an approved operator; revoking an approval is a different action from transferring the token. The reference also exposes a collection's royalty configuration and metadata queries. These distinctions are useful when reading a wallet prompt: recognizing a familiar collection name does not explain which permission a transaction is granting.

Studio 2.0 describes a collection-building workflow with profile-picture drops, open editions and individual artworks. Creators can rehearse contract operations on a test network before publishing on the Hub. Its documentation makes an important exception to the idea of a free rehearsal: media uploads use real storage and carry a cost even when the associated contract experiment is on testnet. The same uploaded files can then be reused during publication, rather than paid for a second time.

Stargaze's storage guide distinguishes the ownership record from the image and metadata to which it points. Studio uses Arweave uploads and quotes their cost in ATOM, avoiding a separate storage-token workflow for the creator. The guide presents permanence as its design goal. This account does not repeat its absolute assurance that files can never become unavailable: a token record, an external storage network and a gateway displaying the file remain different components to examine.

The marketplace fee page lists a platform fee, creator royalty and network gas as separate costs. Its numerical example contains an arithmetic error, so the example should not be used as a reliable proceeds calculator. More broadly, royalty settings do not establish demand for an artwork or income for its creator. The documented fee structure tells a seller which deductions to inspect; an actual transaction and current interface quote determine the amount paid in a particular sale.

Multi-token payment documentation describes selecting a purchase currency and using a routing interface to swap when necessary. It still requires ATOM for network fees. A listing currency is therefore not necessarily the same thing as the gas asset or the asset ultimately received by a seller. Exchange rates, liquidity and slippage can affect an apparently simple purchase. Support for a ticker should not be interpreted as equivalence among every bridged asset that happens to display it.

Migrated STARS has a different role from the old chain's staking asset. The official claim guide says holders of eligible liquid and staked balances can obtain Hub tokens and explicitly removes standalone-chain staking and governance utility. It also distinguishes liquidity-pool positions from ordinary wallet balances. Consequently, an old staking tutorial is not a description of today's token economics, and a pool receipt is not automatically the same object as a directly held migration allocation.

Ruwan's November 2025 proposal argued that maintaining a dedicated chain imposed costs once the Cosmos Hub supported the required application environment. It requested milestone and continuing-development funding, with separate activity incentives, and proposed moving collections and the application suite. These were terms offered to governance, not evidence of completed work. The argument recast success as preserving creators and products on shared infrastructure rather than preserving a separate chain at any cost.

The funding proposal also described a multisig overseeing disbursements and allowed future payments to be paused if obligations were unmet. Those details matter as much as the cultural pitch: consolidation involved accountability, a payment schedule and people deciding whether milestones had been satisfied. The proposal's claimed activity totals and expected economic benefits are the author's case for support. They should not be treated as independently audited usage or as a guaranteed increase in ATOM's value.

The NFT migration guide distinguishes automatically migrated collections from collections requiring a claim. Its instructions specifically exclude partially minted collections from automatic migration and explain that large holdings may be processed in batches. This is more precise than saying every NFT instantly moved. The relevant facts for a holder are the original account, collection status and migration record. A temporary delay in the interface is not, by itself, proof that the underlying token was lost.

DAO treasuries and interchain NFTs created additional cases. The special-case guide says old DAO contract addresses could not simply be reconstructed on the Hub, while NFTs staked by individuals were treated differently. Collections already transferred through ICS-721 required coordination with their home chains; some creators chose a different destination. These instructions explain why a universal claim about all collections would be misleading. Network migration required both software and decisions by the people responsible for each collection.

The guide also distinguishes a recreatable multisig from an inaccessible private-key account. Migration does not produce a general power to recover keys, adjudicate every ownership dispute or override the snapshot. This is an important limit on the idea of continuity: keeping an artistic community together does not mean every original custody arrangement can be copied mechanically. A collector should follow the record for the particular collection and account type rather than rely on a generic social-media migration checklist.

Proposal 351, titled Event Horizon, was a software-upgrade proposal to trigger shutdown at a specified block height. Its explorer record shows that voting ended with passage on June 13, 2026, and its text targeted June 15. This was different from an earlier non-binding signal of intent. Keeping the vote and the planned execution distinct avoids turning every discussion into an accomplished protocol change. The historical upgrade is evidence that closure was an explicit governance action.

A June 18 registry merge then added the migrated Hub token and deprecated the original STARS entries. Maintainer review required a distinct legacy label and removal of the old asset's market identifier, reducing ambiguity between two denominations. This is concrete evidence of migration in infrastructure used by wallets and other services. It does not independently prove that every individual holder claimed or that every exchange adopted the correct representation immediately.

Stargaze Names now identify Hub wallets through readable handles and remain transferable CW721 NFTs. The current guide describes registration terms rather than permanent ownership and says migrated names received a one-year lease beginning in August 2026. Transferring a name does not reset its expiry. That changes the practical meaning of collecting a name: a purchaser acquires the remaining registration term and associated control, not an everlasting right to the word.

Creative access also exists alongside platform rules. The creator guidelines reject impersonation, stolen work, spam and other prohibited material, and describe reporting and verification. These rules concern the service through which collections are discovered; they should not be confused with a universal ability to erase blockchain records. The distinction helps explain why an open contract platform can still have moderated interfaces, disputed visibility and expectations that creators describe their work honestly.

Jcook_14's March 2026 discussion treated bringing Stargaze activity to the Hub as a possible answer to ecosystem fragmentation. MaximumStudent1839 countered that adding a marketplace alone would not distinguish the Hub from other struggling ecosystems. Both comments concerned the value of consolidation, but they drew opposite conclusions. The exchange preserves an investor argument and its rebuttal without converting either participant's claims about users, volumes or future prices into facts.

A later AtlasStaking post used Stargaze NFTs as a proposed record of a staking rebate. moss_throwawayx challenged whether the collectible offered meaningful utility, and AtlasStaking responded that it represented a bonus. Another user reported an eligibility problem. This smaller episode makes the issue concrete: an NFT can reference a service or reward, but the practical benefit depends on eligibility, delivery and the responsible party, not merely the token's presence in a wallet.