Skip to content

Commit 71705bf

Browse files
bumblefudgebumblefudge
authored
Caip 350 namespaces for solana and eip155 (#140)
2 parents 0e974c4 + 90596c4 commit 71705bf

File tree

2 files changed

+207
-0
lines changed

2 files changed

+207
-0
lines changed

‎eip155/caip350.md‎

Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,106 @@
1+
---
2+
namespace-identifier: eip155-caip350
3+
title: eip155 Namespace - Interoperable Address
4+
binary-key: 0000
5+
author: Teddy (@0xteddybear), Joxes (@0xJoxess), Skeletor Spaceman (@skeletor-spaceman), Racu (@0xRacoon), TiTi (@0xtiti), Gori (@0xGorilla), Ardy (@0xArdy), Onizuka (@onizuka-wl)
6+
discussions-to: https://ethereum-magicians.org/t/erc-7930-interoperable-addresses/23365
7+
status: Draft
8+
type: Standard
9+
created: 2025-04-23
10+
requires: CAIP-2
11+
---
12+
13+
## Namespace Reference
14+
15+
ChainType binary key: `0x0000`
16+
[CAIP-104] namespace: `eip155`
17+
18+
## Chain reference
19+
20+
See [EIP-155] and [EIP-2294].
21+
22+
### Text representation
23+
24+
```
25+
eip155:<number>
26+
```
27+
Where `<number>` is the decimal representation of the chain's `chainId`, without leading zeroes.
28+
29+
##### Text representation -> CAIP-2 conversion
30+
31+
In the case where the `chainId` is larger than what can be represented in 32 decimal characters, the leading 32 characters should be used.
32+
33+
##### CAIP-2 - text representation conversion
34+
35+
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.
36+
37+
#### Binary representation
38+
39+
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.
40+
41+
#### Text -> binary conversion
42+
43+
Encode the decimal integer as a big-endian unsigned integer using the minimum necessary amount of bytes.
44+
45+
#### Binary -> text conversion
46+
47+
Compute the decimal representation of the stored big-endian unsigned integer.
48+
49+
#### Examples
50+
51+
Ethereum Mainnet: `0x01` (integer `1`, encoded as uint8)
52+
53+
Optimism Mainnet: `0x0A` (integer `10`, encoded as uint8)
54+
55+
Ethereum Sepolia: `0xaa36a7` (integer `11155111`, encoded as uint24)
56+
57+
## Addresses
58+
59+
Bytes of EVM addresses are trivially stored as the payload.
60+
It's worth noting that addresses are currently 20 bytes, but that might change in the future, most likely to 32 bytes [^2]
61+
62+
### Text representation
63+
64+
For text representation, the 20 bytes of EVM addresses should be hexadecimal-encoded according to [EIP-55].
65+
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.
66+
This profile should be amended in the future to reflect it in such a case.
67+
68+
##### Text representation -> customary text address formats conversion
69+
70+
See [EIP-55].
71+
72+
##### Customary text addresses -> text representation conversion
73+
74+
See [EIP-55].
75+
76+
#### Binary representation
77+
78+
Bytes of EVM addresses are trivially stored as the payload.
79+
It's worth noting that addresses are currently 20 bytes, but that might change in the future, most likely to 32 bytes [^2].
80+
81+
#### Text -> binary conversion
82+
83+
Specified in [EIP-55].
84+
85+
#### Binary -> text conversion
86+
87+
Specified in [EIP-55].
88+
89+
#### Examples
90+
91+
See [EIP-55].
92+
93+
### Extra considerations
94+
95+
Wallets and other software are expected to be able to fetch the extra information needed to convert from [CAIP-2] to this standard.
96+
97+
## References
98+
99+
[^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].
100+
[^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.
101+
102+
[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2
103+
[CAIP-104]: https://chainagnostic.org/CAIPs/caip-104
104+
[EIP-55]: https://eips.ethereum.org/EIPS/eip-55
105+
[EIP-155]: https://eips.ethereum.org/EIPS/eip-155
106+
[EIP-2294]: https://eips.ethereum.org/EIPS/eip-2294

‎solana/caip350.md‎

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
---
2+
namespace-identifier: solana-caip350
3+
title: Solana Namespace - Interoperable Address
4+
binary-key: 0002
5+
author: Teddy (@0xteddybear), Joxes (@0xJoxess), Skeletor Spaceman (@skeletor-spaceman), Racu (@0xRacoon), TiTi (@0xtiti), Gori (@0xGorilla), Ardy (@0xArdy), Onizuka (@onizuka-wl)
6+
discussions-to: https://ethereum-magicians.org/t/erc-7930-interoperable-addresses/23365
7+
status: Draft
8+
type: Standard
9+
created: 2025-04-23
10+
requires: CAIP-2
11+
---
12+
13+
## Namespace Reference
14+
15+
ChainType binary key: `0x0002`
16+
[CAIP-104] namespace: `solana`
17+
18+
## Chain reference
19+
20+
Solana networks are distinguished by their genesis blockhash, which is normally deserialized as 44 base58btc ASCII characters, corresponding to 32 bytes.
21+
We chose to use the blockhash in full, as opposed to using the [CAIP-2], for consistency with `eip155` and to avoid the complexity of slicing base58btc-encoded text [^1].
22+
23+
### Text representation
24+
25+
The full base58btc-encoded genesis blockhash is used. This is larger than the [CAIP-2] representation.
26+
27+
##### Text representation -> CAIP-2 conversion
28+
29+
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.
30+
31+
##### CAIP-2 - text representation conversion
32+
33+
This transformation is not fully deterministic.
34+
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.
35+
36+
#### Binary representation
37+
38+
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.
39+
40+
#### Text -> binary conversion
41+
42+
Text should be base58btc-decoded into raw bytes.
43+
44+
#### Binary -> text conversion
45+
46+
Raw bytes should be base58btc encoded into text.
47+
48+
#### Examples
49+
50+
Solana Mainnet
51+
: `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d`
52+
: `0x45296998a6f8e2a784db5d9f95e18fc23f70441a1039446801089879b08c7ef0`
53+
54+
Note that Solana Mainnet's blockhash is:
55+
- base58btc `5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d`
56+
- base16 `45296998a6f8e2a784db5d9f95e18fc23f70441a1039446801089879b08c7ef0`
57+
58+
## Addresses
59+
60+
Solana addresses are 32-byte public keys, conventionally displayed to users as base58btc-encoded text.
61+
62+
### Text representation
63+
64+
base58btc-encoded ASCII of the entire public key bytes.
65+
66+
##### Text representation -> customary text address formats conversion
67+
68+
No transformation.
69+
70+
##### customary text addresses -> text representation conversion
71+
72+
No transformation.
73+
74+
#### Binary representation
75+
76+
Entire 32-byte public key.
77+
78+
#### Text -> binary conversion
79+
80+
base58btc decoding
81+
82+
#### Binary -> text conversion
83+
84+
base58btc encoding
85+
86+
#### Examples
87+
88+
`7S3P4HxJpyyigGzodYwHtCxZyUQe9JiBMHyRWXArAaKv` -> `0x5F90554BB3D8C2FC82B6EE59C49AAA143E77F7D49A83E956CE1DBEF17A43F805`
89+
90+
`DYw8jCTfwHNRJhhmFcbXvVDTqWMEVFBX6ZKUmG5CNSKK` -> `0xBA7A74F374AB05B70D114A78112EF0D3F0695A819572C79710B5372000D81AE2`
91+
92+
### Extra considerations
93+
94+
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.
95+
96+
## References
97+
98+
[^1]: CAIP-2 limits chain references to 32 characters, so the `solana` namespace instructs to only use the first 32 characters of the base58btc-encoded genesis blockhash. Truncating the base58btc-encoded representation instead of the binary data, however, means the binary representation will differ significantly from what the Solana node might store in its own memory. e.g while truncating the text yields a string representing a 23-byte long result, it does not correspond to simply slicing the first 23 bytes from the genesis blockhash.
99+
100+
[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2
101+
[CAIP-104]: https://chainagnostic.org/CAIPs/caip-104

0 commit comments

Comments
 (0)