feat: add Keeta namespace#183
Conversation
|
|
||
| - `keeta` is the namespace. | ||
| - `<networkId>` is a CAIP-2 reference for a Keeta network as defined by the [Keeta CAIP-2 Profile][CAIP-2 Profile]. | ||
| - `<address>` is the canonical Keeta public key string, **including** its `keeta_` prefix. |
There was a problem hiding this comment.
The keeta_ prefix is up for discussion. Keeta addresses always include the prefix but according to caip-10 the account_address must follow [-.%a-zA-Z0-9]{1,128} which doesn't allow for _.
Would it be possible to add _ to the allowed character set or should we strip the prefix?
There was a problem hiding this comment.
the former is essentially impossible, just do the latter!
| [Keeta][keeta-home] is a Delegated Proof of Stake (DPoS) Layer-1 designed for high-throughput asset transfers, real-world asset tokenization, and built-in compliance primitives (KYC, sanctions, ACLs). | ||
| The protocol uses a [Directed Acyclic Graph (DAG)][whitepaper] of per-account block chains rather than a single linearly-ordered ledger, which lets independent accounts publish concurrently and lets the network achieve sub-second finality. | ||
|
|
||
| The `keeta` namespace describes both the public Keeta main network and any of its sibling networks -- the test, staging, and dev networks, and any privately-launched **sub-network** (a private instance that runs the same protocol but with isolated transaction visibility and its own validator set). |
There was a problem hiding this comment.
the boundaries between networks remains a little ambiguous to me-- by calling them "sub-networks" and referring to the whole as a DAG, i am assuming multiple sub-networks can be "merged" without conflicts to create multi-network views? i would recommend making this more explicit for readers hearing about keeta for the first time and less familiar than me with DAGs.
|
|
||
| Keeta uses Delegated Proof of Stake. | ||
| Token holders elect representatives, which vote on the validity of vote staples (atomic groups of blocks). | ||
| Network-wide policy -- for example, the right to create new tokens or storage accounts -- is expressed as permissions on the [Network Account][accounts], a deterministically-generated identifier account that exists once per network. |
There was a problem hiding this comment.
so if a keypair is used on multiple networks, it can have different permissions on different Network Accounts?
|
|
||
| A Keeta network -- main, test, staging, dev, or any privately-launched network -- is uniquely identified by a single non-negative integer called its `networkId`. | ||
| A privately-launched network is a private instance that runs the same Keeta protocol but with isolated transaction visibility and its own validator set; it shares the key-pair format and address encoding with the public networks but is distinguished from them solely by its `networkId`. | ||
| The same `networkId` is used by the protocol to deterministically derive the network's [Network Account][accounts] and base token address, so two networks with the same `networkId` are by construction the same network. |
There was a problem hiding this comment.
two networks with the same networkId are by construction the same network.
but if they have isolated txn visibility, they're not, they're two independent shards of the same network that don't see each other's transactions until somehow merged or bridged, right? this isn't very clearly explained tbh
| The `reference` MUST match: | ||
|
|
||
| ``` | ||
| ^(0|[1-9][0-9]{0,31})$ |
There was a problem hiding this comment.
If there is a special case for networkId===0, you should explain it in this document. is it a "public key regardless of network" placeholder for CAIP-10 purposes? if so, explain it in both CAIP-2 and CAIP-10 documents, and explain if it can be used in standalone form (i.e. as a CAIP-2), or just as a CAIP-10.
| ^keeta_[a-z2-7]+$ | ||
| ``` | ||
|
|
||
| A regex match is necessary but not sufficient for validity as it does not verify the type indicator, checksum, or body length. |
There was a problem hiding this comment.
| A regex match is necessary but not sufficient for validity as it does not verify the type indicator, checksum, or body length. | |
| A regex match is necessary but not sufficient for checking address validity as it does not verify the type indicator, checksum, or body length. |
|
May I just say my stuff always goes to 404.
Jennifer Wages
…On Wed, May 27, 2026 at 7:06 AM Bumblefudge ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In keeta/caip10.md
<#183 (comment)>
:
> +keeta:<networkId>:<address>
+```
+
+Where:
+
+- `keeta` is the namespace.
+- `<networkId>` is a CAIP-2 reference for a Keeta network as defined by the [Keeta CAIP-2 Profile][CAIP-2 Profile].
+- `<address>` is the canonical Keeta public key string, **including** its `keeta_` prefix.
+
+The `<address>` segment MUST match:
+
+```
+^keeta_[a-z2-7]+$
+```
+
+A regex match is necessary but not sufficient for validity as it does not verify the type indicator, checksum, or body length.
⬇️ Suggested change
-A regex match is necessary but not sufficient for validity as it does not verify the type indicator, checksum, or body length.
+A regex match is necessary but not sufficient for checking address validity as it does not verify the type indicator, checksum, or body length.
—
Reply to this email directly, view it on GitHub
<#183?email_source=notifications&email_token=BGPM7QFNVRFHEOP7RZBDLW3443K3FA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMZXGIYTQMRUGAZKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#pullrequestreview-4372182402>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BGPM7QAIU2OC4OPC3XWUDSL443K3FAVCNFSM6AAAAACYKXCS7WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DGNZSGE4DENBQGI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I’m novice but I’m trying.
Jennifer Wages
On Wed, May 27, 2026 at 7:06 AM Jennifer Wages ***@***.***>
wrote:
… May I just say my stuff always goes to 404.
Jennifer Wages
On Wed, May 27, 2026 at 7:06 AM Bumblefudge ***@***.***>
wrote:
> ***@***.**** commented on this pull request.
> ------------------------------
>
> In keeta/caip10.md
> <#183 (comment)>
> :
>
> > +keeta:<networkId>:<address>
> +```
> +
> +Where:
> +
> +- `keeta` is the namespace.
> +- `<networkId>` is a CAIP-2 reference for a Keeta network as defined by the [Keeta CAIP-2 Profile][CAIP-2 Profile].
> +- `<address>` is the canonical Keeta public key string, **including** its `keeta_` prefix.
> +
> +The `<address>` segment MUST match:
> +
> +```
> +^keeta_[a-z2-7]+$
> +```
> +
> +A regex match is necessary but not sufficient for validity as it does not verify the type indicator, checksum, or body length.
>
> ⬇️ Suggested change
>
> -A regex match is necessary but not sufficient for validity as it does not verify the type indicator, checksum, or body length.
> +A regex match is necessary but not sufficient for checking address validity as it does not verify the type indicator, checksum, or body length.
>
> —
> Reply to this email directly, view it on GitHub
> <#183?email_source=notifications&email_token=BGPM7QFNVRFHEOP7RZBDLW3443K3FA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMZXGIYTQMRUGAZKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#pullrequestreview-4372182402>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/BGPM7QAIU2OC4OPC3XWUDSL443K3FAVCNFSM6AAAAACYKXCS7WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DGNZSGE4DENBQGI>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
|
|
|
||
| Implementations SHOULD use the methods of a Keeta SDK (e.g. `account.isToken()`, `account.isStorage()`) to determine the type of an account. | ||
|
|
||
| Note that account _existence_ is not required for a CAIP-10 string to be valid -- Keeta accounts come into existence when their first block is published, and a freshly-derived keyed address may be a perfectly valid recipient before any block has ever been published to its chain. |
There was a problem hiding this comment.
this might be a good place to explain the networkId 0 special case...
| Keeta addresses encode their algorithm and type in the leading body characters and end in a checksum, so single-character typos and accidental cross-pasting between account types (e.g. sending to a token address instead of a keyed account) are detectable on the client side without a network round-trip. | ||
| Implementations SHOULD perform this check before signing a transaction that references a counterparty CAIP-10. | ||
|
|
||
| The same key pair derives to the same `keeta_...` address on every Keeta network, but the `<networkId>` segment of a CAIP-10 string is not redundant: the on-chain _state_ of an account (balances, permissions, certificates, history) is per-network, and applications MUST treat `keeta:21378:keeta_...` and `keeta:1413829460:keeta_...` as different accounts even when the address bodies are identical. |
There was a problem hiding this comment.
I'd recommend moving this paragraph to the "Introduction" or other section where fewer readers will miss/skip it, it's a crucial semantic assertion useful to first-timers!
bumblefudge
left a comment
bumblefudge
left a comment
There was a problem hiding this comment.
Mostly minor feedback but _ is an invalid character for CAIP-10s, and keeta_ is kind of redundant if keeta: is already being prefixed before the network id, so i'd drop the prefix and have a think on how non-account, non-token addresses can be expressed in CAIP-compatible ways!
3 participants
This PR adds a new
keetanamespace for Keeta, a high-performance Layer 1 blockchain built to meet the demands of the global financial system.It includes specifications for CAIP2, CAIP10, and CAIP19.
References