While you can use the value of
salt as input data to the authentication scheme of the account (e.g. for storing the threshold balance of ERC-1155 tokens required to use the account), the primary behavior of salt is to allow multiple account instances for the same account implementation per token. It doesn’t make sense to keep this data private, as it’s not a key. Storing the
salt data allows for the account implementation to access it’s value (which enables it to be used within the authentication logic) and allows the account to re-compute its own address locally (which is useful for proving account authenticity when calling into other contracts). In short,
salt isn’t designed to store private data.
salt is a required input value for all token bound accounts as it affects the account address computation. Users that don’t wish to customize the salt can default to a salt value of zero. Because
salt is not intended to be used for authentication and is required for all accounts, I don’t think it makes sense to change the language here.
Currently the appended data is determined by the registry and cannot be customized. This is to ensure that the bytecode for any token bound account is easily computable without relying on external data sources.
Using a custom implementation allows you to store any data you wish to using smart contract storage. This allows for easy querying of data. However, smart contract storage behind a proxy cannot be constant or immutable.
Correct, although querying whether a given implementation is a smart contract is trivial by extracting the implementation address from the account bytecode and querying it’s code length.
I’d love to hear more about your use case here! What arbitrary data are you hoping to append to the account bytecode? I’d be open to including an optional
extraData parameter in the account creation function that allows for additional arbitrary data to be embedded in the account contract if there is sufficient interest. The tradeoff would be making deterministic calculation of token bound account addresses more difficult for applications integrating with ERC-6551.