Crypto infrastructure, delivered and operated

A portfolio structure is an unusual choice in crypto, where the default is to pick one protocol and pour everything into it. The reason it works here is that the products share primitives rather than users. Commit-reveal, staked operator reputation, hash-on-chain with payload off-chain, and Solana as a settlement and coordination layer show up across projects that otherwise have nothing to do with each other. Solving one of those once and reusing it is what makes twenty products tractable for a small team.

Each project is genuinely independent. It has its own repository, its own release cycle, its own marketing site at <name>.cryptuon.com, and its own documentation subpath. Nothing imports a shared Cryptuon runtime, and no project requires another to be deployed. That isolation is deliberate: it means a project can be adopted, forked, or abandoned without touching anything else, and it keeps every integration decision reversible for the people who depend on it.

The release discipline is shared even though the code is not. One tagged release publishes the marketing site, the documentation, and the binary together, so the docs a reader sees always describe the artefact they can download. We wrote up that pattern in Shipping Site, Docs, and Binary in One Release, because getting it wrong is the most common way an open-source project loses the trust of the people evaluating it.

Language choice follows the same logic. Rust and Zig for anything where a memory-safety bug becomes a consensus bug. Vyper where the contract surface should be small enough to read in one sitting. Python and TypeScript for SDKs, services, and tooling, because adoption depends on meeting developers in the ecosystem they already work in. The portfolio is multi-language because the problems are, not because we are undecided.