docs(ecosystem-adapters): keep parent ecosystem nav on adapter routes

Use lastEcosystem for /ecosystem-adapters like relayer/monitor; drop
standalone ecosystemAdaptersTree. Add tab url rules and midnight context.
Polish MDX prose; document viem isAddress for EVM addressing.

Author: pasevin

content/ecosystem-adapters/architecture.mdx

@@ -2,7 +2,7 @@
 title: Architecture
 ---
 
-This page describes the capability-based architecture that underpins all OpenZeppelin Ecosystem Adapters. Understanding this architecture will help you choose the right profile for your application, consume capabilities efficiently, and — if needed — build your own adapter.
+This page describes the capability-based architecture that underpins all OpenZeppelin Ecosystem Adapters. Understanding this architecture will help you choose the right profile for your application, consume capabilities efficiently, and build your own adapter if you need to.
 
 ## Package Topology
 
@@ -54,7 +54,7 @@ Tier isolation is enforced physically through sub-path exports, not tree-shaking
 - **Tier 2** modules may import from Tier 1
 - **Tier 3** modules may import from Tier 1 and Tier 2
 
-This means importing `@openzeppelin/adapter-evm/addressing` will never pull in wallet SDKs, RPC clients, or access control code — regardless of your bundler configuration.
+This means importing `@openzeppelin/adapter-evm/addressing` will never pull in wallet SDKs, RPC clients, or access control code, regardless of your bundler configuration.
 
 ### Capability Reference
 
@@ -76,11 +76,11 @@ This means importing `@openzeppelin/adapter-evm/addressing` will never pull in w
 
 ## Profiles
 
-Profiles are pre-composed bundles of capabilities that match common application archetypes. They exist for convenience — you can always consume individual capabilities directly via the `CapabilityFactoryMap`.
+Profiles are pre-composed bundles of capabilities that match common application archetypes. They exist for convenience. You can always consume individual capabilities directly via the `CapabilityFactoryMap`.
 
-Each profile is a strict superset of Declarative — higher profiles add capabilities incrementally:
+Each profile is a strict superset of Declarative. Higher profiles add capabilities incrementally:
 
-### Profile–Capability Matrix
+### Profile-Capability Matrix
 
 | Capability | Declarative | Viewer | Transactor | Composer | Operator |
 | --- | --- | --- | --- | --- | --- |
@@ -138,11 +138,11 @@ sequenceDiagram
 
 ### Dispose Contract
 
-- `dispose()` is **idempotent** — calling it multiple times is a no-op
+- `dispose()` is **idempotent**: calling it multiple times is a no-op
 - After `dispose()`, any method or property access throws `RuntimeDisposedError`
 - Pending async operations (e.g., in-flight `signAndBroadcast`) are rejected with `RuntimeDisposedError`
 - Cleanup follows a staged order: mark disposed → reject pending operations → clean up listeners and subscriptions → dispose capabilities → release wallet and RPC resources
-- Runtime disposal does **not** disconnect the wallet — disconnect is always an explicit user action
+- Runtime disposal does **not** disconnect the wallet. Disconnect is always an explicit user action
 
 ## Execution Strategies
 
@@ -172,14 +172,14 @@ The EVM and Stellar adapters ship with both EOA and Relayer strategies. Adapter
 Each adapter publishes every implemented capability and profile as a dedicated sub-path export:
 
 ```ts
-// Tier 1 — no wallet, no RPC, no heavy dependencies
+// Tier 1: no wallet, no RPC, no heavy dependencies
 import { createAddressing } from '@openzeppelin/adapter-stellar/addressing';
 import { createExplorer } from '@openzeppelin/adapter-stellar/explorer';
 
-// Tier 2 — network-aware
+// Tier 2: network-aware
 import { createQuery } from '@openzeppelin/adapter-stellar/query';
 
-// Tier 3 — wallet-dependent
+// Tier 3: wallet-dependent
 import { createExecution } from '@openzeppelin/adapter-stellar/execution';
 
 // Profile runtimes

content/ecosystem-adapters/building-an-adapter.mdx

@@ -85,12 +85,17 @@ Start with the four stateless capabilities that every adapter must provide:
 ```ts
 // capabilities/addressing.ts
 import type { AddressingCapability } from '@openzeppelin/ui-types';
+import { isAddress } from 'viem';
 
 export function createAddressing(): AddressingCapability {
   return {
     isValidAddress(address: string): boolean {
-      // Your chain's address validation logic
-      return /^0x[0-9a-fA-F]{40}$/.test(address);
+      // EVM: prefer viem's isAddress (as in @openzeppelin/adapter-evm) over a hand-rolled regex;
+      // it covers checksums and library-maintained rules.
+      // Other chains, for example:
+      // Stellar StrKey (account): /^G[A-Z0-9]{55}$/ (simplified; use StrKey helpers in production)
+      // Polkadot SS58: @polkadot/util-crypto validateAddress / decodeAddress
+      return isAddress(address);
     },
   };
 }
@@ -292,7 +297,7 @@ import { createExecution } from '@openzeppelin/adapter-evm-core/execution';
 import { createQuery } from '@openzeppelin/adapter-evm-core/query';
 ```
 
-This is exactly what `adapter-polkadot` does — it delegates ABI loading, queries, transaction execution, and wallet infrastructure to the shared EVM core while adding Polkadot-specific metadata and network configurations.
+This is exactly what `adapter-polkadot` does. It delegates ABI loading, queries, transaction execution, and wallet infrastructure to the shared EVM core while adding Polkadot-specific metadata and network configurations.
 
 ## Lazy Capability Factories
 

content/ecosystem-adapters/getting-started.mdx

@@ -28,7 +28,7 @@ pnpm add @openzeppelin/adapter-stellar @openzeppelin/ui-types
 pnpm add @openzeppelin/adapter-polkadot @openzeppelin/ui-types
 ```
 
-If you're consuming multiple ecosystems, install all of them — each adapter is independent and tree-shakeable.
+If you're consuming multiple ecosystems, install all of them. Each adapter is independent and tree-shakeable.
 
 ## Quick Start
 
@@ -56,7 +56,7 @@ const network = ecosystemDefinition.networks[0]; // e.g., Ethereum Mainnet
 const runtime = ecosystemDefinition.createRuntime('viewer', network);
 ```
 
-The `createRuntime` call is **synchronous** — it assembles capability instances immediately. Expensive initialization (RPC connections, wallet discovery) happens lazily on first use.
+The `createRuntime` call is **synchronous**. It assembles capability instances immediately. Expensive initialization (RPC connections, wallet discovery) happens lazily on first use.
 
 If you request a profile the adapter doesn't fully support, `createRuntime` throws an `UnsupportedProfileError` listing the missing capabilities.
 
@@ -65,10 +65,10 @@ If you request a profile the adapter doesn't fully support, `createRuntime` thro
 Access capabilities directly from the runtime object:
 
 ```ts
-// Validate an address (Tier 1 — instant, no network call)
+// Validate an address (Tier 1: instant, no network call)
 const isValid = runtime.addressing.isValidAddress('0x1234...');
 
-// Read contract state (Tier 2 — triggers RPC on first call)
+// Read contract state (Tier 2: triggers RPC on first call)
 const result = await runtime.query.queryViewFunction(
   '0xContractAddress',
   'balanceOf',
@@ -149,7 +149,7 @@ export default mergeConfig(
 );
 ```
 
-This centralizes `resolve.dedupe`, `optimizeDeps`, `ssr.noExternal`, and any adapter-specific Vite plugins — adapters remain the source of truth for their own build requirements.
+This centralizes `resolve.dedupe`, `optimizeDeps`, `ssr.noExternal`, and any adapter-specific Vite plugins. Adapters remain the source of truth for their own build requirements.
 
 ## Network Switching
 
@@ -194,7 +194,7 @@ Adapters integrate with React through three layers: a **wallet context provider*
 
 ### Wallet Context Provider
 
-Each adapter exports a root React component via `getEcosystemReactUiContextProvider()`. This component wraps your application (or the relevant subtree) and bootstraps the wallet SDK context — for example, EVM adapters render `WagmiProvider` and `QueryClientProvider` internally, while the Stellar adapter renders its own `StellarWalletContext.Provider`.
+Each adapter exports a root React component via `getEcosystemReactUiContextProvider()`. This component wraps your application (or the relevant subtree) and bootstraps the wallet SDK context. For example, EVM adapters render `WagmiProvider` and `QueryClientProvider` internally, while the Stellar adapter renders its own `StellarWalletContext.Provider`.
 
 You don't render these providers yourself. Instead, pass the runtime to a shared `WalletStateProvider` from `@openzeppelin/ui-react`, which delegates to the correct ecosystem provider automatically:
 
@@ -266,7 +266,7 @@ await runtime.wallet.disconnectWallet();
 ```
 
 <Callout type="info">
-`connectWallet` and `disconnectWallet` are imperative calls on the runtime — they are independent of the React rendering layer. You can call them from event handlers, effects, or outside React entirely.
+`connectWallet` and `disconnectWallet` are imperative calls on the runtime. They are independent of the React rendering layer. You can call them from event handlers, effects, or outside React entirely.
 </Callout>
 
 ### Hook Facade Pattern
@@ -295,7 +295,7 @@ Each facade object includes these hooks:
 | `useChains` | Returns the list of configured chains |
 | `useBalance` | Returns the native token balance for the connected account |
 
-In practice, you access facade hooks through the runtime rather than importing them directly — the runtime's `uiKit.getEcosystemReactHooks()` method returns the correct facade for the active ecosystem:
+In practice, you access facade hooks through the runtime rather than importing them directly. The runtime's `uiKit.getEcosystemReactHooks()` method returns the correct facade for the active ecosystem:
 
 ```tsx
 import { useWalletState } from '@openzeppelin/ui-react';
@@ -320,12 +320,12 @@ function AccountInfo() {
 ```
 
 <Callout type="info">
-Hooks that don't apply to a given ecosystem return safe stubs. For example, the Stellar facade's `useSwitchChain` returns `{ switchChain: undefined }` — your components can feature-detect this without conditional imports.
+Hooks that don't apply to a given ecosystem return safe stubs. For example, the Stellar facade's `useSwitchChain` returns `{ switchChain: undefined }`. Your components can feature-detect this without conditional imports.
 </Callout>
 
 ## Multi-Ecosystem Apps
 
-Applications that interact with multiple blockchains create one runtime per ecosystem. Each runtime is independent — it manages its own wallet session, RPC connections, and lifecycle.
+Applications that interact with multiple blockchains create one runtime per ecosystem. Each runtime is independent. It manages its own wallet session, RPC connections, and lifecycle.
 
 ### Setup
 
@@ -359,16 +359,16 @@ Instantiate a runtime from each adapter's `ecosystemDefinition`:
 import { ecosystemDefinition as evmDefinition } from '@openzeppelin/adapter-evm';
 import { ecosystemDefinition as stellarDefinition } from '@openzeppelin/adapter-stellar';
 
-// EVM runtime — e.g., Ethereum Mainnet
+// EVM runtime (e.g. Ethereum Mainnet)
 const evmNetwork = evmDefinition.networks[0];
 const evmRuntime = evmDefinition.createRuntime('composer', evmNetwork);
 
-// Stellar runtime — e.g., Stellar Mainnet
+// Stellar runtime (e.g. Stellar Mainnet)
 const stellarNetwork = stellarDefinition.networks[0];
 const stellarRuntime = stellarDefinition.createRuntime('viewer', stellarNetwork);
 ```
 
-Each runtime is fully isolated. The EVM runtime connects to Ethereum via wagmi, the Stellar runtime connects to Horizon/Soroban — they share no state and can be disposed independently:
+Each runtime is fully isolated. The EVM runtime connects to Ethereum via wagmi, the Stellar runtime connects to Horizon/Soroban. They share no state and can be disposed independently:
 
 ```ts
 // Use both runtimes side by side
@@ -385,7 +385,7 @@ evmRuntime.dispose();
 ```
 
 <Callout type="info">
-Wallet sessions are ecosystem-scoped, not runtime-scoped. Disposing an EVM runtime to switch from Mainnet to Sepolia does not disconnect the user's MetaMask — the wallet session persists across runtime recreation within the same ecosystem.
+Wallet sessions are ecosystem-scoped, not runtime-scoped. Disposing an EVM runtime to switch from Mainnet to Sepolia does not disconnect the user's MetaMask. The wallet session persists across runtime recreation within the same ecosystem.
 </Callout>
 
 ## Next Steps

content/ecosystem-adapters/index.mdx

@@ -2,7 +2,7 @@
 title: Ecosystem Adapters
 ---
 
-**OpenZeppelin Ecosystem Adapters** are a set of modular, chain-specific integration packages that let applications interact with any supported blockchain through a single, unified interface. Built on 13 composable capability interfaces organized in 3 tiers, each adapter encapsulates everything needed — contract loading, type mapping, transaction execution, wallet connection, and network configuration — while keeping consuming applications completely chain-agnostic.
+**OpenZeppelin Ecosystem Adapters** are a set of modular, chain-specific integration packages that let applications interact with any supported blockchain through a single, unified interface. Built on 13 composable capability interfaces organized in 3 tiers, each adapter encapsulates contract loading, type mapping, transaction execution, wallet connection, and network configuration in one place, while keeping consuming applications completely chain-agnostic.
 
 <Callout type="info">
 **Source code**: The adapters are open-source. Browse the implementation, open issues, and contribute at [**github.com/OpenZeppelin/openzeppelin-adapters**](https://github.com/OpenZeppelin/openzeppelin-adapters).
@@ -25,14 +25,14 @@ title: Ecosystem Adapters
 
 ## Why Adapters?
 
-Building cross-chain tooling traditionally forces developers into one of two traps: a monolithic abstraction that leaks chain details, or per-chain forks that drift apart over time. Adapters solve this with a **capability-based decomposition** — each chain implements only the interfaces it supports, and consuming applications pull in only what they need.
+Building cross-chain tooling traditionally forces developers into one of two traps: a monolithic abstraction that leaks chain details, or per-chain forks that drift apart over time. Adapters solve this with a **capability-based decomposition**. Each chain implements only the interfaces it supports, and consuming applications pull in only what they need.
 
 ```mermaid
 flowchart LR
     App["Your Application"] --> Runtime["EcosystemRuntime"]
-    Runtime --> T1["Tier 1 — Lightweight\n4 capabilities\nAddressing, Explorer, ..."]
-    Runtime --> T2["Tier 2 — Schema\n4 capabilities\nContractLoading, Query, ..."]
-    Runtime --> T3["Tier 3 — Runtime\n5 capabilities\nExecution, Wallet, ..."]
+    Runtime --> T1["Tier 1 (Lightweight)\n4 capabilities\nAddressing, Explorer, ..."]
+    Runtime --> T2["Tier 2 (Schema)\n4 capabilities\nContractLoading, Query, ..."]
+    Runtime --> T3["Tier 3 (Runtime)\n5 capabilities\nExecution, Wallet, ..."]
 
     style T1 fill:#e3f2fd,stroke:#1976d2,color:#000
     style T2 fill:#fff3e0,stroke:#f57c00,color:#000
@@ -41,10 +41,10 @@ flowchart LR
 
 ## Key Design Principles
 
-- **Pay for what you use.** Tier 1 capabilities are stateless and never pull in wallet SDKs or RPC clients. Import `addressing` and you get only address validation — nothing more.
+- **Pay for what you use.** Tier 1 capabilities are stateless and never pull in wallet SDKs or RPC clients. Import `addressing` and you get only address validation; nothing else is bundled.
 - **Profiles simplify consumption.** Five pre-composed profiles (Declarative, Viewer, Transactor, Composer, Operator) match common application archetypes so you don't have to assemble capabilities manually.
-- **Adapters own their chains.** All chain-specific logic — ABI parsing, Soroban type mapping, ZK proof orchestration — stays inside the adapter package. The consuming application never touches it.
-- **Runtime lifecycle is explicit.** Runtimes are immutable and network-scoped. Switching networks means disposing the old runtime and creating a new one — no hidden state mutations.
+- **Adapters own their chains.** All chain-specific logic (ABI parsing, Soroban type mapping, ZK proof orchestration) stays inside the adapter package. The consuming application never touches it.
+- **Runtime lifecycle is explicit.** Runtimes are immutable and network-scoped. Switching networks means disposing the old runtime and creating a new one. There are no hidden state mutations.
 
 ## Packages
 
@@ -63,10 +63,10 @@ flowchart LR
 
 Adapters are consumed by several OpenZeppelin products:
 
-- [**UI Builder**](https://github.com/OpenZeppelin/ui-builder) — full-featured smart contract interaction UI
-- [**OpenZeppelin UI**](https://github.com/OpenZeppelin/openzeppelin-ui) — shared UI components and React integration
-- [**UIKit example app (live)**](https://openzeppelin-ui.netlify.app) — hosted demo of OpenZeppelin UI with ecosystem adapters
-- [**Role Manager**](https://github.com/OpenZeppelin/role-manager) — role and permission management tool
-- [**RWA Wizard**](https://github.com/OpenZeppelin/rwa-wizard) — real-world asset token generation
+- [**UI Builder**](https://github.com/OpenZeppelin/ui-builder): full-featured smart contract interaction UI
+- [**OpenZeppelin UI**](https://github.com/OpenZeppelin/openzeppelin-ui): shared UI components and React integration
+- [**UIKit example app (live)**](https://openzeppelin-ui.netlify.app): hosted demo of OpenZeppelin UI with ecosystem adapters
+- [**Role Manager**](https://github.com/OpenZeppelin/role-manager): role and permission management tool
+- [**RWA Wizard**](https://github.com/OpenZeppelin/rwa-wizard): real-world asset token generation
 
 Any TypeScript application that needs chain-agnostic blockchain interaction can use adapters directly.