Skip to content

Commit

Permalink
Merge branch 'main' into add-multiversx
Browse files Browse the repository at this point in the history
  • Loading branch information
radumojic authored Dec 6, 2023
2 parents 96596e9 + 1de24f4 commit a247fd3
Show file tree
Hide file tree
Showing 3 changed files with 93 additions and 4 deletions.
19 changes: 16 additions & 3 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,15 +10,28 @@

Your first PR should be a complete draft of the README.md for your namespace with at least CAIP-2 addressed, but we also welcome additional CAIPs.
An editor will manually review the first PR for a new CAN and assign it a number before merging it.
Make sure you include a `discussions-to` header with the URL to a discussion forum or open GitHub issue where people can discuss the CAN as a whole; if you requested feedback from other teams or counterparties in your namespace before submitting, a private fork of the namespaces repo containing these discussions is a perfectly valid and helpful `discussions-to` entry.
Note that `discussions-to` can be a single value or an array, too much discussion is more helpful than not enough.
It is also acceptable to tag interlocutors and reviewers familiar with the namespace in the initial PR; you may be asked to do so by the editors.
Make sure you include a `discussions-to` header with one or more URLs a GitHub issue, GitHub Discussion, or other forum where people can discuss the CAN going forward; if you requested feedback from other teams or counterparties in your namespace before submitting, an issue or discussion on a fork of the namespaces repo is also a helpful addition to the `discussions-to` entry, which can be an array.
It is also acceptable to tag interlocutors and reviewers familiar with the namespace in the initial PR; you may be asked to do so later by the editors if they are not familiar with the community.

If your CAN requires images, the image files should be included in a subdirectory of the `assets` folder for that CAN as follows: `assets/namespace-N` (where **N** is to be replaced with the CAN name).
When linking to an image in the CAN, use relative links such as `../assets/namespace-{N}/image.png`.

It is greatly appreciated if you can render your PR locally to check the Jekyll syntax; to do so, run `bundle exec jekyll serve`.

## Style Guide

Github-flavored Markdown is encouraged for all CAIP documents, with the following conventions observed:

Line breaks:
- One line per sentence (or independent clause in the case of semicolons) makes for easier parsing of diffs in PR review and is preferred but not required

Link formatting:
- All external documents cited should be defined at the end of the `## References` section of each document, one per line, in the form `[CAIP-1]: https://chainAgnostic.org/CAIPs/CAIP-1` - these link alias definitions are invisible in rendered markdown, but serves as footnotes to readers viewing the files in a text editor.
- All references to other namespaces or to CAIPs should refer to the rendered form on the domain controlled by CASA (e.g. `https://chainagnostic.org/CAIPs/caip-104`) rather than to the current public git repository that it renders from (currently, `https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-104.md?plain=1`, but subject to change)
- All references elsewhere in the text should be by link-alias (e.g. `[CAIP Syntax][CAIP-1]`) rather than self-contained (e.g. `[CAIP syntax](https://ChainAgnostic.org/CAIPs/caip-1)`); note that in this example, `[CAIP-1][CAIP-1]`, `[CAIP-1][]` and `[CAIP-1]` will all link to the same URL if the alias has been defined elsewhere in the document when rendered. This makes the document easier to read in a text editor.
- Links to other sections should always take the form of markdown section heading links rather than HTML anchors or any other reference, e.g. `For further detail, see the [Security Considerations section](#security-considerations)`
- Providing lists of normative and non-normative references according to, e.g., the [IETF style guide for references](https://www.ietf.org/archive/id/draft-flanagan-7322bis-07.html#section-4.8.6) is welcomed but not required; a short list of useful documents or additional resources with captions or explanations is also welcome.

## References

[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2
Expand Down
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ They consist of a 1 high-level "README.md" file to contextualize the ecosystem,
Each "CAIP profile" defines the namespace's syntax, semantics, and context for that CAIP (i.e., it's address format, actor model, asset addressing model, etc.).
The intended audience of both the general "README.md" and each profile is a developer familiar with the CAIP being profiled but not familiar with the ecosystem being described, so the best namespaces provide all the links and entry-level explanations of the context needed for developers to build wallet and/or dapp interfaces that interact with assets, contracts, and accounts of a given namespace.

The namespaces are best read on the [namespaces][] "docs" website rather than in github. To contribute see the [Contributing file](./CONTRIBUTING.md).
The namespaces are best read as rendered on the [namespaces][] website rather than in github. To contribute see the [Contributing file](./CONTRIBUTING.md).

## How it works
Each namespace implements one or more [CAIPs](https://github.com/ChainAgnostic/CAIPs). The most important CAIPs to consider for a namespace are:
Expand Down
76 changes: 76 additions & 0 deletions monero/caip10.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
---
namespace-identifier: monero-caip10
title: Monero - Addresses
author: silverpill (@silverpill)
discussions-to: https://github.com/ChainAgnostic/namespaces/issues/41
status: Draft
type: Informational
created: 2023-09-01
requires: ["CAIP-10"]
---

# CAIP-10

*For context, see the [CAIP-10][] specification.*

## Rationale

CAIP-10 defines a pattern for identifying an account in a blockchain.
Monero chains use UTXO model and [Monero addresses][] are functionally similar to accounts in other namespaces.

## Semantics

Monero has several types of addresses: [standard address](https://monerodocs.org/public-address/standard-address/), [subaddress](https://monerodocs.org/public-address/subaddress/) and [integrated address](https://monerodocs.org/public-address/integrated-address/).
Any address contains network and address type identifiers, public spend key, public view key, a checksum, and may contain additional data depending on the address type.
Note that the [Base58-monero][base58-monero] encoding algorithm is used to encode the address from a byte array into a string; it uses the same alphabet as [base58btc][] but should not be decoded using [base58btc][] libraries due to the additional padding step to normalize string length.

CAIP-10 "accounts" should not be confused with [Monero accounts][], which are used in Monero wallets for grouping related addresses and transactions.

## Syntax

Monero CAIP-10 account ID is a case-sensitive string in the form:

```
account_id: chain_id + ":" + address
chain_id: See Monero CAIP-2 profile
address: [a-zA-Z0-9]{95,106}
```

The syntax of `chain_id` is specified in [Monero CAIP-2][].

## Test Cases

This is a list of manually composed examples:

```
# Monero mainnet standard address
monero:418015bb9ae982a1975da7d79277c270:4AdUndXHHZ6cfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2684Rge
# Monero mainnet integrated address
monero:418015bb9ae982a1975da7d79277c270:4LL9oSLmtpccfufTMvppY6JwXNouMBzSkbLYfpAV5Usx3skxNgYeYTRj5UzqtReoS44qo9mtmXCqY45DJ852K5Jv2bYXZKKQePHES9khPK
# Monero private testnet subaddress
monero:00000000000000000000000000000000:86MD1PNx3vmKUQjLvxNnmUfGQoHXAg8x56Nq97KrziKj5K8ACnpNUYx2KjiNAczP3igo7uUUUoGssDvKuZ7UUEoM1A8cvZs
```

## Additional Considerations

In the future new types of Monero addresses will be introduced.
They will likely be longer and may exceed the 128 character limit set in [CAIP-10][] specification.

## References

- [Address documentation][Monero Addresses] from Monero documentation
- [Account documentation][Monero Accounts] from Monero documentation

[CAIP-10]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-10.md
[Monero addresses]: https://www.getmonero.org/resources/moneropedia/address.html
[Monero accounts]: https://www.getmonero.org/resources/moneropedia/account.html
[base58-monero]: https://monerodocs.org/cryptography/base58/
[Monero CAIP-2]: https://github.com/ChainAgnostic/namespaces/blob/main/monero/caip2.md
[base58btc]: https://datatracker.ietf.org/doc/html/draft-msporny-base58-02
[base58btc-alphabet]: https://datatracker.ietf.org/doc/html/draft-msporny-base58-02#section-21

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

0 comments on commit a247fd3

Please sign in to comment.