ChainAgnostic · paperclip-minim · May 19, 2026 · May 19, 2026 · May 19, 2026 · May 19, 2026
diff --git a/_template/caip350.md b/_template/caip350.md
@@ -24,15 +24,15 @@ ChainType binary key: `0xXXXX`
 <!-- this defines ONLY the chainReference portion; per CAIP-350, the full chain identifier is <namespace>:<chainReference> -->
 <!-- MUST include how to represent the ChainType without a reference, since that is supported by [ERC-7930] -->
 
-##### Text representation -> customary (CAIP-2) conversion
+#### Text -> customary (CAIP-2) conversion
 
 <!-- instructions for how to convert from the above to a CAIP-2 string -->
 
-##### Customary (CAIP-2) conversion - text representation conversion
+#### Customary (CAIP-2) -> text conversion
 
 <!-- instructions for how to convert from a CAIP-2 string to this standard's text representation -->
 
-#### Binary representation
+### Binary representation
 
 <!-- description of how will chain references be laid out in binary Interoperable Addresses' `ChainReference` field -->
 
@@ -44,26 +44,26 @@ ChainType binary key: `0xXXXX`
 
 <!-- instructions for converting from the text representation to the binary one -->
 
-#### Examples
+### Examples
 
 ## Addresses
 
 ### Text representation
 
 <!-- a description of the format of addresses intended for the text representation of ERC-7930 Interoperable Addresses -->
 
-##### Text representation -> native representation conversion
+#### Text -> native conversion
 
 <!-- instructions for how to convert from the above to the native address formats normally used in the ecosystem -->
 <!-- MUST cover all address types used in the ecosystem -->
 <!-- Note: actor addresses should be addressed here natively, i.e. in the native representation format -->
 
-##### Native representation -> text representation conversion
+#### Native -> text conversion
 
 <!-- instructions for how to convert from native address formats normally used in the ecosystem to the Interoperable Address text representation -->
 <!-- MUST cover all address types used in the ecosystem -->
 
-#### Binary representation
+### Binary representation
 
 <!-- description of how will addresses be laid out in binary Interoperable Addresses' `Address` field -->
 
@@ -75,17 +75,17 @@ ChainType binary key: `0xXXXX`
 
 <!-- instructions for converting from the binary representation to the text one -->
 
-#### Examples
+### Examples
 
-### Error handling
+## Error handling
 
 <!-- _(Optional section)_ -->
 
 <!-- Document any error handling considerations specific to this namespace, such as:
 - Scenarios where loss of information may occur during conversions (e.g., CAIP-2 -> CAIP-350 when full chainId can't be determined)
 - Error types and how they should be handled -->
 
-### Implementation considerations
+## Implementation considerations
 
 <!-- _(Optional section)_ -->
 
@@ -94,7 +94,7 @@ ChainType binary key: `0xXXXX`
 - Chain-wildcard limitations
 - Other implementation footguns specific to this ecosystem -->
 
-### Extra considerations
+## Extra considerations
 
 <!-- Anything that is particular to this namespace and of interest to users, such as not being able to satisfy canonicity requirements or imminent expansions/revisions to the conventions of the ecosystem -->
 
diff --git a/bip122/caip350.md b/bip122/caip350.md
@@ -30,15 +30,15 @@ This is the first 32 lowercase hex characters (16 bytes) of the genesis block ha
 
 > **Note:** Per [CAIP-350], the full chain identifier is `bip122:<genesis_hash_prefix>` (e.g., `bip122:000000000019d6689c085ae165831e93`, `bip122:000000000933ea01ad0ee984209779ba`).
 
-##### Text representation -> customary (CAIP-2) conversion
+#### Text -> customary (CAIP-2) conversion
 
 The text representation (chain reference) is the same as the chain reference in the [CAIP-2](caip2.md) chain identifier; no conversion is needed.
 
-##### Customary (CAIP-2) conversion - text representation conversion
+#### Customary (CAIP-2) -> text conversion
 
 The chain reference in the [CAIP-2](caip2.md) chain identifier is the same as the text representation; no conversion is needed.
 
-#### Binary representation
+### Binary representation
 
 The chain reference is the 16 bytes corresponding to the first 32 hex characters of the genesis block hash. Bytes are in the same order as the hex string (first two hex characters encode the first byte, etc.).
 
@@ -50,7 +50,7 @@ Decode the 32-character lowercase hex string to 16 bytes (RFC-4616 base16, no 0x
 
 Encode the 16 bytes as 32 lowercase hex characters (RFC-4616 base16, no 0x-prefix).
 
-#### Examples
+### Examples
 
 | Chain | Text (chain reference) | Binary |
 |-------|------------------------|--------------------------------|
@@ -70,11 +70,11 @@ See this namespace's [CAIP-10](caip10.md) profile. BIP122 supports multiple addr
 
 Where `<address>` is the full native ASCII form (base58btc, bech32, or bech32m) as in [CAIP-10](caip10.md)—e.g. P2SH `35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N`, SegWit `bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk`, or Taproot `bc1pmzfrwwndsqmk5yh69yjr5lfgfg4ev8c0tsc06e`.
 
-#### Text representation -> native representation conversion
+#### Text -> native conversion
 
 No transformation; the text representation is the native representation.
 
-#### Native representation -> text representation conversion
+#### Native -> text conversion
 
 No transformation; the native representation is the text representation.
 

diff --git a/eip155/caip350.md b/eip155/caip350.md
@@ -30,15 +30,15 @@ Where `<number>` is the decimal representation of the chain's `chainId`, without
 > **Note:** Per [CAIP-350], the full chain identifier is `eip155:<number>` (e.g., `eip155:1`, `eip155:10`).
 
 
-##### Text representation -> customary (CAIP-2) conversion
+#### Text -> customary (CAIP-2) conversion
 
 In the case where the `chainId` is larger than what can be represented in 32 decimal characters, the leading 32 characters should be used.
 
-##### Customary (CAIP-2) conversion - text representation conversion
+#### Customary (CAIP-2) -> text conversion
 
 This transformation would not be fully deterministic in the case where `chainId`s larger than 10^32 are used. It is assumed wallets and other software will be able to differentiate between chains from just the leading 32 decimal characters, and use a lookup table of popular chains to complete the missing information to convert CAIP-2 identifiers to this standard.
 
-#### Binary representation
+### Binary representation
 
 The bare `chainId` encoded as a big-endian unsigned integer of the minimum necessary amount of bytes will be used [^1], and leading zeroes will be prohibited.
 
@@ -50,7 +50,7 @@ Encode the decimal integer as a big-endian unsigned integer using the minimum ne
 
 Compute the decimal representation of the stored big-endian unsigned integer.
 
-#### Examples
+### Examples
 
 Ethereum Mainnet: `0x01` (integer `1`, encoded as uint8)
 
@@ -72,15 +72,15 @@ Where `<address>` is the 20 bytes of an EVM address, hexadecimal-encoded accordi
 This standard deliberately does not define the text representation of EVM addresses if they are extended in the future, since it's not possible to know which human-readable representation will be more familiar to users in such hypothetical scenario.
 This profile should be amended in the future to reflect it in such a case.
 
-##### Text representation -> native representation conversion
+#### Text -> native conversion
 
 See [EIP-55].
 
-##### Native representation -> text representation conversion
+#### Native -> text conversion
 
 See [EIP-55].
 
-#### Binary representation
+### Binary representation
 
 Bytes of EVM addresses are trivially stored as the payload.
 It's worth noting that addresses are currently 20 bytes, but that might change in the future, most likely to 32 bytes [^2].
@@ -93,15 +93,15 @@ Specified in [EIP-55].
 
 Specified in [EIP-55].
 
-#### Examples
+### Examples
 
 See [EIP-55].
 
-### Error handling
+## Error handling
 
-### Implementation considerations
+## Implementation considerations
 
-### Extra considerations
+## Extra considerations
 
 Wallets and other software are expected to be able to fetch the extra information needed to convert from [CAIP-2] to this standard.
 

diff --git a/solana/caip350.md b/solana/caip350.md
@@ -30,16 +30,16 @@ Where `<genesis_blockhash>` is the full 44-character base58btc-encoded genesis b
 > **Note:** Per [CAIP-350], the full chain identifier is `solana:<genesis_blockhash>` (e.g., `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d`).
 
 
-##### Text representation -> customary (CAIP-2) conversion
+#### Text -> customary (CAIP-2) conversion
 
 The leading 32 characters are used, and the rest discarded, in a manner similar to what is specified on [this namespace's CAIP-2](caip2.md) profile (e.g., `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp`).
 
-##### Customary (CAIP-2) conversion?CAIP-2 - text representation conversion
+#### Customary (CAIP-2) -> text conversion
 
 This transformation is not fully deterministic.
 It is assumed wallets and other software will be able to differentiate between chains with just the leading 32 base58btc-encoded characters, and use a lookup table of chains to complete the missing information to convert [CAIP-2] identifiers to those defined in this standard.
 
-#### Binary representation
+### Binary representation
 
 To obtain the binary representation from the base58btc-encoded genesis blockhash, first truncate the base58btc-encoded text to its first 32 characters as described above and then decode it to raw bytes.
 
@@ -51,7 +51,7 @@ Text should be base58btc-decoded into raw bytes.
 
 Raw bytes should be base58btc encoded into text.
 
-#### Examples
+### Examples
 
 Solana Mainnet
 : `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d`
@@ -73,15 +73,15 @@ Solana addresses are 32-byte public keys, conventionally displayed to users as b
 
 Where `<public_key>` is the base58btc-encoded ASCII of the entire 32-byte public key.
 
-##### Text representation -> native representation conversion
+#### Text -> native conversion
 
 No transformation.
 
-##### native representation conversion -> text representation conversion
+#### Native -> text conversion
 
 No transformation.
 
-#### Binary representation
+### Binary representation
 
 Entire 32-byte public key.
 
@@ -93,17 +93,17 @@ base58btc decoding
 
 base58btc encoding
 
-#### Examples
+### Examples
 
 `7S3P4HxJpyyigGzodYwHtCxZyUQe9JiBMHyRWXArAaKv` -> `0x5F90554BB3D8C2FC82B6EE59C49AAA143E77F7D49A83E956CE1DBEF17A43F805`
 
 `DYw8jCTfwHNRJhhmFcbXvVDTqWMEVFBX6ZKUmG5CNSKK` -> `0xBA7A74F374AB05B70D114A78112EF0D3F0695A819572C79710B5372000D81AE2`
 
-### Error handling
+## Error handling
 
-### Implementation considerations
+## Implementation considerations
 
-### Extra considerations
+## Extra considerations
 
 Wallets and other software are expected to be able to fetch the extra information needed to convert from [CAIP-2] to produce the corresponding identifier defined by this standard.
 

diff --git a/starknet/caip350.md b/starknet/caip350.md
@@ -30,11 +30,11 @@ Where `<chain_id_string>` is the case-sensitive chain identifier (e.g. `SN_MAIN`
 
 > **Note:** Per [CAIP-350], the full chain identifier is `starknet:<chain_id_string>` (e.g., `starknet:SN_MAIN`, `starknet:SN_GOERLI`).
 
-#### Text representation -> customary (CAIP-2) conversion
+#### Text -> customary (CAIP-2) conversion
 
 The text representation (chain reference) is the same as the chain reference in the [CAIP-2](caip2.md) chain identifier; no conversion is needed.
 
-#### Customary (CAIP-2) conversion - text representation conversion
+#### Customary (CAIP-2) -> text conversion
 
 The chain reference in the [CAIP-2](caip2.md) chain identifier is the same as the text representation; no conversion is needed.
 
@@ -50,7 +50,7 @@ Encode the chain ID string as UTF-8 bytes.
 
 Decode the bytes to the chain ID string (for all current identifiers, the bytes are UTF-8/ASCII).
 
-#### Examples
+### Examples
 
 | Chain | Text (chain reference) | Binary |
 |-------|------------------------|--------------------------------|
@@ -69,15 +69,15 @@ See this namespace's [CAIP-10](caip10.md) profile. StarkNet addresses are 32-byt
 
 Where `<address>` is the 32-byte field element as in [CAIP-10](caip10.md): `0x` followed by 64 hex characters (EIP-55 checksum recommended), e.g. `0x02DdfB499765c064eaC5039E3841AA5f382E73B598097a40073BD8B48170Ab57`.
 
-##### Text representation -> native representation conversion
+#### Text -> native conversion
 
 Strip the `0x` prefix and decode the 64 hex characters to 32 bytes. Checksum validation (if present) follows [EIP-55][].
 
-##### Native representation -> text representation conversion
+#### Native -> text conversion
 
 Encode the 32 bytes as 64 hex characters with `0x` prefix. Apply [EIP-55][] checksum for the canonical text form.
 
-#### Binary representation
+### Binary representation
 
 The address is stored as the raw 32 bytes (big-endian), as in the native field element representation. No length prefix is needed for fixed-size addresses.