Skip to main content
TLDR:
  • Granite upgrade activates on Fuji testnet October 29, 2025, with Mainnet following after successful Fuji deployment.
  • Three Avalanche Community Proposals (ACPs) activate: ACP-181 (P-Chain Epoched Views), ACP-204 (secp256r1 curve support), ACP-226 (Dynamic block times).
  • New proposervm namespace APIs available on all chains (P-chain, X-chain, C-chain) — accessible but not shown in Chainstack UI.
  • Breaking changes only affect library consumers (libevm hooks) and plugin developers (version 44) — standard RPC users unaffected.
No breaking changes for standard RPC users. All existing RPC methods continue to work as expected.
If you’re using Chainstack nodes or other standard RPC endpoints, you don’t need to make any changes to your applications.

​
Main article

The Granite upgrade is a major network upgrade for Avalanche that activates on Fuji testnet on October 29, with Mainnet activation following after successful Fuji deployment.

​
Chainstack nodes are Granite-ready

Chainstack will roll out the Granite upgrade following the Avalanche upgrade timeline: Fuji testnet first, then Mainnet. All nodes on Chainstack are prepared for the respective network upgrades.

​
Three Avalanche Community Proposals (ACPs)

The Granite upgrade implements three ACPs that improve P-Chain operations, expand cryptographic support, and optimize block timing.

​
ACP-181: P-Chain Epoched Views

ACP-181 introduces epoched views for the P-Chain, improving validator set management and consensus efficiency. This proposal restructures how the P-Chain manages validator state across epochs, enabling better coordination and reducing overhead in validator set transitions. See the full proposal: ACP-181: P-Chain Epoched Views

​
ACP-204: Precompile for secp256r1 Curve Support

ACP-204 adds precompile support for the secp256r1 elliptic curve, expanding Avalanche’s cryptographic capabilities. The secp256r1 curve (also known as P-256) is widely used in various cryptographic applications, including TLS/SSL certificates and secure hardware modules. This addition enables smart contracts to verify secp256r1 signatures natively, opening up new integration possibilities with existing systems that use this curve. See the full proposal: ACP-204: Precompile for secp256r1 Curve Support

​
ACP-226: Dynamic Minimum Block Times

ACP-226 introduces dynamic minimum block times with delay excess calculations, allowing more flexible block production timing. Previously, block times were static. This proposal enables the network to adjust block timing dynamically based on network conditions, improving overall efficiency while maintaining security guarantees.
New block header fields: ACP-226 adds TimeMilliseconds and MinDelayExcess fields to C-Chain block headers (implemented in coreth v0.15.4-rc.4). These appear as additional fields in block responses from methods like eth_getBlockByNumber. The existing timestamp field remains unchanged for backward compatibility. Standard RPC clients that ignore unknown JSON fields are unaffected.
See the full proposal: ACP-226: Dynamic Minimum Block Times

​
New API endpoints

The Granite upgrade introduces several new API endpoints across the proposervm and platform namespaces.

​
proposervm namespace

The proposervm namespace is now available on all Avalanche primary chains (P-chain, X-chain, C-chain) with two new methods:
  • GetProposedHeight — retrieves the currently proposed block height.
  • GetCurrentEpoch — returns the current epoch information.
Or using chain aliases:
  • P-chain: /ext/bc/P/proposervm
  • C-chain: /ext/bc/C/proposervm
  • X-chain: /ext/bc/X/proposervm
The proposervm namespace is fully supported on Chainstack nodes but is not displayed in the Chainstack UI. You can access it directly via the endpoints above.

​
platform namespace

A new platform method is available:
  • GetAllValidatorsAt — retrieves all validators at a specific height
This enables more efficient queries of the complete validator set at any given point in the chain’s history.

​
Stateless block types

Granite introduces stateless block types for the new consensus mechanism, reducing the amount of state that needs to be maintained during block processing. This architectural change lays the groundwork for future scalability improvements while maintaining backward compatibility with existing operations.

​
What this means for developers

If you’re building on Avalanche using Chainstack nodes: No action required — your existing applications will continue working without changes. New opportunities — the proposervm namespace provides additional monitoring and observability capabilities for your applications. Future-ready — the Granite upgrade positions Avalanche for enhanced P-Chain operations and improved block timing flexibility.
⌘I