How the network makes money

Pre-revenue

Varnir is on public testnets, where credits are free from a testing button, so it earns nothing yet. This page sets out where revenue is designed to come from; rates shown are illustrations from Pricing, not forecasts.

The revenue Varnir is working toward is credits: each charged action costs its listed credits, and plans are bought monthly with credits: Free (one free on-chain payout a month), Lite (500 credits a month), Hobbyist (2,900), Trader (19,900) and Enterprise (Subscription pricing). This page looks underneath that at the cost stack any charge has to cover, and at which layers of the product could carry more than cost recovery.

Pricing describes the four candidate revenue layers from the buyer's side. This page takes the other side: what each layer has to cover, and which are defensible versus commodity.

The one-line version

Settlement basis points fund the rail and will compress over time. The way keys are held and the treasury-verification layer are where value would actually accrue. The first exists; the second exists only in its smallest form.

What a settlement fee has to cover

Before asking what a rail should charge, here's what it actually spends. No fee is taken on a deposit today (see Pricing); any fee this page models would be paying for a real, identifiable stack:

Cost	Why it exists	Scales with
L1 gas	Moving value off a deposit address is a chain transaction. On Ethereum the price is volatile and outside Varnir's control	Transactions, not value
Node quorum	Four chain nodes across four providers (designed topology)	Roughly fixed
Confidential VM	SEV-SNP capable instances, and two of them for the MPC-TSS method	Roughly fixed, plus keygen
Key inventory	Wallets are generated ahead of demand. Unclaimed keys are paid-for stock	Growth rate, not volume
L1 event watching	Deposit detection runs against third-party event-stream providers, billed per stream or per request	Wallets watched
Everything else	Scanner, API, webhook delivery, support	Sub-linear

The important line is the first one, and it drives the shape of the fee more than anything else. Gas scales with transaction count, not transaction value. That is why the illustrative model on the Pricing page uses max(percentage, floor) rather than a clean percentage: a pure percentage of a small payment does not cover a chain interaction, and a rail that priced it that way would lose money on every small transfer it processed.

It is also the reason a stablecoin rail can plausibly charge single-digit or low-double-digit basis points where card acquiring charges hundreds. Most of what a card fee funds — interchange, chargeback risk, fraud loss, a multi-party scheme — has no counterpart here. What is left is chain cost plus infrastructure, and that is a much smaller number.

Why basis points alone are not a business

The uncomfortable part of a transfer-fee model is that it compresses. Every payment rail's per-transaction margin has trended toward its marginal cost as competition arrives, and a stablecoin rail's marginal cost is a public, observable number that every competitor pays too. There is no structural reason Varnir's settlement bps would resist that.

So settlement fees are best understood as funding the rail rather than being the business: they should cover the cost table above with enough margin to operate, and the actual enterprise value has to come from somewhere a competitor cannot reach by lowering a number.

Two candidates, one built and one not.

Layer one that is defensible: split keys

How keys are held is unusually detailed for a documentation page, and that depth is the point — it is describing something that took real engineering to build and would take real engineering to replicate:

• Key generation that cannot happen until a threshold of independent nodes has separately asked for it.
• Shamir 3-of-4 with information-theoretic security, where the whole key is deleted from the generating VM's memory the moment the shares exist.
• A two-party threshold ECDSA method where the private key is never assembled anywhere, and where each party's share is then Shamir-split across the quorum a second time.
• No break-glass path: no master key and no operator override. Production is designed so that no single party, Varnir included, can produce a signature alone; on testnet Varnir runs every node and both confidential VMs, so that is not yet true (see the qualifier below).

The commercial claim this supports is narrow: for a counterparty whose objection to custodial crypto infrastructure is "your operator can move my money," this architecture is a structural answer rather than a policy answer. That objection is the one that blocks enterprise adoption, and answering it structurally is what a buyer would actually pay for.

And the honest qualifier, which matters more than the claim. Distribution and jurisdiction states that the four nodes currently share one machine, one operator and one jurisdiction; that the confidential VM runs with attestation bypassed (MOCKCVM); and that the single-dev deployment's own README says keys on it should be treated as already compromised. The cryptography is real and executing. The distribution is not. Until it is, this layer's commercial value is potential rather than delivered, and anyone evaluating it should discount accordingly.

The related weakness is named on the same page: only GCP among the four providers has hardware matching what the attestation code checks, so the two MPC parties whose independence the protocol depends on are currently constrained to one provider. Splitting them across GCP and Azure is the obvious next step and has not been taken.

Layer two that is defensible: treasury verification

This layer is mostly not built, and repeating that here matters more than anywhere else on this page, because it is the layer an investor would find most interesting and the one with the least behind it. What exists is the two-key form: one key proposes, one confirms, and the ledger enforces that the proposer cannot execute. What does not exist is anything beyond a single confirmer.

The direction: an AI agent proposes a payment; independent verifying agents check it against policy; only an approved proposal becomes a settled transaction.

Why that is a different kind of product from settlement:

• It prices against risk, not against volume. The buyer is paying for the assurance that an autonomous system cannot move funds on its own say-so. That value does not fall as transaction sizes rise or as chain fees fall.
• It is the thing that makes agent-initiated payment plausible at all. An organisation will not hand payment authority to a model that can act alone. The verification layer is the precondition for the use case, not an add-on to it.
• It compounds with the split keys. Split keys mean no single node can sign, and production is designed so no single party can either; structural verification means no single agent can decide. These answer the two separate questions a treasury team asks, and the combination is harder to assemble than either half.
• It generates a compliance artefact. A signed, timestamped record of what was proposed, who verified it, against which policy, and what settled. That is an audit trail, and audit trails are durable products.

None of this is revenue until it is code. Stated as a direction, exactly as the introduction states it.

What is deliberately not in the model

Omitting these is a positioning choice, and each has a reason:

• Yield on float. Holding customer balances and earning on them is a real revenue line for payment businesses and is deliberately not proposed here. It changes what the business is, from an infrastructure provider into something holding client money for its own account, and it carries licensing obligations that vary by jurisdiction. Any move in that direction would be a regulatory decision before it was a pricing one.
• FX spread. The near-term target is USDT settlement in the Eurozone, which implies a euro/stablecoin boundary somewhere. Spread at that boundary is a plausible line and is not claimed, because the on/off-ramp is not built and because the licensing question above applies again.
• Selling data. The ledger is public and the scanner indexes it. There is nothing proprietary to sell, and selling payment metadata would contradict the rest of the positioning.
• A token. There isn't one, and none is proposed.

The dependency chain, in order

Revenue is gated on things that are not commercial decisions. In dependency order:

1. Real distribution. Four nodes, four providers, more than one jurisdiction — the designed topology, actually deployed.
2. Real confidential compute. SEV-SNP hardware with attestation enforced, replacing MOCKCVM, and the known hardening items closed.
3. Mainnet. Everything above is a precondition for handling value that exists.
4. Metering and billing. No fee is computed or accrued on-ledger today — see Pricing. varnirFee is a field that stays "0". Charges are in credits instead: Varnir.Plans holds each identity's credit balance and sells plans for credits, and withdrawals and wallets take their credits on the ledger. Buying credits is not built. Subscription pricing and How credits work set out the model and where the build is.
5. A rate mechanism that can go down. Varnir.BPMod and depositFeePercent are still deployed but drive nothing — the deposit contract no longer applies any uplift, because it no longer computes a fee at all. Volume-tiered pricing of any kind needs a live rate mechanism to exist first, on-ledger or off.
6. The verification layer. The highest-value item and the least built — the two-key form runs, and everything past it is design.

Steps 1–3 are infrastructure work with known scope. Step 6 is a product that has a foundation and not much else. That ordering is the honest shape of the thing: the revenue model is credible, and it is downstream of a substantial amount of engineering that has not happened yet.

Next

• Pricing — the same layers as example rates, with what the settlement contracts actually charge today (nothing) described in full.
• How Varnir compares — the same argument tested against what comparable companies publish, including the ones already running the parts of this dependency chain that Varnir has not built.
• Distribution and jurisdiction — the deployment gap that steps 1 and 2 above refer to, stated without hedging.