proposal to restrict ethereum address on NEAR

[bowenwang1996]

Proposal to restrict the creation of Ethereum addresses on NEAR to prevent loss of funds and enable future possibilities for Ethereum wallets to support NEAR transactions.

Implementation: near/nearcore#9365

[render]

Your Render PR Server URL is https://nomicon-pr-492.onrender.com.

Follow its progress at https://dashboard.render.com/static/srv-cj1eubr438is380ja8n0.

[pvolnov]

What restrictions are there on creating an address through the registrar account? Will it require a signature with the Ethereum private key to prevent spam?

[abacabadabacaba]

Seems hacky. Why not restrict creation of top-level accounts entirely? Is there a use case for user-created top-level accounts (other than implicit accounts)?

Making a wallet that automatically switches between NEAR and Ethereum based on address doesn't sound good, because this approach cannot be extended to support other chains (many of which use the same address format as Ethereum). Similarly, this proposal may prevent users from accidentally withdrawing their tokens to NEAR, but not to any of the other chains, so this solution doesn't scale.

By the way, do exchanges even prevent withdrawals to a non-existent address? In most blockchains, transferring tokens to a non-existent address is not a problem, so many exchanges may not have any code to detect that.

A much better approach would be to standardize a set of prefixes denoting the chain, e.g. prepend near: to every NEAR address, eth: to every Ethereum address, and so on. If the wallets refuse to send tokens to an address without a correct prefix, the possibility of making a mistake would be greatly reduced, and this works with all chains.

[mfornet]

This seems to be a problem to be solved in the wallet / web interface, rather than in the protocol. Agree with @abacabadabacaba that this proposal feels hacky. What if someone pastes an ethereum address without 0x prefix, that could be a source of confusion as well. We can restrict altogether the creation of TLD without going through registrar, and have this logic on the registrar itself, rather than in the protocol.

[mfornet]

To some extent there is given there are ~5k such addresses already.

[frol]

Thank you @bowenwang1996 for submitting this NEP.

As a moderator, I reviewed this NEP and it meets the proposed template guidelines. I am moving this NEP to the REVIEW stage and would like to ask the @near/wg-protocol working group members to assign 2 Technical Reviewers to complete a technical review (see expectations below).

Just for clarity, Technical Reviewers play a crucial role in scaling NEAR ecosystem as they provide their in-depth expertise in the niche topic while work group members can stay on guard of the NEAR ecosystem. The discussions may get too deep and it would be inefficient for each WG member to dive into every single comment, so NEAR Developer Governance designed this process that includes subject matter experts helping us to scale by writing a summary with the raised concerns and how they were addressed.

Technical Review Guidelines

• First, review the proposal within one week. If you have any suggestions that could be fixed, leave them as comments to the author. It may take a couple of iterations to resolve any open comments.

• Second, once all the suggestions are addressed, produce a Technical Summary, which helps the working group members make a weighted decision faster. Without the summary, the working group will have to read the whole discussion and potentially miss some details.

Technical Summary guidelines:

• A recommendation for the working group if the NEP is ready for voting (it could be approving or rejecting recommendation). Please note that this is the reviewer's personal recommendation.

• A summary of benefits that surfaced in previous discussions. This should include a concise list of all the benefits that others raised, not just the ones that the reviewer personally agrees with.

• A summary of concerns or blockers, along with their current status and resolution. Again, this should reflect the collective view of all commenters, not just the reviewer's perspective.

Here is a nice example and a template for your convenience:

### Recommendation

Add recommendation

### Benefits

* Benefit

* Benefit

### Concerns

| # | Concern | Resolution | Status |

| - | - | - | - |

| 1 | Concern | Resolution | Status |

| 2 | Concern | Resolution | Status |

Please tag the @near/nep-moderators once you are done, so we can move this NEP to the voting stage. Thanks again.

[bowenwang1996]

yeah I think restricting all TLDs (other than implicit accounts) make sense.

[bowenwang1996]

@abacabadabacaba @mfornet the proposal is updated to restrict the creation of all top level accounts (other than implicit accounts)

[birchmd]

Seems ok to me as a way to prevent scams. Might be worth doing a little more research though to see if there are other top-level accounts which currently exist and would have been prevented by this proposal.

[birchmd]

What about other non-Ethereum-like top level accounts whos creation would have been restricted by this proposal?

[bowenwang1996]

There are a total of 11423 accounts on mainnet that are top-level accounts longer than 32 characters and that are not implicit accounts. I don't think there is a clear pattern that people use top-level accounts longer than 32 characters for.

[bowenwang1996]

@frol given that both Marcelo and Michael have approved the proposal, looks like we have a majority of support from the protocol working group. What else do we need to merge this proposal?

[frol]

@bowenwang1996 Thank you for reaching out! I moved this NEP to final comment period and will ask @near/nep-moderators to schedule a Protocol WG call to present this NEP to community and formally vote on it.

[birchmd]

As a member of the protocol working group, I approve this NEP.

Some notes from the discussion we had at the last open working group meeting:

• The title should be changed to reflect the increased scope (all top level accounts disallowed, not just Ethereum-like)
• Concerns around censorship should be addressed in follow-up discussions (i.e. actually spec out the top-level account name auction system; and in the meantime make the current registrar account more permissive).

[mfornet]

As a member of the Protocol WG I approve this NEP

[ori-near]

Thank you to everyone who attended the fifth Protocol Work Group call yesterday! The work group members reviewed the NEP and reached the following consensus:

Status: Approved

• 👍 @birchmd:proposal to restrict ethereum address on NEAR #492 (review)
• 👍 @mfornet: proposal to restrict ethereum address on NEAR #492 (review)

Meeting Recording:
https://youtu.be/oi0ooi9QBuk

@bowenwang1996 Thank you for authoring this NEP!

Next Steps:

• @bowenwang1996 Finish and merge implementation feat(runtime): restrict creation of Ethereum address on NEAR nearcore#9365
• @bowenwang1996 Stabilize the feature