> For the complete documentation index, see [llms.txt](https://pixonaorg.gitbook.io/pixonaorg-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://pixonaorg.gitbook.io/pixonaorg-docs/evolution-protocol/genesis-evolution.md). # Genesis Evolution ## Genesis Evolution ### The Original Path to PIXONA V2 **Genesis Evolution** is one of the two official paths for creating a PIXONA Onchain (V2). It allows holders to use their **PIXONA Genesis (V1)** NFTs as the evolution asset required to access a V2 slot. The concept is simple: > **Burn Genesis → Unlock Evolution → Create V2** Every Genesis NFT used in the process is permanently removed from circulation. *** ## How Genesis Evolution Works The process is designed to turn existing Genesis NFTs into access to the next generation of PIXONA. ``` PIXONA Genesis (V1) ↓ Select Eligible NFTs ↓ Submit Required V1 ↓ Permanent Burn ↓ Unlock V2 Evolution ↓ Access V2 Designer ↓ Create PIXONA V2 ↓ Fully Onchain ``` Once the required Genesis NFTs are successfully burned, the holder can proceed with the corresponding V2 evolution. The exact requirements will depend on the V2 batch being accessed. *** ## Why Burn V1? The Genesis Evolution mechanism creates a direct connection between the original PIXONA collection and V2. Instead of creating V2 as a completely separate collection, Genesis holders can **evolve** their existing NFTs into the next generation. This creates a natural transition: **V1 → Evolution → V2** At the same time, every Genesis NFT used for evolution permanently reduces the circulating V1 supply. This makes the migration an actual transformation of the ecosystem rather than simply launching another collection beside V1. *** ## Evolution Requirements The number of Genesis NFTs required depends on the V2 batch. The protocol is designed so that access to higher rarity batches requires a greater Genesis sacrifice. The final requirements will be enforced by the Evolution Protocol and will correspond to the available V2 batch. The general structure is: | V2 Batch | Rarity | Genesis Requirement | | -------- | --------- | ------------------- | | Batch 1 | Common | Protocol-defined | | Batch 2 | Rare | Protocol-defined | | Batch 3 | Epic | Protocol-defined | | Batch 4 | Legendary | Protocol-defined | | Batch 5 | 1/1 | Protocol-defined | The specific requirements will be published before the corresponding evolution stage becomes available. *** ## One Evolution Creates One V2 Genesis Evolution follows one fundamental rule: ### 1 Evolution = 1 V2 The number of Genesis NFTs required for an evolution does not change the number of V2 NFTs created. Whether the evolution requires one Genesis NFT or multiple Genesis NFTs: **One completed evolution creates one V2.** This ensures the V2 supply remains controlled. *** ## Permanent Burning Once Genesis NFTs are used for an evolution, they are permanently burned. They cannot be: * Recovered * Reused * Transferred * Returned * Used for another evolution The burn is final. This means holders should carefully review the evolution requirements before confirming a transaction. *** ## Genesis Supply Reduction Genesis Evolution contributes to the long-term reduction of the V1 supply. The broader migration begins after the required pre-migration buyback-and-burn stage has been completed. The initial migration target is: **8,000 Genesis NFTs** After reaching this stage, the project transitions away from the treasury-funded V1 buyback-and-burn process and begins the V2 migration through the Evolution Protocol. From there, Genesis NFTs are primarily reduced through actual holder participation in the Evolution Protocol. *** ## Genesis Evolution vs. MUTAGEN Genesis Evolution is not the only way to access V2. Holders can also use MUTAGEN. #### Genesis Evolution **Burn V1 → Create V2** #### MUTAGEN Evolution **Consume MUTAGEN → Preserve V1 → Create V2** This gives holders a choice based on the assets they own and how they want to participate in the migration. Both paths: * Create one V2. * Consume one evolution asset. * Follow the V2 batch system. * Respect the 3,333 V2 supply cap. *** ## The V2 Creation Process After completing the required Genesis evolution, the holder moves into the V2 creation process. The general flow is: **1. Complete Genesis Evolution** ↓ **2. Unlock V2 Designer** ↓ **3. Select Available Traits** ↓ **4. Customize Your PIXONA** ↓ **5. Finalize Character** ↓ **6. Deploy Fully Onchain** The result is a new PIXONA V2 that becomes part of the fully onchain collection. *** ## Protecting the 3,333 Supply The Genesis Evolution system is directly connected to the permanent V2 supply cap. V2 has a maximum supply of: ### 3,333 Every Genesis evolution consumes exactly one available V2 slot. Once all 3,333 slots have been filled, no additional V2 evolution can occur. This means Genesis Evolution can reduce V1 supply, but it can never cause V2 to exceed its fixed maximum. *** ## Why Genesis Evolution Matters Genesis Evolution creates a meaningful connection between the two generations of PIXONA. V1 becomes more than an older collection. It becomes the foundation from which V2 evolves. Every Genesis NFT used in the process represents a piece of the original collection being sacrificed to create something new. That creates a permanent connection between the history of PIXONA and its onchain future. **V1 is the foundation.** **The burn is the sacrifice.** **V2 is the evolution.** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://pixonaorg.gitbook.io/pixonaorg-docs/evolution-protocol/genesis-evolution.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.