Add EIP: Native Tokens

[PaulRBerg]

This EIP introduces Multiple Native Tokens as a backward-compatible extension of the EVM, enabling
fungible tokens to function with native-like properties.

[eth-bot]

File EIPS/eip-7809.md

Requires 1 more reviewers from @axic, @g11tech, @gcolvin, @lightclient, @SamWilsn

[PaulRBerg]

Could we please get a number assigned to this EIP?

We have written an accompanying thread for posting on X/ Farcaster, which would attract more reviewers.

cc @abcoathup

[u59149403]

Edit: I changed my opinion. See: https://ethereum-magicians.org/t/eip-7809-native-tokens/21615/9?u=u59149403

All these functionality already exists in https://eips.ethereum.org/EIPS/eip-223 . Read it carefully, including rationale. In particular pay attention to this phrase: "This standard allows payloads to be attached to transactions using the bytes calldata _data parameter, which can encode a second function call in the destination address, similar to how msg.data does in an ether transaction". In other words, 3rd parameter of transfer method may contain another call. I. e. you can perform "call with value", i. e. this is what your NTCALL does.

See also: https://eips.ethereum.org/EIPS/eip-1363

And finally: https://eips.ethereum.org/EIPS/eip-1155 . eip-1155 allows to transfer multiple tokens in single call. And send arbitrary data, which (similarly to eip 223) may contain another call.

So, I think existing EIPs already subsume your proposal. (Note: I'm not Ethereum developer)

[u59149403]

I suggest initializing ETH's ID (i. e. ETH's unique contract address) to 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee instead. This value is already widely used by many dapps (in particular by DEXs) to refer to ETH. I. e. it is used as "pseudo-ERC-20" contract address for ETH. (Note: I'm not Ethereum developer)

[github-actions]

The commit dcdc6ee (as a parent of 3e75013) contains errors.
Please inspect the Run Summary for details.

[miohtama]

Good work! As there is some finally some work on this topic, here is the wish list (copied from other chains) on some of the items on the check list for better UX and DX which could be addresses in this spec, or other ERCs. It's important to have "full package" of the token features for building applications. Let's make sure the spec carries all the way through and addresses all the needs of application developers.

Some very important user stories include:

-[ ] 1. One RPC call to get balances of tokens of an address: wallets need to do know what tokens the user owns, now it is a good time to add an index for this as a standard full node RPC feature
-[ ] 2. Reject token transfers: Never ever lose your money when sending unsupported tokens to CEX
-[ ] 3. New token enumeration and events: You need to know when new tokens are created
-[ ] 4. Standardised rich token metadata including: icon, website, various discussion forums, source code, repository, issue tracker, legal contract, default price feed for a wallet to convert balance to USD (currently all of these are painfully manually tracked offchain)

Some list of token standard documentation from other relevant chains

• https://spl.solana.com/token
• https://spl.solana.com/token-2022
• https://docs.multiversx.com/tokens/overview
• https://docs.radixdlt.com/docs/asset-oriented

[Dexaran]

@PaulRBerg what this opcode should do?

NTCALL - 0xb4 NTCALLCODE - 0xb5

(I suppose they act similar to call and callcode but the behaviour/logic of the opcodes is not written in the proposal, just the args)

Also, why is the transferring method so overcomplicated?

• transferred_tokens_length: the number of transferred tokens
• The list of transferred_tokens_length (token_id, token_amount) pairs
• argsOffset: byte offset in the memory in bytes, the calldata of the sub context
• argsSize: byte size to copy (size of the calldata)
• retOffset: byte offset in the memory in bytes, where to store the return data of the sub context
• retSize: byte size to copy (size of the return data)

I guess the idea was to let tokens be transferred with just one transaction but this overcomplicates the logic of transferring significantly and I can envision a huge number of mistakes the implementers will be making with that.

I would be in favour of keeping the logic as clean and simple as possible. Only allow 1 token to be transferred at a time, so that you would only need gas, address, token_id, quantity and data. No offsets, no lists in args.

[wjmelements]

@Dexaran the preferred forum for discussion is specified by discussions-to