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.
The funding decision lost its counterparty (3–11 September 2026)
The deliverables below ask the DAO to identify who carries Xi'an, and to scope and budget that work through an RFP. Both assume a willing recipient. At 00:28 UTC on 3 September 2026 the author of the only candidate implementation removed himself from that position, writing in the hyperscale-rs channel that he had “decided not to pursue any proposal, grants or ongoing engagements with radix as a network, dao, or otherwise”, and confirming the same morning that the scope of the refusal is future funding rather than the work: “I do not wish to pursue additional grants from Radix”. The RFC that this card's budget question was built around stands on the forum unaltered and unfunded.
On 11 September 2026, asked directly in the channel what becomes of the community and its XRD now, he answered the adoption question and declined the stewardship one in the same message: “i intend for hyperscale to be an open source project in the most exemplary sense… i want to focus on building good primitives, and it doesn't matter overmuch to me who ends up using them”, and on what becomes of Radix holders, “i don't know mate. it is not really something that i have any control over — and as such, i don't think about at all.” Authorship is confirmed at the message's own public embed.
That leaves this card a genuine decision rather than a stalled one, and changes what it is a decision about. The dual MIT/Apache-2.0 licence committed in August 2026 is irrevocable, so the code is available to Radix whether or not anyone is paid to bring it here; what is not available is the author's commitment that Radix is where it lands, or his participation in an RFP. The question the DAO now faces is adoption and integration — who ports, tests and operates someone else's open-source protocol, and who migrates the state onto it — not the R&D procurement this card was drafted to settle. The developer has said he would help with a state migration “if Radix still exists, and the DAO wants help”, which is the one piece of the handover still offered.
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
- Governed by Daffy's Radix DAO framework (repo
Shadaffy/radix-dao); see the Governance Framework Reference Repo and Charter (Round 1). - Prioritized under the product roadmap.
- Released safely via the dry-run upgrade process.
