In Regen Ledger we have the need to create a couple of different types of Account types other than the ones that are defined in the SDK. These Account's wouldn't have a public key associated with them but would have other authorization methods for sending coins. One example is an Account for an "organization" type entity that can only spend coins based on governance decisions. The ID of one of these organizations is internally just an auto-incrementing integer.

In looking at the implementation for addresses I see that they are fixed in length to 20 bytes. While the length of these keys may be enough to prevent any possible collisions via sheer randomness, I am concerned that this length limitation and the lack of any sort of prefixing on the built in address types reduces security because it increases the chance for a collision however small.

I don't have a lot of context for why the design is the way it is, but it seems to me that a more cautious design would be to add some sort of 1 byte prefix to the existing addresses (secp256k1 and ed25519) and allow for different address lengths as measures to prevent collisions. At a minimum, I would want the option to choose a different address length for my custom account types to at least avoid any potential collision there and to also avoid needing to unnecessarily pad them with zeros. I'm thinking that maybe the current 20 byte limitation is to ensure that addresses are entered correctly but maybe the bech32 checksum takes care of that?

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned