Astar Technical Development Updates: Runtime-1900 Upgrade

[Juminstock]

Greetings, Astar Community!

We’re excited to share details on the upcoming Runtime-1900 Upgrade for Astar Network. This release is a runtime-only upgrade that introduces three critical developments:

• Preparations for the Asset Hub Migration (November 4, 2025): an important network upgrade that reduces DOT costs and helps align Astar with the broader Polkadot ecosystem evolution.
• Implementation of the Decay Factor: the technical foundation of Tokenomics 3.0, which will gradually shift ASTR toward a fixed supply model.
• Collator Selection Governance Improvement: a transition to a governance-approved collator selection process that enhances network security and operational standards.

This upgrade represents more than just a technical release: it’s a strategic step toward strengthening Astar’s long-term sustainability, network efficiency, and governance maturity. Together, these developments ensure that Astar remains interoperable, future-ready, and fully aligned with the next evolution of the Polkadot ecosystem.

I. Asset Hub Migration

As we shared before in our forum announcement, the Asset Hub Migration for Astar Network is scheduled for November 4, 2025.

Following the successful migration on our canary network Shiden earlier this month, Astar is now ready to embrace this transformative change that will:

• Reduce DOT transaction fees by ~90%
• Lower the minimum DOT balance from 1 DOT → 0.01 DOT
• Enable more efficient, unified cross-chain operations

As part of the runtime-1800 upgrade, new extrinsic calls have been introduced to prepare for the Polkadot Asset Hub migration. These extrinsics focus on migrating assets securely, disabling XCM transfers, and controlling reserve behavior during the migration. Key points include:

• AssetHubMigrationStep: Allows governance to signal the start and completion of the migration, controlling which XTokens calls are active.
• Temporary deactivation of XTokens calls using relay chain reserves: Ensures that DOT tokens are not mistakenly transferred via the relay chain during migration.
• Controlled asset location adjustment: For XTokens, assetLocation is temporarily set to None during the migration to avoid incorrect routing via UMP/DMP.

These extrinsics temporarily deactivate cross-chain transfers during the Polkadot Asset Hub migration to ensure consistency and avoid potential errors.

For full technical details, please refer to the dedicated Astar post on the Asset Hub migration:

Asset Hub Migration on Astar

II. Decay Factor Implementation

Alongside Asset Hub preparations, Runtime-1900 Upgrade also includes the implementation of the Decay Factor, a core element of Tokenomics 3.0.

The Decay Factor gradually reduces token emissions over time, moving ASTR from its current inflationary model toward a fixed-supply system.

Key Extrinsic Calls for Decay Factor

Runtime-1900 Upgrade introduces two main extrinsics to manage Astar’s new inflation decay mechanism:

1. force_set_decay_rate
   • Purpose: Allows governance to set a new decay rate for token emissions.
   • Usage: Can be triggered during economic adjustments.
   • Effect: Determines the rate at which the decay factor changes per block, directly influencing the pace of token emission reduction.
   • Access: Governance-only call; ensures that only authorized parties can modify network-wide tokenomics parameters.
2. update_decay_factor
   • Purpose: Automatically updates the decay factor during block initialization (on_initialize).
   • Usage: Runs on every block to ensure the current decay factor is applied to all inflation reward payouts.
   • Effect: Gradually reduces emissions according to the configured decay rate.
   • Access: Called automatically by the runtime; not directly user-triggered.

• Support for protocol-level inflation decay: Integrates the new inflation decay factor to ensure predictable token emission post-migration.

Additional Notes

• Storage migration: For previous runtimes with no decay, decay_rate and decay_factor are initialized to 1 (Perquintill::one()), ensuring backward compatibility.
• Integration with rewards: All reward payout calculations (including dApp staking rewards) now respect the updated decay factor, ensuring consistent inflation behavior.
• Test coverage: Fully tested via unit, integration, and end-to-end (e2e) tests to prevent arithmetic errors, including scenarios where decay factor is zero.

Read the full conversation here

III. Collator Selection Governance Improvement

Runtime-1900 Upgrade introduces a significant update to the collator selection mechanism, transitioning from a permissionless system to a governance-approved collator selection process. This change enhances network security and ensures that only vetted and approved nodes participate in block production.

Note: All collator-related parameters including bonds, slashing, rewards, and the collator set, remain unchanged with this upgrade.

Check our official documentation here: Learn about Collators | Welcome to Astar

Overview of the New System

Under the updated mechanism, prospective collators must now follow a two-step process to join the active collator set:

• Candidate applicants first submit an application on Astar Forum by reserving the required 3.2M ASTR.
• Only after Governance Referendum or Main Council approval is the node officially added to the collator candidates pool.
• Additionally, Governance Referendum or Main Council now has the authority to remove underperforming or malicious collators through forced removal and slashing mechanisms, strengthening the network’s ability to maintain high operational standards.

This approach provides the network with greater control over collator quality and performance standards.

Governance Origins & New Extrinsic Calls

The collator selection pallet utilizes two distinct configurable origins to manage governance actions:

• GovernanceOrigin is responsible for approving and closing candidacy applications. For Astar network, this origin requires either a two-thirds majority vote from the Main Council or approval through a standard referendum.
• ForceRemovalOrigin handles the forcible removal and slashing of candidates. The configuration mirrors that of GovernanceOrigin, requiring either two-thirds Main Council approval or referendum passage on Astar.

The updated pallet introduces four new extrinsic calls that enable the governance-approved collator selection workflow:

• apply_for_candidacy allows prospective collators to submit their application by reserving the required 3.2M ASTR. This serves as the initial step in the candidacy process and demonstrates the applicant’s commitment to operating a collator node.
• close_application enables applicants to withdraw their pending application and unreserve their bond if they decide not to proceed with candidacy. This provides flexibility for applicants who may need to reconsider their participation.
• approve_application is a governance-restricted call that allows authorized origins to approve pending candidacy applications. Once approved, the node is officially added to the collator candidates pool and can begin participating in block production. This call can only be executed by the GovernanceOrigin.
• kick_candidate provides governance with the ability to immediately remove and slash 1% of the bond from a collator candidate who exhibits poor performance or malicious behavior. This call can only be executed by the ForceRemovalOrigin. In situations where governance wishes to remove a candidate without applying slashing penalties, this can be achieved by wrapping the leave_intent call with the utility pallet’s dispatch_as function through a referendum.

Important Notice for Existing Collators

The previous register_as_candidate extrinsic has been deprecated and will return a Permission error if called. All new collator candidacy submissions must utilize the apply_for_candidacy extrinsic followed by governance approval through the new workflow.

Check the Github PR here

IV. Community Participation: Vote Now!

This runtime upgrade is live as an onchain referendum. We invite all ASTR holders to cast their vote and shape the network’s future.

Referendum Details

• Voting Opens: October 22nd, 2025
• Voting Period: 1 week
• Execution: October 27th, 2025 (instant enactment)

Vote on Subsquare Here

V. Closing Thoughts

The Astar Runtime-1900 Upgrade represents a comprehensive update that includes preparations for the Asset Hub Migration, implementation of the Decay Factor, and the introduction of governance-approved collator selection. These updates contribute to aligning Astar with Polkadot’s ongoing development, support sustainable tokenomics over time, and strengthen network security through improved collator governance.

Thank you to all community members for your participation in governance and support of these transformative upgrades. Together, we continue to shape the future of Astar, innovative, sustainable, and connected to web3.

[you425]

Thank you for the detailed report!

I’m in favor of the upgrade itself, but I have two concerns:

1. The features required for Tokenomics 3.0 will be implemented first—how will discussions (including milestones) proceed from here?
2. The collator selection system will be updated—how will existing collators be handled?

[SimonB]

How can we not be happy to see continuous development and technical updates, especially the start of the implementation for Tokenomics 3.0?
I also support the idea of making collator participation in Astar Network possible through governance.
One concern, however, might be whether users have enough knowledge to properly assess if a collator has the right skills to participate in the network or not.

[Matt]

Hey guys, thank you for this report. I’m curious about two things:

1. With the Decay Factor implementation, how will the community be informed or involved in future adjustments to the decay rate parameters will there be a transparent schedule or governance discussion process?

2. Regarding the new collator approval system, is there any plan to introduce performance metrics or dashboards so the community can track approved collators’ reliability and uptime transparently?

[tksarah]

Thank you for introducing the update.
I have a question.
Regarding the “Collator Selection Governance Improvement,” I believe it refers specifically to Astar Collators. Can I confirm that the participation process for Shiden Collators remains unchanged under this update?
Incidentally, I’m planning to operate an Astar Collator in the future, and have just begun preparing to run a Shiden Collator as the first step.

[tksarah]

That concern is certainly valid, and I’ve imagined what such a situation might look like. Surprisingly, the judgment may not be all that difficult. If users understand that collators are essential for maintaining the robustness of the blockchain, and if candidates can clearly demonstrate the appropriate skills and track record to operate such a system, then users should be able to make reasonably informed decisions. Since the initial step involves submitting an application on the Forum, it’s likely that individuals with sufficient technical expertise will review those submissions. In some cases, delegating voting power to technically knowledgeable participants could also be considered a meaningful form of governance participation.

[SimonB]

Of course, I completely understand what you mean. Compared to a fully permissionless system, we’ll definitely have an additional layer of filtering and evaluation for the admission of new collators. The proposals on the forum will surely be reviewed by more experienced users, and even this aspect alone makes the process much more engaging and adds even greater value to governance.