How to calculate in advance the fee & rent?

[oleiba]

For a transfer transaction (e.g. by using SystemProgram.transfer) I want to be able to calculate in advance the fee to be reduced from the sender's balance, together with the transfer amount itself.
To highlight - I'm looking for a way to do it before the transaction is actually broadcast.

Also, I want to be able to calculate the rent to be reduced from the receiving account. I understand that paying rent depends on whether a receiving account is new or not - so I would like that to be included in the calculation.

How can these be done?

[mvines]

For a transfer transaction (e.g. by using SystemProgram.transfer) I want to be able to calculate in advance the fee to be reduced from the sender's balance, together with the transfer amount itself.
To highlight - I'm looking for a way to do it before the transaction is actually broadcast.

You can use Connection.getFeeCalculatorForBlockhash() to determine the fee for any valid blockhash and the compute the fee for the transaction, before sending it.

Also, I want to be able to calculate the rent to be reduced from the receiving account. I understand that paying rent depends on whether a receiving account is new or not - so I would like that to be included in the calculation.

Connection.getMinimumBalanceForRentExemption() will indicate the balance required to avoid paying rent. We currently don't have a method that will return the rent that will be charged every epoch for accounts that fail to meet the minimum rent exemption balance.

[oleiba]

Can rent pre-calculation be added as a feature request?
It's extremely important because as wallet developer I would like this amount to be added to the sender's transfer amount, to ensure that the receiver eventually gets the exact amount requested (i.e. the sender himself will compensate for the rent).

[jstarry]

Can rent pre-calculation be added as a feature request?

@oleiba do you mean the rent charged every epoch? If so, yes we have an issue tracking this here: solana-labs/solana#7413

[oleiba]

I mostly mean the rent to be charged immediately after receiving coins (e.g. for the first time)

[jstarry]

@oleiba would that be solved by knowing how much rent is charged in a single epoch?

[oleiba]

I would also need to know whether the specific receiving account is due to pay rent.
Is that answered solely by checking whether this account has a balance of 0?

[jstarry]

@ryoqun is it possible that early on in an epoch, the receiving account might already exist but not be rent collected yet? Is it possible to compute that ahead of time?

[ryoqun]

@jstarry Yeah, it's technically possible by checking account.rent_epoch. But the exact specification/timing around it isn't set in stone. it's very much current implementation dependant. Not not recommended for any serious use.

@oleiba Thanks for developing with us. :)

Normally, our rent fee is very small and normally rent aren't incurred, so this shouldn't be usually concern. Could you let us know the exact user story / system requirement for your wallet?

Any Solana's system accounts with balance of larger than or equal to 0.001_781_760 SOL is rent-exempt, meaning any transfers to the account doesn't incur any rents. So, say sending 1 SOL to new account results in the new account with the balance of exactly 1 SOL. For existing, the increase is just be +1 SOL likewise.

So, the rent concern is only for accounts with very low balance. Even if you want to care for the case, the transfer alone doesn't end here by itself. That's because rent is periodically collected (about 0.000_002_439 SOL per 2 day at the moment). So, the your user might wonder if their balance starts to gradually reduce from say 0.001_000_000 SOL.

Lastly, even if the account's pre rent could be reliably calculated using rpc, the rent calculation and actual transfer wouldn't be atomic at the moment. So, the destination account could be rent-collected by other activities just before your transaction with properly-rent-adjusted transfers, resulting in not exact amount of balance deltas in the block explorer page for your transfer transaction.

Anyway, rent is a bit opaque to clients/users. That's true... But that's partly due to being so negligible as I explained for most of cases.

I'm not that expert for UX, but I think if your user's accounts are expected to be with very small denomination (maybe, some micropayment?), you can pop-up friendly remainder that the destination account will slowly reduce its balance due to its rent collection. Also, it might be typo in your user transfer amount.

To check that rent will be collected or not for the pop-up, we have aptly named getMinimumBalanceForRentExemption. :)

For details: https://docs.solana.com/apps/rent

[oleiba]

The use case is simple.
Normally, user A would like to send a specific amount, say X SOL, to user B.
The problem: by calling an out-of-the-box transfer method, e.g. SystemProgram.transfer(params), the eventual amount user B would see is X - rent.
It would make more sense that the sender would add this rent to the sent amount, so that user B would eventually see exactly X SOL added to its balance, as this is usually its expectation from a payment.

[ryoqun]

@oleiba

The problem: by calling an out-of-the-box transfer method, e.g. SystemProgram.transfer(params), the eventual amount user B would see is X - rent.

Thanks for sharing the clear use case. Yeah, your understanding of calculation of rent is correct.

However, this is the case when the X is less than 0.001_781_760 SOL (which is less than 1 cent in USD today) AND the B doesn't have an account or its account balance is below 0.001_781_760 SOL. Thus, I believe this is quite rare case.

Vast majority of current transfers are ended up being rent-exempt.

It would make more sense that the sender would add this rent to the sent amount, so that user B would eventually see exactly X SOL added to its balance, as this is usually its expectation from a payment.

Yeah, this might be useful if there are so many small-denominated transfers. I think we can support rent-payer in similar spirit to fee-payer. (thoughts? @jstarry )

However, I'm afraid that due to relatively infrequent concern, the feature request might take some time to actually for us to get on it.

If possible, could you share your idea? Why this is so much important, like basing on your customer's actual paying pattern, expected average transfer amount?

[jstarry]

@ryoqun agreed that rent-payer sounds like a nice feature. We could have the fee-payer rent fees even. But I also agree that sending small denominations of SOL isn't too common and so having support for calculating rent fees perfectly is not a big priority currently. If there was an important use-case we could definitely put more thought into it.

[github-actions]

Hi @oleiba,

Thanks for your question!

We want to make sure to keep signal strong in the GitHub issue tracker – to make sure that it remains the best place to track issues that affect the development of the Solana JavaScript SDK itself.

Questions like yours deserve a purpose-built Q&A forum. Unless there exists evidence that this is a bug with the Solana JavaScript SDK itself, please post your question to the Solana Stack Exchange using this link: https://solana.stackexchange.com/questions/ask

---

This automated message is a result of having added the ‘question’ tag.

[github-actions]

Because there has been no activity on this issue for 7 days since it was closed, it has been automatically locked. Please open a new issue if it requires a follow up.