The state of CX

Where development stopped

CX is three repositories.

The last release of CX is 0.8.0, from March 2021. The language targets Go 1.15 and cx-chains Go 1.14, both long out of support.

What CX chains were meant to be

In a CX chain, a CX program's state lives on the blockchain. Each transaction carries a piece of CX code. To make a block, a node loads the program's state from the chain, runs the transaction's code against it, and stores the new state back in the block. The program and the chain state are the same thing, which was the idea that set CX apart.

The design holds together on paper. The implementation was never finished.

What does not work

• CX chains run an old CX. cx-chains is built on a snapshot of CX from December 2020, so nothing done to the language since then reaches it.
• A chain program is limited to one package. That rules out libraries and programs built from several parts. The code marks this with a TODO.
• Running a program is not deterministic. Every node must get exactly the same result from the same transaction. CX programs can read the clock, use random numbers and iterate maps in varying order, and nothing stops them.
• There are no limits on what a program costs. There is no gas or step metering, so a transaction with an endless loop would stop the chain.
• Errors stop the virtual machine. Many errors in the CX runtime end the process instead of failing one transaction, so one bad transaction could crash a node.
• Chain programs can reach the outside world. The standard library's file, network and operating-system packages are not walled off from code that runs on a chain.
• There is no written consensus rule. What makes a block valid, and what happens when nodes get different results, was never specified.
• The tracker does not sign the chain specs it serves, which the code also marks as a TODO.

Only small examples, such as a counter, were ever shown running on a CX chain.

What finishing it would take

In order of what depends on what:

1. Bring the language up to date with current Go and its own tests.
2. Make the virtual machine deterministic: randomness and time from the block, a fixed map order, and only operations that give the same result everywhere.
3. Add metering, with a cost per operation and a limit per transaction.
4. Turn runtime errors into failed transactions that roll back their changes.
5. Separate the parts of the standard library a chain program may use from the parts it may not.
6. Allow more than one package per chain program.
7. Rebuild cx-chains on the current CX instead of the 2020 snapshot.
8. Write down the consensus and execution rules.
9. Finish the tracker and the tools: spec signing, an explorer, and a deploy flow that works end to end.

None of this is unusual work, but it is a lot of it. An assessment in April 2026 estimated one to two years of work for one person before a credible test network.

Possible directions

Three paths have been considered. None has been chosen.

• Finish CX as it is. This keeps the original idea of the program state being the chain state, and it needs all of the work above.
• Keep the language, replace the virtual machine. CX could compile to WebAssembly and run on an existing smart-contract runtime that already has deterministic execution, metering and sandboxing. This is much less work, but the program would no longer be the chain state.
• Start again from the design. A new implementation of the same ideas, without the old code's unfinished parts. This costs the most.

Using CX today

The language still builds, with the build tags its Makefile uses, and runs simple programs, such as its hello-world example, on current Go. It and its documentation are on GitHub, and the CX book still teaches the language as it was designed. Treat them as a record of the project, not as a supported platform. Questions are welcome in @skywire on Telegram.