Skip to content

Commit 362fb4d

Browse files
bumblefudgebumblefudge
authored
Merge branch 'main' into main
2 parents 10a9ddd + 9de3a61 commit 362fb4d

6 files changed

Lines changed: 524 additions & 0 deletions

File tree

‎bip122/caip350.md‎

Lines changed: 130 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
1+
---
2+
namespace-identifier: bip122-caip350
3+
title: BIP122 Namespace - Interoperable Address
4+
binary-key: 0001
5+
author: Orca (@0xrcinus), Mono (@0xMonoAx)
6+
discussions-to: https://ethereum-magicians.org/t/erc-7930-interoperable-addresses/23365
7+
status: Draft
8+
type: Standard
9+
created: 2026-01-29
10+
requires: CAIP-2
11+
---
12+
13+
## Namespace Reference
14+
15+
ChainType binary key: `0x0001`
16+
17+
[CAIP-104] namespace: `bip122`
18+
19+
## Chain reference
20+
21+
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.
22+
23+
### Text representation
24+
25+
```
26+
<genesis_hash_prefix>
27+
```
28+
29+
This is the first 32 lowercase hex characters (16 bytes) of the genesis block hash as defined in [BIP122][].
30+
31+
> **Note:** Per [CAIP-350], the full chain identifier is `bip122:<genesis_hash_prefix>` (e.g., `bip122:000000000019d6689c085ae165831e93`, `bip122:000000000933ea01ad0ee984209779ba`).
32+
33+
##### Text representation -> customary (CAIP-2) conversion
34+
35+
The text representation (chain reference) is the same as the chain reference in the [CAIP-2](caip2.md) chain identifier; no conversion is needed.
36+
37+
##### Customary (CAIP-2) conversion - text representation conversion
38+
39+
The chain reference in the [CAIP-2](caip2.md) chain identifier is the same as the text representation; no conversion is needed.
40+
41+
#### Binary representation
42+
43+
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.).
44+
45+
#### Text -> binary conversion
46+
47+
Decode the 32-character lowercase hex string to 16 bytes (RFC-4616 base16, no 0x-prefix).
48+
49+
#### Binary -> text conversion
50+
51+
Encode the 16 bytes as 32 lowercase hex characters (RFC-4616 base16, no 0x-prefix).
52+
53+
#### Examples
54+
55+
| Chain | Text (chain reference) | Binary |
56+
|-------|------------------------|--------------------------------|
57+
| Bitcoin mainnet | `000000000019d6689c085ae165831e93` | `0x000000000019d6689c085ae165831e93` |
58+
| Bitcoin testnet | `000000000933ea01ad0ee984209779ba` | `0x000000000933ea01ad0ee984209779ba` |
59+
| Litecoin mainnet | `12a765e31ffd4059bada1e25190f6e98` | `0x12a765e31ffd4059bada1e25190f6e98` |
60+
61+
## Addresses
62+
63+
See this namespace's [CAIP-10](caip10.md) profile. BIP122 supports multiple address types (P2SH, SegWit, Taproot) with different native encodings (base58btc, bech32, bech32m).
64+
65+
### Text representation
66+
67+
```
68+
<address>
69+
```
70+
71+
Where `<address>` 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`.
72+
73+
#### Text representation -> native representation conversion
74+
75+
No transformation; the text representation is the native representation.
76+
77+
#### Native representation -> text representation conversion
78+
79+
No transformation; the native representation is the text representation.
80+
81+
### Binary representation
82+
83+
The binary representation uses a one-byte type prefix followed by the decoded payload (without checksum):
84+
85+
- **0x01 — P2SH**: 1 byte version (network-dependent) + 20 bytes script hash (21 bytes total after type).
86+
- **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).
87+
88+
Checksums are omitted in binary; they can be recomputed when converting back to text.
89+
90+
#### Text -> binary conversion
91+
92+
1. Detect address type from prefix (e.g. `3` for P2SH, `bc1q`/`tb1q` etc. for witness).
93+
2. Decode using the appropriate scheme ([base58btc][] for P2SH, [bech32][]/[bech32m][] for witness) and strip checksum.
94+
3. Prepend type byte 0x01 (P2SH) or 0x02 (witness), then append version byte and hash/program bytes as above.
95+
96+
#### Binary -> text conversion
97+
98+
1. Read the type byte (0x01 or 0x02).
99+
2. For 0x01: read 21 bytes (1 version + 20 hash), encode with base58btc including checksum for the target network.
100+
3. For 0x02: read 1 byte witness version, then 20 or 32 bytes program; encode with [bech32][] or [bech32m][] (and correct HRP for network).
101+
102+
### Examples
103+
104+
| Text (Bitcoin mainnet) | Binary (hex, after type byte) |
105+
|------------------------|-------------------------------|
106+
| P2SH `35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N` | `0x01` + base58btc-decoded payload (version + 20-byte hash) |
107+
| SegWit `bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk` | `0x02` + `0x00` + 20-byte witness program |
108+
| Taproot `bc1pmzfrwwndsqmk5yh69yjr5lfgfg4ev8c0tsc06e` | `0x02` + `0x01` + 32-byte witness program |
109+
110+
## Error handling
111+
112+
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.
113+
114+
## Implementation considerations
115+
116+
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).
117+
118+
## References
119+
120+
[BIP122]: https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki
121+
[BIP13]: https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki
122+
[BIP173]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
123+
[BIP350]: https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki
124+
[base58btc]: https://datatracker.ietf.org/doc/html/draft-msporny-base58-02
125+
[bech32]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
126+
[bech32m]: https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki
127+
[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2
128+
[CAIP-10]: https://chainagnostic.org/CAIPs/caip-10
129+
[CAIP-104]: https://chainagnostic.org/CAIPs/caip-104
130+
[CAIP-350]: https://chainagnostic.org/CAIPs/caip-350

‎flow/README.md‎

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
---
2+
namespace-identifier: flow
3+
title: Flow Namespace
4+
author: Hao Fu
5+
status: Draft
6+
type: Informational
7+
created: 2026-01-13
8+
requires: ["CAIP-2"]
9+
---
10+
11+
# Namespace for Flow
12+
13+
Flow is a layer-1 blockchain focused on scalable smart contracts and consumer applications.
14+
This namespace documents how Flow networks are identified for CAIP use cases.
15+
16+
## Rationale
17+
18+
Flow networks are distinguished by stable, human-readable network names.
19+
A clear CAIP-2 profile makes these networks unambiguous across wallets, dapps, and tooling.
20+
21+
## Governance
22+
23+
Flow protocol changes are governed by the Flow community and its core development process.
24+
Network identifiers in this namespace are expected to remain stable for each network.
25+
26+
## References
27+
28+
- [Flow] - Official Flow website and documentation portal.
29+
- [Flow Developers] - Flow developer documentation.
30+
- [Flow GitHub] - Flow open source repositories.
31+
- [CAIP-2] - Chain ID Specification.
32+
33+
[Flow]: https://flow.com
34+
[Flow Developers]: https://developers.flow.com/
35+
[Flow GitHub]: https://github.com/onflow
36+
[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2
37+
38+
## Copyright
39+
40+
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

‎flow/caip2.md‎

Lines changed: 83 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,83 @@
1+
---
2+
namespace-identifier: flow-caip2
3+
title: Flow Namespace - Chains
4+
author: Hao Fu
5+
discussions-to: https://github.com/ChainAgnostic/namespaces/issues/163
6+
status: Draft
7+
type: Informational
8+
created: 2026-01-13
9+
requires: CAIP-2
10+
---
11+
12+
# CAIP-2
13+
14+
_For context, see the [CAIP-2][] specification._
15+
16+
## Introduction
17+
18+
The Flow namespace uses short, human-readable network identifiers.
19+
These identifiers are stable and map to distinct Flow networks.
20+
21+
## Specification
22+
23+
### Semantics
24+
25+
A valid Flow CAIP-2 identifier takes the form:
26+
27+
`flow:<network>`
28+
29+
Where `<network>` is one of the following reserved identifiers:
30+
31+
- `mainnet`
32+
- `testnet`
33+
34+
### Syntax
35+
36+
#### Regular Expression
37+
38+
`^flow:(mainnet|testnet)$`
39+
40+
#### Example
41+
42+
`flow:mainnet`
43+
44+
### Resolution Mechanics
45+
46+
Clients should resolve a Flow network identifier by querying the Flow REST API network parameters endpoint for the target network and verifying the returned `chain_id`.
47+
48+
**Sample request (mainnet):**
49+
50+
`GET https://rest-mainnet.onflow.org/v1/network/parameters`
51+
52+
**Sample response:**
53+
54+
```json
55+
{
56+
"chain_id": "flow-mainnet"
57+
}
58+
```
59+
60+
## Rationale
61+
62+
Stable, human-readable network names provide a simple and consistent way to identify Flow networks across tooling.
63+
64+
### Backwards Compatibility
65+
66+
There are no legacy identifiers for Flow networks in this namespace.
67+
68+
## Test Cases
69+
70+
- **Flow Mainnet:** `flow:mainnet`
71+
- **Flow Testnet:** `flow:testnet`
72+
73+
## References
74+
75+
- [Flow] - Official Flow website and documentation portal.
76+
- [CAIP-2] - Chain ID Specification.
77+
78+
[Flow]: https://flow.com
79+
[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2
80+
81+
## Copyright
82+
83+
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

‎haneul/README.md‎

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
---
2+
namespace-identifier: haneul
3+
title: Haneul Ecosystem
4+
author: Geunhwa Jeong (@GeunhwaJeong)
5+
discussions-to: https://github.com/ChainAgnostic/namespaces/pull/168
6+
status: Draft
7+
type: Informational
8+
created: 2026-01-19
9+
updated: 2026-01-19
10+
---
11+
12+
# Namespace for Haneul Chains
13+
14+
Haneul is a Layer 1 smart contract platform that uses a Move-based, object-centric data model and is optimized for parallel execution. Transactions in Haneul operate on objects rather than accounts, allowing independent operations to be executed in parallel without coordination. This enables high throughput while preserving safety and determinism.
15+
16+
A Haneul network is maintained by a validator committee responsible for processing transactions, reaching consensus, and producing checkpoint digests — cryptographic summaries of network state at fixed intervals. These checkpoints serve as the canonical state and ensure consistency across nodes.
17+
18+
Each network is uniquely identified by its genesis checkpoint digest — the cryptographic hash of the very first checkpoint, signed by the original validator set. This digest anchors the network's identity in verifiable history and validator consensus.
19+
20+
## Rationale
21+
22+
Because chain identity and state in Haneul revolve around checkpoints and objects rather than blocks and accounts, standard CAIP identifiers (e.g., for chains, accounts, and assets) must be adapted accordingly.
23+
24+
This namespace defines how Haneul's architecture maps to cross-chain standards to support consistent and interoperable multi-chain tooling.
25+
26+
## Governance
27+
28+
Haneul protocol upgrades and standards are coordinated by Haneul Labs in collaboration with core contributors and the broader developer community. Changes are proposed through HIPs (Haneul Improvement Proposals), with open discussion and reference implementations maintained on GitHub.
29+
30+
## References
31+
32+
- [Haneul GitHub] — Official GitHub repository for the Haneul blockchain.
33+
- [Haneul TypeScript SDK] — Official TypeScript SDK for Haneul.
34+
35+
[Haneul GitHub]: https://github.com/GeunhwaJeong/haneul
36+
[Haneul TypeScript SDK]: https://github.com/GeunhwaJeong/haneul-ts-sdks
37+
38+
## Copyright
39+
40+
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

0 commit comments

Comments
 (0)