NEP-642: Account cost increase#642
Conversation
|
Thank you @jancionear for submitting this NEP. As a moderator, I reviewed this NEP and it meets the proposed template guidelines. I am moving this NEP to the REVIEW stage and suggest @jakmeier and @mitinarseny as SME reviewers to complete a technical review (see expectations). @near/wg-protocol working group members, please let us know if you have better suggestions. Please find some guidelines below for completing the technical review. Technical Review Guidelines
Please tag the @near/nep-moderators once you are done, so we can move this NEP to the voting stage. Thanks again. |
walnut-the-cat
added
the
S-review/needs-sme-review
jakmeier
left a comment
jakmeier
left a comment
There was a problem hiding this comment.
SME report by @jakmeier
I recommend approving this proposal.
Summary of benefits
- This change allows setting the cost for long-term storage related to account creation to a NEAR denominated value. Without the proposal, such a cost change would disrupt existing on-chain applications.
- The new cost of creating a new account is a minimum of 0.007 NEAR, regardless of how the account is created. (Burning the cost for ZBA creation vs. reserving the fee on the account for storage staking.) This aligns the paid cost with the fair cost as considered by the protocol team.
- Potential future changes to the cost of storage will be easier to adopt.
Summary of concerns and blockers
| Concern | Status |
|---|---|
| The proposal undoes the gas pricing model simplification achieved by removing pessimistic gas pricing. With this proposal, accounts will need higher minimal balances and access keys need higher allowances to keep functioning as they do today. | Dismissed: Discussions with dApp developers showed that this is not a big concern. They are able to increase the balances and allowances where necessary. |
| The proposal undoes the reduction in refund receipts achieved by removing pessimistic gas pricing. | Dismissed: The overhead of additional receipts is comparatively low and future possibilities to address this issue are listed in the proposal. |
| Increasing account creation gas parameters fees can lead to more expensive transfers to implicit accounts. Today this always includes the ZBA gas fee even when the target account already exists. | Resolved: The implementation resolves this with two tricks. (1) Shift the bulk of the gas fee from SEND to EXEC and (2) only apply the extra cost when the account didn't exist at the start of the receipt execution. |
Note that we discussed these concerns outside what is documented here on GitHub. I raised them early in the design phase of the proposal and the team worked together to resolve the issues ahead of time. My thanks go to everyone listed as contributor, with special thanks to @jancionear and @Trisfald who put in the most work to resolve all known issues.
mitinarseny
left a comment
mitinarseny
left a comment
There was a problem hiding this comment.
Hey @jancionear, thank you for working on this NEP!
Taking into account all the nuances around gas & storage management, it seems that the proposed solution removes the cost imbalance in an efficient way without breaking backwards compatibility and other significant tradeoffs.
Left couple of minor comments but, in general, looks good to me 👍🏻
|
|
||
| | Parameter | Value | Meaning | | ||
| | :-- | :-- | :-- | | ||
| | `min_gas_purchase_price` | `0.001 NEAR/TGas` | Minimum price at which the gas attached to a receipt is *purchased*. This is 10x the network minimum gas price of `0.0001 NEAR/TGas`. | |
There was a problem hiding this comment.
Do we really need an additional config parameter here or can it be derived from already existing storage_amount_per_byte somehow?
There was a problem hiding this comment.
Using storage_amount_per_byte would be nice, but then the charge would be 0.0077 NEAR (770 bytes), while we have only 7.2 TGas to burn, which gives us 0.0072 NEAR. It was easier to define an explicit charge for each created account. Orr we could raise gas price even higher, but I wanted to avoid doing that because it negatively affects users.
| * At low (typical) gas prices, `burned_cost` is small, the top-up brings the total up to the fixed `0.007 NEAR`. | ||
| * At high gas prices, the naturally-burned gas already exceeds `0.007 NEAR`, no top-up is taken, and the user simply pays the (higher) gas cost. | ||
|
|
||
| This applies regardless of *how* the account is created - an explicit `CreateAccount` action, implicit account creation by transferring to a not-yet-existing implicit account, a `DeterministicStateInit` action, or an account created by a contract through a cross-contract call. Because the receipt that creates the account is not known to be account-creating at the time its gas is purchased, all receipts must purchase gas at `min_gas_purchase_price`; the charge is only taken from the surplus of receipts that actually create an account. |
There was a problem hiding this comment.
Maybe it's worth to mention here that despite Implicit AccountIds are created on receiving a first native transfer, but there are following exceptions:
- refunds of gas or total attached deposit to a failed receipt
- non-existing
beneficiary_idfromDeleteAccountaction
Also, can there be a case when a not-yet-existing implicit account is created on execution of the first DelegateAction signed by account's "implicit access key"?
There was a problem hiding this comment.
Good point, I'll add a section about them.
Also, can there be a case when a not-yet-existing implicit account is created on execution of the first DelegateAction signed by account's "implicit access key"?
I think this can't happen, a delegate action fails if the transaction author doesn't exist (see check_account_existence in apply_action)
walnut-the-cat
added
S-voting/needs-wg-voting-indication
|
Looks like we're ready to schedule a meeting to present this NEP to the community and have @near/wg-protocol vote. @jancionear @walnut-the-cat @mitinarseny @jakmeier - please share your availability here |
|
As a protocol working member I lean towards approving this proposal. As the NEP notes, it is important that storage costs are aligned, regardless of how the bytes which need to be stored are created. It is unfortunate that we are effectively seeing the return of pessimistic gas pricing (undoing the gains of NEP-536), but I agree with the authors of the proposal that maintaining backwards compatibility (thus ruling out the possibility of increasing the cost of account creation directly) is more important. Hopefully future work on how users pay for storage can make progress again. |
Friendly bump on this @mitinarseny :) |
|
As PWG member I also lean toward approving this PR. I agree that we should change equally everywhere in the protocol for storage, and the change for end users (even if it is 10x) should no have a big impact with regard to price. I guess this will affect more applications onboarding millions of users, but still considering the expected value a user will bring to the platform absorbs the cost of the price increase. |
|
Based on everyone's availability here, I've setup a call for Friday July 3rd, 2026 @ 4:00PM UTC. @jancionear please prepare a short overview for this NEP to get us started and then we will follow up with SME's review. Please register to attend here: https://luma.com/xatywncd cc @jancionear @walnut-the-cat @mitinarseny @jakmeier @birchmd @mfornet @gagdiez |
|
@jancionear @mitinarseny @jakmeier can you update your availability here. Unfortunately, one of the SME's had a schedule change for this Friday and is no longer able to attend. Pushing to next week dependent on everyone's availability. |
@mitinarseny please add your availability so we can get this meeting rescheduled. |
|
As the moderator, I would like to thank @jancionear for submitting this NEP, and for the group members for your review. Based on the discussion it seems like this proposal is approved we are therefore scheduling a group meeting next week. Everyone is welcome to join. Meeting Info |
8 participants
This proposal makes creating a new account on NEAR roughly 10x more expensive than it is today. The cost of other operations remains unchanged.
This is needed to bring the cost of storage taken up by the account in line with the cost of storage paid for with storage deposits. Currently the storage taken up by new accounts is cheaper than storage purchased with storage deposits, which makes for an unfair balance.
The cost increase will be achieved by increasing the upfront gas purchase price 10x. For creating an account we will charge the full 10x gas price. For other operations we will charge a lower price and refund the difference, so that the final cost remains unchanged.