Add ERC for deposit address and contract interface

[junderw]

This ERC defines a simple contract interface for managing deposits. It also defines a new address format that encodes the extra data passed into the interface's main deposit function.

[junderw]

Question: Should I explicitly mention that address(0) is not a valid base address and explicitly require an address validator to fail if the base address portion is address(0)? Or is it sufficient enough to assume as a given?...

[MicahZoltu]

I left some comments, but the structure looks good so this is good to merge as a draft I believe. You may want to look into payment URLs (https://eips.ethereum.org/EIPS/eip-681) as I think it strives to serve a similar purpose, but with token support and without limiting to only this particular contract interface. The idea is that any wallet that works with payment URLs would be able to send to whatever receiving contract that the recipient wanted.

[junderw]

Thanks for the comments, I made a fix here #2877

As for eip-681, from the perspective of an exchange looking for a solution to a problem (which I am), here are the reasons why I found it insufficient:

1. Adoption rate is low among other exchanges and wallets.
2. Designing a UI/UX around it is nearly impossible, since any transaction we make on behalf of our user we need to get confirmation "is this what you want to do?"... but if we scan a URI that says "call gorbldeyGoopedy(uint256,bytes8) with this number and these bytes" how do I confirm that with my user without confusing the heck out of them? If we assume the users all know the abi of the contracts and what they do/mean, yeah maybe we could make a UI that just says the function name and shows the parameters... but this assumption is not safe imo.
3. Implementation is difficult. Not only due to UX/UI issues above, but also conceptually for developers to comprehend the vast possibility space of what a scanned URI could mean for the app they are developing. It is extremely open ended, and if they think "well, our exchange only needs to deposit funds, why do I need to support every possible abi under the sun? They will likely avoid using it for their ETH wallet. Perhaps they'll use it if they are super-into ETH development and want to support some super complicated DeFi app, but exchanges especially want to have the smallest exposure possible to possible issues.

From an exchange perspective, the best UX and dev experience for account-based-blockchain deposit systems has been ripple, thanks to their destination tag feature. However, that is not without its headaches (there is no checksum nor is the dest_tag embedded in the address, so people forget it or mistype it all the time... the deposit address format laid out in the EIP fixes those problems).

It would also be easy to fit support into existing APIs for my proposal. ie. web3.eth.sendTransaction could accept deposit address format in the to field, and throw an error if to is a deposit address and data is not null. Then exchanges will automatically be able to support this deposit address format if they use web3.eth.sendTransaction internally.

These are the reasons why I did not decide to just use EIP-681.

I really look forward to evangelizing this standard.

[MicahZoltu]

Note: The following is personal opinion, unrelated to my job as an EIP editor:

For (1), it feels like you'll end up with the same problem with this standard. Anything you can do to push adoption of this EIP you can do to push adoption of 681.

It feels like there isn't much of a difference to end-users between "put 0xabcd1234... into your wallet" and "put eth://abcd1234 into your wallet". In both cases the user will get an unhelpful error if their wallet doesn't support the standard, and in the case of this EIP the thing they paste into their wallet looks like a regular address (just a hex string) so it is less likely they'll ask the right questions or a wallet support representative who doesn't know about this EIP will realize the user is following a new standard.

A wallet could, if they so chose, only implement ETH transfers via 681 and give the user a "useful error" if they try to use a payment URL that does anything else. Alternatively, you could standardize a particular contract endpoint (like this EIP does) that is used specifically for ETH transfers but have the wallet integration protocol be 681. This way wallets could have a smaller set of 681 things to support, rather than having to support arbitrary method calls.