Tokenomics EVMORE DFPN Tesseract Portfolio

Tokenomics across Cryptuon: what's earned, what's allocated, and what we deliberately left off

Six projects in the Cryptuon portfolio have on-chain tokens. EVMORE is a 21M-cap fair-launch PoW token. DFPN allocates 1B tokens across six buckets with a per-request fee split. Tesseract has tiered staking APY. Here's what the designs share, where they diverge, and what we chose not to put a token on.

DS
Dipankar Sarkar
10 min read 1,882 words

Six of the twenty projects in the Cryptuon portfolio have on-chain tokens with meaningful economic design: EVMORE, DFPN, Njord, Tesseract, StreamSync, and Mentat. The other fourteen deliberately don’t. That distinction matters: a token isn’t a feature you add to make a project feel more serious. It’s a coordination mechanism for a specific behaviour you can’t get any other way. When the behaviour doesn’t need it, we don’t ship one.

This post walks through the four token designs we can describe in concrete numbers from each project’s public README — EVMORE, DFPN, Njord, and Tesseract — and then explains why the other fourteen projects in the portfolio (SolScript, Zig-EVM, nklave, blockchain-compression, commit-reveal, dgbit, PolyBot, sarpoy, Switchboard, SolanaVault, DataMgmt Node, Moby Market, SolanaLM, StxScript) deliberately have no token. Where the README didn’t commit to specific numbers (Mentat, StreamSync’s allocation table), we say so explicitly rather than invent them.

TL;DR

  • EVMORE is a Bitcoin-shaped fair launch on Ethereum: 21,000,000 supply hard cap, 50 EVMORE block reward, halving every ~4 years, no premine, no ICO, no team allocation. Distribution is entirely through KeccakCollision proof-of-work mining.
  • DFPN is a network-rewards-heavy design: 1,000,000,000 supply allocated 38% Network Rewards / 20% Treasury / 18% Team & Advisors / 12% Ecosystem Growth / 7% Strategic Partners / 5% Liquidity, with a per-request fee split of 65% Workers / 20% Model Developers / 10% Treasury / 5% Insurance Pool.
  • Njord has a 1,000,000,000 NJORD supply, a 2.5% protocol fee, and a four-tier affiliate progression (New → Verified → Trusted → Elite) where staking buys discounts.
  • Tesseract ships a TESS governance token with 5-15% staking APY based on lock duration and up to 50% fee discounts for stakers.
  • The 14 projects without a token are the ones where the right incentive is already a sale (PyPI / crates.io install, paid Docker image, support contract) or where no group of decentralised actors needs to be coordinated.

EVMORE: fair launch as a design constraint

EVMORE is the easiest token in the portfolio to describe because the README does the work for you. From the project’s own at-a-glance table:

Max Supply: 21,000,000 EVMORE Block Reward: 50 EVMORE (halves every ~4 years) Premine: None — 100% fair launch

The whole design is a deliberate echo of Bitcoin’s distribution function, on Ethereum, with one important substitution: instead of SHA-256 proof-of-work, EVMORE introduces KeccakCollision — a memory-hard PoW where miners must find four values whose Keccak-256 hashes collide on the lowest N bits. The README’s framing is unambiguous: “ASIC-resistant, GPU/CPU accessible, and verified entirely on-chain. No premine. No ICO. No team allocation. Every EVMORE in circulation was mined through computational work.”

What’s interesting about this from a tokenomics design point of view is that EVMORE has no allocation table to argue about. There is no “team” share, no “treasury” share, no “ecosystem growth” carve-out. The distribution function is the protocol. Either you mined a block or you didn’t. The supply curve is entirely determined by the halving schedule.

This buys the design something real: it is impossible to be late to EVMORE in the way you can be late to a project that allocated 20% to a treasury at genesis. It also gives up something real: there is no protocol-controlled budget for grants, audits, or marketing. The README is comfortable with that tradeoff and says so.

The implementation backs the description: the README lists EvmoreToken.vy as a 627-line Vyper contract that is an ERC-20 with integrated mining, halving, and difficulty adjustment. There is no separate governance contract, no separate treasury contract. The token is the protocol.

DFPN: a network-rewards-heavy allocation

DFPN is the opposite end of the design space, and its README publishes the full allocation table. The total supply is 1,000,000,000 DFPN, broken into:

AllocationShare
Network Rewards38%
Treasury20%
Team & Advisors18%
Ecosystem Growth12%
Strategic Partners7%
Liquidity5%

The design intent is visible in the allocation itself: 38% is the largest single bucket, and it’s for paying workers. That’s not an accident. DFPN is a coordination protocol for deepfake detection. The whole point is to make running an honest detection node more profitable than the alternatives. If the network rewards bucket isn’t the biggest, the protocol doesn’t work, because there’s no reason for anyone to bring a GPU to it.

Per-request, the fee split goes:

Workers           ██████████████████████████  65%
Model Developers  ████████                    20%
Treasury          ████                        10%
Insurance Pool    ██                           5%

Worker scoring is decomposed in the README as Accuracy (50%) + Availability (25%) + Latency (15%) + Consistency (10%) — a weighting that says, in plain English, we’d rather be right than fast. Workers must stake a minimum of 5,000 DFPN; model developers stake 20,000 DFPN per model. The README is explicit about slashing: “Fraud gets slashed. The protocol aligns incentives without trusting anyone.”

The contrast with EVMORE is total. EVMORE’s distribution function is a global, anonymous PoW puzzle. DFPN’s distribution function is a per-request scored allocation across four named parties. Neither is “more correct.” They’re shaped by completely different problems. EVMORE is trying to be money. DFPN is trying to be a marketplace.

Njord: a flat supply with tier-based discounts

Njord publishes less of the allocation table in its public README than DFPN does, but the design surface is clear. Total NJORD supply is 1,000,000,000. The protocol charges a flat 2.5% fee on affiliate commissions. Transaction cost is ~$0.00025. Staking NJORD buys two things: up to 50% fee discounts, and access to higher volume tiers.

There are two tier ladders, each with four rungs:

  • Affiliate tiers: New → Verified → Trusted → Elite
  • Bridge tiers: Bronze → Silver → Gold → Platinum

The README does not publish the specific allocation breakdown between treasury, team, liquidity, and rewards. We’re not going to invent one — the docs at https://docs.cryptuon.com/njord/ are the canonical source, and the published tokenomics page (documentation/docs/tokenomics.md in the repo) is where the full breakdown lives. The honest statement is: NJORD’s supply is fixed at 1B, the protocol fee is fixed at 2.5%, and staking is the lever that compresses that fee for active users.

The design intent is recognisable as “affiliate-marketing-as-a-token-network”: the chain replaces NET-90 payment terms (the README’s framing) and the opaque tracking dashboards of traditional affiliate networks. The token is the access mechanism, and the staking is the alignment mechanism. The supply is large enough (1B) to support a four-tier ladder without rounding to dust.

Tesseract: governance + staking APY

Tesseract takes a third approach. Instead of distributing supply across worker rewards (DFPN) or mining (EVMORE), it ships a governance token (TESS) whose primary economic surface is fee reduction for the protocol’s actual users — DeFi protocols doing cross-rollup atomic swaps.

From the Tesseract README’s tokenomics section:

  • TESS Token: Governance and fee discount token
  • Staking Rewards: 5-15% APY based on lock duration
  • Fee Discounts: Up to 50% fee reduction for stakers

The implementation is split across three Vyper contracts that the README lists explicitly:

  • TesseractToken.vy (4,521 bytes) — the TESS ERC-20.
  • TesseractStaking.vy (6,890 bytes) — tiered staking with lock duration as the dial.
  • FeeCollector.vy (3,245 bytes) — protocol fee collection and distribution.

The 5-15% APY range is itself a design statement: a lower bound that makes short-lock staking viable as a yield product, and an upper bound (15%) that makes long-lock staking economically interesting without being so high that the supply emission becomes unsustainable. The README doesn’t publish the cap-table-style allocation breakdown — that’s also a deliberate signal. Tesseract treats TESS as governance-and-fee infrastructure, not as a fundraising instrument.

StreamSync and Mentat: published designs without full numbers

StreamSync’s README references $STRM as the network access and staking token, with racing rewards split 70% to the winning operator and 15% each to the two verifiers. Minimum stake is 10,000 STRM with a 7-day cooldown. The README points at docs/token-economics.md for the full design and we’ll respect that — the canonical page is the docs site at https://docs.cryptuon.com/streamsync/.

Mentat references a tokenomics design and a fee model in docs/fee-model.md and docs/tokenomics.md. The public README does not commit to specific supply or fee figures, so neither will this post. The Mentat docs at https://docs.cryptuon.com/mentat/ are the place to look.

What we deliberately did not put a token on

Fourteen of the twenty projects in the portfolio ship without a token. The list is worth reading because the pattern is the point:

  • Compilers: SolScript, StxScript. The right incentive is pip install and cargo install. There’s no decentralised set of actors that needs to be coordinated. Distribution is a registry, not a chain.
  • Runtimes: Zig-EVM. The same logic. It’s a library you embed in your own rollup. The right business model around it is consulting and support, not minting a token.
  • Validator security: nklave. The user is a single staking operator protecting their own keys. There’s no network of actors. A token would be ceremonial.
  • Libraries: blockchain-compression, commit-reveal. Standard open-source libraries. Distributed via crates.io and PyPI.
  • Trading systems: dgbit (algorithmic trading framework for Bybit), PolyBot (trading bot for Polymarket / Kalshi). These have paid SaaS / Docker / support business models built in already. There’s no protocol layer that needs token coordination.
  • Solana-native products with their own monetisation: Sarpoy (pay-per-message puzzle arena, paid in SOL directly), Switchboard (cross-chain state sync sold as infrastructure), SolanaVault (storage with direct revenue), DataMgmt Node (enterprise data sharing), Moby Market (institutional DeFi venue with its own fee model), SolanaLM (nodes earn in SOL directly, per the README).

The pattern is: token = coordination of an open set of actors whose behaviour can’t be policed any other way. For everything else, regular software business models work better. SolScript doesn’t need a token because no one is going to maliciously refuse to install your Solidity compiler. nklave doesn’t need a token because the validator running it has every incentive to keep it honest — its own stake is what’s at risk.

The forcing function

Looking at the four token designs that publish specific numbers, the question every Cryptuon token design has to answer is: what behaviour are you trying to make profitable, and what behaviour are you trying to make expensive?

  • EVMORE: profitable to mine, expensive to short-circuit the PoW.
  • DFPN: profitable to run an accurate detection model, expensive to submit fraudulent verifications (you get slashed).
  • Njord: profitable to send real, attributable affiliate traffic, expensive to game the bridge-operator settlement (lower tier).
  • Tesseract: profitable to stake long-term and use the protocol, no obvious behaviour that’s deliberately made expensive (the design is fee-discount-centric).

The four answers are completely different, but the question is the same. If a project can’t answer it, that’s the strongest signal we have that it shouldn’t ship a token. Most projects in the portfolio can’t answer it, and so they don’t. Six can, and so they do.

DS

Dipankar Sarkar

Founder, Cryptuon

Blockchain researcher and systems engineer. Author of 5 published papers on cross-chain composability, MEV mitigation, and DePIN protocols. Building production blockchain infrastructure in Rust and Zig.

Build on research-grade infrastructure

Ready to deploy smart contracts across chains, execute atomic cross-rollup swaps, or protect your validators from slashing?