Thanks for the questions! Answers below:
RAC sign-off vs community governance
The RAC+Arbitrator structure exists specifically so that milestone sign-off is an objective technical call rather than a community vote. The intent is that completions are largely procedural: deliverable shipped, criteria met, payment released. Where there’s genuine ambiguity, you want it resolved by the arbitrator with the technical context to reach an objective conclusion, not by a vote that ends up turning on vibes or partial information.
The risk of putting milestone sign-off into community governance directly is that completion becomes subjective. That cuts both ways: it could mean payments get withheld on milestones that have actually been delivered, or released on milestones that haven’t been. Either failure mode is bad for the project and for the community. The RAC+Arbitrator layer is meant to take that ambiguity off the table.
If the concern is RAC continuity (the RAC may not exist in 18 months), that’s a fair worry and worth handling explicitly. The proposal can carry a fallback clause: if no RAC equivalent exists at the time a milestone is up for sign-off, the community votes. But the default should remain “objective technical review by a delegated body” rather than “vote on each milestone.”
How much of each milestone is already done?
Zero percent on the milestones themselves. This is all net new work.
There’s some basic integration between Radix Engine and hyperscale-rs already, but it’s the duct-taped path called out in the proposal. Not production-ready: the fundamental data models and data prerequisites aren’t aligned yet, and that alignment is exactly what M2 exists to do.
The work to date is the foundation that makes the milestones tractable: the consensus engine, the simulation harness, the architectural decisions, the prototype that proves the path is viable. None of it is a milestone deliverable in its own right.
Audit findings and the warranty period
Yes. If a third party audit gets commissioned and finds critical or high severity issues attributable to the Xi’an codebase, remediating those falls into scope.
Post-quantum: all or nothing, or swap later?
Two sides to this, and they’re somewhat independent.
On the infrastructure side, the goal is to build it so the system supports both classical (BLS, as currently used) and the future PQ scheme side by side. This will be feature-flagged so PQ enactment can be trivially toggled via a setting in a protocol upgrade later, if the call is made that it should be deferred from immediate enactment at Xi’an. Either way, the protocol is ready for it.
On the signing scheme side, the wallet account types are the other half. The PQ scheme will be added as a third signing type alongside the existing ECDSA Secp256k1 and Ed25519 types. The wallet then needs to implement signing support for the new account type, which is a separate piece of work and can happen independently of the Xi’an timeline. Users would then manually transfer assets from non-PQ-safe account types to PQ-safe ones over time.
The community may also want to explore “freezing” non-PQ account types after some publicised end date, which would be a governance decision rather than a protocol one. That’s the same sort of discussion that’s been happening in Bitcoin recently along the same lines, and worth having here at some point too.
So: not all or nothing on the protocol side, and the migration story for users has a clean path that doesn’t require everyone to coordinate on day one.
Documentation as part of milestone sign-off
Reasonable. The soft deliverables section covers a lot of this in principle, but you’re right that having documentation explicitly tied to milestone sign-off, rather than treated as a parallel stream, is cleaner.
Happy to make documentation a sign-off criterion per milestone where it makes sense. Concretely: M3 should require gateway integration docs, M4 should require validator setup guides, M5 should require crypto migration notes for integrators, M6 should require onboarding material for downstream teams. Easy to bake into the milestone definitions.
Outstanding roadmap features?
Depends which ones you have in mind. Xi’an as scoped here is the consensus, sharding, and PQ work, with Engine-level feature parity to Babylon. New features beyond Babylon-equivalent (smart accounts changes, new asset primitives, tokenomics adjustments, etc.) aren’t in scope for v1 but the architecture should support adding them post-launch.
If there are specific features you’re thinking of, drop them in and I can give a concrete answer per feature on whether it’s compatible with the Xi’an design and what implementing it would look like.
AI use
Yes, honestly. Same as any modern developer at this point. AI tools come into play for boilerplate and pure mechanical implementation work, exploring API surface options, drafting documentation, and sometimes as a second pair of eyes on code review. Where they don’t come into play is the load-bearing protocol design and the consensus logic itself. That’s human-authored and held to the same standard regardless of whether AI was involved in any earlier draft.
