Skip to content

Update docs CAIP-350 #395

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 CAIP-350 #395

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
084ba91
Update CAIP-350
0xMonoAx Jan 13, 2026
d0f7134
Revert "Update CAIP-350"
0xMonoAx Jan 13, 2026
1c9f498
Update CAIP-350
0xMonoAx Jan 13, 2026
fab6a9a
Update CAIP-35
0xMonoAx Jan 21, 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
35 changes: 30 additions & 5 deletions CAIPs/caip-350.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,18 +30,43 @@ Standards like CAIP-2 and CAIP-10 are simple text representations of addresses a

## Specification

The purpose of each namespace's profile is to specify deterministic and unambiguous conversions between the following format-pairs:
The purpose of each namespace's profile is to specify deterministic and unambiguous conversions between format pairs for the Addresses and Chain References of the ecosystem.

- Customary address text formats of the ecosystem (which may also be described in its [CAIP-10] profile) and the Interoperable Names text representation defined in [ERC-7930]
- Customary chain reference text formats of the ecosystem (which may also be described in [CAIP-2]) and the text representation defined in [ERC-7930]
- [ERC-7930]'s Interoperable Address and [ERC-7930]'s Interoperable Name of the ecosystem's chain references
- [ERC-7930]'s Interoperable Address and [ERC-7930]'s Interoperable Name of the ecosystem's addresses *for all address formats of said ecosystem*
#### CAIP-2/CAIP-10 Compatibility
The "standard text" in CAIP-350 profiles is a variant of [CAIP-2]/[CAIP-10] that is identical for most namespaces, but less lossy for those where length restrictions cause truncation (e.g., Solana's genesis blockhash).

Each CAIP-350 profile MUST state whether its standard text differs from [CAIP-2]/[CAIP-10], and how.
Copy link
Collaborator

@bumblefudge bumblefudge Jan 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice good thinking


### Chain References
- **customary text ↔ standard text**: Between customary chain reference text formats of the ecosystem (which may also be described in [CAIP-2]) and a standard text representation
Copy link
Collaborator

@bumblefudge bumblefudge Jan 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is kind of confusing because [CAIP-2] profiles per namespace already unambiguously convert between customary text and [a slightly different, in some cases] standard text... I think it would help to better explain that the "standard text" here is a slight variant of CAIP-2 that is identical for many namespaces but for others less lossy.

Copy link
Author

@0xMonoAx 0xMonoAx Jan 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a new section titled “CAIP-2/CAIP-10 Compatibility.”

- **standard text ↔ binary**: Between the standard text representation and a binary _ChainReference_ representation

### Addresses
- **customary text ↔ standard text**: Between customary address text formats of the ecosystem (which may also be described in its [CAIP-10] profile) and a standard text representation
- **standard text ↔ binary**: Between the standard text representation and a binary _Address_ representation, for all address formats of said ecosystem

Crucially, each namespace MUST also define exactly ONE (1) 2-byte bytestring to uniquely identify the namespace itself, without colliding with previous definitions, which will provide the value for the `chainType` property defined in [ERC-7930].

Every namespace MUST specify all of the above in a CAIP-350 profile to maximize interoperability and review.
A [template for these profiles](https://github.com/ChainAgnostic/namespaces/blob/main/_template/caip350.md) is defined in the Namespaces registry.

### Chain Identifier Text Representation


The standard text representation of a chain identifier MUST follow the format:
```
<namespace>:<chainReference>
```
Where:
- `<namespace>` is the [CAIP-104] namespace identifier (e.g., `eip155`, `solana`, `bip122`)
- `<chainReference>` is the chain-specific reference as defined by each namespace's CAIP-350 profile


This format ensures global uniqueness across all namespaces and maintains consistency with [CAIP-2].


Each namespace's CAIP-350 profile MUST define only the syntax and semantics of the `<chainReference>` portion. The `<namespace>:` prefix is implicitly applied as defined by this specification and SHOULD NOT be redefined in individual profiles.

## Rationale

The main alternative to this standard would've been to define all formats and conversions in [ERC-7930], turning it into a Living ERC, which was not ideal since:
Expand Down