Project Portfolio — 20 projects

The Cryptuon project portfolio

The 20 open-source projects behind Cryptuon’s delivery work, spanning Solana infrastructure, cross-chain protocols, trading systems, compilers, and crypto libraries. Each card shows its public evidence level. Prefer the category view? Head to Open Source.

Networks & Protocols

8 projects

These are the projects with other people in them. A network is not finished when the code works — it is finished when enough independent operators are running it that the decentralisation claim is true rather than aspirational. That makes their timeline different from everything else here: the engineering can be complete while the network is still early, and no amount of further coding fixes that. When evaluating one, read the operator requirements before the feature list.

Token Projects

2 projects

A token appears in this portfolio only where it solves a coordination problem that cannot be solved with a fee. Stake makes misbehaviour expensive, emissions bootstrap a network before demand exists, and governance allocates a parameter nobody should be able to set unilaterally. Where none of those apply, the project ships without one. The designs diverge sharply as a result, and the differences are the interesting part.

Trading & Markets

4 projects

Everything in this group touches live venues and real money, which changes what “working” means. Correctness is not enough; these projects also need risk controls, defaults that fail safe, and a paper-trading mode that is genuinely the default rather than a flag you have to remember. Read the risk documentation first, and treat any strategy framework as scaffolding around your own judgement rather than a replacement for it.

Developer Tools

4 projects

These are the projects with no runtime, no token, and no network. They run on your machine, emit an artefact, and disappear. That makes them the easiest things here to evaluate: clone the repository, run the compiler or the daemon against something you already have, and read what comes out. It also makes them the easiest to walk away from, which is deliberate — a tool you cannot abandon is a dependency, not a tool.

Libraries

2 projects

Small, single-purpose, and dependency-light on purpose. Each was extracted from a larger project after the same code appeared in it for the third time. The right way to assess one is to read it end to end, which is feasible because they are short. If a cryptographic primitive is too large to read in an afternoon, that is information about the primitive.

Looking for the full source — including research papers, tooling, and protocol implementations? Browse the GitHub organisation.

How to read a project’s stage

Of the 20 projects here, 10 carry a “Production” badge and 10 are marked “Building”. Those two labels answer one narrow question — whether the interfaces are settled — and they are routinely read as answering several broader ones they do not. The checklist below is what we would actually want someone to work through before depending on any of this.

  1. Separate the tool from the network. A compiler either produces correct output or it does not, and you can find out this afternoon. A network’s value depends on how many independent operators are running it, which no repository can tell you. The same “Production” badge means very different things in those two cases.
  2. Read the limitations before the features. Every project site carries an explicit statement of what it cannot do yet, split between current constraints and roadmap items. That section is written to be useful rather than reassuring, and it is the fastest way to discover that a project is aimed at a neighbouring problem rather than yours.
  3. Check audit status per repository, never per portfolio. It varies. Some critical paths have been formally verified; other code has had no external review at all. The MIT licence means the code is yours to inspect and equally means it comes with no warranty, so anything holding value deserves your own review regardless of what the badge says.
  4. Confirm the docs match the release you can download. One tagged release publishes the site, the docs, and the binary together, so they should agree. If they do not, something has gone wrong and it is worth an issue.
  5. Decide how you would leave. Nothing here imports a shared Cryptuon runtime and no project requires another to be deployed, so every dependency is meant to be reversible. Working out the exit before the integration is the cheapest form of due diligence available for open-source infrastructure.

Looking for these grouped by the problem they solve instead of by structure? The solutions page routes by symptom, and the FAQ covers licensing, tokens, and what the status labels do and do not claim.

Need one of these integrated or operated?

Every project is MIT-licensed and free to use. When you need a migration, integration, or managed operation delivered against acceptance criteria, start with the outcome.

Describe your project Browse solutions