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.
There was a problem hiding this comment.
A Keeta network is one large DAG. That DAG is made of account chains, each a proper chain of blocks belonging to one account. Operations in those blocks can point at other account chains. For example, a SEND from keeta_aa..aa to keeta_ab..bb lives on a’s chain and only holds a soft pointer to b. The collection of these account chains and their operations is one Keeta network and its ledger.
There was a problem hiding this comment.
Subnetworks are networks subordinated to a full network. They operate very similarly, with their own set of validators, except they are forever connected to their supernetwork. Account balances can flow freely and trustlessly between a supernetwork and its subnetworks, but not between unrelated networks.
The proposed spec does not incorporate subnetworks into the CAIP-2 namespace, and only implements full networks. I think this happened because subnetworks are only a planned feature, not something that exists today. Syntax in the form of keeta:<networkId>-<subnetworkId> could work to identify a subnetwork. It's TBD if we should do that today or as part of a later expansion when this feature is released.
|
|
||
| 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?
There was a problem hiding this comment.
Yes, exactly. The account corresponding to a keypair can have completely different permissions and balances across networks.
|
|
||
| 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
There was a problem hiding this comment.
Every network is a network with its own validators and own ledger. Networks can be deployed in various contexts. Some of them may be in centralized enterprise environments where some restrictions might be in place. Regardless, these are all just networks (and subnetworks - as described above) and shouldn't be treated any differently by this CAIP standard.
Just doing a quick pass now. Will try to adjust so it's better explained in the spec
| 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!
4 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