Hi, as I presented in previous AllWalletDevs about a proposal to represent leading zeros in address which reduces chance of phishing, I am thinking of starting an ERC.

## Motivation

• reduce phishing

## Specification

The format will be `0{N}xAA..BBBB`, where

• `N` is the number of leading zeros in decimal form
• `AA` is the two hex digits of two digits since first non-zero hex digit
• `BBBB` is the last four hex digits

## Rationale

• We choose `0{N}x` format so it can be easily differentiate from 0x
• We choose 2 digits before and 4 digits after in the non-zero part, instead of 4,4 for length restriction, but up for discussion
• We choose to turn into upper case ditching ERC-55 or ERC-1191 because those case switching no longer serves the purpose of checksum.
• We shall anticipate the short-form will need to be compatible with assumptions made in CAIPs

## Reference Implementation

``````// Javascript
function convertHexString(hexString) {
// Ensure the input is a string
if (typeof hexString !== 'string') {
throw new Error('Input must be a string.');
}

// Regex to match leading zeros
return hexString.toUpperCase(); // Return original in uppercase if no leading zeros
}

const zeroCount = leadingZeros[0].length - 2; // Subtract 2 for '0x'
const remainingString = hexString.slice(zeroCount + 2).toUpperCase(); // +2 for '0x', then convert to uppercase
const truncated = remainingString.substring(0, 2) + '...' + remainingString.slice(-4);

return `0{\${zeroCount}}x\${truncated}`;
}

// Example usage
const result = convertHexString('0x00000000219ab540356cbb839cbe05303d7705fa');
console.log(result); // Outputs: 0{8}x21...05FA
``````

## Test

original short note
`0x00000000219ab540356cbb839cbe05303d7705fa` `0{8}x21...05FA` ETH 2.0 deposit
`0x000000000022d473030f116ddee9f6b43ac78ba3` `0{10}x22...8BA3` Uniswap Permit2
`0x0000000000A39bb272e79075ade125fd351887Ac` `0{10}xA3...87AC` Blur
`0x00000000000000adc04c56bf30ac9d3c0aaf14dc` `0{14}xAD...14DC` OpenSea Seaport 1.4

## Soliciting Reviewers

We kindly invite the following reviewers for feedback

And anyone whose work and interest involves short form address representation.

2 Likes

The `0x` prefix signals that the constant literal immediate is hexadecimal. This prefix should not be split up.

The syntax you suggest is similar to the regular expression syntax but it is not a valid regular expression.

For both of these reasons your suggested format is an abomination.

Hiding the middle digits also increases the ease of phishing, though this is your supposed motivation.

Iâd be more interested in a solution like Bitcoinâs base58 which would increase the number of bits encoded per character while remaining alphanumeric.

2 Likes

Unicode emoji are good candidates for compressed addresses since they are easy to recognize. There are almost 4000 of them so far.

If you like Base58-style encoding gymnastics, you are gonna LOVE the multibase project over in IPFS land:

3 Likes

Iâm not sure Iâd go as far as `abomination` but I agree that this scheme risks being confused for or mistaken for schemes it rhymes with but breaks. What about something like
`0x0*8x21...05FA` or `0x8x21...05FA`?

Another wierd nit while weâre in pre-draft spitballing phase-- donât those `00` always come in pairs? Wouldnât it be `0x4x21...` since there are 4 bits of `00` rather than 8 characters of `0`?

You mean compare to
0{8}x21âŚ05FA, use `0x0*8x21...05FA` or `0x8x21...05FA`

I think thatâs doable!

The pros is that they are less like RegEx. Though the cons is they might look more like a math formular.

I am totally open to all suggestions regarding the best format. Having your opinion helps we gauge possible response from broader user base.

I think itâs possible there are odd number of zeros and itâs easier for general (non-tech) user to understand âthis is the first non-zero digitâ as opposed on zero always come in pair because its a âbyteâ

1 Like

but the first byte of 000005 isnât 5 itâs 05-- i take your point, tho, 0x2x05 might be confusing to a normie

Yes. Thatâs a rationale that deserves consideration. In that case it could be something like
`{9}0x1234`, but it may confuse user to think 0x1234 is the beginning of full 20bytes wallet address. I am still debating whether itâs better or less ideal.

Itâs possible for someone like you and I who are developers to be confused it with RegEx.

If our target is end user who are general and non-tech savvy, RegEx is not a widely known thing outside of developers. I wonât worry too much about it being confused with RegEx.

Thatâs possible, except for that it could create a bigger barrier to existing EVM wallet users, itâs too much a change and a much higher learning curve. Also could mistaken user from recognizing them and compare it with the hex string

1 Like

I encountered this scam attempt today