4

I see that there are many events emitted during the process of deploying my contract on Substrate local chain (SNOW Network to be specific).

  1. 4 ICZ was reserved from deployer account
  2. 1 ICZ & 2 ICZ were respectively transferred from deployer account to the Deployed contract as depicted by two different events. (I assume this is storageDeposit)
  3. The received 1 ICZ & 2 ICZ got reserved on the deployed contract.
  4. Total of 12.719 ICZ was withdrawn and then 11.651 ICZ was deposited to the deployer account (I assume this is for tx fees).
  5. 0.213 ICZ was deposited into Alice account (sudo account). (I assume this is block rewards)
  6. If we are to terminate this contract, the 1+2 = 3 ICZ is returned (ReserveRepatriated) to the Deployer account.

I have learned that the contract takes some fees for the storageDeposit during deployment. I think the 1 ICZ and 2 ICZ transferred in the #2, #3 and #6 above indicates this deposit amount.

What I would like to understand are:

  1. Why 4 ICZ was reserved on the deployer account which doesn't get freed up even when the contract is terminated, and
  2. Why the storage deposit is consumed in two steps of 1 ICZ and 2 ICZ, instead of consuming 3 ICZ at once?

Balance Transfers and Reserves during deployment

1 Answer 1

3

Your assumptions you made in #1 to #6 are all correct.

Now to your questions:

  1. This is the storage deposit for storing the code. In contrast to the deposit for the contract which is using said code (charged in #2). The deposit for the code stays at the uploader as only they can remove the code. It isn't freed up because a code needs to be manually removed by the original uploader using the remove_code dispatchable. It can only be removed once no contract is using the code anymore. Note that you can also only upload a new code without instantiating by using the upload_code dispatchable. You can also instantiate a contract from an already existing code using the instantiate dispatchable.

  2. The first transfer is the balance that pays for the contract and its account itself. It needs to be done before executing the contract so that the account is above the existential deposit while executing (this is an invariant we enforce). This only happens on instantiation but not on a normal call. The second transfer is the deposit which is incurred by the contract creating additional storage. The amount is only known after a contract is done executing. This is why it happens later.

Please note that this behavior is about to change. We now store the deposit on separate account from the contract itself and no longer reserve it. More information here: https://github.com/paritytech/substrate/pull/13369

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.