GAL (migrated to Gravity – G)

GAL migrated to G: How Galxe’s credential platform connects to Gravity

GAL is the legacy token of Galxe, whose current token is Gravity’s G. The project combines an onchain engagement platform, credential infrastructure, privacy-oriented identity tools, and an EVM-compatible Layer 1. The main questions for users are no longer limited to token utility: they also include migration status, bridge dependencies, governance control, and the degree to which Galxe’s services remain dependent on its operating team.

From Project Galaxy to Galxe and Gravity

Galxe began as a credential and community-engagement platform, but its current documentation describes a broader product suite spanning Quest, Passport, Score, Compass, Alva, and Gravity. Quest is designed for reward-based campaigns and community activity, while the identity products organize credentials and verification around users’ onchain and offchain attributes. Gravity is the blockchain layer intended to provide the ecosystem with its own execution environment and native token.

The asset listed as GAL is therefore a legacy identity. In July 2024, Galxe announced that proposals GP-25 and GP-30 approved the migration of GAL to Gravity’s G. The stated objective was to use one token across the Galxe application ecosystem and Gravity network. The migration was announced at a 1:60 ratio, meaning one GAL was exchanged for 60 G, while the original GAL remained a separate legacy token if not migrated.

What the Galxe platform does

Galxe Quest lets projects define campaigns around user actions, including wallet activity, token or NFT ownership, social information, and data supplied through APIs or other verification systems. Its credential documentation shows that eligibility can be checked through contract queries, REST or GraphQL endpoints, spreadsheets, CSV files, or custom APIs. This makes Galxe closer to a campaign and verification platform than to a standalone consumer blockchain.

The practical architecture separates a credential holder, issuer, verifier, and credential-type designer. Galxe’s identity documentation describes smart contracts for onchain credential management alongside SDKs and offchain authentication tools. Credentials may be revocable, selectively disclosed, or represented through soulbound tokens and zero-knowledge-oriented verification flows. These mechanisms are intended to let an application verify a condition without necessarily receiving a user’s entire underlying profile, although the quality of the result still depends on the issuer, data source, and verification design.

Gravity’s role and technical dependencies

Gravity is presented as an EVM-compatible Layer 1 built around a pipelined architecture and AptosBFT-derived consensus components. The project’s open-source Gravity SDK describes separation between transaction ordering, execution, and commitment, while the Gravity core-contract repository organizes staking, validator management, governance, oracle functions, epoch handling, and consensus coordination into layered modules. These repositories show the intended system design, but published performance claims should not be treated as independent evidence of production throughput under real workloads.

Gravity L1 Mainnet was announced on July 21, 2026. Galxe says Gravity Alpha Mainnet will remain available until November 1, 2026, after which the Alpha environment is scheduled for deprecation and assets left there may no longer be transferable. The transition creates an operational dependency for users who hold G on the older network, use Alpha-based applications, or still have tokens in the former staking system.

What G does after the migration

G is intended to serve three broad roles. It is the native gas token for Gravity transactions, a governance and staking asset, and a payment or incentive token within Galxe products. The project’s migration announcement also identifies G as an ERC-20 token on Ethereum and BNB Chain, with an announced contract address of 0x9C7BEBa8F6eF6643aBd725e45a4E8387eF260649. The Ethereum contract source inspected on Etherscan includes pausing, burning, permit approvals, and limited minter-management functions for cross-chain operation.

The older GAL contract remains an ERC-20 with a maximum supply of 200 million GAL, but that supply figure should not be confused with the post-migration G supply. Users must distinguish the legacy GAL contract from G contracts and from native G on Gravity. Contract addresses, network selection, bridge routes, and wallet display settings are all material to avoiding an accidental transfer to an unsupported destination.

Governance and control

G DAO governance is based on staking and a staged process. The published procedure calls for a forum temperature check followed by a Snapshot vote. Standard proposals require more than 50% approval and endorsement from addresses staking at least 120 million G; smaller or less consequential proposals may use a lower 12 million G quorum. Passed changes are implemented by Galxe’s operating team and may require a multisignature transaction, so token voting does not mean every decision executes automatically onchain.

The governance design therefore combines community voting with operational and multisignature execution. That can make upgrades practical, but it also leaves an important trust boundary between a successful vote and the code or transaction that implements it. The core-contract repository’s inclusion of governance, staking, validator, and oracle layers indicates that protocol control is broader than simple treasury voting.

Users, limitations, and open questions

The intended users are project teams seeking campaign distribution, developers needing credential or identity checks, communities running loyalty programs, and applications that want access to Gravity’s execution environment. The system’s usefulness depends on a network effect between those builders, campaign participants, credential issuers, verifiers, wallets, bridges, and Gravity validators. A large catalogue of possible credential types does not by itself prove that any particular credential is accurate, resistant to Sybil abuse, or useful outside the application that issued it.

The main unresolved issues are operational rather than purely conceptual. Users must track the GAL-to-G migration history, the move from Gravity Alpha to Gravity L1, and the availability of supported bridge routes. The G token contract also exposes administrative controls such as pausing and owner-managed functions. Identity features introduce additional dependencies on issuers, verification providers, offchain services, and privacy assumptions. These factors mean that token utility is tied to continued execution by Galxe, Gravity infrastructure, and third-party applications rather than being guaranteed by the token contract alone.

Key takeaways

• GAL is the legacy Galxe token; the project’s current unified token is Gravity’s G.
• Galxe combines campaign distribution, credential verification, identity products, and a blockchain network rather than operating as only a token project.
• G is intended for Gravity gas, staking, governance, payments, and ecosystem incentives.
• Credential privacy and accuracy depend on issuers, verification services, offchain components, and application-specific schemas.
• G DAO uses forum discussion, Snapshot voting, staking thresholds, and possible multisignature implementation.
• Gravity Alpha Mainnet is scheduled for deprecation on November 1, 2026, creating a time-sensitive migration dependency for affected users.

Risks and open questions

• Legacy GAL and current G have different contracts, supplies, utilities, and network roles, creating contract-selection and migration risk.
• Gravity Alpha Mainnet is scheduled to be deprecated on November 1, 2026; assets left there may become non-transferable according to Galxe’s announcement.
• The G ERC-20 contract includes owner-controlled pause and mint-management capabilities, so users must account for administrative trust and bridge controls.
• Governance outcomes may still require implementation by Galxe’s operating team and multisignature signers rather than executing automatically from token-holder votes.
• Credential systems depend on issuers, third-party verification providers, APIs, offchain services, and application-specific data quality.
• The project’s technical repositories document intended architecture, not independent proof of security, decentralization, adoption, or claimed production performance.