> For the complete documentation index, see [llms.txt](https://docs.gravity.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gravity.xyz/the-g-token/g-token.md).
# G Token
Powering the future of Web3. G is the native token on Gravity, and the utility token of both Gravity and the Galxe ecosystem.
## **GAL -> G Migration**
With the approval of proposals [GP-25](https://dao.galxe.com/#/proposal/0x8d3f386c3b0cb9fa170d4231c65f18bd45ea1402b90a70116e1101c22e62ed01) and [GP-30](https://dao.galxe.com/#/proposal/0xa6af134cd0522ea34d2d6485a557fafdb01cc7f32726f409bd8f399cc2af2514) by the Galxe DAO community, we’re migrating the Galxe (GAL) token to Gravity (G), unifying and streamlining the experience across both ecosystems. This upgrade focuses on enhancing the user journey, integrating the token seamlessly across our Layer 1 and the Galxe ecosystem, and simplifying the ticker for easier recognition. G will serve as the universal token, providing utility in governance, transactions, and incentives across the entire ecosystem. Read this article to learn more about [the token migration](https://gravity.xyz/blog/gal-g).
[The migration portal is available](https://app.galxe.com/gal-token-migration) for all GAL holders to migrate their existing GAL to G.
## **What is G Token?**
G is the native token on Gravity and the utility token for both Gravity and the Galxe ecosystem. G powers transactions as the gas token and secures the network through staking. As the primary utility token across both ecosystems, G drives governance decisions, incentivizes growth, and facilitates payments.
## G Token
### As the Native Token
* G is the native coin of **Gravity Mainnet (L1)** (chain ID `127001`, now live) and of the legacy **Gravity Alpha Mainnet (L2)**.
### Genesis Allocation on Gravity Mainnet (L1)
At Gravity Mainnet (L1) genesis, **7,000,000 G** was allocated as initial validator stake across the seven launch validators:
| Validator | Genesis stake |
| ----------- | --------------: |
| Validator-1 | 1,000,000 G |
| Validator-2 | 1,000,000 G |
| Validator-3 | 1,000,000 G |
| Validator-4 | 1,000,000 G |
| Validator-5 | 1,000,000 G |
| Validator-6 | 1,300,000 G |
| Validator-7 | 700,000 G |
| **Total** | **7,000,000 G** |
To back this allocation, a matching **7,000,000 G** was locked on Ethereum mainnet in the canonical bridge's `GBridgeSender` contract ([`0xE82c61Ac9Ec2041b493118051afa4F18a55dC876`](https://etherscan.io/address/0xE82c61Ac9Ec2041b493118051afa4F18a55dC876)). G held by the GBridgeSender is permanently locked to back native G on L1 and **should be considered burned** from the circulating ERC-20 supply. This is a one-time genesis bootstrap and will not recur.
**Transaction:** [`0xa1c2e4ec30a116a8c7f752c674a3a07c635d92cbdc7edca6055c8ed2b21fcff2`](https://etherscan.io/tx/0xa1c2e4ec30a116a8c7f752c674a3a07c635d92cbdc7edca6055c8ed2b21fcff2) — 7,000,000 G transferred to the GBridgeSender on 2026-05-28.
### As ERC-20 Token
* Token Name: **Gravity**
* Token Symbol: **G**
* Initial Total Supply: 12,000,000,000 G
* Decimal: 18
* ERC-20 Contract Address: `0x9C7BEBa8F6eF6643aBd725e45a4E8387eF260649`
* Token Icon: , or [visit this link](https://gal.xyz/brand) for different versions
* **Currently Available Networks:**
* [**Ethereum**](https://etherscan.io/token/0x9C7BEBa8F6eF6643aBd725e45a4E8387eF260649#code)
* Contract owner: [Safe multi-sig on Ethereum](https://etherscan.io/address/0xbD6e434dB90FD8AD4E28d85C133AD34cA6fbfB6D)
* Initial supply: 10,000,000,000 G
* Current on-chain supply: read the Ethereum GToken contract’s `totalSupply()`. The earlier 11,526,557,260 G figure reflects the rebalances listed below, not a live supply value. Fast-withdrawal minting and subsequent burns change this value; see [Supply accounting during the Alpha L2 sunset](#supply-accounting-during-the-alpha-l2-sunset).
* Rebalance Event 1: Receiving 1,515,000,000 G From BNB Chain.
* Rebalance Event 2: Sending 10,000,000 G To Base.\
* Rebalance Event 4 (Ethereum Token Upgrader): Receiving 21,557,260 G From BNB Chain Token Upgrader
* Gravity Alpha Mainnet (L2), i.e. `num_bridged G`
* As a rollup on the Ethereum mainnet, G tokens bridged to the Gravity Alpha Mainnet are locked in [this contract](https://etherscan.io/address/0x7983403dda368aa7d67145a9b81c5c517f364c42): `0x7983403dda368aa7d67145a9b81c5c517f364c42`, as backing for the rollup’s native G.
* The number of G tokens is dynamic, fluctuating as users bridge tokens in and out of the L2. Read the G token balance of the [contract address](https://etherscan.io/address/0x7983403dda368aa7d67145a9b81c5c517f364c42) above for canonical backing. It also includes withdrawals not yet claimed on Ethereum; it is not a measure of freely spendable G remaining on L2.
* Gravity Mainnet (L1), i.e. G locked in the canonical L1 bridge
* G bridged to Gravity Mainnet (L1) is locked in the `GBridgeSender` contract [`0xE82c61Ac9Ec2041b493118051afa4F18a55dC876`](https://etherscan.io/address/0xE82c61Ac9Ec2041b493118051afa4F18a55dC876) and **should be considered burned** from the circulating ERC-20 supply — it is permanently locked to back native G on L1. This includes the one-time 7,000,000 G genesis backing (see [Genesis Allocation on Gravity Mainnet (L1)](#genesis-allocation-on-gravity-mainnet-l1)).
* [**BNB Chain**](https://bscscan.com/token/0x9C7BEBa8F6eF6643aBd725e45a4E8387eF260649#code)
* Contract owner: [Safe multi-sig on BNB Chain](https://bscscan.com/address/0xBB86C74ecCA362D007293EE8A2E24E9De0B9E558)
* Initial supply: 2,000,000,000 G
* Current supply: 458,442,740 G
* Rebalance Event 1: Sending 1,515,000,000 G To Ethereum
* Rebalance Event 3: Sending 5,000,000 G to Base
* Rebalance Event 4 (BNB Chain Token Upgrader): Sending 21,557,260 G to Ethereum Token Upgrader
* [**Base**](https://basescan.org/token/0x9c7beba8f6ef6643abd725e45a4e8387ef260649#code)
* Contract owner: [Safe multi-sig on Base](https://basescan.org/address/0x08bDCC846D80d81eF6e058bB64228Ec58CA6726a)
* Initial supply: 0 G
* Current supply: 15,000,000 G
* Rebalance Event 2: Receiving 10,000,000 G From Ethereum
* Rebalance Event 3: Receiving 5,000,000 G From BNB Chain
* Audit report
{% file src="/files/PcnWrGpAkK9N2RF2SQy9" %}
#### Supply accounting during the Alpha L2 sunset
{% hint style="info" %}
**Fast withdrawals do not increase the economic supply of G.** They move existing G from Alpha L2 to Ethereum at a **1:1 ratio**. Every G minted through the fast-withdrawal path corresponds to G already deposited and locked on Alpha; the original principal cannot remain spendable alongside the Ethereum G. Its canonical backing is subsequently sent to the fixed BurnSink and burned. Count this value once across the networks, including any pending withdrawal entitlement, rather than adding locked backing to the replacement tokens.
Ethereum's raw `totalSupply()` can temporarily rise between minting and settlement burning. This is a timing difference in the bridge's accounting, not an additional economic allocation of G or an increase in circulating G from counting both sides. Pending delivery can temporarily reduce immediately spendable balances; this bridge does not make a claim that global circulating supply is constant despite other locks, unlocks or token operations.
{% endhint %}
From the launch of [Alpha G fast withdrawals announced by Gravity](https://x.com/GravityChain/status/2101627729221132731) through the Alpha L2 sunset, some G is locked while its canonical settlement completes. A fast withdrawal locks native G in the Alpha escrow and, once its message is delivered, mints the same amount of ERC-20 G on Ethereum. Operators periodically withdraw the locked principal in batches through the canonical bridge, claim it into the Ethereum BurnSink, and burn it. Settlement tracking must continue until the last batch is claimed and burned, even if that occurs after L2 stops accepting transactions.
**The contract restricts where this principal can go.** `AlphaGEscrow.exitEscrow()` sends it only to the fixed `GBurnSink` address. BurnSink has no transfer, approval, recovery or upgrade path: its only function for disposing of G is the owner's `burn()`. Burning requires an explicit settlement action, which may be batched with the claim in one transaction; the passage of time or the initiation of an L2 withdrawal does not itself burn Ethereum ERC-20 G. Until the matching burn, fast-withdrawal minting can temporarily increase Ethereum's reported `totalSupply()`.
**Addresses and values to read**
All amounts use 18 decimals. Use native `eth_getBalance` for Alpha escrow G and Ethereum **GToken `balanceOf(address)`** for ERC-20 balances; an address's ETH balance is not its G balance.
| Symbol | Network / contract | Read |
| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `T` | Ethereum GToken [`0x9C7BEBa8F6eF6643aBd725e45a4E8387eF260649`](https://etherscan.io/address/0x9C7BEBa8F6eF6643aBd725e45a4E8387eF260649#readContract) | `totalSupply()` — current raw Ethereum ERC-20 supply |
| `D`, `X`, `Q` | Alpha L2 Escrow [`0x8412Fe9ae34Ca66c140E950927591ee8dc09a235`](https://explorer.gravity.xyz/address/0x8412Fe9ae34Ca66c140E950927591ee8dc09a235?tab=read_contract) | `totalDeposited()`, `totalExitInitiated()`, `escrowed()`; `Q = D − X`. Compare `Q` with its native G balance. |
| `M` | Ethereum Minter [`0x7b7fDA78d7C262b5Eff124dB57D3434F1f3bFFD8`](https://etherscan.io/address/0x7b7fDA78d7C262b5Eff124dB57D3434F1f3bFFD8#readContract) | `totalMinted()`; match individual `Bridged` / `Minted` events by GUID and check `processed(guid)`. |
| `S`, `B` | Ethereum BurnSink [`0x6Ba324f1B84c9973249D0cf7B87Aca396164a04e`](https://etherscan.io/address/0x6Ba324f1B84c9973249D0cf7B87Aca396164a04e#readContract) | `S = GToken.balanceOf(BurnSink)`; `B = BurnSink.totalBurned()` |
| `K` | Ethereum canonical Alpha bridge [`0x7983403dDA368AA7d67145a9b81c5c517F364c42`](https://etherscan.io/address/0x7983403dDA368AA7d67145a9b81c5c517F364c42#readContract) | `GToken.balanceOf(bridge)` — backing for the whole Alpha bridge, not just fast withdrawals |
| `C` | Ethereum Outbox [`0x1153a1e4B1523DFf36f77d696bd6eBF2B0e7DAbF`](https://etherscan.io/address/0x1153a1e4B1523DFf36f77d696bd6eBF2B0e7DAbF#readContract) and claim receipts | Derive cumulative G successfully claimed **from this Escrow to this BurnSink**; there is no `C` getter. Match each `ExitInitiated` / ArbSys `L2ToL1Tx` withdrawal ID to successful Outbox execution and `GToken.Transfer(bridge, BurnSink, amount)`. Check `isSpent(position)`. |
**Include both kinds of in-flight amounts**
| Stage | Amount | Interpretation |
| ------------------------------ | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Fast message awaiting mint | `U = D − M` | Deposited principal whose matching Ethereum mint has not completed. Track the individual GUIDs; do not count it as already minted. |
| Still in L2 escrow | `Q = D − X` | Principal not yet sent through the canonical withdrawal path. |
| Canonical withdrawal in flight | `F = X − C` | Principal already removed from escrow but not yet claimed on Ethereum, including both the challenge period and claimable-but-unclaimed withdrawals. It is still backed by G in the canonical bridge. |
| Claimed, awaiting burn | `S` | G held by BurnSink, unavailable for transfer but still included in Ethereum `totalSupply()`. |
| Burn completed | `B` | Actual cumulative burns through BurnSink; already reflected as a reduction in `T`. |
`U` describes message delivery; it is **not another location of principal to add to `Q + F + S`**. For normal settlement, operators select already-minted deposits before initiating canonical exits. The L2 contract does not independently verify the Ethereum mint, so reconcile GUIDs as well as totals.
With no unrelated G transfers into BurnSink, and all figures covering the same deployment and consistent observation window:
```
Q = D − X
F = X − C
C = S + B
D = Q + F + S + B
U = D − M
Temporary raw ERC-20 accounting increase awaiting a matching burn:
O = M − B = Q + F + S − U
Ethereum raw supply with this temporary fast-withdrawal increment removed:
T_adjusted = T − O = T − M + B
```
For the deposited principal, `M + U = D`: the value is either delivered to Ethereum or remains a pending mint entitlement. Locked escrow principal, in-flight canonical backing and BurnSink holdings are settlement assets, not additional spendable G to add to that value. This is the conservation rule behind the 1:1 migration.
`T_adjusted` isolates the fast bridge's mint/burn effect; it is **not** a circulating-supply calculation or the total supply across all networks. Do not subtract `B` again: burning already reduced `T`. Other minting, burning and network rebalances must be accounted for separately.
For an Ethereum balance-based view, exclude canonical bridge backing `K` and BurnSink holdings `S` from freely transferable ERC-20 balances, along with other applicable locked allocations. Do not then subtract `Q` or `F` again: their Ethereum backing is already part of `K`. The permanently locked Gravity **Mainnet L1** `GBridgeSender` balance described above is a separate exclusion; it is not the Alpha escrow or canonical bridge.
**Example: a 100 G fast withdrawal**
The user starts with 100 G on Alpha and receives 100 G on Ethereum. The locked original and its canonical backing are unavailable to spend again. The migration represents **100 G of economic value throughout**, including the pending entitlement before delivery; it never makes 200 G available for circulation.
| State | `D` | `M` | `Q` | `F` | `S` | `B` | `U` | `O` |
| ------------------------------------- | --: | --: | --: | --: | --: | --: | --: | --: |
| Deposited; mint pending | 100 | 0 | 100 | 0 | 0 | 0 | 100 | 0 |
| Ethereum mint delivered | 100 | 100 | 100 | 0 | 0 | 0 | 0 | 100 |
| Canonical exit initiated; not claimed | 100 | 100 | 0 | 100 | 0 | 0 | 0 | 100 |
| Claimed into BurnSink | 100 | 100 | 0 | 0 | 100 | 0 | 0 | 100 |
| Burn completed | 100 | 100 | 0 | 0 | 0 | 100 | 0 | 0 |
In particular, **zero balances at both Escrow and BurnSink do not mean settlement is complete**: the third row has 100 G in flight. Use `X − C` to retain that amount in the ledger.
**Executed example: 1 G claimed and burned**
These two successful transactions settle the same **1 G** canonical withdrawal, **withdrawal ID / Outbox position `3754`**:
| Step | Transaction | Evidence |
| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Alpha L2 exit — September 20, 2026, 11:37:57 UTC | [L2 exit transaction](https://explorer.gravity.xyz/tx/0xf8994a237a628c1a6eb5bb26480d390127a8ac7d344539fe4f60b0692228400f) | Escrow's `ExitInitiated` records ID `3754`, `1000000000000000000` wei (1 G), and the fixed BurnSink. ArbSys's `L2ToL1Tx` records the same position, Escrow as caller, BurnSink as destination, and empty calldata. |
| Ethereum claim and burn — September 29, 2026, 06:23:59 UTC | [Ethereum claim-and-burn transaction](https://etherscan.io/tx/0x18909f2cd70d1db835c88b6133bfc536c5ad02e1402ee477f906cf7fb88fc7f5) | Outbox executes position `3754`. GToken emits `Transfer(canonical bridge, BurnSink, 1 G)`, then `Transfer(BurnSink, address(0), 1 G)`. BurnSink emits `Burned(1 G)`. |
For this batch, `X` increased by 1 G on Alpha while `C` and `B` were unchanged: that 1 G was in flight. The Ethereum transaction later increased **both `C` and `B` by 1 G**. Claim and burn were executed in one Safe batch, so this batch added no lasting BurnSink balance: the receipt's ordered events establish the intermediate receipt and subsequent destruction even though the end-of-transaction change in `S` is zero. Ethereum `totalSupply()` decreased by 1 G from the burn. These are per-batch changes, not a claim that every other withdrawal has settled.
Record block heights and timestamps on both chains, use confirmed receipts and allow for observation lag before treating a discrepancy as an error. Forced native transfers can make the Escrow balance exceed `Q`. Unrelated ERC-20 transfers into BurnSink can make `C != S + B`; identify those transfers and any burns of them separately before applying the matching-burn formulas. Do not silently clamp negative or inconsistent values to zero. Caps and replenishing minter allowances are permissions, not outstanding supply, and must not substitute for the cumulative variables above.
### As LayerZero OFT
{% hint style="warning" %}
**Legacy:** The LayerZero OFT deployment described below is legacy and is no longer actively used.
{% endhint %}
For chains that do not have G token contract deployed natively, we use LayerZero's OFT standard to bring G tokens to those chains.
* Token Name: `GravityTokenG (OFT)`
* Token Symbol: `G.oft`
Deployed networks:
* [**Polygon**](https://polygonscan.com/address/0x7653235DA659c8e573B365B16EE95b847A1777ba)
* Owner: [Safe multi-sig on Polygon](https://polygonscan.com/address/0x897a91caf592c42fcc953da16890c50372e63c61)
* Initial supply: 0 G (minted on-demand by bridging from Ethereum mainnet)
Security configurations:
* [OFT Adapter](https://etherscan.io/address/0x71c066fd4949C44B2cB2f509E2CD2421FbD36bca) on Ethereum mainnet: `0x71c066fd4949C44B2cB2f509E2CD2421FbD36bca`
* Owner: [Safe multi-sig on Ethereum](https://etherscan.io/address/0xbD6e434dB90FD8AD4E28d85C133AD34cA6fbfB6D)
* Ethereum -> Polygon
* Confirmation required: 15
* [LayerZero Labs](https://docs.layerzero.network/v2/developers/evm/technical-reference/dvn-addresses#layerzero-labs): `0x589dEDbD617e0CBcB916A9223F4d1300c294236b`
* [Google Cloud](https://docs.layerzero.network/v2/developers/evm/technical-reference/dvn-addresses#google-cloud): `0xD56e4eAb23cb81f43168F9F45211Eb027b9aC7cc`
* Polygon -> Ethereum
* Confirmation required: 512
* [LayerZero Labs](https://docs.layerzero.network/v2/developers/evm/technical-reference/dvn-addresses#layerzero-labs): `0x23DE2FE932d9043291f870324B74F820e11dc81A`
* [Google Cloud](https://docs.layerzero.network/v2/developers/evm/technical-reference/dvn-addresses#google-cloud): `0xD56e4eAb23cb81f43168F9F45211Eb027b9aC7cc`
### **Bridging G Between Networks**
**To Gravity Mainnet (L1, `127001`):** only the official [Gravity Native Bridge](https://bridge.gravity.xyz/) (Mainnet tab) supports L1 today — Ethereum → Gravity L1. The third-party routes below are being migrated to L1; until then they reach the legacy L2 only. Full guide: [How to Get G](/the-g-token/how-to-get-g.md).
**To Gravity Alpha Mainnet (L2, `1625`):**
* [Gravity Alpha Mainnet official canonical bridge](https://bridge.gravity.xyz/) (Legacy L2 tab) for Ethereum <> Gravity Alpha Mainnet
* [Symbiosis](https://app.symbiosis.finance/swap?amountIn\&chainIn=BNB\&chainOut=Gravity\&tokenIn=0x9C7BEBa8F6eF6643aBd725e45a4E8387eF260649\&tokenOut=G) for other networks
{% hint style="info" %}
**There is no canonical bridge between the Ethereum, BNB Chain and Base deployments of G.** Those three ERC-20s are independent deployments that happen to share the same address; each has its own owner multisig, and none of them is an omnichain (OFT) token. The **Rebalance Events** listed above are manual treasury transfers between deployments, not a user-accessible route.
To move G between those chains, use a third-party liquidity route (for example [Symbiosis](https://app.symbiosis.finance/swap)) or a centralized exchange. These are swaps against pooled liquidity, not canonical bridging.
{% endhint %}
### **Token Release Schedule**
Please [refer to this table](https://docs.google.com/spreadsheets/d/e/2PACX-1vQKC7RmjjYkPbgPWbY9XPTiZFBgLHDQnQJaKszhiu80AAKIoS4gf6E1C20I55a3JFNm7V5HDF9giCmW/pubhtml) for the completed **token release schedule of G**.
To find the previous token release schedule of GAL, [visit this table](https://gal.org/token-table).
### How to get G
> For getting native **G on Gravity Mainnet (L1)**, follow [How to Get G](/the-g-token/how-to-get-g.md) — the canonical L1 guide. Some on-chain links below currently route to the legacy **Alpha Mainnet (L2)** and are being migrated to L1.
* Buy G with credit card
* [Alchemy Pay](https://ramp.alchemypay.org/?appId=Ds23NPiP1aeapVES#/index)
* [Onramp Money](https://onramp.money/main/buy/?appId=1\&coinCode=g\&network=erc20)
* Get G on supported exchanges
* Find the list of supported exchanges on [CoinMarketCap](https://coinmarketcap.com/currencies/gravity-token/) or [CoinGecko](https://www.coingecko.com/en/coins/gravity)
* Get G onchain
* [Jumper Exchange](https://jumper.exchange/?fromChain=1\&toChain=1625\&toToken=0x0000000000000000000000000000000000000000)
* [Uniswap](https://app.uniswap.org/explore/tokens/ethereum/0x9C7BEBa8F6eF6643aBd725e45a4E8387eF260649)
* [Symbiosis](https://app.symbiosis.finance/swap?amountIn\&chainIn=Ethereum\&chainOut=Gravity\&tokenIn=ETH\&tokenOut=G)
* [Gas.zip](https://www.gas.zip/)
* [Comet](https://cometbridge.app/instantGas)
* If you have a balance in any vault in [Smart Saving](https://app.galxe.com/SmartSavings), click the corresponding vault and choose to receive the withdrawal token as G
### API
To get G supplies:
* **Total Supply:**
* **Circulating Supply:**
## **G Utilities**
Beyond migrating the existing utilities from GAL, G will expand its range of applications to serve all users within our ecosystems. Here are the key functionalities of G:
* **Staking:** Stake G to actively participate in governance, secure the network, and contribute to the long-term sustainability of both the Gravity and Galxe ecosystems. Additionally, G stakers gain convenient access to exclusive rewards from applications built by Galxe.
* **Governance:** G DAO is governed by G holders. Acting as a transparent, secure, and decentralized framework, G DAO fosters unity and progress among its members.
* **Transacting:** As the native gas token of Gravity Chain, G is used for executing and paying for all onchain transactions.
* **Payments:** As the utility token in the Galxe ecosystem, G is used to pay fees for applications built by Galxe, including Galxe Quest, Galxe Passport, Galxe Score, Alva, and more.
### Additional Examples of G Utilities in the Galxe Ecosystem
* **Galxe Shop**
Shop from thousands of online merchants and earn cash back in G. Galxe Shop offers a seamless and rewarding shopping experience, exclusive to the Galxe community.
* **Galxe Earn**
G stakers may be eligible for exclusive airdrops from partners within the Galxe ecosystem. Powered by Galxe Quest, Galxe Earn facilitates direct engagement and smarter distribution of rewards.
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.gravity.xyz/the-g-token/g-token.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
.jpg?alt=media&token=176bec0a-3108-4d31-a7f6-75e0568d2531)