An instruction set architecture is a specification. There's no technical reason one has to be proprietary, and yet for forty years nearly every commercially significant one was. SPARC's published specification and POWER's late opening were real exceptions, but neither broke the x86-Arm duopoly's grip.
RISC-V's contribution is that its specification is open and its extensions are modular. Both halves matter, and the second half causes most of the real-world grief.
Where it is¶
We'll report this carefully, because coverage of RISC-V runs well ahead of ratification and conference material gets cited as though it were a standard.
- Server SoC and Boot specifications are ratified. RISC-V's own 2025 annual report says so.
- The Server Platform specification is ratified too. The ratified specifications library lists Server Platform v1.0, dated May 2026. The 2025 annual report had forecast ratification by the end of 2026. A forecast and the record of the event it forecast are not in conflict, and the library is the record.
- Recently ratified extensions include Instruction/Data Coherence (Ziccid, June 2026), per the ratified extensions table.
If you want a current answer, go and read the ratified-extensions table. Don't trust a summary, this one included, past its date.
The fragmentation problem is the real one¶
Modularity is the selling point and the liability in one. An ISA assembled out of optional extensions means that "RISC-V" on its own tells you nothing about what a chip can do, and two conforming parts can fail to run the same binary. It's a kit car; everyone's is road-legal and no two take the same spare.
Platform specifications exist to fix this: a profile that declares these extensions mandatory, so software has a baseline to target. The work is thankless and it matters more to adoption than any individual extension, because it's the difference between an ecosystem and a pile of incompatible chips.
ARM solved the same problem by being one company with the authority to say no. An open standard has to do it by committee, which is slower and produces documents like the ones above.
It matters because of what happens downstream when nobody owns the document:
- Verification. You can't formally verify an implementation of a specification you aren't allowed to read. The seL4 proofs reached RISC-V for a reason.
- Capability extensions. Memory-safety research that adds new semantics to pointers is being specified as a RISC-V extension, which on a proprietary ISA would need the owner's agreement and the owner's commercial interest in the outcome.
- Research silicon. Academic and small-vendor parts exist that would never have cleared a licensing conversation.
The ARM port already did the hard cultural work; see ARM reaching the server room. RISC-V arrives in a world where "does it build on another architecture" is a normal question rather than an exotic one, which is why its software story starts from a far better place than ARM's did.
Look a little further and the prize is a different shape of hardware industry. If the specification is free, then designing a chip stops requiring a negotiation with a competitor. That matters most for the parts nobody large wants to make: a controller for agricultural equipment in a country without a semiconductor industry, a processor for a medical device with a thirty-year service life, a repairable design whose documentation outlives the company that sold it. The thing that becomes cheap is the low-volume part, and low-volume parts are where repairability, longevity and local manufacturing live. A specification with no owner cannot be withdrawn when a product line stops being interesting, which is the failure mode that strands working hardware today.
For engineering the win is more immediate: a target you can read is a target you can simulate, model and prove things about. Expect the serious verification work of the next decade to happen on RISC-V, for no better reason than that the documents are available and the licence does not have to be renegotiated for each new academic.
The profile, rather than the specification, is the chokepoint.
An open ISA with optional extensions does not guarantee an open ecosystem. It guarantees an open document. What software targets is a profile, and whoever decides which extensions are mandatory in the profile that matters decides what the architecture effectively is. Today that is a committee of members, which is slow and visible. The risk is that it stops being the thing that matters.
The failure mode to watch for is vendor dialects. A large chip vendor ships a part with its own custom extensions, writes a toolchain that targets them, gets enough software built against it, and the practical baseline becomes "their RISC-V" rather than the ratified profile. Nothing about this breaks the licence or the specification. It does not have to. The specification stays open while the ecosystem splits, and you end up with three incompatible families, each open, each useless to the others. That is the worst of both worlds: the coordination cost of a committee and the lock-in of a proprietary ISA. Anybody who lived through the Unix wars has seen this film, and the lesson from it is that an open standard with no enforcement is a suggestion.
The other pressure is geopolitical and it is specific. An ISA designed to be unlicensable is attractive to whoever is worried about losing a licence, which means significant RISC-V investment now comes from states with an interest in not being dependent on American architecture licences. That is a real strength for the architecture and a real risk for its coherence, because the incentive for a state-backed programme is a profile it controls rather than one it shares. Export control pressure applied to the specification process would accelerate that split. The specification being public does nothing to stop the community that maintains it fragmenting along the same lines.
And the thing an open ISA never addressed: fabrication. You can read the specification, design the chip, verify it formally and still need one of a very small number of fabs to make it. Open silicon design with closed manufacturing is a real improvement over closed both, and it is not sovereignty.
Where is the open side? Winning on the document, holding its own on toolchains and vulnerable on profiles. The practical defence is dull and effective: target a ratified profile, treat vendor extensions as the proprietary dependency they are and refuse to ship software that only runs on one company's dialect. Here at AxisOps that is how we will buy RISC-V hardware when we buy it. If a board's value proposition requires their fork of the toolchain, it is not an open architecture, whatever the marketing says; it is a proprietary chip with a fashionable name on the box.
Where the value turns up¶
RISC-V's significance is unlikely to be displacing x86 or ARM in a datacentre this decade. It's that the specification is a public good, and the second and third order effects of that (verification, research, capability hardware) are where the value turns up.