Update docs: template and namespace profiles (#165)

Author: bumblefudge

_template/caip350.md

@@ -10,25 +10,27 @@ created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
 requires: <list of standards required to understand this one>
 ---
 
-## Chain reference
-
+## Namespace Reference
 ChainType binary key: `0xXXXX`
 [CAIP-104] namespace: `XXXXX`
 
+## Chain reference
+
 <!-- check existing caip350 profiles on namespaces chainagnostic.org as well as open PRs for collisions with previously-registered binary keys -->
 
 ### Text representation
 
-<!-- a description of the format of chain namespace + reference intended for the text representation of ERC-7930 Interoperable Addresses -->
+<!-- a description of the format of the chain reference specific to this namespace -->
+<!-- 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 -> CAIP-2 conversion
+##### Text representation -> customary (CAIP-2) conversion
 
 <!-- instructions for how to convert from the above to a CAIP-2 string -->
 
-##### CAIP-2 - text representation conversion
+##### Customary (CAIP-2) conversion - text representation conversion
 
-<!-- instructions for how to convert from a CAIP-2 string to the Interoperable Address format -->
+<!-- instructions for how to convert from a CAIP-2 string to this standard's text representation -->
 
 #### Binary representation
 

eip155/caip350.md

@@ -22,15 +22,19 @@ See [EIP-155] and [EIP-2294].
 ### Text representation
 
 ```
-eip155:<number>
+<number>
 ```
+
 Where `<number>` is the decimal representation of the chain's `chainId`, without leading zeroes.
 
-##### Text representation -> CAIP-2 conversion
+> **Note:** Per [CAIP-350], the full chain identifier is `eip155:<number>` (e.g., `eip155:1`, `eip155:10`).
+
+
+##### Text representation -> 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.
 
-##### CAIP-2 - text representation conversion
+##### Customary (CAIP-2) conversion - text representation 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.
 
@@ -60,8 +64,11 @@ 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]
 
 ### Text representation
+```
+<address>
+```
+Where `<address>` is the 20 bytes of an EVM address, hexadecimal-encoded according to [EIP-55] with `0x` prefix.
 
-For text representation, the 20 bytes of EVM addresses should be hexadecimal-encoded according to [EIP-55].
 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.
 

solana/caip350.md

@@ -22,13 +22,19 @@ We chose to use the blockhash in full, as opposed to using the [CAIP-2], for con
 
 ### Text representation
 
-The full base58btc-encoded genesis blockhash is used. This is larger than the [CAIP-2] representation.
+```
+<genesis_blockhash>
+```
+Where `<genesis_blockhash>` is the full 44-character base58btc-encoded genesis blockhash. This is larger than the [CAIP-2] representation (which truncates to 32 characters).
 
-##### Text representation -> CAIP-2 conversion
+> **Note:** Per [CAIP-350], the full chain identifier is `solana:<genesis_blockhash>` (e.g., `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d`).
 
-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.
 
-##### CAIP-2 - text representation conversion
+##### Text representation -> 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
 
 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.
@@ -61,7 +67,11 @@ Solana addresses are 32-byte public keys, conventionally displayed to users as b
 
 ### Text representation
 
-base58btc-encoded ASCII of the entire public key bytes.
+```
+<public_key>
+```
+
+Where `<public_key>` is the base58btc-encoded ASCII of the entire 32-byte public key.
 
 ##### Text representation -> native representation conversion