From f10c2ea869bee7e9ae54d498c486c8674cdc6f76 Mon Sep 17 00:00:00 2001 From: orca <227982352+0xrcinus@users.noreply.github.com> Date: Thu, 29 Jan 2026 11:07:33 +0000 Subject: [PATCH 1/8] 350 profiles for bip122, starknet --- bip122/caip350.md | 133 ++++++++++++++++++++++++++++++++++++++++++++ starknet/caip350.md | 116 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 249 insertions(+) create mode 100644 bip122/caip350.md create mode 100644 starknet/caip350.md diff --git a/bip122/caip350.md b/bip122/caip350.md new file mode 100644 index 00000000..925d284c --- /dev/null +++ b/bip122/caip350.md @@ -0,0 +1,133 @@ +--- +namespace-identifier: bip122-caip350 +title: BIP122 Namespace - Interoperable Address +binary-key: 0001 +author: Orca (@0xrcinus), Mono (@0xMonoAx) +discussions-to: https://ethereum-magicians.org/t/erc-7930-interoperable-addresses/23365 +status: Draft +type: Standard +created: 2026-01-29 +requires: CAIP-2 +--- + +## Namespace Reference + +ChainType binary key: `0x0001` +[CAIP-104] namespace: `bip122` + +## Chain reference + +See this namespace's [CAIP-2](caip2.md) profile. The chain reference is the first 32 characters (16 bytes) of the genesis block hash in lowercase hex. + +### Text representation + +``` + +``` + +Where `` is the first 32 lowercase hex characters (16 bytes) of the genesis block hash as defined in [BIP122][]. + +> **Note:** Per [CAIP-350], the full chain identifier is `bip122:` (e.g., `bip122:000000000019d6689c085ae165831e93`, `bip122:000000000933ea01ad0ee984209779ba`). + +##### Text representation -> customary (CAIP-2) conversion + +The text representation is identical to the [CAIP-2](caip2.md) chain identifier; no conversion is needed. + +##### Customary (CAIP-2) conversion - text representation conversion + +The [CAIP-2](caip2.md) chain identifier is identical to the text representation; no conversion is needed. + +#### Binary representation + +The chain reference is the 16 bytes corresponding to the first 32 hex characters of the genesis block hash. Bytes are in the same order as the hex string (first two hex characters encode the first byte, etc.). + +#### Text -> binary conversion + +Decode the 32-character lowercase hex string to 16 bytes (RFC-4616 base16, no 0x-prefix). + +#### Binary -> text conversion + +Encode the 16 bytes as 32 lowercase hex characters (RFC-4616 base16, no 0x-prefix). + +#### Examples + +| Chain | Text | Binary (hex of ChainReference) | +|-------|------|--------------------------------| +| Bitcoin mainnet | `bip122:000000000019d6689c085ae165831e93` | `0x000000000019d6689c085ae165831e93` | +| Bitcoin testnet | `bip122:000000000933ea01ad0ee984209779ba` | `0x000000000933ea01ad0ee984209779ba` | +| Litecoin mainnet | `bip122:12a765e31ffd4059bada1e25190f6e98` | `0x12a765e31ffd4059bada1e25190f6e98` | + +## Addresses + +See this namespace's [CAIP-10](caip10.md) profile. BIP122 supports multiple address types (P2SH, SegWit, Taproot) with different native encodings (base58btc, bech32, bech32m). + +### Text representation + +``` +
+``` + +Where `
` is the full native ASCII form (base58btc, bech32, or bech32m) as in [CAIP-10](caip10.md)—e.g. P2SH `35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N`, SegWit `bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk`, or Taproot `bc1pmzfrwwndsqmk5yh69yjr5lfgfg4ev8c0tsc06e`. + +##### Text representation -> native representation conversion + +No transformation; the text representation is the native representation. + +##### Native representation -> text representation conversion + +No transformation; the native representation is the text representation. + +#### Binary representation + +The binary representation uses a one-byte type prefix followed by the decoded payload (without checksum): + +- **0x01 — P2SH**: 1 byte version (network-dependent) + 20 bytes script hash (21 bytes total after type). +- **0x02 — Witness (SegWit / Taproot)**: 1 byte witness version (0 for P2WPKH, 1 for P2TR, etc.) + 20 or 32 bytes program (22 or 34 bytes total after type). + +Checksums are omitted in binary; they can be recomputed when converting back to text. + +#### Text -> binary conversion + +1. Detect address type from prefix (e.g. `3` for P2SH, `bc1q`/`tb1q` etc. for witness). +2. Decode using the appropriate scheme ([base58btc][] for P2SH, [bech32][]/[bech32m][] for witness) and strip checksum. +3. Prepend type byte 0x01 (P2SH) or 0x02 (witness), then append version byte and hash/program bytes as above. + +#### Binary -> text conversion + +1. Read the type byte (0x01 or 0x02). +2. For 0x01: read 21 bytes (1 version + 20 hash), encode with base58btc including checksum for the target network. +3. For 0x02: read 1 byte witness version, then 20 or 32 bytes program; encode with bech32 or bech32m (and correct HRP for network). + +#### Examples + +| Text (Bitcoin mainnet) | Binary (hex, after type byte) | +|------------------------|-------------------------------| +| P2SH `35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N` | `0x01` + base58btc-decoded payload (version + 20-byte hash) | +| SegWit `bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk` | `0x02` + `0x00` + 20-byte witness program | +| Taproot `bc1pmzfrwwndsqmk5yh69yjr5lfgfg4ev8c0tsc06e` | `0x02` + `0x01` + 32-byte witness program | + +### Error handling + +When converting from CAIP-2 to this profile, the chain reference is already fully specified (32 hex chars), so no loss of information occurs. For addresses, invalid or unsupported native encodings (e.g. legacy P2PKH excluded from [CAIP-10](caip10.md)) should be rejected with an appropriate error. + +### Implementation considerations + +Legacy P2PKH addresses are excluded from [CAIP-10](caip10.md) and therefore from this profile. Only P2SH, SegWit, and Taproot address types are supported. Implementations must use the correct HRP and version bytes per network (e.g. mainnet vs testnet, or other BIP122 chains). + +### Extra considerations + +Wallets and other software are expected to be able to fetch the extra information needed to convert from [CAIP-2](caip2.md) to produce the corresponding identifier defined by this standard. + +## References + +[BIP122]: https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki +[BIP13]: https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki +[BIP173]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki +[BIP350]: https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki +[base58btc]: https://datatracker.ietf.org/doc/html/draft-msporny-base58-02 +[bech32]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki +[bech32m]: https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki +[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2 +[CAIP-10]: https://chainagnostic.org/CAIPs/caip-10 +[CAIP-104]: https://chainagnostic.org/CAIPs/caip-104 +[CAIP-350]: https://chainagnostic.org/CAIPs/caip-350 diff --git a/starknet/caip350.md b/starknet/caip350.md new file mode 100644 index 00000000..2cb6ab17 --- /dev/null +++ b/starknet/caip350.md @@ -0,0 +1,116 @@ +--- +namespace-identifier: starknet-caip350 +title: StarkNet Namespace - Interoperable Address +binary-key: 0003 +author: Orca (@0xrcinus), Mono (@0xMonoAx) +discussions-to: https://ethereum-magicians.org/t/erc-7930-interoperable-addresses/23365 +status: Draft +type: Standard +created: 2026-01-29 +requires: CAIP-2 +--- + +## Namespace Reference + +ChainType binary key: `0x0003` +[CAIP-104] namespace: `starknet` + +## Chain reference + +See this namespace's [CAIP-2](caip2.md) profile. Chains are identified by string identifiers (e.g. `SN_MAIN`, `SN_GOERLI`) that are encoded as field elements on the chain but expressed as ASCII strings in CAIP-2. + +### Text representation + +``` + +``` + +Where `` is the case-sensitive chain identifier (e.g. `SN_MAIN`, `SN_GOERLI`) as returned by `starknet_chainId` after converting the hex-encoded field element to a string. + +> **Note:** Per [CAIP-350], the full chain identifier is `starknet:` (e.g., `starknet:SN_MAIN`, `starknet:SN_GOERLI`). + +##### Text representation -> customary (CAIP-2) conversion + +The text representation is identical to the [CAIP-2](caip2.md) chain identifier; no conversion is needed. + +##### Customary (CAIP-2) conversion - text representation conversion + +The [CAIP-2](caip2.md) chain identifier is identical to the text representation; no conversion is needed. + +#### Binary representation + +The chain reference is the binary form of the chain ID as used by the chain: the bytes obtained by decoding the hex-encoded value returned by `starknet_chainId` (RFC-4616 base16, strip any `0x` prefix). This is the field element in byte form. Length is variable (e.g. 7 bytes for `SN_MAIN`, 9 bytes for `SN_GOERLI`). The ChainReference field in binary Interoperable Addresses must carry this byte sequence; higher-level framing (e.g. length prefix) is defined by [ERC-7930][] / CAIP-350. + +#### Text -> binary conversion + +Obtain the chain ID string (the segment after `starknet:`). To get the binary form: decode the hex returned by `starknet_chainId` for that chain to bytes. Equivalently, for current chain IDs the byte form coincides with the UTF-8 encoding of the string. + +#### Binary -> text conversion + +Decode the bytes to the chain ID string (for current identifiers, the bytes are UTF-8/ASCII) and format as `starknet:`. + +#### Examples + +| Chain | Text | Binary (hex of ChainReference) | +|-------|------|--------------------------------| +| StarkNet mainnet | `starknet:SN_MAIN` | `0x534e5f4d41494e` (binary form from `starknet_chainId`) | +| StarkNet Goerli | `starknet:SN_GOERLI` | `0x534e5f474f45524c49` (binary form from `starknet_chainId`) | + +## Addresses + +See this namespace's [CAIP-10](caip10.md) profile. StarkNet addresses are 32-byte field elements, represented as `0x` followed by 64 hexadecimal characters (zero-padded), with optional [EIP-55][] checksum. + +### Text representation + +``` +
+``` + +Where `
` is the 32-byte field element as in [CAIP-10](caip10.md): `0x` followed by 64 hex characters (EIP-55 checksum recommended), e.g. `0x02DdfB499765c064eaC5039E3841AA5f382E73B598097a40073BD8B48170Ab57`. + +##### Text representation -> native representation conversion + +Strip the `0x` prefix and decode the 64 hex characters to 32 bytes. Checksum validation (if present) follows [EIP-55][]. + +##### Native representation -> text representation conversion + +Encode the 32 bytes as 64 hex characters with `0x` prefix. Apply [EIP-55][] checksum for the canonical text form. + +#### Binary representation + +The address is stored as the raw 32 bytes (big-endian), as in the native field element representation. No length prefix is needed for fixed-size addresses. + +#### Text -> binary conversion + +Remove the `0x` prefix and decode the 64 hex characters to 32 bytes (RFC-4616 base16). + +#### Binary -> text conversion + +Encode the 32 bytes as 64 hex characters and prepend `0x`. Apply [EIP-55][] checksum for the canonical form. + +#### Examples + +| Text | Binary (hex of Address field) | +|------|-------------------------------| +| `0x02DdfB499765c064eaC5039E3841AA5f382E73B598097a40073BD8B48170Ab57` | `0x02ddfb499765c064eac5039e3841aa5f382e73b598097a40073bd8b48170ab57` (32 bytes) | + +### Error handling + +When converting from CAIP-2 to this profile, the chain reference is fully determined by the chain ID string, so no loss of information occurs. If a chain ID is unknown or the UTF-8 encoding is invalid, implementations should signal an error. + +### Implementation considerations + +Chain IDs are resolved via `starknet_chainId` (hex-encoded); the interoperable format uses the string form for text representation and the hex-decoded bytes (binary form) for binary representation. Addresses are always 32 bytes; leading zero in hex is normal for field elements below 2^255. + +### Extra considerations + +Wallets and other software are expected to be able to fetch the extra information needed to convert from [CAIP-2](caip2.md) to produce the corresponding identifier defined by this standard. + +## References + +[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2 +[CAIP-10]: https://chainagnostic.org/CAIPs/caip-10 +[CAIP-104]: https://chainagnostic.org/CAIPs/caip-104 +[CAIP-350]: https://chainagnostic.org/CAIPs/caip-350 +[EIP-55]: https://eips.ethereum.org/EIPS/eip-55 +[ERC-7930]: https://eips.ethereum.org/EIPS/eip-7930 From 2aedc8cc95f884bdaaf79384d01540ff5e858119 Mon Sep 17 00:00:00 2001 From: orca <227982352+0xrcinus@users.noreply.github.com> Date: Wed, 4 Feb 2026 16:48:20 +0000 Subject: [PATCH 2/8] caip350 edits for clarity --- bip122/caip350.md | 14 +++++++------- starknet/caip350.md | 22 +++++++++++----------- 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/bip122/caip350.md b/bip122/caip350.md index 925d284c..f5f3bfcf 100644 --- a/bip122/caip350.md +++ b/bip122/caip350.md @@ -31,11 +31,11 @@ Where `` is the first 32 lowercase hex characters (16 bytes ##### Text representation -> customary (CAIP-2) conversion -The text representation is identical to the [CAIP-2](caip2.md) chain identifier; no conversion is needed. +The text representation (chain reference) is the same as the chain reference in the [CAIP-2](caip2.md) chain identifier; no conversion is needed. ##### Customary (CAIP-2) conversion - text representation conversion -The [CAIP-2](caip2.md) chain identifier is identical to the text representation; no conversion is needed. +The chain reference in the [CAIP-2](caip2.md) chain identifier is the same as the text representation; no conversion is needed. #### Binary representation @@ -51,11 +51,11 @@ Encode the 16 bytes as 32 lowercase hex characters (RFC-4616 base16, no 0x-prefi #### Examples -| Chain | Text | Binary (hex of ChainReference) | -|-------|------|--------------------------------| -| Bitcoin mainnet | `bip122:000000000019d6689c085ae165831e93` | `0x000000000019d6689c085ae165831e93` | -| Bitcoin testnet | `bip122:000000000933ea01ad0ee984209779ba` | `0x000000000933ea01ad0ee984209779ba` | -| Litecoin mainnet | `bip122:12a765e31ffd4059bada1e25190f6e98` | `0x12a765e31ffd4059bada1e25190f6e98` | +| Chain | Text (chain reference) | Binary | +|-------|------------------------|--------------------------------| +| Bitcoin mainnet | `000000000019d6689c085ae165831e93` | `0x000000000019d6689c085ae165831e93` | +| Bitcoin testnet | `000000000933ea01ad0ee984209779ba` | `0x000000000933ea01ad0ee984209779ba` | +| Litecoin mainnet | `12a765e31ffd4059bada1e25190f6e98` | `0x12a765e31ffd4059bada1e25190f6e98` | ## Addresses diff --git a/starknet/caip350.md b/starknet/caip350.md index 2cb6ab17..8542eca0 100644 --- a/starknet/caip350.md +++ b/starknet/caip350.md @@ -25,36 +25,36 @@ See this namespace's [CAIP-2](caip2.md) profile. Chains are identified by string ``` -Where `` is the case-sensitive chain identifier (e.g. `SN_MAIN`, `SN_GOERLI`) as returned by `starknet_chainId` after converting the hex-encoded field element to a string. +Where `` is the case-sensitive chain identifier (e.g. `SN_MAIN`, `SN_GOERLI`). > **Note:** Per [CAIP-350], the full chain identifier is `starknet:` (e.g., `starknet:SN_MAIN`, `starknet:SN_GOERLI`). ##### Text representation -> customary (CAIP-2) conversion -The text representation is identical to the [CAIP-2](caip2.md) chain identifier; no conversion is needed. +The text representation (chain reference) is the same as the chain reference in the [CAIP-2](caip2.md) chain identifier; no conversion is needed. ##### Customary (CAIP-2) conversion - text representation conversion -The [CAIP-2](caip2.md) chain identifier is identical to the text representation; no conversion is needed. +The chain reference in the [CAIP-2](caip2.md) chain identifier is the same as the text representation; no conversion is needed. #### Binary representation -The chain reference is the binary form of the chain ID as used by the chain: the bytes obtained by decoding the hex-encoded value returned by `starknet_chainId` (RFC-4616 base16, strip any `0x` prefix). This is the field element in byte form. Length is variable (e.g. 7 bytes for `SN_MAIN`, 9 bytes for `SN_GOERLI`). The ChainReference field in binary Interoperable Addresses must carry this byte sequence; higher-level framing (e.g. length prefix) is defined by [ERC-7930][] / CAIP-350. +The chain reference is the UTF-8 encoding of the chain ID string. Length is variable (e.g. 7 bytes for `SN_MAIN`, 9 bytes for `SN_GOERLI`). The ChainReference field in binary Interoperable Addresses must carry this byte sequence; higher-level framing (e.g. length prefix) is defined by [ERC-7930][] / CAIP-350. #### Text -> binary conversion -Obtain the chain ID string (the segment after `starknet:`). To get the binary form: decode the hex returned by `starknet_chainId` for that chain to bytes. Equivalently, for current chain IDs the byte form coincides with the UTF-8 encoding of the string. +Encode the chain ID string as UTF-8 bytes. #### Binary -> text conversion -Decode the bytes to the chain ID string (for current identifiers, the bytes are UTF-8/ASCII) and format as `starknet:`. +Decode the bytes to the chain ID string (for current identifiers, the bytes are UTF-8/ASCII). #### Examples -| Chain | Text | Binary (hex of ChainReference) | -|-------|------|--------------------------------| -| StarkNet mainnet | `starknet:SN_MAIN` | `0x534e5f4d41494e` (binary form from `starknet_chainId`) | -| StarkNet Goerli | `starknet:SN_GOERLI` | `0x534e5f474f45524c49` (binary form from `starknet_chainId`) | +| Chain | Text (chain reference) | Binary | +|-------|------------------------|--------------------------------| +| StarkNet mainnet | `SN_MAIN` | `0x534e5f4d41494e` | +| StarkNet Goerli | `SN_GOERLI` | `0x534e5f474f45524c49` | ## Addresses @@ -100,7 +100,7 @@ When converting from CAIP-2 to this profile, the chain reference is fully determ ### Implementation considerations -Chain IDs are resolved via `starknet_chainId` (hex-encoded); the interoperable format uses the string form for text representation and the hex-decoded bytes (binary form) for binary representation. Addresses are always 32 bytes; leading zero in hex is normal for field elements below 2^255. +The interoperable format uses the chain ID string for text representation and its UTF-8 encoding for binary. Chain IDs may be resolved via `starknet_chainId` when needed (e.g. to discover the identifier for a connected node). Addresses are always 32 bytes; leading zero in hex is normal for field elements below 2^255. ### Extra considerations From 9f368e0ec8871104d245edc36bae63e71b9b99cd Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 11 Feb 2026 12:34:35 +0100 Subject: [PATCH 3/8] minor formatting on bip122/caip350.md --- bip122/caip350.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip122/caip350.md b/bip122/caip350.md index f5f3bfcf..08a61e93 100644 --- a/bip122/caip350.md +++ b/bip122/caip350.md @@ -96,7 +96,7 @@ Checksums are omitted in binary; they can be recomputed when converting back to 1. Read the type byte (0x01 or 0x02). 2. For 0x01: read 21 bytes (1 version + 20 hash), encode with base58btc including checksum for the target network. -3. For 0x02: read 1 byte witness version, then 20 or 32 bytes program; encode with bech32 or bech32m (and correct HRP for network). +3. For 0x02: read 1 byte witness version, then 20 or 32 bytes program; encode with [bech32][] or [bech32m][] (and correct HRP for network). #### Examples @@ -108,7 +108,7 @@ Checksums are omitted in binary; they can be recomputed when converting back to ### Error handling -When converting from CAIP-2 to this profile, the chain reference is already fully specified (32 hex chars), so no loss of information occurs. For addresses, invalid or unsupported native encodings (e.g. legacy P2PKH excluded from [CAIP-10](caip10.md)) should be rejected with an appropriate error. +When converting from this profile's [CAIP-2] encoding to this profile's [CAIP-350] encoding, the chain reference is already fully specified (32 hex chars), so no loss of information or difference of expression occurs. For addresses, invalid or unsupported native encodings (e.g. legacy P2PKH excluded from [CAIP-10](caip10.md)) should be rejected with an appropriate error. ### Implementation considerations From 1c2c8431fed3aeba5093357f9cdca64498721e7a Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 11 Feb 2026 12:53:28 +0100 Subject: [PATCH 4/8] fix header levels in bip122/caip350 --- bip122/caip350.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/bip122/caip350.md b/bip122/caip350.md index 08a61e93..070475d8 100644 --- a/bip122/caip350.md +++ b/bip122/caip350.md @@ -69,15 +69,15 @@ See this namespace's [CAIP-10](caip10.md) profile. BIP122 supports multiple addr Where `
` is the full native ASCII form (base58btc, bech32, or bech32m) as in [CAIP-10](caip10.md)—e.g. P2SH `35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N`, SegWit `bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk`, or Taproot `bc1pmzfrwwndsqmk5yh69yjr5lfgfg4ev8c0tsc06e`. -##### Text representation -> native representation conversion +#### Text representation -> native representation conversion No transformation; the text representation is the native representation. -##### Native representation -> text representation conversion +#### Native representation -> text representation conversion No transformation; the native representation is the text representation. -#### Binary representation +### Binary representation The binary representation uses a one-byte type prefix followed by the decoded payload (without checksum): @@ -98,7 +98,7 @@ Checksums are omitted in binary; they can be recomputed when converting back to 2. For 0x01: read 21 bytes (1 version + 20 hash), encode with base58btc including checksum for the target network. 3. For 0x02: read 1 byte witness version, then 20 or 32 bytes program; encode with [bech32][] or [bech32m][] (and correct HRP for network). -#### Examples +### Examples | Text (Bitcoin mainnet) | Binary (hex, after type byte) | |------------------------|-------------------------------| @@ -106,15 +106,15 @@ Checksums are omitted in binary; they can be recomputed when converting back to | SegWit `bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk` | `0x02` + `0x00` + 20-byte witness program | | Taproot `bc1pmzfrwwndsqmk5yh69yjr5lfgfg4ev8c0tsc06e` | `0x02` + `0x01` + 32-byte witness program | -### Error handling +## Error handling When converting from this profile's [CAIP-2] encoding to this profile's [CAIP-350] encoding, the chain reference is already fully specified (32 hex chars), so no loss of information or difference of expression occurs. For addresses, invalid or unsupported native encodings (e.g. legacy P2PKH excluded from [CAIP-10](caip10.md)) should be rejected with an appropriate error. -### Implementation considerations +## Implementation considerations Legacy P2PKH addresses are excluded from [CAIP-10](caip10.md) and therefore from this profile. Only P2SH, SegWit, and Taproot address types are supported. Implementations must use the correct HRP and version bytes per network (e.g. mainnet vs testnet, or other BIP122 chains). -### Extra considerations +## Extra considerations Wallets and other software are expected to be able to fetch the extra information needed to convert from [CAIP-2](caip2.md) to produce the corresponding identifier defined by this standard. From 7734a30015a7934d403946a582ad5906c6ae6087 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 11 Feb 2026 12:53:44 +0100 Subject: [PATCH 5/8] minor formatting on starknet/caip350.md --- starknet/caip350.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/starknet/caip350.md b/starknet/caip350.md index 8542eca0..e2a3bfc5 100644 --- a/starknet/caip350.md +++ b/starknet/caip350.md @@ -17,7 +17,7 @@ ChainType binary key: `0x0003` ## Chain reference -See this namespace's [CAIP-2](caip2.md) profile. Chains are identified by string identifiers (e.g. `SN_MAIN`, `SN_GOERLI`) that are encoded as field elements on the chain but expressed as ASCII strings in CAIP-2. +See this namespace's [CAIP-2](caip2.md) profile. Chains are identified by string identifiers (e.g. `SN_MAIN`, `SN_GOERLI`) that are encoded as field elements on the chain but expressed as ASCII strings in [CAIP-2]. ### Text representation @@ -29,17 +29,17 @@ Where `` is the case-sensitive chain identifier (e.g. `SN_MAIN` > **Note:** Per [CAIP-350], the full chain identifier is `starknet:` (e.g., `starknet:SN_MAIN`, `starknet:SN_GOERLI`). -##### Text representation -> customary (CAIP-2) conversion +#### Text representation -> customary (CAIP-2) conversion The text representation (chain reference) is the same as the chain reference in the [CAIP-2](caip2.md) chain identifier; no conversion is needed. -##### Customary (CAIP-2) conversion - text representation conversion +#### Customary (CAIP-2) conversion - text representation conversion The chain reference in the [CAIP-2](caip2.md) chain identifier is the same as the text representation; no conversion is needed. -#### Binary representation +### Binary representation -The chain reference is the UTF-8 encoding of the chain ID string. Length is variable (e.g. 7 bytes for `SN_MAIN`, 9 bytes for `SN_GOERLI`). The ChainReference field in binary Interoperable Addresses must carry this byte sequence; higher-level framing (e.g. length prefix) is defined by [ERC-7930][] / CAIP-350. +The chain reference is the UTF-8 encoding of the chain ID string. Length is variable (e.g. 7 bytes for `SN_MAIN`, 9 bytes for `SN_GOERLI`). The ChainReference field in binary Interoperable Addresses must carry this byte sequence; higher-level framing (e.g. length prefix) is defined by [ERC-7930][] / [CAIP-350][]. #### Text -> binary conversion @@ -47,7 +47,7 @@ Encode the chain ID string as UTF-8 bytes. #### Binary -> text conversion -Decode the bytes to the chain ID string (for current identifiers, the bytes are UTF-8/ASCII). +Decode the bytes to the chain ID string (for all current identifiers, the bytes are UTF-8/ASCII). #### Examples @@ -82,11 +82,11 @@ The address is stored as the raw 32 bytes (big-endian), as in the native field e #### Text -> binary conversion -Remove the `0x` prefix and decode the 64 hex characters to 32 bytes (RFC-4616 base16). +Remove the `0x` prefix and decode the 64 hex characters to 32 bytes (via [RFC-4616] base16). #### Binary -> text conversion -Encode the 32 bytes as 64 hex characters and prepend `0x`. Apply [EIP-55][] checksum for the canonical form. +Encode the 32 bytes as 64 hex characters and prepend `0x`. Apply [EIP-55][] checksum casing for the canonical form. #### Examples @@ -96,11 +96,11 @@ Encode the 32 bytes as 64 hex characters and prepend `0x`. Apply [EIP-55][] chec ### Error handling -When converting from CAIP-2 to this profile, the chain reference is fully determined by the chain ID string, so no loss of information occurs. If a chain ID is unknown or the UTF-8 encoding is invalid, implementations should signal an error. +When converting from [CAIP-2] to this profile, the chain reference is fully determined by the chain ID string, so no loss of information occurs. If a chain ID is unknown or the UTF-8 encoding is invalid, implementations should signal an error. ### Implementation considerations -The interoperable format uses the chain ID string for text representation and its UTF-8 encoding for binary. Chain IDs may be resolved via `starknet_chainId` when needed (e.g. to discover the identifier for a connected node). Addresses are always 32 bytes; leading zero in hex is normal for field elements below 2^255. +The interoperable format uses the chain ID string for text representation and its UTF-8 encoding for binary. Chain IDs may be resolved via the `starknet_chainId` method when needed (e.g. to discover the identifier for a connected node). Addresses are always 32 bytes; leading zero in hex is normal for field elements below 2^255. ### Extra considerations @@ -114,3 +114,4 @@ Wallets and other software are expected to be able to fetch the extra informatio [CAIP-350]: https://chainagnostic.org/CAIPs/caip-350 [EIP-55]: https://eips.ethereum.org/EIPS/eip-55 [ERC-7930]: https://eips.ethereum.org/EIPS/eip-7930 +[RFC-4616]: https://datatracker.ietf.org/doc/html/rfc4616 From b656203a2c9eebb48f54828e66c0ac772743c7fd Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 11 Feb 2026 12:54:34 +0100 Subject: [PATCH 6/8] fix header levels in starknet/caip350 --- starknet/caip350.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/starknet/caip350.md b/starknet/caip350.md index e2a3bfc5..886b7cc9 100644 --- a/starknet/caip350.md +++ b/starknet/caip350.md @@ -88,21 +88,21 @@ Remove the `0x` prefix and decode the 64 hex characters to 32 bytes (via [RFC-46 Encode the 32 bytes as 64 hex characters and prepend `0x`. Apply [EIP-55][] checksum casing for the canonical form. -#### Examples +### Examples | Text | Binary (hex of Address field) | |------|-------------------------------| | `0x02DdfB499765c064eaC5039E3841AA5f382E73B598097a40073BD8B48170Ab57` | `0x02ddfb499765c064eac5039e3841aa5f382e73b598097a40073bd8b48170ab57` (32 bytes) | -### Error handling +## Error handling When converting from [CAIP-2] to this profile, the chain reference is fully determined by the chain ID string, so no loss of information occurs. If a chain ID is unknown or the UTF-8 encoding is invalid, implementations should signal an error. -### Implementation considerations +## Implementation considerations The interoperable format uses the chain ID string for text representation and its UTF-8 encoding for binary. Chain IDs may be resolved via the `starknet_chainId` method when needed (e.g. to discover the identifier for a connected node). Addresses are always 32 bytes; leading zero in hex is normal for field elements below 2^255. -### Extra considerations +## Extra considerations Wallets and other software are expected to be able to fetch the extra information needed to convert from [CAIP-2](caip2.md) to produce the corresponding identifier defined by this standard. From fd88e6a2b5c8aa603d28b3ab91198c0bbde5b3af Mon Sep 17 00:00:00 2001 From: orca <227982352+0xrcinus@users.noreply.github.com> Date: Wed, 11 Feb 2026 14:44:00 +0000 Subject: [PATCH 7/8] remove unnecessary extra considerations --- bip122/caip350.md | 4 ---- starknet/caip350.md | 4 ---- 2 files changed, 8 deletions(-) diff --git a/bip122/caip350.md b/bip122/caip350.md index 070475d8..53af48ad 100644 --- a/bip122/caip350.md +++ b/bip122/caip350.md @@ -114,10 +114,6 @@ When converting from this profile's [CAIP-2] encoding to this profile's [CAIP-35 Legacy P2PKH addresses are excluded from [CAIP-10](caip10.md) and therefore from this profile. Only P2SH, SegWit, and Taproot address types are supported. Implementations must use the correct HRP and version bytes per network (e.g. mainnet vs testnet, or other BIP122 chains). -## Extra considerations - -Wallets and other software are expected to be able to fetch the extra information needed to convert from [CAIP-2](caip2.md) to produce the corresponding identifier defined by this standard. - ## References [BIP122]: https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki diff --git a/starknet/caip350.md b/starknet/caip350.md index 886b7cc9..7fb36ebc 100644 --- a/starknet/caip350.md +++ b/starknet/caip350.md @@ -102,10 +102,6 @@ When converting from [CAIP-2] to this profile, the chain reference is fully dete The interoperable format uses the chain ID string for text representation and its UTF-8 encoding for binary. Chain IDs may be resolved via the `starknet_chainId` method when needed (e.g. to discover the identifier for a connected node). Addresses are always 32 bytes; leading zero in hex is normal for field elements below 2^255. -## Extra considerations - -Wallets and other software are expected to be able to fetch the extra information needed to convert from [CAIP-2](caip2.md) to produce the corresponding identifier defined by this standard. - ## References [CAIP-2]: https://chainagnostic.org/CAIPs/caip-2 From e2a40a807888e880ccac9178a9f6290a3314cf21 Mon Sep 17 00:00:00 2001 From: orca <227982352+0xrcinus@users.noreply.github.com> Date: Wed, 25 Feb 2026 15:30:14 +0000 Subject: [PATCH 8/8] fix: clowestab nits --- bip122/caip350.md | 3 ++- starknet/caip350.md | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/bip122/caip350.md b/bip122/caip350.md index 53af48ad..d37c700f 100644 --- a/bip122/caip350.md +++ b/bip122/caip350.md @@ -13,6 +13,7 @@ requires: CAIP-2 ## Namespace Reference ChainType binary key: `0x0001` + [CAIP-104] namespace: `bip122` ## Chain reference @@ -25,7 +26,7 @@ See this namespace's [CAIP-2](caip2.md) profile. The chain reference is the firs ``` -Where `` is the first 32 lowercase hex characters (16 bytes) of the genesis block hash as defined in [BIP122][]. +This is the first 32 lowercase hex characters (16 bytes) of the genesis block hash as defined in [BIP122][]. > **Note:** Per [CAIP-350], the full chain identifier is `bip122:` (e.g., `bip122:000000000019d6689c085ae165831e93`, `bip122:000000000933ea01ad0ee984209779ba`). diff --git a/starknet/caip350.md b/starknet/caip350.md index 7fb36ebc..1f715499 100644 --- a/starknet/caip350.md +++ b/starknet/caip350.md @@ -13,6 +13,7 @@ requires: CAIP-2 ## Namespace Reference ChainType binary key: `0x0003` + [CAIP-104] namespace: `starknet` ## Chain reference