Skip to content

Migration design #7

@hackfisher

Description

@hackfisher

Regarding the transition from old Staking to new Staking, direct migration is not supported, because it may take a long time to clear. Therefore, you can consider setting a transition period of 2 months, time_since_upgrade_start / 2 months * settings_collator_count uses the new one, and the rest uses the old one.

After 2 months, the old Staking can be runtime_migrated, the legacy RING is returned to the user, and the collator Staking is deleted.

For the settings_collator_count read, the new collator contract returns an error or is insufficient (the insufficient part is filled with 0x0), it is recommended to use the backup address to cyclically fill the empty address. (The backup address is filled with the technical committee address or the development team, and the session key needs to be set in advance, so that it can be backed up at any time)

Deposit supports long-term direct migration to new contract by adding a new migrate runtime call.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions