paritytech / ss58-registry

Registry for SS58 account types

SS58 Registry

A list of known SS58 account types as an enum, typically used by the Polkadot, Kusama or Substrate ecosystems.

These are derived from the json data file in this repository which contains entries like this:

{
	"prefix": 5,                       // unique u16
	"network": "astar",                // unique no spaces
	"displayName": "Astar Network",    //
	"symbols": ["ASTR"],               // symbol for each instance of the Balances pallet (usually one)
	"decimals": [18],                  // decimals for each symbol listed
	"standardAccount": "*25519",       // Sr25519, Ed25519 or secp256k1
	"website": "https://astar.network" // website or code repository of network
},

Process

1. Fork and clone this repo.

2. Add an additional account type to ss58-registry.json (contiguous prefixes are better).

3. Bump the minor (middle) version number of the Cargo.toml by running:

cargo install cargo-bump && cargo bump minor

4. Run git stage, commit, push and then raise a pull request.

5. Once the PR has landed, one of the admins can create a new release. This will release the new version to crates.io

Licensing

Apache-2.0

ss58-registry's Issues

[CI] cargo-unleash runs successfully but returns error

Example: https://gitlab.parity.io/parity/ss58-registry/-/jobs/1208916

Publish to npmjs registry

I didn't want to include this in #28 which I suspect is already underway. This is also about publishing, but slightly different.

1. After #33 we can now align the version of the root package.json with the Rust sources. To do so you can run npm run alignVersion. The suggested approach here is that after we tag/create a version (as per #28), we run this command and then can push the changes back to GitHub.

2. After #34 we can now publish the JS packages to npmjs as well. Basically run npm run alignVersion and then npm run build, which will create the outputs and then we can publish with cd npm_dist && npm publish --access public

The npm publish here should be no different from what we do in other @substrate packages (just not that familiar with the process generally employed for these on Parity CI)

Next steps

• Bump version to 1.0.0
• Release it to crates.io
• Create a release flow that will bump the patch version and push it to crates.io. This will make it very easy to add new addresses. But the release should probably only be triggered by a label or something. (As there could be other prs that don't mean we should release a new version or even we need to bump major version or whatever). Here @chevdor can probably help

Renumber Totem Kapex to fit within u8

This change is to align the Totem Kapex Parachain address identifier to fit within the u8 space rather than the current u16 to align with polkadotjs (apps).

std-leackage?

I have question regarding the ss58Registry, which has recently been introduced. Can you explain to me, how that does not introduce std-leakage in sp-core?

https://github.com/paritytech/substrate/blob/3b2ce548c6e00183ab12ab086859325164263584/primitives/core/Cargo.toml#L71

I seems to to so in our no_std crate depending on sp-core.

when run cargo bump minor, return error?

   Compiling clap v2.34.0                                                                                                                                                 
   Compiling semver v0.9.0                                                                                                                                                
   Compiling chrono v0.4.19                                                                                                                                               
   Compiling toml_edit v0.1.5                                                                                                                                             
   Compiling cargo_metadata v0.7.4                                                                                                                                        
   Compiling cargo-bump v1.1.0                                                                                                                                            
    Finished release [optimized] target(s) in 2m 51s                                                                                                                      
  Installing /root/.cargo/bin/cargo-bump
   Installed package `cargo-bump v1.1.0` (executable `cargo-bump`)
thread 'main' panicked at 'Workspaces are not supported yet.', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-bump-1.1.0/src/config.rs:102:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Does this allow duplicative prefix?

We want to keep things simple. Our canary network's prefix is 42 which is the same as the Substrate default prefix. Can I open a PR to add it to this repository?

Update Totem and add Totem Parachain [Kapex]

This is an update the existing entry for Totem, changing the symbol from XTX to TOTEM.

Additionally the Totem Kapex Parachain requires a new id and symbol as it has a different number of decimals.

The prefix selected is based on the reserved parachainID for the Kapex Parachain.

Tag & publish

CI should tag & publish a new crate version when a new crate version hits the main branch.

Support Testnets

We don't provide custom prefixes to testnets, instead these testnets should use 42 as prefix. However, some people still would like to have testnets inside the ss58 json file, because polkadot-js for example seems to use this as a canonical source of networks. See this for some more context.

Adding support for these testnets should be fairly simple. We would not support the reverse lookup, aka 42 would always return Substrate, but that should be okay.

@jacogr WDYT?

New Substrate docs do not contain the SS58 spec & details.

https://github.com/substrate-developer-hub/substrate-docs/blob/archive/main-mdx/v3/docs/07-advanced/h-ss58/index.mdx is the now non-existent file on main.

AFAIK there is now no hosted details on how SS58 works in detail.... where should this content live?

• In this repo?
• In a wiki for this repo?
• In a new place on docs?
• Other?