Add aelf namespace (aelf) with CAIP-2 profile

[okwme]

Adds a CAN for aelf with a CAIP-2 Blockchain ID profile.

Who wrote this

I do not represent the aelf ecosystem. I maintain FAR, an open cross-reference between CAIP-19, CoinGecko and ISO 24165 identifiers. Offered as a starting point for aelf's maintainers to correct, adopt or replace.

Proposal

aelf: + the chain id in its canonical base58 form.

aelf:AELF    MainNet main chain
aelf:tDVV    MainNet side chain

aelf:AELF is not a stutter: lowercase names the ecosystem, uppercase is the main chain's own id — and the stutter disappears at aelf:tDVV.

The encoding, established from source rather than assumed

aelf chain ids are an int32 that renders as a short base58 string, but the mapping is not plain base58 of the integer. From ChainHelper.cs (fetched via the GitHub API — raw URLs 404 on every branch; the default branch is dev): ConvertChainIdToBase58 takes the low three bytes of the int32's little-endian form, big-endian, plain base58, no checksum.

I implemented both directions and round-tripped them: AELF↔9992731, tDVV↔1866392, tDVW↔1931928 — matching the integers aelf's own documentation publishes. Because only three bytes survive, the value space is 0…16777215 and the base58 form is 3–5 characters (brute-forced across all 16,777,216 values).

The spec therefore defines canonicality as a round-trip rule rather than an enumeration: ^[1-9A-HJ-NP-Za-km-z]{3,5}$ and ConvertChainIdToBase58(ConvertBase58ToChainId(ref)) == ref. Every invalid test case was computed, not guessed — e.g. 1AELF→-1736828160→re-encodes to 136H.

Verified live (2026-09-14)

GET /api/blockChain/chainStatus on https://aelf-public-node.aelf.io → "ChainId":"AELF"; on https://tdvv-public-node.aelf.io → "ChainId":"tDVV".

⚠️ A collision I could not resolve, and most want reviewed

aelf's TestNet main chain is documented as also using AELF, which would mean aelf:AELF does not distinguish MainNet from TestNet. aelf-test-node.aelf.io and tdvw-test-node.aelf.io returned HTTP 522 throughout, so the testnet rows are documentation-only and I could not confirm it either way.

The spec has a dedicated Collisions section stating the ambiguity and giving three mitigations (out-of-band network context, corroborate GenesisBlockHash, refuse). This is the item most likely to need community correction and the first thing I would ask a maintainer to look at.

Flagged for a future CAIP-19 profile

aelf tokens live in a shared MultiToken system contract, not one contract per token — verified live on both chains by decoding the contract descriptor set at JRmBduh4… (AELF) and 7RzVGiuVWkvL4VfVHdZfQF2Tri3sgLe9U991bohHFfSRZXuGX (tDVV), both containing token_contract.proto / MultiToken.

So token identity is (chain id, symbol) and never a contract address. This is not hypothetical: in the cross-reference project that prompted this PR, every aelf token collided on that one address.

discussions-to: 0xcounting/FAR#1