Add xync namespace (CAIP-2, CAIP-10, CAIP-19 profiles)

xync/README.md

@@ -0,0 +1,71 @@
+---
+namespace-identifier: xync
+title: Xync Network Namespace
+author: Xync Network (@XyncNet)
+status: Draft
+type: Informational
+created: 2026-07-08
+---
+
+# Namespace for Xync Network
+
+**Xync Network** ("xync") is a payments-only Layer-1 blockchain: the
+protocol supports exactly two user operations — *send money* and
+*request money* — in up to 255 protocol-native currencies plus the
+native token XYNC. There is no virtual machine and no general-purpose
+smart contracts.
+
+Key architectural facts relevant to cross-chain developers:
+
+- **Finality:** consensusless fastpath (FastPay-style attestation
+  quorums, 2f+1 of n validators) finalizes a transfer in one network
+  round trip (~0.3 s); a lazy uncertified DAG orders rare system
+  events (registrations, validator-set changes, checkpoints).
+- **Accounts:** compact integer indexes issued sequentially at paid
+  registration (`0` is the genesis operator). Public keys are
+  *rotatable* (`rekey`), so the stable account identifier is the
+  index, not a key or its hash. This drives the CAIP-10 design.
+- **Transactions:** the entire transfer packs into 128 bits (= UUID);
+  a signed transfer is 80 bytes on the wire.
+- **Currencies:** a protocol-level registry of up to 255 currencies
+  (fiat-backed by regulated issuers, wrapped coins, loyalty units)
+  addressed by a single byte — the basis of the CAIP-19 profile.
+
+Profiles in this namespace:
+
+- [caip2.md](caip2.md) — Blockchain ID (`xync:main`)
+- [caip10.md](caip10.md) — Account ID (`xync:main:518-K7`)
+- [caip19.md](caip19.md) — Asset ID (`xync:main/cur:1`)
+
+## Rationale
+
+The namespace addresses everything by the smallest stable number the
+protocol already assigns, rather than by a cryptographic artifact:
+networks by their genesis `chain_id`, accounts by their integer index,
+currencies by their single-byte registry code. Keys are rotatable and
+therefore unfit as identifiers; hashes would be verbose and, for
+accounts, would require an on-chain reverse index. The three profiles
+map 1:1 onto the fields of the native 128-bit transaction, so a CAIP
+identifier converts to its on-the-wire form without transformation.
+
+## Governance
+
+Network names (CAIP-2 references) and currency codes (CAIP-19
+references) are assigned by Xync Network governance and recorded in the
+network's canonical, content-addressed genesis file. That file's
+SHA-256 is co-signed by the validator checkpoint quorum (2f+1 of n), so
+every reference resolves to exactly one genesis and is verifiable
+against live checkpoints. Account references are issued by the protocol
+itself, sequentially, at registration.
+
+## References
+
+- [Xync Network Yellow Paper][] - full protocol specification
+- [XyncPay][] - the live payment product operating on the network
+
+[Xync Network Yellow Paper]: https://xync.net/papers/yellowpaper.en.pdf
+[XyncPay]: https://t.me/XyncPayBot
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

xync/caip10.md

@@ -0,0 +1,112 @@
+---
+namespace-identifier: xync-caip10
+title: Xync Network - Account ID Specification
+author: Xync Network (@XyncNet)
+discussions-to: https://github.com/ChainAgnostic/namespaces/pull/188
+status: Draft
+type: Informational
+created: 2026-07-08
+requires: ["CAIP-2", "CAIP-10"]
+---
+
+# CAIP-10
+
+*For context, see the [CAIP-10][] specification.*
+
+## Introduction
+
+Xync accounts are compact non-negative integer indexes issued
+sequentially by the protocol at registration (account `0` is the
+genesis operator). Public keys are rotatable (`rekey` operation), so
+the stable identifier of an account is its index — NOT a key or a hash
+of one. An optional 2-character checksum suffix protects against typos
+and cross-network confusion; it is REQUIRED in user-facing contexts.
+
+## Specification
+
+### Semantics
+
+The address is the account index in decimal, optionally followed by
+`-CC` where CC is a checksum. Because the index space is dense (most
+small integers are existing accounts), a mistyped address usually hits
+a *real* account — unlike sparse hash-address namespaces. Wallets,
+QR codes and deep links MUST therefore render the checksummed form;
+parsers MUST validate the checksum when present. Exchanges SHOULD
+require the checksummed form for withdrawals.
+
+### Syntax
+
+```
+account_id:        chain_id + ":" + address
+address:           index | index + "-" + checksum
+index:             0 | [1-9][0-9]{0,8}      (< 268,435,456 in format v1)
+checksum:          2 characters of Crockford base32
+```
+
+Checksum computation:
+
+```
+CC = crockford_base32( first 10 bits of SHA-256(chain_id_caip2 + ":" + index) )
+# example: SHA-256("xync:main:518") -> first 10 bits -> "K7"
+```
+
+Crockford base32 alphabet (`0123456789ABCDEFGHJKMNPQRSTVWXYZ`);
+parsing is case-insensitive and maps `I`/`L`→`1`, `O`→`0`. Binding the
+CAIP-2 identifier into the hash makes a testnet address fail checksum
+validation on mainnet and vice versa.
+
+### Resolution Mechanics
+
+```jsonc
+// GET https://<node>/account/518
+{
+  "index": 518,
+  "caip10": "xync:main:518-K7",
+  "pubkey": "…",          // current key; rotatable, NOT part of the address
+  ...
+}
+```
+
+## Rationale
+
+1. *Index, not pubkey:* keys rotate (`rekey`); an address derived from
+   a key would break on every rotation. The index maps 1:1 to the
+   28-bit address field of the native 128-bit transaction format.
+2. *Checksum-in-address:* analogous in spirit to [EIP-55][] — a
+   canonical plain form and a checksummed display form coexist within
+   one CAIP-10 grammar (`[-.%a-zA-Z0-9]{1,128}` permits both).
+
+### Backwards Compatibility
+
+Not applicable.
+
+## Test Cases
+
+```bash
+# mainnet account 518, checksummed (display form)
+xync:main:518-K7
+
+# the same account, canonical plain form (accepted, checksum not verified)
+xync:main:518
+
+# genesis operator account
+xync:main:0
+
+# devnet account (same index, DIFFERENT checksum than mainnet)
+xync:dev-1:518-9Q
+```
+
+(Checksum values above are illustrative; compute per the algorithm.)
+
+## References
+
+- [Xync Network Yellow Paper][] - account model, rekey, transaction format
+- [EIP-55][] - the precedent of in-identifier optional checksums
+
+[CAIP-10]: https://chainagnostic.org/CAIPs/caip-10
+[EIP-55]: https://eips.ethereum.org/EIPS/eip-55
+[Xync Network Yellow Paper]: https://xync.net/papers/yellowpaper.en.pdf
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

xync/caip19.md

@@ -0,0 +1,86 @@
+---
+namespace-identifier: xync-caip19
+title: Xync Network - Asset ID Specification
+author: Xync Network (@XyncNet)
+discussions-to: https://github.com/ChainAgnostic/namespaces/pull/188
+status: Draft
+type: Informational
+created: 2026-07-08
+requires: ["CAIP-2", "CAIP-19"]
+---
+
+# CAIP-19
+
+*For context, see the [CAIP-19][] specification.*
+
+## Introduction
+
+Xync carries up to 255 protocol-native currencies (fiat units backed
+by regulated issuers, wrapped coins, loyalty units) plus the native
+token XYNC. Currencies are not contracts: they are single-byte codes
+in an on-chain registry that also stores the display name, decimal
+scale and issuer. Every asset therefore addresses with one byte.
+
+## Specification
+
+### Semantics
+
+The asset namespace is `cur`; the asset reference is the registry code
+(0–255). Code `0` is permanently the native token XYNC. The registry
+entry (resolvable below) carries `name` and `scale` — amounts on the
+wire are integers in minimal units of the given scale.
+
+### Syntax
+
+```
+asset_id:        chain_id + "/" + "cur" + ":" + code
+code:            0 | [1-9][0-9]{0,2}     (0..255)
+```
+
+### Resolution Mechanics
+
+```jsonc
+// GET https://<node>/currencies
+{
+  "0": {"name": "XYNC", "scale": 6},
+  "1": {"name": "USD",  "scale": 3, "issuer_acct": 8},
+  ...
+}
+```
+
+## Rationale
+
+A currency is a registry number, not a deployed contract: zero
+attack surface, identical behavior for every asset, and a 1:1 mapping
+to the 8-bit currency field of the native 128-bit transaction format.
+
+### Backwards Compatibility
+
+A `slip44:` asset namespace alias for the native token MAY be added
+after a SLIP-44 coin type is assigned to XYNC; `cur:0` remains
+canonical.
+
+## Test Cases
+
+```bash
+# native token XYNC on mainnet
+xync:main/cur:0
+
+# protocol-native USD (issuer-backed) on mainnet
+xync:main/cur:1
+
+# a currency on the development network
+xync:dev-1/cur:3
+```
+
+## References
+
+- [Xync Network Yellow Paper][] - the currency registry, issuers,
+  proof-of-reserves
+
+[CAIP-19]: https://chainagnostic.org/CAIPs/caip-19
+[Xync Network Yellow Paper]: https://xync.net/papers/yellowpaper.en.pdf
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

xync/caip2.md

@@ -0,0 +1,95 @@
+---
+namespace-identifier: xync-caip2
+title: Xync Network - Blockchain ID Specification
+author: Xync Network (@XyncNet)
+discussions-to: https://github.com/ChainAgnostic/namespaces/pull/188
+status: Draft
+type: Informational
+created: 2026-07-08
+requires: CAIP-2
+---
+
+# CAIP-2
+
+*For context, see the [CAIP-2][] specification.*
+
+## Introduction
+
+Xync Network is a payments-only Layer-1 blockchain. Networks in the
+"xync" namespace are identified by a short human-readable network name
+declared in the network's genesis file (`chain_id`). The genesis file
+is canonical and content-addressed: its SHA-256 hash is co-signed by
+the validator quorum in every checkpoint, so a reference resolves
+unambiguously to one genesis.
+
+## Specification
+
+### Semantics
+
+The reference is the `chain_id` field of the network's genesis file:
+`main` for the production network, `test-N` / `dev-N` for test and
+development networks. The reference intentionally excludes the
+namespace name (no `xync-` prefix) to avoid stutter.
+
+### Syntax
+
+```
+chain_id:    namespace + ":" + reference
+namespace:   xync
+reference:   [-_a-zA-Z0-9]{1,32}
+```
+
+### Resolution Mechanics
+
+Query any validator's public API:
+
+```jsonc
+// GET https://<node>/status
+{
+  "chain": "main",
+  "caip2": "xync:main",
+  "genesis_sha256": "9f2c…",   // co-signed by the checkpoint quorum
+  ...
+}
+```
+
+A client validates that `caip2` matches the expected identifier and
+MAY verify `genesis_sha256` against the published genesis file and the
+latest checkpoint signatures (2f+1 of the validator set).
+
+## Rationale
+
+Named references (like `hedera:mainnet`) rather than genesis-hash
+references (like `solana`): the genesis hash is still verifiable via
+resolution, while the identifier stays short and human-readable —
+consistent with the network's compact-identifier design philosophy
+(a whole transaction is 128 bits). Network names are unique within the
+namespace and assigned by namespace governance.
+
+### Backwards Compatibility
+
+Not applicable (the namespace launches with this specification).
+
+## Test Cases
+
+```bash
+# Xync mainnet
+xync:main
+
+# Xync development network
+xync:dev-1
+```
+
+## References
+
+- [Xync Network Yellow Paper][] - protocol specification (network
+  model, genesis, checkpoints)
+- [XyncPay][] - the live payment product on the network
+
+[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2
+[Xync Network Yellow Paper]: https://xync.net/papers/yellowpaper.en.pdf
+[XyncPay]: https://t.me/XyncPayBot
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).