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
const leadingZeros = hexString.match(/^0x0+/);
if (!leadingZeros) {
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
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”
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