Ethereum devs publish EIP-7809 proposal for native tokens
Ethereum developer Paul Berg published a proposal for multiple native tokens on Ethereum that he says will improve user experience when transferring tokens, make native financial products easier to implement, and improve the potential for innovation in Ethereum Layer 2 applications.
Called EIP-7809, the proposal will add a backward-compatible extension to the EVM that will allow fungible tokens to operate with “native-like” properties if it passes Ethereum’s process for approving new proposals.
Ether (ETH) already functions as Ethereum’s native token. Nearly every other Ethereum-based token was built on top of the network without including most of the same “native” qualities that ETH has.
This limits functions such as direct token transfers using opcodes and transferring multiple tokens in a single contract call. EIP-7809 introduces four new opcodes:
- MINT & BURN, which allows token supply management through (obviously) minting and burning tokens
- BALANCEOF for checking token balances
- NTCALL for token transfers that require calling a contract
- NTCREATE for creating a contract that includes upfront token deposits
The new EIP also proposes replacing the “value” field with “(token_id, token_amount)” pairs. This new variable will be bundled with “transferred_tokens_length” in the “native_tokens_list” element.
Berg says this proposal arose from work on the now-discontinued Sablier Mainnet. The mainnet would have provided an infrastructure for token distribution. Sablier decided to launch on the L2 platform Morph instead.
One critic on EIP-7809’s GitHub page said parts of the proposal were redundant due to similarities with previous proposals. EIP-223 already proposes a standard that “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.”
EIP-223’s calldata_data parameter sounded similar to the NTCALL opcode.
Read more: Did Vitalik Buterin’s girlfriend stall Ethereum development?
EIP-1155 describes another proposed method for transferring multiple tokens in a single call. EIP-1363 describes a method for executing a contract after a token transfer without having to pay a gas fee twice.
Similarities to functions that are already available on the Solana blockchain were duly noted. Solana introduced the Token Program and Token Extensions to develop a common implementation for viewing and managing Solana-based tokens.
This proposal might not affect the actual supply of ETH unless the developers decide to use the MINT & BURN opcode to adjust it. MINT & BURN likely uses the proposal’s “token_id,” or unique smart contract address.
One commenter suggested changing ETH’s token ID to 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee, a value they said was already used by several decentralized exchanges.
If Berg’s EIP-7809 proposal passes, ETH may soon become one of many native or “native-like” tokens on Ethereum. It could help simplify token supply management, checking token balances, and token transfers that have to interact with a contract.
Got a tip? Send us an email or ProtonMail. For more informed news, follow us on X, Instagram, Bluesky, and Google News, or subscribe to our YouTube channel.