> 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/gravity-networks/testnet-hardforks.md).

# Gravity Longevity Testnet Hardforks

Gravity Longevity Testnet (L1) hardfork schedule, how activations are stored, and the node version needed to follow the live chain.

Longevity Testnet (chain ID `7771625`) activation times live in each node's `genesis.json` under `config.<name>` (for example `pragueTime`, `alphaTime`). Rolling upgrades append those fields. They are **not** compiled into `gravity_node` the way [Mainnet hardforks](/gravity-networks/mainnet-hardforks.md) are.

A public full node must use:

1. a `genesis.json` / `waypoint.txt` pair that matches the live chain identity and hardfork schedule; and
2. a `gravity_node` release that implements every fork already activated on testnet.

## Current required version

Testnet operators are on [v1.10.1](https://github.com/Galxe/gravity-sdk/releases/tag/v1.10.1) (or newer). It covers both TestnetOwnerFix activations. Gravity-operated testnet nodes run v1.10.1 since 2026-10-19. Build or pull that tag before syncing a new PFN to the live tip.

```bash
docker pull ghcr.io/galxe/gravity_node:v1.10.1
```

Canonical artifacts:

* Genesis / waypoint: [`gravity-sdk/genesis/testnet`](https://github.com/Galxe/gravity-sdk/tree/main/genesis/testnet)
* Network overview: [Gravity Longevity Testnet (L1)](/gravity-networks/l1-longevity-testnet.md)
* Deploy a PFN: [binary](/gravity-networks/run-a-testnet-pfn.md) · [Docker](/gravity-networks/run-a-testnet-pfn-with-docker.md)

## Schedule

Newest first. Times are taken from live `debug_chainConfig` and match the recorded upgrade plans under `mono-grav/docs/testnet/upgrades/`. All rows have activated.

| Hardfork          | Activation (UTC)    | Unix         | First release used on testnet                                                                                    |
| ----------------- | ------------------- | ------------ | ---------------------------------------------------------------------------------------------------------------- |
| TestnetOwnerFixV2 | 2026-09-09 10:00:00 | `1788948000` | [v1.10.1-testnet](https://github.com/Galxe/gravity-sdk/releases/tag/v1.10.1-testnet) (same-tag rebuild)          |
| TestnetOwnerFix   | 2026-09-04 03:00:00 | `1788490800` | [v1.10.1-testnet](https://github.com/Galxe/gravity-sdk/releases/tag/v1.10.1-testnet)                             |
| Gamma             | 2026-08-19 03:00:00 | `1787108400` | [v1.10.0-pre](https://github.com/Galxe/gravity-sdk/releases/tag/v1.10.0-pre)                                     |
| Beta + Osaka      | 2026-08-04 03:00:00 | `1785812400` | [v1.9.0](https://github.com/Galxe/gravity-sdk/releases/tag/v1.9.0)                                               |
| Alpha             | 2026-07-06 09:00:00 | `1783328400` | live genesis field (`alphaTime`; no archived upgrade JSON)                                                       |
| Prague            | 2026-06-08 09:04:02 | `1780909442` | [`v1.6.3`](https://github.com/Galxe/gravity-sdk/tree/v1.6.3) (upgrade artifact labeled `gravity-mainnet-v1.6.3`) |

Beijing (UTC+8) equivalents: TestnetOwnerFixV2 18:00, TestnetOwnerFix 11:00, Gamma 11:00, Beta/Osaka 11:00, Alpha 17:00, Prague 17:04:02 on the same calendar dates.

## Testnet vs mainnet

|                      | Longevity Testnet                  | Mainnet                                                     |
| -------------------- | ---------------------------------- | ----------------------------------------------------------- |
| Chain ID             | `7771625`                          | `127001`                                                    |
| Where times live     | `genesis.json` `config.*` fields   | compiled into `gravity_node`                                |
| Editing genesis      | updates the schedule for that node | does not override the binary                                |
| Public schedule page | this page                          | [Mainnet hardforks](/gravity-networks/mainnet-hardforks.md) |

Do not copy mainnet unix timestamps onto testnet (or the reverse). The two networks activate the same fork names on different clocks.

## If you miss a hardfork

A node on older rules computes a different execution hash once the network has moved on. The first mismatched block stops the process. RPC height stops increasing. This is fail-stop: the node does not keep serving a private fork.

Search logs for:

```
commit_info mismatch
Block hash mismatch
assertion `left == right` failed
```

There is no dedicated "hardfork missed" message.

Recovery for a public full node is usually: install a current release, load a genesis that includes the live hardfork fields, then warm-start from the [testnet data snapshot](/gravity-networks/run-a-testnet-pfn.md#5-optional-warm-start-from-a-snapshot-or-existing-node) instead of replaying from block zero.

## See also

* [Gravity Longevity Testnet (L1)](/gravity-networks/l1-longevity-testnet.md)
* [Run a Gravity Testnet Public Full Node](/gravity-networks/run-a-testnet-pfn.md)
* [Run a Gravity Testnet Public Full Node With Docker](/gravity-networks/run-a-testnet-pfn-with-docker.md)
* [Gravity Mainnet Hardforks](/gravity-networks/mainnet-hardforks.md)


---

# 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/gravity-networks/testnet-hardforks.md?ask=<question>&goal=<user_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.