-
Notifications
You must be signed in to change notification settings - Fork 102
Add atto namespace and CAIP-2 specification
#178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 3 commits
01e62cf
a45f57f
30aca52
4392b9a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,47 @@ | ||
| --- | ||
| namespace-identifier: atto | ||
| title: Atto Ecosystem | ||
| author: Felipe Rotilho (@rotilho) | ||
| status: Draft | ||
| type: Informational | ||
| created: 2026-03-18 | ||
| --- | ||
|
|
||
| # Namespace for Atto Networks | ||
|
|
||
| ## Introduction | ||
|
|
||
| The `atto` namespace refers to the Atto ecosystem: | ||
| a fee-less account-chain payment network where value transfers are represented as native Atto blocks and transactions. | ||
|
|
||
| Atto is a native layer-1 system with its own chain model, transaction encoding, and account addressing, all defined by the Atto protocol. | ||
|
|
||
| The purpose of this namespace is to provide stable chain identifiers for Atto networks and a neutral reference point for cross-chain tooling built on CAIPs. | ||
|
|
||
| ## Rationale | ||
|
|
||
| Atto needs its own namespace because it introduces a distinct execution and validation model. | ||
| Native account-chain semantics, address encoding, and transaction serialization do not fit under existing namespaces such as EVM, Solana, or Stellar. | ||
| A dedicated namespace allows tools to refer to Atto deployment environments consistently using human-readable CAIP-2 identifiers. | ||
|
|
||
| ## Governance | ||
|
|
||
| This namespace tracks the Atto protocol and its network identifiers as defined by the Atto ecosystem maintainers. | ||
| Future CAIP profiles for Atto should follow this namespace to document account IDs, asset IDs, and other ecosystem-specific conventions. | ||
| Public network naming should remain stable over time to ensure long-term interoperability. | ||
|
|
||
| ## References | ||
|
|
||
| - [Documentation][] - Official documentation for the Atto ecosystem. | ||
| - [Node API Reference][] - Reference for the Atto node RPC and REST interfaces. | ||
| - [Integration Guide][] - Overview of Atto components, integration model, and operational guidance. | ||
| - [GitHub][] - Source code and development resources. | ||
|
|
||
| [Documentation]: https://atto.cash/docs | ||
| [Node API Reference]: https://atto.cash/api/node | ||
| [Integration Guide]: https://atto.cash/docs/integration | ||
| [GitHub]: https://github.com/attocash | ||
|
|
||
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,134 @@ | ||
| --- | ||
| namespace-identifier: atto-caip2 | ||
| title: Atto Namespace - Blockchain ID Specification | ||
| author: Felipe Rotilho (@rotilho) | ||
| discussions-to: https://github.com/ChainAgnostic/namespaces/pull/178 | ||
| status: Draft | ||
| type: Standard | ||
| created: 2026-03-18 | ||
| requires: CAIP-2 | ||
| --- | ||
|
|
||
| # CAIP-2 | ||
|
|
||
| *For context, see the [CAIP-2][] specification.* | ||
|
|
||
| ## Introduction | ||
|
|
||
| The `atto` namespace identifies Atto chains. | ||
| Atto is a native layer-1 payment network with an account-chain model, native address format, native transaction serialization, and lightweight proof-of-work used for anti-spam rather than consensus. | ||
|
|
||
| A CAIP-2 identifier in this namespace takes the form `atto:<reference>`. | ||
| The reference identifies a concrete Atto network environment such as mainnet, beta/test, development, or local/private development. | ||
|
|
||
| ## Specification | ||
|
|
||
| ### Semantics | ||
|
|
||
| The `atto` namespace is intended for chains that use the native Atto protocol and validation model. | ||
| A valid CAIP-2 identifier in this namespace refers to an Atto network that shares Atto's block model, address model, signing rules, and proof-of-work rules. | ||
|
|
||
| The following references are defined by this draft: | ||
|
|
||
| - `live` — Atto mainnet | ||
| - `beta` — Atto public beta / test network | ||
| - `dev` — Atto development network | ||
| - `local` — local or private development network | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this work like
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, exactly. Let me reword it to make that more explicit. |
||
|
|
||
| These references are intentionally short and stable. | ||
| They are meant to be human-readable deployment identifiers rather than hashes of genesis state. | ||
|
|
||
| ### Syntax | ||
|
|
||
| An Atto blockchain ID is a CAIP-2 string with namespace `atto` and a lowercase network reference. | ||
|
|
||
| Canonical format: | ||
|
|
||
| ```text | ||
| atto:<reference> | ||
| ``` | ||
|
|
||
| Reference values currently defined by this draft: | ||
|
|
||
| ```text | ||
| live | beta | dev | local | ||
| ``` | ||
|
|
||
| Suggested validation regex: | ||
|
|
||
| ```text | ||
| ^atto:(live|beta|dev|local)$ | ||
| ``` | ||
|
|
||
| Implementations MUST treat the namespace component as exactly `atto`. | ||
| Implementations SHOULD treat the reference component as lowercase. | ||
| Unknown future references within the `atto` namespace SHOULD be rejected unless explicitly supported by the implementation. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this mean the same private key will be able to sign for the same address on different chainIds, i.e., that it has an EVM-style replay vulnerability if a transaction is valid on multiple chains?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, the same private key can be used to control the same address across different chain. However, transactions include the network ID in the signed payload so a transaction signed for one chain is not valid on another and cannot be replayed across chains. |
||
|
|
||
| ### Resolution Mechanics | ||
|
|
||
| Resolution of an Atto CAIP-2 identifier is performed by selecting a node or service configured for the corresponding Atto network environment. | ||
| The identifier therefore resolves operationally through network-specific Atto infrastructure rather than through on-chain contract registries. | ||
|
|
||
| For public/shared environments, implementations SHOULD map the following identifiers to their corresponding Atto deployments: | ||
|
|
||
| - `atto:live` → mainnet infrastructure | ||
| - `atto:beta` → public beta/test infrastructure | ||
| - `atto:dev` → development infrastructure | ||
| - `atto:local` → local/private development infrastructure | ||
|
|
||
| If an implementation exposes multiple Atto environments, it MUST ensure that transactions, account state reads, and address validation are performed against infrastructure for the selected Atto chain only. | ||
|
|
||
| ## Rationale | ||
|
|
||
| Atto needs a dedicated namespace because its interoperability assumptions are not those of any existing namespace. | ||
| The same client or wallet logic used for EVM, Stellar, or Solana cannot be reused without Atto-specific validation logic. | ||
| Atto-native tooling must understand native account-chain state, native address encoding, and Atto-native transaction verification. | ||
|
|
||
| The references `live`, `beta`, `dev`, and `local` are chosen because they are short, operationally intuitive, and consistent with how integrators commonly distinguish production, test, development, and local environments. | ||
| This draft intentionally avoids deriving chain identifiers from opaque hashes or environment-specific values that are less legible for wallet and payment tooling. | ||
|
|
||
| ### Backwards Compatibility | ||
|
|
||
| Not applicable. | ||
|
|
||
| ## Test Cases | ||
|
|
||
| ```text | ||
| # Atto mainnet | ||
| atto:live | ||
|
|
||
| # Atto public beta / test network | ||
| atto:beta | ||
|
|
||
| # Atto development network | ||
| atto:dev | ||
|
|
||
| # Atto local / private development network | ||
| atto:local | ||
| ``` | ||
|
|
||
| ## Additional Considerations | ||
|
|
||
| This draft only defines CAIP-2 identifiers for Atto chains. | ||
| Additional Atto namespace profiles may later define: | ||
|
|
||
| - CAIP-10 account identifiers for Atto addresses | ||
| - CAIP-19 asset identifiers for the native Atto asset and future asset models, if any | ||
| - Other Atto-specific profiles where cross-chain tooling benefits from explicit namespace guidance | ||
|
|
||
| ## References | ||
|
|
||
| - [Documentation][] - Official documentation for the Atto ecosystem. | ||
| - [Node API Reference][] - Reference for the Atto node RPC and REST interfaces. | ||
| - [Integration Guide][] - Overview of Atto components, integration model, and operational guidance. | ||
| - [GitHub][] - Source code and development resources. | ||
|
|
||
| [Documentation]: https://atto.cash/docs | ||
| [Node API Reference]: https://atto.cash/api/node | ||
| [Integration Guide]: https://atto.cash/docs/integration | ||
| [GitHub]: https://github.com/attocash | ||
| [CAIP-2]: https://chainagnostic.org/CAIPs/caip-2 | ||
|
|
||
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this^ part is implicit-- if your namespace PR gets accepted, any future PRs extending or updating it are assumed to recognize your "first write wins" for conflict resolution 😅 . Usually, this section is for adding links to help the editors confirm if the ecosystem itself passed an improvement proposal, hard fork, etc when a later contributor wants to update it!
For instance, I saw this section, which is probably worth linking to from this section, but maybe also link to whatever github or other public forum concrete protocol updates are discussed in? That way, if a future contributor wants to update your PR, we can check to validate any claims about community governance decisions that happened in the interim.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right! :D
Rewrote this section and linked more resources in the References section