DCIPs/EIPS/eip-2026.md

---
eip: 2026
title: State Rent H - Fixed Prepayment for accounts
author: Alexey Akhunov (@AlexeyAkhunov)
discussions-to: https://ethereum-magicians.org/t/eip-2026-fixed-rent-prepayment-for-all-accounts-change-h-from-state-rent-v3-proposal/3273
status: Stagnant
type: Standards Track
category: Core
created: 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.
1. In [first version of State Rent proposal](https://github.com/ledgerwatch/eth_state/blob/master/State_rent.pdf), 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).
2. In the [second version of State Rent proposal](https://github.com/ledgerwatch/eth_state/blob/master/State_Rent_2.pdf), 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](../LICENSE.md).