docs: add T10 network upgrade

src/pages/docs/guide/node/network-upgrades.mdx

@@ -15,6 +15,7 @@ For detailed release notes and binaries, see the [Changelog](/docs/changelog).
 
 | Release | Date | Network | Description | Priority |
 |---------|------|---------|-------------|----------|
+| v1.13.0 | Aug 17, 2026 | Testnet + Mainnet | Required for T10. Enshrines ZoneFactory, assigns deterministic ZonePortal addresses, and installs canonical shared zone runtimes. Testnet activation is scheduled for Aug 20, 2026; mainnet activation is scheduled for Aug 21, 2026. | <Badge variant="red">Required</Badge> |
 | [v1.12.0](https://github.com/tempoxyz/tempo/releases/tag/v1.12.0) | Aug 3, 2026 | Testnet + Mainnet | Required for T9. Adds TIP-403 storage for TIP-20 token policy bindings used by zones/provable contract flows, plus a targeted migration path for existing tokens that need one. T9 is active on testnet and mainnet. | <Badge variant="red">Required</Badge> |
 | [v1.11.0](https://github.com/tempoxyz/tempo/releases/tag/v1.11.0) | Jul 22, 2026 | Testnet + Mainnet | Required for T8. Includes current committee state, FeeAMM policy changes, versioned Stablecoin DEX order storage, DEX V2Order support, and final TIP-20 rewards deprecation. T8 is active on testnet and mainnet. | <Badge variant="red">Required</Badge> |
 | [v1.10.1](https://github.com/tempoxyz/tempo/releases/tag/v1.10.1) | Jun 29, 2026 | Testnet + Mainnet | Required for T7; includes storage credits for DEX order storage and TIP-20 channel storage, dynamic base fee behavior, and TIP-20 rewards deprecation. | <Badge variant="red">Required</Badge> |
@@ -37,6 +38,22 @@ For detailed release notes and binaries, see the [Changelog](/docs/changelog).
 | [v1.3.1](https://github.com/tempoxyz/tempo/releases/tag/v1.3.1) | Feb 22, 2026 | Testnet + Mainnet | Fixes high-load issues and finalizes T1A/T1B hardening for expiring nonce replay protection and keychain precompile gas handling | <Badge variant="red">Required</Badge> |
 | [v1.2.0](https://github.com/tempoxyz/tempo/releases/tag/v1.2.0) | Feb 13, 2026 | Mainnet only | Fixes validation bug rejecting transactions with gas limits above ~16.7M, blocking large contract deployments | <Badge variant="red">Required</Badge> |
 
+## T10
+
+| | |
+|---|---|
+| **Scope** | Native ZoneFactory, deterministic ZonePortal accounts, and protocol-managed shared zone runtimes |
+| **TIPs** | [Enshrined ZoneFactory](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1091.md) |
+| **Details** | [T10 network upgrade](/docs/protocol/upgrades/t10) |
+| **Release** | v1.13.0 (forthcoming) |
+| **Testnet** | Scheduled: August 20, 2026 at 14:00 UTC (`1787234400`) |
+| **Mainnet** | Scheduled: August 21, 2026 at 14:00 UTC (`1787320800`) |
+| **Priority** | <Badge variant="red">Required</Badge> |
+
+T10 is scheduled for testnet on August 20, 2026 and mainnet on August 21, 2026. Node operators must upgrade to v1.13.0 before activation once the release is available.
+
+---
+
 ## T9
 
 | | |

src/pages/docs/protocol/upgrades/t10.mdx

@@ -0,0 +1,64 @@
+---
+title: T10 Network Upgrade
+description: T10 enshrines ZoneFactory and installs canonical ZonePortal runtimes for native zone creation.
+---
+
+# T10 Network Upgrade
+
+T10 makes zone creation a native Tempo protocol operation. It enshrines `ZoneFactory`, assigns each zone a deterministic `ZonePortal` address, and installs canonical shared runtimes for portals, verification, and messaging.
+
+For most partners, T10 matters if you operate a node, create Tempo Zones, or integrate directly with `ZoneFactory` and `ZonePortal`.
+
+:::info[T10 status]
+T10 is scheduled for testnet on August 20, 2026 at 14:00 UTC and mainnet on August 21, 2026 at 14:00 UTC. The forthcoming v1.13.0 release is required; see the [Network Upgrades and Releases table](/docs/guide/node/network-upgrades#node-operator-updates) for the current node-operator release status.
+:::
+
+## Timeline
+
+| Network | Date | Unix timestamp |
+|---------|------|----------------|
+| Testnet | August 20, 2026 at 14:00 UTC | `1787234400` |
+| Mainnet | August 21, 2026 at 14:00 UTC | `1787320800` |
+
+Node operators must run v1.13.0 before T10 activates on their network to stay synced.
+
+## T10 upgrade overview
+
+T10 introduces three related protocol changes:
+
+- **Native zone creation.** `ZoneFactory` becomes a precompile at `0x5AF2000000000000000000000000000000000000`.
+- **Deterministic zone portals.** Every new zone receives a `ZonePortal` account whose address encodes its zone ID.
+- **Protocol-managed shared runtimes.** The hardfork installs canonical portal, verifier, and messenger runtimes at reserved addresses.
+
+Read the [TIP-1091 specification](https://github.com/tempoxyz/tempo/blob/main/tips/tip-1091.md).
+
+## Native `ZoneFactory`
+
+Zone creation moves from a separately deployed factory contract into the Tempo protocol. The native factory retains the canonical registry behavior, including sequential zone IDs, `zones`, `nextZoneId`, `isZonePortal`, and the `ZoneCreated` event.
+
+The initial T10 rollout is permissioned. Only the factory owner can call `createZone`; a later hardfork can open zone creation. A successful `createZone` call consumes at least 15,000,000 gas.
+
+An initial TIP-20 token must have an explicit [TIP-403 policy binding](/docs/protocol/upgrades/t9) before the factory can create a zone with it.
+
+## Deterministic `ZonePortal` accounts
+
+Each zone receives a portal at a reserved vanity address. The high 12 bytes are the fixed prefix `0x5AD000000000000000000000`, and the low 8 bytes contain the zone ID in big-endian form. For example, zone ID `1` maps to:
+
+```text
+0x5AD0000000000000000000000000000000000001
+```
+
+Use `ZoneFactory.isZonePortal(address)` to validate portal addresses instead of reproducing the prefix and zone-ID checks in application code.
+
+Each portal is an ERC-1167 proxy to a shared, protocol-managed implementation. Portals keep independent state while using the same canonical logic.
+
+## Protocol-managed Zone runtimes
+
+At activation, T10 installs the factory and three shared runtimes atomically:
+
+| Component | Address |
+|-----------|---------|
+| `ZoneFactory` | `0x5AF2000000000000000000000000000000000000` |
+| `ZonePortal` implementation | `0x5AD1000000000000000000000000000000000000` |
+| Zone verifier | `0x5a56000000000000000000000000000000000000` |
+| Zone messenger | `0x5A4d000000000000000000000000000000000000` |

src/pages/docs/protocol/zones/architecture.mdx

@@ -66,6 +66,15 @@ The system consists of contracts on both Tempo Mainnet and within each Tempo Zon
 - **`ZonePortal`** is the central bridge contract. It locks all deposited tokens, verifies validity proofs, and processes withdrawals. The Zone Portal contract maintains the authoritative state: which deposits have been made, which batches have been proven, and which withdrawals are pending.
 - **`ZoneMessenger`** handles withdrawals that include callbacks. When a user wants to withdraw tokens and trigger a contract call atomically, the messenger executes both operations together. If the callback fails, the entire withdrawal reverts and funds bounce back to the zone.
 
+The protocol manages the shared Tempo contracts at these addresses:
+
+| Component | Address |
+|-----------|---------|
+| `ZoneFactory` | `0x5AF2000000000000000000000000000000000000` |
+| `ZonePortal` implementation | `0x5AD1000000000000000000000000000000000000` |
+| Zone verifier | `0x5a56000000000000000000000000000000000000` |
+| `ZoneMessenger` | `0x5A4d000000000000000000000000000000000000` |
+
 ### Zone Predeploys
 
 Tempo Zones have four system contract predeploys at fixed addresses:

vocs.config.ts

@@ -893,6 +893,11 @@ export default defineConfig({
             text: 'Network Upgrades',
             collapsed: false,
             items: [
+              {
+                text: 'T10',
+                badge: { text: 'Planned', variant: 'note' as const },
+                link: '/docs/protocol/upgrades/t10',
+              },
               {
                 text: 'T9',
                 badge: { text: 'Latest', variant: 'info' as const },