From 08ad356dabd5c1f7b0cfbd367c77b282709ea1fe Mon Sep 17 00:00:00 2001 From: 0xmono Date: Tue, 28 Oct 2025 10:08:01 -0300 Subject: [PATCH 1/2] docs: update CAIP-350 namespace profile and remove deprecated ERC-7785 references --- eip155/caip350.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/eip155/caip350.md b/eip155/caip350.md index cf7c475f..9cdc68bd 100644 --- a/eip155/caip350.md +++ b/eip155/caip350.md @@ -65,11 +65,11 @@ For text representation, the 20 bytes of EVM addresses should be hexadecimal-enc 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 -> customary text address formats conversion +##### Text representation -> native representation conversion See [EIP-55]. -##### Customary text addresses -> text representation conversion +##### Native representation -> text representation conversion See [EIP-55]. @@ -90,13 +90,17 @@ Specified in [EIP-55]. See [EIP-55]. +### Error handling + +### Implementation 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. ## References -[^1]: This makes it possible to represent some chains using the full word as their chainid, which CAIP-2 does not support since the set of values representable with 32 `a-zA-Z0-9` characters has less than `type(uint256).max` elements. This is done in an effort to support chains whose ID is the output of `keccak256`, as proposed in [ERC-7785]. +[^1]: This makes it possible to represent some chains using the full word as their chainid, which CAIP-2 does not support since the set of values representable with 32 `a-zA-Z0-9` characters has less than `type(uint256).max` elements. [^2]: With EVM Object Format as a prerequisite, Address Space Expansion could be implemented. If that happens, expanded addresses may be represented in 32 bytes, but pre-expansion addresses must remain 20 bytes in order to preserve a consistent address. [CAIP-2]: https://chainagnostic.org/CAIPs/caip-2 From 46844d43f0f2ee3d21f76b586d59ad2806cc5622 Mon Sep 17 00:00:00 2001 From: 0xmono Date: Tue, 28 Oct 2025 10:13:02 -0300 Subject: [PATCH 2/2] docs: update CAIP-350 namespace profile to align with the new template --- solana/caip350.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/solana/caip350.md b/solana/caip350.md index 1e68dd9e..36889963 100644 --- a/solana/caip350.md +++ b/solana/caip350.md @@ -63,11 +63,11 @@ Solana addresses are 32-byte public keys, conventionally displayed to users as b base58btc-encoded ASCII of the entire public key bytes. -##### Text representation -> customary text address formats conversion +##### Text representation -> native representation conversion No transformation. -##### customary text addresses -> text representation conversion +##### native representation conversion -> text representation conversion No transformation. @@ -89,6 +89,10 @@ base58btc encoding `DYw8jCTfwHNRJhhmFcbXvVDTqWMEVFBX6ZKUmG5CNSKK` -> `0xBA7A74F374AB05B70D114A78112EF0D3F0695A819572C79710B5372000D81AE2` +### Error handling + +### Implementation 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.