proposal to restrict ethereum address on NEAR

neps/nep-0492.md

@@ -0,0 +1,74 @@
+---
+NEP: 492
+Title: Restrict creation of Ethereum Addresses
+Authors: Bowen Wang<bowen@near.org>
+Status: Draft
+DiscussionsTo: https://github.com/near/NEPs/pull/492
+Type: Protocol
+Version: 0.0.0
+Created: 2023-07-27
+LastUpdated: 2023-07-27
+---
+
+## Summary
+
+This proposal aims to restrict the creation of top level accounts (other than implicit accounts) on NEAR to both prevent loss of funds due to careless user behaviors and scams
+and create possibilities for future interopability solutions.
+
+## Motivation
+
+Today an [Ethereum address](https://ethereum.org/en/developers/docs/accounts/) such as "0x32400084c286cf3e17e7b677ea9583e60a000324" is a valid account on NEAR and because it is longer than 32 characters,
+anyone can create such an account. This has unfortunately caused a few incidents where users lose their funds due to either a scam or careless behaviors.
+For example, when a user withdraw USDT from an exchange to their NEAR account, it is possible that they think they withdraw to Ethereum and therefore enter their Eth address.
+If this address exists on NEAR, then the user would lose their fund. A malicious actor could exploit this can create known Eth smart contract addresses on NEAR to trick users to send tokens to those addresses. With the proliferation of BOS gateways, including Ethereum ones, such exploits may become more common as users switch between NEAR wallets and Ethereum wallets (mainly metamask).
+
+In addition to prevent loss of funds for users, this change allows the possibility of Ethereum wallets supporting NEAR transactions, which could enable much more adoption of NEAR. The exact details of how that would be done is outside the scope of this proposal.
+
+There are currently ~5000 Ethereum addresses already created on NEAR. It is also outside the scope of this proposal to discuss what to do with them. 
+
+## Specification
+
+The proposed change is quite simple. Only the protocol registrar account can create top-level accounts that are not implicit accounts
+
+## Reference Implementation
+
+The implementation roughly looks as follows:
+
+```Rust
+fn action_create_account(...) {
+    ...
+    if account_id.is_top_level() && !account_id.is_implicit()
+                && predecessor_id != &account_creation_config.registrar_account_id
+            {
+                // Top level accounts that are not implicit can only be created by registrar
+                result.result = Err(ActionErrorKind::CreateAccountOnlyByRegistrar {
+                    account_id: account_id.clone(),
+                    registrar_account_id: account_creation_config.registrar_account_id.clone(),
+                    predecessor_id: predecessor_id.clone(),
+                }
+                .into());
+                return;
+            }
+    ...
+}
+```
+
+## Alternatives
+
+There does not appear to be a good alternative for this problem.
+
+## Future possibilities
+
+Ethereum wallets such as Metamask could potentially support NEAR transactions through meta transactions.
+
+## Consequences
+
+In the short term, no new top-level accounts would be allowed to be created, but this change would not create any problem for users.
+
+### Backwards Compatibility
+
+For Ethereum addresses specifically, there are ~5000 existing ones, but this proposal per se do not deal with existing accounts.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).