RADIX WikiRADIX Wiki

Protocol upgrades (the Xi’an line of work) and Radix Engine maintenance previously sat with Foundation-funded teams. The DAO must decide how it funds and directs continued core-protocol R&D so the roadmap does not stall during the handover.

What the scope became (1 August 2026)

This card was written when "Xi'an and Radix Engine work" read as one continuous line of maintenance. It is not. On 1 August 2026 the hyperscale-rs lead developer told the project's Telegram channel that the Radix Engine is not being adapted for sharding – asked whether it was built for it, the reply was "it's not in the ballpark. it's not in the same zip code as the ballpark" – and that a purpose-built VM is underway in its place, because "the sharding adjustments are so many that it'd require touching everything. at some point it becomes easier to start with intention than to retrofit". Later the same day came the confirmation that of the three migration options framed in April, the two that would have spared existing dApps – unchanged blueprints, and a dual modality running beside a legacy environment – "have dissolved". What this means for Scrypto was asked in the same session and drew no answer.

That changes what a funding decision here is actually for: a new execution layer, plus a migration for everything already built on the current one, rather than continued maintenance of the Radix Engine. It also widens the acceptance question in the deliverables below, since a dry-run protocol upgrade rehearses a release, not a change of execution environment. The message-by-message record is on hyperscale-rs.

Deliverables

  • Identify the teams/contributors who will carry Xi’an and Radix Engine work.
  • Scope and budget continued protocol development via RFP.
  • Define acceptance/verification for protocol releases (see dry-run upgrades).

Dependencies & cross-references

Sources

HydrateLast updated Aug 2, 2026v1.1.13 revisionsVerified Aug 2, 2026