docs: expand capabilities 13→17 (ENS name resolution + RWA capabilities)

content/ecosystem-adapters/architecture.mdx

@@ -31,20 +31,20 @@ flowchart TD
     style Core fill:#fff3e0,stroke:#ef6c00,color:#000
 ```
 
-- **`@openzeppelin/ui-types`** defines all 13 capability interfaces. It is the single source of truth.
+- **`@openzeppelin/ui-types`** defines all 17 capability interfaces. It is the single source of truth.
 - **`adapter-runtime-utils`** provides profile composition, lazy capability instantiation, and staged disposal.
 - **`adapter-evm-core`** centralizes reusable EVM implementations shared by `adapter-evm` and `adapter-polkadot`.
 - Each public adapter exposes an `ecosystemDefinition` conforming to `EcosystemExport`.
 
 ## Capability Tiers
 
-Adapter functionality is decomposed into **13 capability interfaces** organized across **3 tiers**. The tiers reflect increasing levels of runtime requirements: stateless metadata, network-aware schema operations, and stateful wallet-dependent interactions.
+Adapter functionality is decomposed into **17 capability interfaces** organized across **3 tiers**. The tiers reflect increasing levels of runtime requirements: stateless metadata, network-aware operations (schema parsing, read-only queries, and name resolution), and stateful wallet-dependent interactions.
 
 | Tier | Category | Network | Wallet | Capabilities |
 | --- | --- | --- | --- | --- |
 | **1** | Lightweight | No | No | `Addressing`, `Explorer`, `NetworkCatalog`, `UiLabels` |
-| **2** | Schema | Yes | No | `ContractLoading`, `Schema`, `TypeMapping`, `Query` |
-| **3** | Runtime | Yes | Yes | `Execution`, `Wallet`, `UiKit`, `Relayer`, `AccessControl` |
+| **2** | Network-Aware | Yes | No | `NameResolution`, `ContractLoading`, `Schema`, `TypeMapping`, `Query` |
+| **3** | Runtime | Yes | Yes | `Execution`, `Wallet`, `UiKit`, `Relayer`, `AccessControl`, `ERC3643`, `ERC4626`, `IRS` |
 
 ### Tier Import Rules
 
@@ -64,6 +64,7 @@ This means importing `@openzeppelin/adapter-evm/addressing` will never pull in w
 | Explorer | `ExplorerCapability` | 1 | `getExplorerUrl`, `getExplorerTxUrl` |
 | NetworkCatalog | `NetworkCatalogCapability` | 1 | `getNetworks` |
 | UiLabels | `UiLabelsCapability` | 1 | `getUiLabels` |
+| NameResolution | `NameResolutionCapability` | 2 | `isValidName`, `resolveName`, `resolveAddress` |
 | ContractLoading | `ContractLoadingCapability` | 2 | `loadContract`, `getContractDefinitionInputs` |
 | Schema | `SchemaCapability` | 2 | `isViewFunction`, `getWritableFunctions` |
 | TypeMapping | `TypeMappingCapability` | 2 | `mapParameterTypeToFieldType`, `getTypeMappingInfo` |
@@ -73,6 +74,13 @@ This means importing `@openzeppelin/adapter-evm/addressing` will never pull in w
 | UiKit | `UiKitCapability` | 3 | `getAvailableUiKits`, `configureUiKit` |
 | Relayer | `RelayerCapability` | 3 | `getRelayers`, `getNetworkServiceForms` |
 | AccessControl | `AccessControlCapability` | 3 | `registerContract`, `grantRole`, and 17 more |
+| ERC3643 | `ERC3643Capability` | 3 | `balanceOf`, `isVerified`, `simulateTransfer`, `mint`, `transfer`, `freeze`, and more |
+| ERC4626 | `ERC4626Capability` | 3 | `convertToAssets`, `convertToShares`, `totalAssets`, `deposit`, `withdraw` |
+| IRS | `IRSCapability` | 3 | `getOnchainId`, `isVerified`, `buildClaimPayload`, `deployOnchainId`, `registerIdentity`, and more |
+
+<Callout type="info">
+**Optional capabilities.** `NameResolution` is gated on factory presence and surfaces on every profile when the adapter provides it — it is not a profile requirement. `ERC3643`, `ERC4626`, and `IRS` are EVM-only, opt-in capabilities imported via dedicated sub-path exports (`@openzeppelin/adapter-evm/erc3643`, etc.); they are not assembled into standard profile runtimes.
+</Callout>
 
 ## Profiles
 
@@ -88,6 +96,7 @@ Each profile is a strict superset of Declarative. Higher profiles add capabiliti
 | `Explorer` | ✅ | ✅ | ✅ | ✅ | ✅ |
 | `NetworkCatalog` | ✅ | ✅ | ✅ | ✅ | ✅ |
 | `UiLabels` | ✅ | ✅ | ✅ | ✅ | ✅ |
+| `NameResolution` | ✅* | ✅* | ✅* | ✅* | ✅* |
 | `ContractLoading` | | ✅ | ✅ | ✅ | ✅ |
 | `Schema` | | ✅ | ✅ | ✅ | ✅ |
 | `TypeMapping` | | ✅ | ✅ | ✅ | ✅ |
@@ -98,6 +107,8 @@ Each profile is a strict superset of Declarative. Higher profiles add capabiliti
 | `Relayer` | | | | ✅ | |
 | `AccessControl` | | | | | ✅ |
 
+\* `NameResolution` is optional and adapter-gated. When the adapter's `CapabilityFactoryMap` includes `nameResolution`, the capability is exposed on every profile; adapters without it leave `runtime.nameResolution` undefined.
+
 ### Profile Selection Guide
 
 | If your application needs to… | Choose |

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

@@ -6,14 +6,14 @@ This guide walks through implementing a new ecosystem adapter from scratch. By t
 
 ## How Much Do You Need to Implement?
 
-Adapters are **incrementally adoptable**. You don't need to implement all 13 capabilities to ship a useful adapter. Start small and add capabilities as your ecosystem's support matures.
+Adapters are **incrementally adoptable**. You don't need to implement all 17 capabilities to ship a useful adapter. Start small and add capabilities as your ecosystem's support matures.
 
 ```mermaid
 flowchart TD
     Start["Start Here"] --> T1["Implement Tier 1\n(4 capabilities)"]
     T1 -->|"Unlocks"| Dec["Declarative Profile\nAddress validation, explorer links,\nnetwork catalogs"]
 
-    T1 --> T2["Add Tier 2\n(4 capabilities)"]
+    T1 --> T2["Add Tier 2\n(5 capabilities)"]
     T2 -->|"Unlocks"| View["Viewer Profile\nContract reading, schema parsing,\ntype mapping, queries"]
 
     T2 --> T3a["Add Execution + Wallet"]
@@ -25,6 +25,9 @@ flowchart TD
     T3a --> T3c["Add UiKit + AccessControl"]
     T3c -->|"Unlocks"| Op["Operator Profile\nRole and permission\nmanagement"]
 
+    T3a --> T3d["Add RWA caps (optional)"]
+    T3d -->|"Unlocks"| RWA["ERC3643 / ERC4626 / IRS\nRegulated-asset workflows\n(EVM sub-path exports)"]
+
     style Start fill:#e8eaf6,stroke:#3f51b5,color:#000
     style T1 fill:#e3f2fd,stroke:#1976d2,color:#000
     style T2 fill:#fff3e0,stroke:#f57c00,color:#000
@@ -50,7 +53,8 @@ packages/adapter-<chain>/
 │   │   ├── explorer.ts
 │   │   ├── network-catalog.ts
 │   │   ├── ui-labels.ts
-│   │   ├── contract-loading.ts    # Tier 2+
+│   │   ├── name-resolution.ts   # Tier 2 (optional)
+│   │   ├── contract-loading.ts  # Tier 2+
 │   │   ├── schema.ts
 │   │   ├── type-mapping.ts
 │   │   ├── query.ts
@@ -59,6 +63,9 @@ packages/adapter-<chain>/
 │   │   ├── ui-kit.ts
 │   │   ├── relayer.ts
 │   │   ├── access-control.ts
+│   │   ├── erc3643.ts             # Tier 3 (opt-in sub-path)
+│   │   ├── erc4626.ts
+│   │   ├── irs.ts
 │   │   └── index.ts
 │   ├── profiles/              # Profile runtime factories
 │   │   ├── shared-state.ts

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 contract loading, type mapping, transaction execution, wallet connection, and network configuration in one place, 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 17 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).
@@ -31,8 +31,8 @@ Building cross-chain tooling traditionally forces developers into one of two tra
 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 --> T2["Tier 2 (Network-Aware)\n5 capabilities\nNameResolution, ContractLoading, ..."]
+    Runtime --> T3["Tier 3 (Runtime)\n8 capabilities\nExecution, Wallet, ERC3643, ..."]
 
     style T1 fill:#e3f2fd,stroke:#1976d2,color:#000
     style T2 fill:#fff3e0,stroke:#f57c00,color:#000

content/ecosystem-adapters/supported-ecosystems.mdx

@@ -2,31 +2,33 @@
 title: Supported Ecosystems
 ---
 
-Each adapter implements the subset of the [13 capability interfaces](/ecosystem-adapters/architecture#capability-tiers) that its blockchain supports. This page summarizes what each production adapter provides.
+Each adapter implements the subset of the [17 capability interfaces](/ecosystem-adapters/architecture#capability-tiers) that its blockchain supports. Summary counts match the [capability matrix](#capability-support-matrix) below: one checkmark per implemented factory in the adapter's `CapabilityFactoryMap`, plus EVM-only RWA capabilities available as sub-path exports.
 
 | Adapter | Networks | Capabilities | Status |
 | --- | --- | --- | --- |
-| **EVM** | Ethereum, Polygon, Arbitrum, Base, Optimism, ... | 13/13 | Production |
-| **Stellar** | Stellar Public, Stellar Testnet | 13/13 | Production |
-| **Polkadot** | Polkadot Hub, Moonbeam, Moonriver | 13/13 (EVM path) | Production |
-| **Midnight** | Midnight Testnet | 11/13 | Production |
-| **Solana** | Devnet, Testnet, Mainnet Beta | 4/13 (Tier 1 only) | Scaffolding |
+| **EVM** | Ethereum, Polygon, Arbitrum, Base, Optimism, ... | 17/17 | Production |
+| **Stellar** | Stellar Public, Stellar Testnet | 13/17 | Production |
+| **Polkadot** | Polkadot Hub, Moonbeam, Moonriver | 13/17 (EVM path) | Production |
+| **Midnight** | Midnight Testnet | 12/17 | Production |
+| **Solana** | Devnet, Testnet, Mainnet Beta | 12/17 (scaffolding) | In Progress |
 
 ## EVM (`@openzeppelin/adapter-evm`)
 
-The EVM adapter targets Ethereum and all EVM-compatible chains. It implements the full set of 13 capabilities and supports all 5 profiles.
+The EVM adapter targets Ethereum and all EVM-compatible chains. It implements all 17 capabilities and supports all 5 profiles. Standard `createRuntime` profiles expose 14 capabilities (including `nameResolution`); the three RWA/token-standard capabilities (`erc3643`, `erc4626`, `irs`) are available as dedicated sub-path exports for opt-in composition.
 
 **Supported Networks**: Ethereum Mainnet, Sepolia, Polygon, Polygon Amoy, Arbitrum One, Arbitrum Sepolia, Base, Base Sepolia, Optimism, Optimism Sepolia, and more.
 
 **Profiles Supported**: Declarative, Viewer, Transactor, Composer, Operator
 
 ### Highlights
 
+- **Name Resolution**: Forward and reverse ENS resolution via viem and the Universal Resolver. Network-scoped, with optional mainnet-L1 miss-fallback for testnets.
 - **Contract Loading**: Fetches ABIs from Etherscan and Sourcify with automatic fallback ordering. Detects proxy contracts and resolves implementation ABIs.
 - **Type Mapping**: Maps all Solidity types (`uint256`, `address`, `bytes32`, tuples, dynamic arrays) to UI-friendly form fields.
 - **Execution Strategies**: Pluggable EOA (direct wallet signing via Wagmi/Viem) and OpenZeppelin Relayer strategies.
 - **Wallet Integration**: Built on Wagmi and RainbowKit with React context providers and hooks.
 - **Access Control**: Full role management including `grantRole`, `revokeRole`, `renounceRole`, ownership transfers, and role enumeration.
+- **RWA / Token Standards** (sub-path exports): `erc3643` (T-REX permissioned tokens), `erc4626` (tokenized vaults), and `irs` (ONCHAINID / Identity Registry Storage) for regulated-asset workflows.
 
 ### Configuration Resolution
 
@@ -53,7 +55,7 @@ The EVM adapter resolves RPC URLs and explorer API keys through a layered priori
 
 ## Stellar (`@openzeppelin/adapter-stellar`)
 
-The Stellar adapter provides a complete Soroban implementation with all 13 capabilities.
+The Stellar adapter provides a complete Soroban implementation with 13 of 17 capabilities (all profile capabilities except `nameResolution` and the EVM-only RWA trio).
 
 **Supported Networks**: Stellar Public, Stellar Testnet
 
@@ -89,7 +91,7 @@ Non-EVM execution paths (native Substrate) are not yet implemented. Requesting a
 
 ## Midnight (`@openzeppelin/adapter-midnight`)
 
-The Midnight adapter enables browser-based interaction with Midnight contracts using zero-knowledge proof workflows.
+The Midnight adapter enables browser-based interaction with Midnight contracts using zero-knowledge proof workflows. It implements **12 of 17** capabilities: all profile capabilities except `nameResolution`, `accessControl`, and the EVM-only RWA trio (`erc3643`, `erc4626`, `irs`).
 
 **Supported Networks**: Midnight Testnet
 
@@ -122,11 +124,11 @@ const adapterConfigs = await loadOpenZeppelinAdapterViteConfig({
 The Solana adapter is scaffolding only and is not yet production-ready.
 </Callout>
 
-The Solana package defines the package boundaries and network configurations for a future adapter. It currently provides:
+The Solana package defines the package boundaries and network configurations for a future adapter. Its `CapabilityFactoryMap` currently registers **12 of 17** capabilities (Tier 1 through `relayer`); `nameResolution`, `accessControl`, and the EVM-only RWA trio are absent. Tier 2–3 factories exist as scaffolding stubs and are not production-ready.
 
 - Solana network configurations (Devnet, Testnet, Mainnet Beta)
 - Package structure and sub-path export scaffolding
-- Tier 1 capability implementations (Addressing, Explorer, NetworkCatalog, UiLabels)
+- Tier 1 capability implementations (Addressing, Explorer, NetworkCatalog, UiLabels) plus stub Tier 2–3 factories
 
 The Operator profile is explicitly unsupported. Calling `createRuntime('operator', ...)` throws `UnsupportedProfileError` because `accessControl` factories are not yet implemented.
 
@@ -138,12 +140,20 @@ The Operator profile is explicitly unsupported. Calling `createRuntime('operator
 | Explorer | ✅ | ✅ | ✅ | ✅ | ✅ |
 | NetworkCatalog | ✅ | ✅ | ✅ | ✅ | ✅ |
 | UiLabels | ✅ | ✅ | ✅ | ✅ | ✅ |
-| ContractLoading | ✅ | ✅ | ✅ | ✅ | - |
-| Schema | ✅ | ✅ | ✅ | ✅ | - |
-| TypeMapping | ✅ | ✅ | ✅ | ✅ | - |
-| Query | ✅ | ✅ | ✅ | ✅ | - |
-| Execution | ✅ | ✅ | ✅ (EVM) | ✅ | - |
-| Wallet | ✅ | ✅ | ✅ | ✅ | - |
-| UiKit | ✅ | ✅ | ✅ | ✅ | - |
-| Relayer | ✅ | ✅ | ✅ | - | - |
+| NameResolution | ✅ | - | - | - | - |
+| ContractLoading | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Schema | ✅ | ✅ | ✅ | ✅ | ✅ |
+| TypeMapping | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Query | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Execution | ✅ | ✅ | ✅ (EVM) | ✅ | ✅ |
+| Wallet | ✅ | ✅ | ✅ | ✅ | ✅ |
+| UiKit | ✅ | ✅ | ✅ | ✅ | ✅ |
+| Relayer | ✅ | ✅ | ✅ | ✅ | ✅ |
 | AccessControl | ✅ | ✅ | ✅ | - | - |
+| ERC3643 | ✅† | - | - | - | - |
+| ERC4626 | ✅† | - | - | - | - |
+| IRS | ✅† | - | - | - | - |
+
+† EVM-only. Available via `@openzeppelin/adapter-evm/erc3643`, `/erc4626`, and `/irs` sub-path exports; not assembled into standard profile runtimes.
+
+Counts are derived from each adapter's `CapabilityFactoryMap` in `openzeppelin-adapters` (`profiles/shared*.ts`), plus the three EVM RWA sub-path factories. Midnight is missing `nameResolution`, `accessControl`, and the RWA trio (12 ✅). Solana registers stub Tier 2–3 factories but remains scaffolding.

content/tools/uikit/architecture.mdx

@@ -50,16 +50,16 @@ flowchart TD
 <a id="capabilities"></a>
 ## Capabilities
 
-The UIKit type system defines 13 **capabilities**: small, focused interfaces that describe what an adapter can do.
+The UIKit type system defines 17 **capabilities**: small, focused interfaces that describe what an adapter can do.
 
 Capabilities are organized into three tiers based on their requirements:
 
 ```mermaid
 %%{init: {'flowchart': {'nodeSpacing': 30, 'rankSpacing': 30}} }%%
 flowchart TD
   T1["<b>Tier 1 (Lightweight)</b><br/>Addressing · Explorer · NetworkCatalog · UiLabels"]
-  T2["<b>Tier 2 (Network-Aware)</b><br/>ContractLoading · Schema · TypeMapping · Query"]
-  T3["<b>Tier 3 (Stateful)</b><br/>Execution · Wallet · UiKit · Relayer · AccessControl"]
+  T2["<b>Tier 2 (Network-Aware)</b><br/>NameResolution · ContractLoading · Schema · TypeMapping · Query"]
+  T3["<b>Tier 3 (Stateful)</b><br/>Execution · Wallet · UiKit · Relayer · AccessControl · ERC3643 · ERC4626 · IRS"]
 
   T1 --"may import"--> T2 --"may import"--> T3
 
@@ -76,6 +76,7 @@ flowchart TD
 | `Explorer` | 1 | Block explorer URL generation |
 | `NetworkCatalog` | 1 | Available network listing and metadata |
 | `UiLabels` | 1 | Human-readable labels for ecosystem-specific terms |
+| `NameResolution` | 2 | Forward (name → address) and reverse (address → name) resolution |
 | `ContractLoading` | 2 | Fetch and parse contract ABIs/IDLs |
 | `Schema` | 2 | Transform contract definitions into form-renderable schemas |
 | `TypeMapping` | 2 | Map blockchain types (e.g. `uint256`) to form field types |
@@ -85,6 +86,13 @@ flowchart TD
 | `UiKit` | 3 | Ecosystem-specific React components and hooks |
 | `Relayer` | 3 | Gas-sponsored transaction execution via relayers |
 | `AccessControl` | 3 | Role-based access control queries and snapshots |
+| `ERC3643` | 3 | ERC-3643 (T-REX) permissioned token reads and writes |
+| `ERC4626` | 3 | ERC-4626 tokenized-vault reads and writes |
+| `IRS` | 3 | ONCHAINID / Identity Registry Storage onboarding flows |
+
+<Callout type="info">
+`NameResolution` is optional and adapter-gated — when present it surfaces on every profile runtime. `ERC3643`, `ERC4626`, and `IRS` are EVM-only opt-in capabilities imported via adapter sub-path exports; see [Supported Ecosystems](/ecosystem-adapters/supported-ecosystems#capability-support-matrix).
+</Callout>
 
 ### Capability Bundles