diff --git a/EIPS/eip-2035.md b/EIPS/eip-2035.md
new file mode 100644
index 0000000000000..6b0eac7f5866a
--- /dev/null
+++ b/EIPS/eip-2035.md
@@ -0,0 +1,81 @@
+---
+eip: 2035
+title: Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs
+author: Alexey Akhunov (@AlexeyAkhunov)
+discussions-to: https://ethereum-magicians.org/t/eip-2035-stateless-clients-repricing-sload-and-sstore-to-pay-for-block-proofs/3284
+status: Draft
+type: Standards Track
+category: Core
+created: 2019-05-16
+---
+
+<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
+
+## Simple Summary
+<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
+The gas cost of EVM opcodes `SLOAD` and `SSTORE` increases in order to accommodate extra bandwidth required to propagate block proof together with the block
+headers and block bodies, as explained [here](https://medium.com/@akhounov/data-from-the-ethereum-stateless-prototype-8c69479c8abc).
+
+## Abstract
+<!--A short (~200 word) description of the technical issue being addressed.-->
+It is part of the State Rent roadmap. This particular change prepares Ethereum for introduction of the block proofs (current understanding is that they
+can be introuced without a hard fork). The introduction of the block proofs allows any Ethereum node that wishes to receive them, to process transactions
+in the blocks without needing to access the Ethereum state. All necessary information for the execution (and the proof of validity) is continued in the
+block proofs. In most Ethereum nodes, it will speed up the block processing and reduce the memory footprint of such processing. For mining nodes, however,
+there will be more work to do to construct and transmit the block proofs. Therefore, the extra charge (payable to the miners) is introduced. In the first
+phase, only contract storage will be covered by the block proofs. It means that the Ethereum nodes will still need access to the accounts in the state,
+but block proofs will make it optional to have access to contract storage for executing transactions. Therefore, only `SSTORE` and `SLOAD` opcodes are
+affected.
+
+## Motivation
+<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
+There is [empirical analysis](https://github.com/holiman/vmstats/blob/master/README.md) showing that `SLOAD` opcode is currently underpriced in terms
+of execution latency it adds to the block processing. The hypothesis is that it is due to the latency of the database accesses. In the same
+analysis, `SSTORE` is not considered, because its effect on the database accesses can be (and are in many implementations) delayed until the end of
+the block. Stateless clients approach to the contract storage will largely negate that latency because no database accesses will be required.
+Instead, bandwidth consumption goes up. There is emprical analysis (unpublished, but will be) suggesting that 1 uncached `SSTORE` or `SLOAD` adds
+at most 1 kB to the block proofs. At the current cost of data transmission (68 gas per byte), this translates to the increase of gas cost of both
+operations by 69k gas. However, in light of proposal in [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028), the increase can be made much smaller.
+
+## Specification
+<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
+Not very formal at the moment, but will be formalised with more research and prototyping. Gas of operations `SLOAD` and `SSTORE` increases by `X` gas when the storage slots accessed (read by `SLOAD` or written by `SSTORE`) were not previously accessed (by another `SLOAD` or `SSTORE`) during the same transaction.
+
+Future variant (will be possible after the implementation of the *Gross contract size acccounting*) is researched, where the increase is varied
+depending on the size of the contract storage, i.e. `SLOAD` and `SSTORE` for smaller contracts will be cheaper.
+
+## Rationale
+<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+[EIP-1884](https://eips.ethereum.org/EIPS/eip-1884) seeks to increase the gas cost of `SLOAD` but using a different justification
+(latency of the execution as described in the Motivation). This EIP is likely to increase the cost of `SLOAD` by a larger amount, therefore partially
+(because EIP-1884 also proposed other increases) supersedes EIP-1884.
+
+[EIP-2028](https://eips.ethereum.org/EIPS/eip-2028) describes the model that can be used for deciding the gas cost of data transmission. It is relevant
+because in the stateless client regime `SSTORE` and `SLOAD` operations add more data to be transmitted (as well as computation to verify the proofs).
+
+The main alternate design is the rent proportional to the size of the contract storage, which unfortunately introduces a serious griefing
+vulnerability problem, and so far the solution seems to be in redesigning and rewriting smart contracts in a way, which makes them not vulnerable.
+However, this approach is likely to be very expensive on the non-technical (ecosystem) level.
+
+## Backwards Compatibility
+<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
+This change is not backwards compatible and requires hard fork to be activated.
+There might also be an adverse effect of this change on the already deployed contract. It is expected that after this EIP and
+[EIP-2026](https://eips.ethereum.org/EIPS/eip-2026) (rent prepayment for accounts), the recommendation will be made to raise the gas limit. This can somewhat dampen the
+adverse effect of EIP. The most problematic cases would be with the contracts that assume certain gas costs of `SLOAD`
+and `SSTORE` and hard-code them in their internal gas computations. For others, the cost of interacting with the contract
+storage will rise and may make some dApps based on such interactions, non-viable. This is a trade off to avoid even bigger
+adverse effect of the rent proportional to the contract storage size. However, more research is needed to more fully
+analyse the potentially impacted contracts.
+
+## Test Cases
+<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
+Tests cases will be generated out of a reference implementation.
+
+## Implementation
+<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
+There will be proof of concept implementation to refine and clarify the specification.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+