Expand description

Contract code upgrades.

If you ever wish to update the logic of your contract without having to use a full-access key, you can take advantage of the upgrade patterns in this module. Upgrading a contract usually consists of two parts:

  1. A reflexive DEPLOY_CONTRACT action.
  2. A follow-up state migration, if necessary. (See: crate::migrate.)

This module provides a few different ways to perform an upgrade. Most new projects should probably start with the serialized module.

By default, after updating the contract logic the contract state is migrated. This behaviour can be changed by providing a custom PostUpgrade.

The [raw] module is included mostly for legacy / compatibility reasons, and for the niche efficiency use-case, since it allows for the most efficient binary serialization (though only by a little). However, it is more difficult to use and has more sharp edges.

Safety

If the contract state is migrated, the new contract logic must deserialize the existing state according to the old schema and migrate it to the new schema. If the new contract has a different storage schema from the old contract and does not migrate the state schema, the contract may become unusable.

Modules

Contract upgrade functions that work as expected in conjunction with #[near_bindgen].

Structs

Function call after upgrade descriptor

Constants

Default input to send to the post-upgrade function.
Default value for the name of the function that will be called after upgrade (usually a migrate function).
Guarantee the post-upgrade function receives at least this much gas by default.