Skip to content

Latest commit

 

History

History
74 lines (53 loc) · 3.32 KB

nep-0492.md

File metadata and controls

74 lines (53 loc) · 3.32 KB
Raw
NEP Title Authors Status DiscussionsTo Type Version Created LastUpdated
492
Restrict creation of Ethereum Addresses
Bowen Wang <bowen@near.org>
Final
Protocol
0.0.0
2023-07-27
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 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:

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.