EIPs/EIPS/eip-2026.md

eip	title	author	discussions-to	status	type	category	created
2026	State Rent H - Fixed Prepayment for accounts	Alexey Akhunov (@AlexeyAkhunov)	https://ethereum-magicians.org/t/eip-2026-fixed-rent-prepayment-for-all-accounts-change-h-from-state-rent-v3-proposal/3273	Draft	Standards Track	Core	2019-05-14

Simple Summary

Creation of new accounts (both contracts and non-contracts) requires a fixed one-off rent prepayment. Pre-existed accounts require the same prepayment upon the first modification. The act of rent prepayment causes the addition of an extra field to accounts, called rentbalance. This field becomes part of state.

Abstract

This is part of the State Rent roadmap. This particular change introduces a fixed charge for state expansion that comes from adding new accounts to the state. Theoretically, it puts a bound on the number of accounts that can be ever created, because that fixed charge cannot be recycled via mining.

Motivation

The penalty is levied to the transaction sender. Rather than raising the gas cost of account creation (that would direct levy towards the miner), this change directs prepayment into the account's special field, rentbalance. It addresses several shortcomings of the simple raising of the gas cost:

1. Prepayments cannot be recycled via mining, which puts a theoretical bound on number of accounts in the state (though it is unlikely to ever be reached).
2. It is not possible for miners to circumvent the penalty or to extend such circumventions onto other users (via private fee rebates, for example).
3. This prepayment will be used to cover state rent in the future, and it will allow newly created contracts with 0 endowment not to be evicted in the same block.
4. It makes is possible to refund rentbalance upon self-destruction - when contract is self-destructed, both balance and rentbalance are returned.
5. Prepayments on pre-existing accounts are necessary to prevent hoarding of accounts ahead of this change.

Specification

On and after block H, every newly created account gets a new field rentbalance of type unsigned 256-bit integer. On and after block H, any operation that leads to the creation of a new account, deducts the amount ACCOUNT_PREPAYMENT from tx.origin. This amount is added to the rentbalance field of the created account. On and after block H, any operation that modifies an account that does not yet have rentbalance field, deducts the amount ACCOUNT_PREPAYEMENT from tx.origin. This amount is added to the rentbalance field of the modified account. This is a anti-hoarding measure.

Operations leading to the creations of a new account:

1. Creation of a non-contract account by sending non-zero ETH to an address with no associated account
2. Creation of a non-contract account by the block with coinbase pointing to an address with no associated account
3. Creation of a non-contract account by SELFDESTRUCT with the argument being an address with no associated account
4. Creation of a contract by transaction without destination but with data. This can result in either converting a non-countract account into a contract account, or creation of a contract account.
5. Creation of a contract by execution of CREATE or CREATE2. This can result in either converting a non-countract account into a contract account, or creation of a contract account.

After prepayments are introduced, there can be two reasons for ether to be deducted from tx.origin: purchasing and spending gas, and spending gas for prepayments. Gaslimit of a transaction currently plays a role of safety limit, where gaslimit * gasprice represents the maximum amount of wei the sender (tx.origin) authorises the transaction to deduct from its account. After prepayments are introduced, gaslimit * gasprice will still represent the maximum amount of wei spend, but it will be used for both gas purchases and prepayments, as necessary.

Rationale

Prior to rent prepayments, other alternatives were considered:

1. Simple raising of the gas cost - discussed in the Motivation section.
2. In first version of State Rent proposal, there was no notion of extra levy upon account creation. It created a slight usability issue, where newly created contracts with 0 endowment would be evicted in the same block (when rent is introduced). It delays the benefits of the State Rent programme until the actual introduction of rent (in second or third hard-fork).
3. In the second version of State Rent proposal, there was a notion of lock-up. It is very similar to rent prepayment, with the different that lock-up would not be covering future rent payments.

An alternative approach to limiting the prepayments (instead of the using gaslimit * gasprice as the limit) is to introduce a new dedicated field prepaymenlimit into the transaction. This field would only limit prepayments). Such approach would require changes in the transaction format, as well as changes in the user interface for transaction sender, and having two counters during the transaction execution - one for gas, and one for prepayments.

Backwards Compatibility

This change is not backwards compatible and requires hard fork to be activated. It might have some adverse effects on the existing contracts, due to more gas needed to be allocated for the creation of new accounts. These adverse effects need to analysed in more detail.

Test Cases

Tests cases will be generated out of a reference implementation.

Implementation

There will be proof of concept implementation to refine and clarify the specification.

Copyright

Copyright and related rights waived via CC0.