20 products

The full Cryptuon portfolio

Every project is open source and MIT-licensed, with its own marketing site at <name>.cryptuon.com, source on GitHub, and docs at docs.cryptuon.com/<name>/.

Solana (6) Cross-chain (3) EVM (2) Trading & markets (4) Dev tools (3) Libraries (2)

Solana

6 products

Coordination networks, indexing, storage, AI, and games settled on Solana.

You are here if: You need a service whose credibility depends on not being run by one company — or you have hardware sitting idle and want it earning.

Distinguish these by what the operator is actually being paid to do. StreamSync pays for query latency, SolanaVault for storage and retrieval, SolanaLM for GPU cycles, DFPN for detection verdicts, Njord for verified conversions, and Sarpoy for running a game with a live prize pool. The economics follow the work: latency-competitive services reward the fastest honest operator, while judgement-based services reward accuracy measured over time, which is why their staking and slashing rules look nothing alike.

Cross-chain

3 products

Atomic swaps and state sync that span L2s and EVM/non-EVM chains.

You are here if: Your application already lives on more than one chain, and every workaround so far has meant trusting a bridge or accepting a partial fill.

The split here is value versus state. Tesseract moves assets under an all-or-nothing guarantee and cares deeply about what happens when one leg fails. Switchboard moves information and cares about how quickly a write on one chain becomes readable on another. DataMgmt Node moves neither: it coordinates custody of records between organisations that do not fully trust each other. Picking the wrong one usually shows up as building a settlement mechanism on top of a read layer, or vice versa.

TE

Tesseract

Cross-chain / DeFi

Production

A cross-rollup atomic swap protocol for Ethereum L2s — Vyper contracts plus a Rust relayer enforce all-or-nothing swaps with commit-reveal MEV protection, no bridges or wrapped assets.

Built for: DeFi builders swapping natively across L2s.

Publicly tested Maturity 2 of 4 · Source + public test suite (not all scenarios pass yet); deployable to EVM testnets
Vyper · Rust Cross-chain
Need this delivered? Integrate across chains →
tesseract.cryptuon.com Docs

EVM

2 products

An embeddable parallel EVM and a fair-launch proof-of-work ERC-20.

You are here if: You need EVM semantics inside something that is not an Ethereum node, or you are studying what a token looks like with no allocation at all.

Zig-EVM is a library and EVMORE is an asset, so they share a category only in the sense that both concern the EVM. Reach for Zig-EVM when you need execution semantics inside another system — a rollup sequencer, a simulator, a fork-testing harness, an indexer that must replay transactions — and would rather not embed a full node to get them. EVMORE is relevant if you are studying fair-launch distribution, mineable ERC-20 mechanics, or what a token contract looks like with no administrative functions in it at all.

Trading & markets

4 products

Prediction markets and algorithmic + institutional trading systems.

You are here if: Your order is large enough that broadcasting it moves the price against you, or your strategy needs backtesting before it touches a live venue.

Order size decides which of these is aimed at you. Moby Market is built for positions where slippage and information leakage dominate the cost of trading, and its features — RFQ, dark pools, randomised child orders, zero-knowledge privacy — are all answers to that one problem. dgbit and PolyBot are frameworks rather than venues: they assume you have a strategy and need backtesting, execution plumbing, and risk controls around it. Mentat and Sarpoy are market designs, where the interesting part is how the market resolves rather than how you trade in it.

DG

dgbit

Trading framework

Production

A professional algorithmic trading framework for Bybit — a Python package and multi-service stack (FastAPI, NNG bus, Vue 3 dashboard) for backtesting, building, and executing crypto strategies.

Built for: Crypto traders backtesting and deploying on Bybit.

Publicly tested Maturity 2 of 4 · PyPI (pip install dgbit), Docker image; Bybit testnet supported
Python · FastAPI Trading
Need this delivered? Productionise trading research →
dgbit.cryptuon.com Docs

Dev tools

3 products

Smart-contract compilers and validator signing security.

You are here if: Your team knows Solidity or TypeScript, the chain you need does not, and rewriting is the whole project plan.

Compare these on what they refuse to do. SolScript will not silently paper over Solana account model semantics, so account validation and PDA derivation stay visible in the generated program. StxScript will not emit Clarity a reviewer cannot read, because Clarity source is what ships to the chain and an unreadable transpiler output would erode the property that made Stacks attractive. nklave will not produce a signature that violates a slashing rule, no matter what the validator client asks for. In all three cases the constraint is the product.

Libraries

2 products

Small, focused crypto primitives you can drop into any project.

You are here if: You need one primitive done correctly, and every option you have found arrives attached to a framework.

These are extractions, not products built for their own sake. Each one exists because the same code was being written a third time inside a larger project. commit-reveal is pure Python with no dependencies, which matters because a cryptographic primitive that drags in a dependency tree is a supply-chain liability. blockchain-compression is a Rust crate on crates.io whose advantage over generic Zstandard comes entirely from dictionaries trained on real Solana byte patterns — a reminder that domain-specific compression beats general compression when the domain is narrow enough.

Looking for the source, research, and tooling behind these? Browse the GitHub organisation.

Conventions that hold across every product

Systems languages where a bug becomes consensus
Rust and Zig carry the protocol implementations, relayers, worker daemons, and the execution engine. Vyper carries contracts that should be short enough to read in one sitting — the proof-of-work token contract is a deliberate example. Python and TypeScript carry SDKs, gateways, and tooling, because a library nobody can call from the ecosystem they already work in does not get adopted no matter how correct it is. The split is by consequence of failure, not by preference.
Chains are a deployment target, not an identity
Solana carries the coordination networks because sub-second confirmation and negligible fees are what make per-request operator payments arithmetically possible. Ethereum and its L2s carry the cross-rollup and asset work. Stacks appears through the Clarity toolchain, and Bitcoin-style proof-of-work appears once, in a mineable ERC-20. No project assumes a single chain wins, and several exist specifically because none has.
One address pattern, three surfaces
Every project resolves the same way. The marketing site is at <name>.cryptuon.com, the documentation at docs.cryptuon.com/<name>/, and the source at github.com/cryptuon/<name>. Nothing is behind a signup wall and no product has a private companion repository that the public one depends on.
The release publishes all three together
A tagged release updates the site, the docs, and the binary in the same run, so documentation never describes a version you cannot download. This is why a docs page and a release artefact should never disagree, and if they do, that is a bug worth reporting.
MIT, without a dual-licence twist
Every project is MIT-licensed with no contributor licence agreement, no commercial edition withheld from the repository, and no clause that converts on a revenue threshold. Commercial use, modification, and redistribution inside closed-source products are all permitted, and the licence comes with no warranty — which is the part worth taking seriously before deploying anything that holds value.
Status labels describe interfaces, not audits
“Production” means the API surface is settled and a breaking change would arrive with a migration note. “Building” means interfaces can still move between releases. Neither label makes any claim about security review; audit status is stated per repository, because summarising it at portfolio level would be misleading for at least one project in either direction.
Numbers come with methodology or they do not appear
Where a throughput, compression, or latency figure is published, the measurement setup is written down next to it. Where we do not have a figure we are prepared to defend, the mechanism is described and the number is omitted rather than estimated. The reasoning behind one such set of measurements is in Parallel EVM Benchmarks 2026.

Getting from this index to running code

Every project documents itself the same way, which means the path from “this looks relevant” to “this is installed” is identical regardless of which card you clicked.

  1. Start at the project site’s How it works page. It describes the architecture in one pass — what runs where, what the components are, and what the request or transaction lifecycle looks like. Five minutes here saves an hour of reading source.
  2. Read the Compare pages before the Features page. Each project names the alternatives it is measured against and says plainly where those alternatives win. If the honest comparison already rules the project out for your case, you have saved the install.
  3. Then the Quickstart, which assumes nothing. Install commands, a minimal working example, and the first thing to run. Libraries are on the standard registries — Rust crates on crates.io, Python packages on PyPI — so for those the quickstart is usually one install line and an import.
  4. Check the FAQ for the awkward questions. Token status, licensing, what the project explicitly is not, and the threat model where one applies. These are written to answer what people actually ask rather than what is comfortable to answer.
  5. Pin a version. Because one tagged release publishes the site, the docs, and the binary together, pinning gives you documentation that describes the exact artefact you are running rather than whatever shipped most recently.

Projects that are protocols rather than tools have two extra pages worth reading before anything else: a tokenomics page covering supply, emissions, fee splits, stake floors, and slashing, and an operator guide covering hardware, stake, and what the daemon actually does. Joining a network is a different commitment from installing a library, and the documentation is structured to make that distinction obvious rather than to blur it.

What is genuinely shared, and what is not

A portfolio this size invites a reasonable suspicion: that these are twenty thin wrappers around one codebase. They are not, and the distinction matters if you are deciding whether adopting one commits you to any of the others.

What is shared are ideas. A commit-reveal window appears in cross-rollup swap ordering, in sealed-bid auctions, and in collusion-resistant scoring, because the same adversary — someone who benefits from seeing others’ inputs first — recurs in all three. Staked operator reputation appears wherever independent parties are paid for judgement. Hash-on-chain with the payload off-chain appears wherever a record must be verifiable without being republished. Solana as a settlement and coordination layer appears wherever payments are too small and too frequent for anything slower.

What is not shared is code. There is no Cryptuon SDK that every project imports, no shared service that must be running, and no cross-project dependency that would break one repository when another changes. The two published libraries are the exception that proves the rule: they exist precisely because a primitive was being reimplemented often enough to deserve extraction, and they are on crates.io and PyPI for anyone to use, with no relationship to the rest of the portfolio required.

The practical consequence is that adoption is granular. Using the Solidity-to-Solana compiler commits you to a compiler, not to a network, a token, or a chain preference. Running a detection node commits you to that protocol’s stake and slashing rules and to nothing else here. Every dependency in this portfolio is meant to be individually reversible, and that is a design constraint rather than a happy accident.

Problems the open-source portfolio does not solve

Knowing what is absent is faster than working through six categories to discover it. These are deliberate gaps, not gaps waiting to be filled, and in each case there is a better place to look.

There is no wallet and no key-management product
Nothing here holds user keys or takes custody of user funds. Escrow contracts hold value under rules that are public and enforced on-chain, which is a different arrangement entirely. If you need a wallet, an MPC signer, or an institutional custody stack, that is a separate category of product with its own regulatory surface.
There is no L1, and no plan for one
The portfolio builds on chains rather than competing with them. The embeddable EVM is a library for people building execution environments, not a chain; the coordination networks settle on Solana rather than running their own consensus. Launching another base layer would add a security budget to defend and solve nothing that the existing ones do not.
There is no bridge
This one is a position rather than an omission. The cross-rollup swap protocol exists specifically to avoid the bridge model: no wrapped assets, no custodied pool, and a failure that returns both sides to where they started rather than stranding one. Where bridges are genuinely needed, other teams build them and we do not duplicate that work.
There is no exchange, and no stablecoin
The trading projects are execution infrastructure and strategy frameworks, not venues. They route to existing liquidity rather than hosting it. Similarly, nothing here issues an asset intended to hold a peg — the payment work settles in assets that already exist, because a stablecoin is a balance-sheet product wearing a smart contract.
The projects are not a hosted service
Every project is software you run, or a protocol you join as an operator or a client. There is no metered API behind a signup form and no managed tier that the open repository is a teaser for. When you need one of them integrated, migrated, or operated for you, that is a separate, scoped engagement — see engagements & pricing.

How the projects compose

Most real systems need pieces from more than one category, and the seams between them are where the design decisions live. Three combinations come up often enough to be worth describing explicitly.

An autonomous agent that pays for what it uses

The payment leg needs escrow that releases on a verified action rather than a prepaid balance, which is the Njord pattern. The coordination leg needs the agent to read and write state on whichever chain the counterparty lives on without a bespoke integration per chain, which is Switchboard. The verification leg needs proof that the work being paid for actually happened, which is where replicated inference and commit-reveal aggregation come in. The hard part is not any single leg — it is that the settlement window, the state-sync latency, and the verification quorum all have to fit inside one agent loop.

A rollup or appchain that needs EVM semantics

Embedding Zig-EVM gives you execution without inheriting a full client’s database and networking stack, and its wave-based scheduler runs independent transactions concurrently instead of strictly in order. Once you have your own execution environment, the next problem is almost always interoperability: assets that need to move to another rollup without a bridge custodian, which is the Tesseract case, and state that needs reading from elsewhere, which is the Switchboard case. Compilers enter the picture when you want existing Solidity to target something that is not the EVM at all.

A regulated institution moving on-chain

Execution comes first: large positions need impact management, privacy, and venue routing before anything else matters, which is the Moby Market case. Custody of the accompanying records is a separate problem, and it is the one that determines whether an auditor accepts the arrangement — hashes and access grants on chain, ciphertext off it, so integrity survives while erasure remains possible through key destruction. Staking operations add a third requirement, where the relevant control is a signing boundary that refuses to produce a slashable signature rather than a policy document saying it should not.

A validator operation that cannot afford a slashing event

The control that matters here is not monitoring and not a runbook — both act after a signature already exists. nklave sits between the validator client and the signing key and refuses to produce a signature that would violate an EIP-3076 slashing rule, which converts an incident into a rejected request. Everything else in the staking stack is downstream of that boundary: the client can crash, a duplicate can be scheduled, a migration can go wrong, and the failure mode is a failed sign rather than a slashed balance. We took the reasoning apart in Preventing Validator Slashing by Policy Enforcement.

Before you integrate

  • Read the limitations section on the project’s own site before the feature list. It is written to be useful rather than reassuring, and it is the fastest way to find out the project is aimed at a neighbouring problem.
  • Check whether you are adopting a tool or joining a network. A tool works the moment you run it. A network’s guarantees depend on how many independent operators are participating, which is a question no repository answers.
  • Decide where the trust boundary sits in your design, then check that the project puts it in the same place. Most integration failures here are not bugs; they are a mismatch about who is allowed to be wrong.
  • Pin a release. One tag publishes the site, the docs, and the binary together, so a pinned version gives you documentation that matches the artefact you are running.

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