> For the complete documentation index, see [llms.txt](https://docs.memecore.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.memecore.com/support/hardforks.md).

# Hardforks

A complete record of every hardfork on the MemeCore Mainnet — activation blocks and timestamps, what changed, and how to verify each activation on-chain.

## Hardforks

This page is the canonical record of all protocol upgrades (hardforks) that have been activated on the MemeCore Mainnet. Each entry lists the exact activation point, the changes it introduced, and the Ethereum Improvement Proposals (EIPs) it adopted, where applicable.

A **hardfork** is a change to the protocol rules that is not backward-compatible: once it activates, nodes that have not upgraded will stop following the canonical chain. All MemeCore hardforks are planned, coordinated upgrades shipped in a specific `gmeme` client release and activated at a predetermined block number or timestamp. MemeCore has never performed a soft fork.

{% hint style="warning" %}
**Node operators:** every hardfork requires upgrading your `gmeme` client **before** the activation point. A node running an outdated version will diverge from the canonical chain at the activation block and must be resynced. See Running a node.
{% endhint %}

***

### Network at a glance

<table data-search="false"><thead><tr><th>Parameter</th><th>Value</th></tr></thead><tbody><tr><td>Network</td><td>MemeCore Mainnet</td></tr><tr><td>Chain ID</td><td><code>4352</code></td></tr><tr><td>Genesis</td><td>2025-01-06 10:10:10 UTC (block <code>#0</code>)</td></tr><tr><td>Consensus</td><td>Proof of Authority (Clique-style) — see Consensus</td></tr><tr><td>Block time</td><td>~7 seconds</td></tr><tr><td>Hardforks to date</td><td>3</td></tr><tr><td>Soft forks to date</td><td>0</td></tr></tbody></table>

#### Activation methods

MemeCore uses two activation mechanisms, mirroring Ethereum's own transition from block-based to timestamp-based forks:

* **Block-based** — the fork activates at a fixed block height. The wall-clock time is approximate until the block is actually produced. Used by RewardTree and GasTree.
* **Timestamp-based** — the fork activates on the first block whose timestamp is greater than or equal to a fixed Unix timestamp. The exact block number is only known after activation. Used by CanPraTree and all future hardforks.

***

### Activations

All hardforks on the MemeCore Mainnet, newest first.

| Hardfork   | Type      | Activation                              | Date (UTC)          | Summary                                                                     |
| ---------- | --------- | --------------------------------------- | ------------------- | --------------------------------------------------------------------------- |
| CanPraTree | Timestamp | `1774404000` (first block `#5,419,305`) | 2026-03-25 02:00:00 | Ethereum Cancun + Prague EVM upgrades (EIP-4844, EIP-7702, and others)      |
| GasTree    | Block     | `#5,332,985`                            | 2026-03-18 02:09:24 | Minimum base fee reduced from 1,500 Gwei to 15 Gwei                         |
| RewardTree | Block     | `#2,300,000`                            | 2025-07-15 08:31:26 | Block reward reduced from 112.5 M to 30 M per block                         |
| Genesis    | —         | `#0`                                    | 2025-01-06 10:10:10 | Mainnet launch. EIP-1559 fee market active from genesis (`LondonBlock = 0`) |

***

### CanPraTree

The CanPraTree hardfork brings the MemeCore EVM in line with Ethereum's **Cancun** (March 2024) and **Prague** (May 2025) execution-layer upgrades, so that contracts, tooling and wallets built for current Ethereum work on MemeCore without modification. This is MemeCore's first timestamp-based hardfork.

| Field                       | Mainnet                                |
| --------------------------- | -------------------------------------- |
| Status                      | Active                                 |
| Activation type             | Timestamp                              |
| Activation timestamp        | `1774404000`                           |
| Activation time             | 2026-03-25 02:00:00 UTC (11:00:00 KST) |
| First block under new rules | `#5,419,305` — 2026-03-25 02:00:04 UTC |

#### Summary

* Activates the full Cancun EVM feature set: blob-carrying transactions, transient storage, `MCOPY`, and the restricted `SELFDESTRUCT` semantics.
* Activates the Prague EVM feature set: EOA code delegation (EIP-7702), the block-hash history system contract, BLS12-381 precompiles, and the revised calldata cost model.
* Beacon-chain–specific EIPs from both upgrades are **not** included, because MemeCore is a Proof of Authority chain and has no beacon chain or validator deposit/withdrawal pipeline.
* Blob base fees introduced by EIP-4844 are burned in the same way as the regular base fee — see Transaction Fees & Burn.

#### Included changes

**Cancun**

* [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) — Shard blob transactions (type `0x03`) and the `BLOBHASH` opcode
* [EIP-7516](https://eips.ethereum.org/EIPS/eip-7516) — `BLOBBASEFEE` opcode
* [EIP-1153](https://eips.ethereum.org/EIPS/eip-1153) — Transient storage opcodes (`TLOAD` / `TSTORE`)
* [EIP-5656](https://eips.ethereum.org/EIPS/eip-5656) — `MCOPY` memory copying instruction
* [EIP-6780](https://eips.ethereum.org/EIPS/eip-6780) — `SELFDESTRUCT` only in the same transaction as creation

**Prague**

* [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) — Set EOA account code (SetCode transactions, type `0x04`)
* [EIP-2935](https://eips.ethereum.org/EIPS/eip-2935) — Serve historical block hashes from state (system contract)
* [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537) — Precompiles for BLS12-381 curve operations
* [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) — Increase calldata cost

#### Not included

The following EIPs are part of Ethereum's Cancun and Prague upgrades but are intentionally **excluded** from CanPraTree, since they depend on an Ethereum beacon chain that does not exist on a Proof of Authority network:

* [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) — Beacon block root in the EVM
* [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) — Supply validator deposits on chain
* [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) — Execution-layer triggerable withdrawals
* [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) — Increase the `MAX_EFFECTIVE_BALANCE`

#### What this means for you

* **Developers:** contracts compiled for the `cancun` or `prague` EVM target can be deployed directly. Transient storage, `MCOPY`, and the BLS12-381 precompiles are available.
* **Wallets and account abstraction:** EIP-7702 enables smart-account features (batching, sponsorship) for existing EOAs.
* **Node operators:** the activation is timestamp-based, so clients must be upgraded before `1774404000` regardless of block height.

***

### GasTree

The GasTree hardfork lowered the network's **minimum base fee by 100×**, from 1,500 Gwei to 15 Gwei, to make transactions on MemeCore substantially cheaper while keeping the EIP-1559 fee market and burn mechanism unchanged.

| Field            | Mainnet                                |
| ---------------- | -------------------------------------- |
| Status           | Active                                 |
| Activation type  | Block                                  |
| Activation block | `#5,332,985`                           |
| Activation time  | 2026-03-18 02:09:24 UTC (11:09:24 KST) |
| Unix timestamp   | `1773799764`                           |

#### Summary

* Minimum base fee (`baseFeePerGas` floor): **1,500 Gwei → 15 Gwei**.
* Priority fee behaviour, base-fee adjustment algorithm, and the fee burn are unchanged.
* No EVM opcode or transaction-type changes; contracts are unaffected.

#### What this means for you

* **Users:** typical transaction costs dropped by roughly two orders of magnitude from this block onward.
* **Developers:** hard-coded gas price assumptions (e.g. a fixed 1,500 Gwei `gasPrice`) should be replaced with `eth_gasPrice` / `eth_feeHistory` lookups. See Transaction Fees & Burn for the current fee parameters.

***

### RewardTree

The RewardTree hardfork reduced the **block reward** minted by the protocol from 112.5 M to 30 M per block, adjusting the issuance schedule of $M. It was MemeCore's first hardfork.

| Field            | Mainnet                                |
| ---------------- | -------------------------------------- |
| Status           | Active                                 |
| Activation type  | Block                                  |
| Activation block | `#2,300,000`                           |
| Activation time  | 2025-07-15 08:31:26 UTC (17:31:26 KST) |
| Unix timestamp   | `1752568286`                           |

#### Summary

* Protocol block reward: **112.5 M → 30 M per block**.
* The reward is still minted by the client at each block and routed to the reward contract; only the amount changed. Distribution across validators, delegators and PoM participants is unchanged — see Multi-reward.
* No EVM or transaction-format changes.

#### What this means for you

* **Validators and delegators:** per-block rewards after block `#2,300,000` are 30 M. Reward calculators and dashboards should apply the new rate from this height.
* **Token holders:** the change reduces ongoing $M issuance; see Token Allocation for the overall supply schedule.


---

# 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.memecore.com/support/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.