Eleven of the twenty projects on github.com/cryptuon touch Solana in some material way. Some are pure on-chain programs with off-chain indexers (Njord, Mentat, Sarpoy). Some treat Solana as the settlement layer for a decentralised network of off-chain workers (DFPN, SolanaLM, StreamSync). Some are Solana-adjacent libraries that any Solana project can pull in (blockchain-compression, SolanaVault). After shipping or actively iterating on all of them, a handful of patterns have hardened into rules-of-thumb that we apply to every new Solana project we start.
This post collects those lessons, with concrete references to the projects they came from. Each section names the project the lesson came out of and links to the marketing page and the docs.
TL;DR
- Solana is good at coordination, not computation. The projects that worked smoothly model the on-chain program as a tiny coordination kernel (escrow, accounting, slashing) and push everything else to off-chain workers. DFPN and SolanaLM are the clearest examples.
- Anchor 0.30.x is the boring, productive choice. Across the portfolio we’re on Anchor 0.30.1 (DFPN), 0.32.1 (Njord), and 0.29.0 (Sarpoy). The version differences matter much less than picking one and freezing it for the life of the IDL.
- Off-chain stack converges on the same shape. FastAPI or Nuxt frontends, PostgreSQL with an event indexer that subscribes to the Solana WebSocket feed, JWT auth. We’ve now rebuilt this stack at least four times across projects; the next post in this series will pull it out into a reusable scaffold.
- Tokenomics are about distribution, not denomination. The Solana projects with real tokens (DFPN, Njord, Mentat, StreamSync) all designed the distribution function (worker rewards, treasury, slashing) before they picked the SPL parameters.
Lesson 1: The on-chain program should be the smallest possible kernel
The hardest lesson, and the one most projects learn the wrong way, is: don’t put logic on chain unless it materially needs to be there.
DFPN is the clearest example. It is, in the README’s own phrasing, “a decentralized coordination layer for deepfake detection on Solana.” That’s a striking framing because the detection itself happens entirely off chain. The on-chain Solana program does four things and nothing else:
- Holds worker stake (minimum 5,000 DFPN tokens per worker, 20,000 DFPN per model developer).
- Accepts request payments into escrow.
- Distributes rewards to workers, model developers, treasury, and insurance pool according to the published split (65% / 20% / 10% / 5%).
- Slashes stake when verification fails.
That’s it. The detection models, the GPU coordination, the consensus among worker responses — all of that runs off chain. The on-chain program is, in effect, a payment-and-slashing primitive. This is correct. Putting an ML inference loop in Anchor would be both impossible (BPF compute limits) and pointless (no one needs the inference to be byzantine-fault-tolerant; they need the payment for the inference to be byzantine-fault-tolerant).
SolanaLM follows the same shape for LLM inference and federated learning. Nodes earn SOL through “dual revenue streams: serving inference requests and participating in training rounds.” The Solana program is the meter and the rail. The model weights and the inference computation live on the node operator’s hardware.
Njord pushes this even further. The README’s own diagram shows the on-chain program managing escrow and commission settlement for affiliate marketing campaigns, while the click attribution — the thing that has historically been the hardest, most disputed, most centralised part of affiliate marketing — happens off-chain through bridge operators with on-chain reputation. Sub-cent per transaction (~$0.00025) is only achievable because the chain is doing very little per transaction.
The rule we now apply to every new Solana project: draw the boundary at the place where Byzantine fault tolerance buys you something the user cares about. Payment, stake, slashing, reputation — yes. Inference, ranking, search — no.
Lesson 2: Embrace the off-chain indexer as a first-class component
If the on-chain program is small, the off-chain indexer becomes the thing your users actually interact with. Across the Solana subset of the portfolio, the same architecture keeps reappearing:
- An event indexer that subscribes to the Solana WebSocket feed and writes every relevant transaction into PostgreSQL.
- A read API (FastAPI or Nuxt server routes) that serves the indexed data with normal SQL queries.
- A frontend (Vue 3 + Pinia + Vite is the recurring choice) that reads from the API.
Mentat lays this out explicitly. The README describes a “TypeScript indexer with PostgreSQL storage and a WebSocket feed”, together with the Vue 3 frontend, FastAPI backend, PostgreSQL with Aerich migrations, JWT auth, and the market-factory / market-settlement Anchor programs with generated IDLs. Sarpoy has the same shape: FastAPI + TortoiseORM backend, Nuxt 3 + Tailwind frontend, Solana RPC through solders and anchorpy, and an Anchor 0.29.0 program for escrow and message-fee accounting.
The reason every Solana project ends up with this architecture is that the chain is genuinely fast, but it’s not a database. Anchor accounts are great for the things that must be on chain. But “give me the last 50 markets created, paginated, filtered by category” is a query you want PostgreSQL to answer, not the RPC.
StreamSync is the most explicit answer to this. The README pitches it as “guaranteed sub-10ms Solana query performance through competitive node operations.” It is, effectively, productising the indexer-as-a-network. Independent operators race to serve queries, with $STRM token staking (minimum 10,000 STRM, 7-day cooldown) and racing rewards (70% to the winning node, 15% to each verifier). If you’re building a Solana app and you don’t want to operate your own indexer, StreamSync is the bet that you’ll be able to pay one.
Lesson 3: The Anchor version doesn’t matter; freezing it does
Across the portfolio:
- DFPN: Anchor 0.30.1
- Njord: Anchor 0.32.1
- Sarpoy: Anchor 0.29.0
People sometimes ask which Anchor version they should be on. The honest answer is “any of them, as long as you pick one and freeze the IDL.” The IDL is the contract between the on-chain program and every off-chain consumer — your TypeScript SDK, your Python client, your indexer, your CLI. The version of Anchor that produces that IDL is much less interesting than the question of whether the IDL is stable. The projects in the portfolio that ran into the most rework were the ones that upgraded Anchor mid-flight and discovered that the regenerated IDL broke their indexer.
The rule: pick the Anchor version when you start. Pin it in Cargo.toml. Pin the matching @coral-xyz/anchor version on the client. Don’t upgrade until you have a real reason.
Lesson 4: The token design problem is the distribution function
Four of the eleven Solana-touching projects have on-chain tokens with meaningful tokenomics:
- DFPN: 1,000,000,000 DFPN supply, allocated 38% Network Rewards, 20% Treasury, 18% Team & Advisors, 12% Ecosystem Growth, 7% Strategic Partners, 5% Liquidity. Per-request fee split: 65% Workers, 20% Model Developers, 10% Treasury, 5% Insurance Pool. Worker scoring is Accuracy (50%) + Availability (25%) + Latency (15%) + Consistency (10%).
- Njord: 1,000,000,000 NJORD supply, 2.5% protocol fee, stake for up to 50% fee discounts. Four affiliate tiers (New → Verified → Trusted → Elite), four bridge tiers (Bronze → Silver → Gold → Platinum). Transaction cost ~$0.00025.
- StreamSync: $STRM token, racing rewards 70% / 15% / 15%, 10,000 STRM minimum stake.
- Mentat: Token economics defined in
docs/tokenomics.md; market settlement via zkTLS proofs.
What’s striking is that the SPL token itself is almost the least interesting part of any of these designs. Minting a token on Solana is a few lines of Anchor. The hard part — the part the docs actually spend pages on — is the distribution function: who earns what, when, under what conditions, and with what verification.
DFPN’s per-request 65/20/10/5 split is the entire economic engine of the protocol. The 38% Network Rewards allocation is the budget for that engine. If those two numbers are wrong, no amount of Anchor sophistication saves the design. If they’re right, the rest is plumbing.
We have a longer post coming up specifically on tokenomics across the six token-bearing Cryptuon projects, comparing EVMORE’s pure-PoW fair launch (21M supply, no premine, no team allocation) with DFPN’s network-rewards-heavy split. The short version of that comparison: there is no single right answer, but there is a forcing function — what behaviour are you trying to make profitable.
Lesson 5: Compression and storage matter once the data is real
Two libraries in the portfolio exist specifically to deal with Solana data volume:
- SolanaVault advertises a 15-25:1 compression ratio and “95% storage savings” for Solana blockchain data, framed as a decentralised storage network with economic incentives.
- blockchain-compression is the lower-level Rust library underneath the idea: lossless compression built on Zstandard with custom dictionaries trained on blockchain-specific byte patterns (program IDs, public keys, signatures, common amounts). The README cites compression ratios “up to 60:1.”
These exist because Solana’s growth makes naive storage untenable. Archive nodes get expensive, historical queries get slow, and the operational cost of being a serious node operator climbs. If you’re building anything that needs historical Solana data — analytics, indexing, replay-based testing — these two projects are likely cheaper to depend on than to rebuild.
Lesson 6: Build the SDK before you ship the program
Every Solana project that shipped well in the portfolio had a TypeScript SDK in the same repo as the Anchor program. Njord ships a TypeScript SDK alongside the dashboard. DFPN’s README pitches Vue 3 dashboard, TypeScript SDK, PyTorch models in the same breath as the Anchor program. SolanaLM, SolanaVault, Mentat — same story.
The reason is simple: the IDL is a generated artefact. If you don’t immediately consume it, you don’t immediately find out that your account layout is awkward, your enum variants don’t serialise the way you think, or your instruction takes thirteen accounts and is unusable from a wallet. Writing the SDK forces those problems out into the open while the program is still flexible.
The rule: every new Anchor program in the portfolio ships with a TypeScript SDK in the same monorepo from commit one. The SDK is the proof that the program is usable.
Where this goes next
The eleven Solana projects in the Cryptuon portfolio are at different stages — Sarpoy and Mentat both carry the “Active development, APIs may change between releases” warning in their READMEs, while DFPN is on devnet and Njord has live devnet deployment. None of this is production-grade in the sense that a Coinbase or a Phantom is production-grade, and we are careful to say so.
What we can say is that the architectural pattern has hardened. Small on-chain kernel, off-chain indexer, TypeScript SDK as the contract surface, and the token (if there is one) designed by its distribution function rather than its denomination. The next twelve months of the portfolio will mostly be about pushing the existing projects from “active development” to “production-leaning” — and almost none of that work, in our experience, is on the chain itself.
- DFPN: https://dfpn.cryptuon.com/ — docs at https://docs.cryptuon.com/dfpn/
- Njord: https://njord.cryptuon.com/ — docs at https://docs.cryptuon.com/njord/
- Mentat: https://mentat.cryptuon.com/ — docs at https://docs.cryptuon.com/mentat/
- StreamSync: https://streamsync.cryptuon.com/ — docs at https://docs.cryptuon.com/streamsync/
- SolanaLM: https://solanalm.cryptuon.com/ — docs at https://docs.cryptuon.com/solanalm/
- SolanaVault: https://solanavault.cryptuon.com/ — docs at https://docs.cryptuon.com/solanavault/
- Sarpoy: https://sarpoy.cryptuon.com/ — docs at https://docs.cryptuon.com/sarpoy/
- blockchain-compression: https://blockchain-compression.cryptuon.com/ — docs at https://docs.cryptuon.com/blockchain-compression/