Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions atto/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
---
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 public Atto protocol as documented by the ecosystem's maintainers.
Protocol-level changes and governance-relevant decisions should be validated against public Atto materials, especially the whitepaper and official documentation, and against the implementation history in the public GitHub repositories.
Future updates to this namespace should cite those sources when describing changes to network behavior, distribution, staking, or other community-facing protocol decisions.

## References

- [Documentation][] - Official documentation for the Atto ecosystem.
- [Whitepaper][] - Public protocol and governance context, including decentralization and representative voting.
- [Node API Reference][] - Reference for the Atto node RPC and REST interfaces.
- [Integration Guide][] - Overview of Atto components, integration model, and operational guidance.
- [Blog][] - Public announcements and writeups for major ecosystem and protocol changes.
- [GitHub][] - Source code, issues, and pull requests for implementation history and concrete protocol updates.
- [Node Repository][] - Reference implementation of the Atto node and consensus behavior.

[Documentation]: https://atto.cash/docs
[Whitepaper]: https://atto.cash/docs/whitepaper
[Node API Reference]: https://atto.cash/api/node
[Integration Guide]: https://atto.cash/docs/integration
[Blog]: https://atto.cash/blog
[GitHub]: https://github.com/attocash
[Node Repository]: https://github.com/attocash/node

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
138 changes: 138 additions & 0 deletions atto/caip2.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,138 @@
---
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, a shared development network, or an ephemeral local/private development network.

## 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 public development network
- `local` — ephemeral local/private network

`atto:dev` is intended for a development deployment that is reachable by multiple participants and stable enough for shared testing, integration work, or external references.
`atto:local` is reserved for local-only, such as integration tests, benchmarks, and developer machines, where a fresh genesis may be created and no persistence or public discoverability is assumed.

### 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.
Copy link
Copy Markdown
Collaborator

@bumblefudge bumblefudge Apr 1, 2026

Choose a reason for hiding this comment

The 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?
If so, you might want a MUST not a SHOULD here (and a warning about replays and using a given key on multiple networks!) 😅

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The 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.

Source: https://atto.cash/docs/integration/advanced/protocol-offline-signing-reference#overview-of-atto-blocks


### 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` → shared development infrastructure
- `atto:local` → local/private development infrastructure

Implementations SHOULD treat `atto:local` similarly to a localhost-style environment: it is not expected to name a globally shared network, and identifiers using it are not expected to remain reusable outside the local context in which they were created.

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 uses stable, human-readable environment names instead of genesis-derived identifiers, because Atto deployments are intended to be referenced operationally by role.
This draft gives `local` stronger semantics than a generic development label: it is reserved for ephemeral or operator-scoped environments, while `dev` refers to a shared Atto development network that other participants may also target.
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 shared development network
atto:dev

# Atto ephemeral 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/).