Been wondering this for a while now

and then I thought “That’s a daft thing to do, Ask someone.”

So here goes…

Why do all the address created so far on the shared vaults, on a private vault or in a private network begin with safe://h and then the next few chars are chosen from h, y, n or b

I know that answer will be something that should be obvious and I will probably kick myself when it is revealed…
Are we -as yet- restricting ourselves to a small subset of the available zillions of addresses and these chars are the result of some hard-coded value? But that would seem to me to run counter to the design philosophy so far.

And once again, thank you to @frabrunelle for decoding my horrendous typos in the original post :slight_smile: We are not worthy of such superb moderators


@Southside I’m clueless, but my guess is

It’s to indicate that your on the SAFE Network and using the SAFE protocol I suppose :thinking:
Like http or https is on clearnet

1 Like

Yeah, I know about the safe:// bit thats obvious, its the “h” then restricted set of [h n y b] usually repeated that form the next 5-6 chars that I was wondering about

1 Like

Hmmm interesting I didn’t notice that part (I’m using the mobile SAFE browser 0.3.0).

Maybe it has something to do with the NRS, I’ve been wondering for a while if that’s the same as publicid’s (NRS is not the same as Publicid’s as far as I know)… :thinking:

1 Like

The “XorURL” as we know it is actually a base32z string (base 32 is a string encoding scheme).

In base32, the following mappings exist:

  • 0 = y
  • 1 = b
  • 2 = n

I’m going to assume that the second value in the XorURL is the data type, from 0 - 8.

I believe the first value (the h) is the encoding_version of the XorURL, with the default currently being XOR_URL_VERSION_1 = 0x1, as for why it’s an h though, I’m not sure.

The code internally has this mapping (for the data type - the second character in the XorURL):

            0 => Ok(Self::SafeKey),
            1 => Ok(Self::PublishedImmutableData),
            2 => Ok(Self::UnpublishedImmutableData),
            3 => Ok(Self::SeqMutableData),
            4 => Ok(Self::UnseqMutableData),
            5 => Ok(Self::PublishedSeqAppendOnlyData),
            6 => Ok(Self::PublishedUnseqAppendOnlyData),
            7 => Ok(Self::UnpublishedSeqAppendOnlyData),
            8 => Ok(Self::UnpublishedUnseqAppendOnlyData),

You can find the code which implements the encoding of the XorURL here in the Safe-API libraries:


This makes sense now :slight_smile: Thank you

I suppose I should now be able to work out what is going on at the end of each address with the 9s - Or have I simply chosen a small unrepresentative sample?

New SafeKey created at: “safe://hbyyyybd7if5jqa4mu74mjnh6cgiufj8d9e6kdru1rdjq5eif3myi9sg9w”
Wallet created at: “safe://hnyybyqix8y47e5fbog9hirhx4tryzsogdrchb766sy1ijn5mfbys1azooy9e”
New SafeKey created at: “safe://hbyyyybkabrnso5nbjbu6dz5dfni8uirocwrddwdtbsz3c5s3b5s4atyn9”
Wallet created at: “safe://hnyybyq9sumcgmr98perut4m6q1fpmot896aqak3h411y78asrjkzh8fsky9e”


I believe - but this is unsubstantiated and based off very little research - that the final value is the content_version, so in the case of, say, a public_name it would be the published version of that public_name


I assume the latest definition of xor URLs should be linked here


In case it helps and you weren’t aware of, you can also use xorurl decode command to get details of the targeted content:


This topic was automatically closed after 60 days. New replies are no longer allowed.