I want to empty my transactable balance,but alwalys got LackofBalance error.
I've used gas price* gas limit and ransfer_cost + create_account_cost + add_key_cost.full_access_cost by
https://nomicon.io/GenesisConfig/RuntimeFeeConfig/ActionCreationConfig#transfer_cost to calculate fee and max transaction amount.None of them work well.
If your account is linked to the NEAR wallet, you can use Send MAX to transfer as much NEAR balance as possible. After that operation your account will be, in some sense, locked since you need to receive funds from someone to continue operating with it.
An alternative to getting ALL the funds from your account is deleting it and set another account as the target where all funds should go. This can be done via near-cli using near delete tobedestroyed.near receiver.near
Related
One customer had a problem where an incorrect email (from another customer) was assigned to a case. The incorrectly assigned email is a response to a case that was deleted. However, the current case has the same tracking token as the deleted one. It seems that the CRM system uses the same tracking token as soon as it is available again. This should not happen! Here Microsoft has a real programming error from our point of view. The only solution we see is to increase the number of numbers to the maximum so that it takes longer until all tracking tokens are used up. But in the end, you still reach the limit.
Is there another possibility or has Microsoft really made a big mistake in the way emails are allocated?
We also activated Smart Matching, but that didn't help in this case either, because the allocation was made via the Tracking Token first.
Thanks
The structure of the tracking token can be configured and is set to 3 digits by default. This means that as soon as 999 emails are reached, the tracking token starts again at 1, which is basically a thinking error on Microsoft's part.
If you have set "Automatic replies", these will be reached in the shortest possible time. We therefore had to increase the number to 9 digits, which is also not a 100% solution. At some point, this number of emails is also reached and then emails are again assigned to requests that do not belong together. Microsoft has to come up with another solution.
I send transactions programmatically and I need to know exactly how much the fee is going to be. I managed to figure out how to calculate fees for ordinary transaction ((transfer cost + receipt creation cost) * 2), but now I'm struggling with a case where I need all my funds out of the account without deleting it. As I understand, in this case there must be a storage rent left on the account. However, I can't really figure out how to calculate that rent. There is a value returned from 'EXPERIMENTAL_protocol_config' method that seem to be connected to rent - 'storage_amount_per_byte', which implies that each byte costs 10000000000000000000 yocto, and also I can get 'storage_usage' from 'query' method with request type 'view_account', which is supposedly indicated how many bytes my account uses (which is 182). But whenever I try to send a transaction, I get a 'NotEnoughBalance' error that states that transaction cost is higher than the balance, but just by 669547687500000000 yocto. Whatever I do, I can't understand where this number comes from. No combination of fees from aforementioned 'EXPERIMENTAL_protocol_config' method yields this number.
There seems to be little to no decent documentation on transaction fee calculation, except for some 'fixed' values for most used actions. If you have any info on fee/storage rent calculation - I'll be thankful for it.
Through a random chance, I managed to find out the name that the number '6695476875' is referred to as, 'Reserved for transactions', (in gas, not tokens) as in the official wallet (wallet.near.org). God knows why it is reserved, neither docs.near.org, nomicon.io nor wiki.near.org have any info regarding this 'reservation' and this number is never mentioned in any RPC API method. This number is also never mentioned in 'near-api-js' lib, so I really have no idea if devs are even aware of it.
Anyway, since the title of this problem is 'How to calculate storage rent', the answer is something like this:
You get account info from 'query' method of RPC API (here's the doc) and take the "storage_usage" value (this is the amount of bytes that your account takes up on the blockchain).
You get protocol info from 'EXPERIMENTAL_protocol_config' method of RPC API (here's the doc) and take the "storage_amount_per_byte" value.
You multiply the amount of bytes by the storage_amount_per_byte and add the magic 669547687500000000 number to it.
And the resulting number is the least amount of tokens that you must have at your account at any time.
I don't know why it is a common practice to make lives of developers harder in blockchain industry, but this is a good example of such practice.
I have already prepared the Candy Machines for minting an NFT collection in the Solana network, and I am testing the Mint process using its Devnet.
Even if you can find a lot of tutorials about how to prepare the candy machines, there are some questions that I am still not able to find the right answer and I think that could be useful for other users.
Does the Mint need to be one by one? If a user would like to buy, for example 50 NFTs, does it require approving 50 transactions and pay 50 times the fees (using Phantom or any other wallet)?
I assume that yes, because every minted NFT is a new contract. Am I right?
I am successfully doing a Mint in the Devnet using my Phantom wallet in order to determine the fees. For a single NFT, the transaction fee reflected in the wallet is 0.012SOL = 2.16$ at this time. It seems really expensive based on what a transaction in Solana should cost. How are these fees calculated? Is this the normal fee price that a user pay for minting 1 NFT?
To answer both your questions:
The mint does not need to be one by one (from a mint site I am assuming is what you mean). You can string multiple transactions together like what this repo has achieved: https://github.com/maxwellfortney/next-candy-machine
Note: this repo is for cmv1 which is no longer supported but can be simply adjusted to work with cmv2 as the transactions themseleves should be similar.
Yes, that is a normal fee for minting. Transactions (transfering tokens or sol) themselves on solana are extremely cheap but storing data is not as cheap. To store data (such as is required by an NFT as they need a URI for the metadata) some "rent" costs are involved, as defined in the solana docs https://docs.solana.com/implemented-proposals/rent. Basically you have to pay for the NFT to store this data and exist which is the minting fees you are witnessing, a tiny fraction of the price you pay is for transferring the NFT to your wallet.
Mints are usually done one by one, but someone could hand code a transaction to do multiple, especially with Candy Machine V1.
The rent collected depends on the amount of bytes stored for each NFT. You can check how much it will cost with solana -um rent <bytes>. You can find more information here
I recently update the candy machine to v2, and it has some interesting features as minting more than one NFT or handle a whitelist of wallets:
https://docs.metaplex.com/candy-machine-v2/getting-started
for your second question, you can maybe think to use an external service that handles the transaction fees.
In this way you'll be able to let you customer get the NFT without paying any fee.
If you are interested in implementing a similar external solution, I guess that this APIs Service is for you: cowsigner.com
You can also solve your first point, because when you create a transaction, you'll be able to add as many instructions as you want to it.
For anything else, just drop a simple comment below :)
I uploaded and created a new smart contract. I sent 1000 units to this smart contract.
However when the contract is deployed the transferable is not equal to 1000.
And when I execute any function it also deducts the transferable.
Is there any way to prevent this. I want to deduct user token instead of the smart contract token. In Ethereum, the user token is deducted.
I want to deduct user token instead of the smart contract token. In Ethereum, the user token is deducted.
I think there is a misunderstanding here, you probably understood the deducted tokens as gas. But gas is deducted from the instantiating account (what you referred to as "user token"), same as in Ethereum.
The amount that is deducted from the contract here is state rent ‒ i.e. the contract has to regularly pay for the amount of state and code storage it uses. This is a concept which is currently used by the contracts pallet to reduce state bloat. I won't link to the documentation here though, since a new paradigm will be introduced soon, making it obsolete.
To set up an account on the NEAR blockchain, it requires you to send some number of tokens to fund that account. For example, when using the NEAR Wallet to set up a new account, you have to fund it with 3N first. Why is this?
You can create a NEAR "implicit" account with 0 NEAR. Near implicit accounts are the same as in Ethereum or Bitcoin. You create the a keypair locally and the public key becomes your account id (a hex string, like in Ethereum or Bitcoin)
See here: https://nomicon.io/DataStructures/Account.html
and here: https://docs.near.org/docs/roles/integrator/implicit-accounts
You only need 3 NEAR if you want to create a "named" account, that is an account like alice.near that's way easier to use than implicit accounts like 641537c21dC82F97b7fC8AD778e99997beeE0d73
On NEAR, data usage is "funded" by holding a balance of tokens on the account which reserves the storage space. So, in order for the account to be created, it has to set aside some storage on the chain, which requires some amount of tokens to "pay" for those initial bytes of memory by sitting on the account.
This minimum balance depends on how much data the account uses and could start as low as < 1N for a basic account to ~40N for one with multifactor authentication and other bells and whistles added to it.
For more, see the docs at https://docs.near.org/docs/concepts/storage which describe the "state staking" approach used here.