Skip to content

Update docs: template and namespace profiles #165

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
0xMonoAx wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Update docs: template and namespace profiles #165

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
85e5e56
Update the template and namespace profiles for solana and eip155
0xMonoAx Jan 13, 2026
11ad230
Clarify CAIP-350 definitions
0xMonoAx Jan 13, 2026
6026d4a
fix template
0xMonoAx Jan 13, 2026
83faa32
Merge branch 'main' into docs--update-caip350-solana-eip155
0xMonoAx Jan 13, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 8 additions & 6 deletions _template/caip350.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
15 changes: 11 additions & 4 deletions eip155/caip350.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -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].

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.

Expand Down
18 changes: 14 additions & 4 deletions solana/caip350.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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`).


##### 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.

##### CAIP-2 - text representation conversion
##### 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.
Expand Down Expand Up @@ -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

Expand Down