Pricing
Varnir is on public testnets. Its charges are in credits, which the testnet hands out free from a button; see How credits work. The per-transaction pricing below shows how the rail could otherwise be priced, so you can check the economics before building. It is not an offer or commercial terms; those will be set by contract.
Why this matters
If you are deciding whether to build on Varnir, this section tells you what it would cost and what it costs today. The short version: moving value between Varnir accounts, and trading on the exchange, cost nothing, because they settle on Varnir's own ledger with no chain gas. The only thing priced is money leaving for an outside chain, where Varnir pays real gas, and wallets added after sign-up. Those cost credits at a listed price per action, not a cut of each payment; a monthly plan (Lite, Hobbyist, Trader or Enterprise) lowers the wallet prices and raises the limits. On the testnet, credits come free from the web wallet's testing button.
What is real: no on-ledger fee runs today
The settlement layer takes no Varnir fee on a deposit, an L2/inbound
transfer, or a withdrawal — on any transaction, today. Varnir.Deposit and
Varnir.CryptoTransfer do not deduct anything from the credited amount.
varnirFee stays as a field on streams and API responses, for readers that
already expect it, and it is always "0" on a new transaction. (An in-flight
presign made before this shipped can still carry whatever it was signed with
under the old rules — that is a leftover from before the change, not a new
charge.)
Withdrawals still touch real L1 gas, and that part is not free — it is just not a Varnir fee:
- Native withdrawals (ETH, TRX, tBNB, POL) pay gas in the same asset being
withdrawn, on top of the amount: the recipient gets the full amount,
and the sender's balance must cover the amount plus the gas. A gas hold is
taken at presign — a price/limit envelope, not a charge — and settled once
at confirm: the sender pays
min(actual gas, hold)in-kind, whatever is left over on the hold is released, and the amount charged is never negative. - Token withdrawals (USDT, or a user-added token) pay gas in the network's native asset, which the withdrawal itself doesn't hold. Varnir fronts that gas from its own pooled wallet. The user's balance in the token being withdrawn is debited for the withdrawal amount and nothing else — no fee, no native-asset deduction.
- Any failure, on either path — a revert, an out-of-gas, or a failure
before the transaction is even included — refunds the user in full: the
whole hold, nothing kept back. Whatever gas was actually burned (and any
gas spent cancelling) is booked as Varnir's own cost,
.fees.deductible— accounting for what settlement cost Varnir, not a fee charged to anyone. - Each withdrawal also records an outcome —
sent,failed-on-chain, orfailed-before-inclusion— alongside its network and asset. That field exists so a future, off-ledger billing system can read it; no such system reads it yet.
The chargeable flag you can still see on a token in listTokens() (from
Varnir.TokenRegistry) is a legacy label. It no longer drives any fee
decision in the contracts.
Billing on top of this is plans and credits, never a deduction inside a
settlement transaction — see Subscription
pricing and How credits
work. Where that stands in code: Varnir.Plans holds
each identity's credit balance and sells plans for credits, with auto-renew;
withdrawals and wallets added after sign-up take their credits on the
ledger, in the same transaction as the action. On the testnet, credits come
from the web wallet's testing button; buying credits is not built.
Illustrative pricing
Everything from here on is an example structure, not a commitment.
Since 2026-10-17 credits are the only pricing unit. A plan is bought monthly with credits and includes none; it buys discounts and higher limits. Each charged action, such as an L1 withdrawal, costs its listed credits. The plans are on Subscription pricing, the model on How credits work, and every price on the homepage. The per-transaction layers below are the alternative that model was weighed against; where the two differ, credits are the current pricing.
The design principle behind it: charge on the axis where Varnir actually bears cost or actually differentiates, and charge nothing on the axes where it does neither. Four layers fall out of that, and they map onto four different things the system does.
1. Settlement — basis points on value received
An example structure for a per-transaction model — these volume bands are not
the subscription plans, and not the mechanism in code today (see above): a
per-transaction fee deducted on-ledger at credit time is the shape
Varnir.Deposit and Varnir.CryptoTransfer were originally built for, but
neither deducts anything now:
| Monthly settled volume | Example rate | Example minimum |
|---|---|---|
| Under €100k | 25 bps | €0.20 |
| €100k – €1M | 15 bps | €0.15 |
| Over €1M | 8 bps | €0.10 |
| Sustained high volume | Below 8 bps, negotiated | By agreement |
Charged to the receiving business, deducted at credit time, if this shape is
ever built out — the declining-with-volume tiers are what the (also disabled)
Varnir.BPMod rate hook was written for. Subscription
pricing explores a different shape for the
same idea: metering after the fact instead of deducting on-ledger.
The floor is the load-bearing part, not the bps. Whatever the percentage, a per-transaction minimum has to cover an L1 interaction, and on Ethereum that is a variable cost Varnir does not control.
For context on where these example numbers sit: card acquiring is typically 150–300 bps plus a fixed item fee, and correspondent-banking wires carry flat fees measured in tens of euros regardless of amount. A stablecoin rail's structural advantage is that it is closer to the cost of the chain interaction than to either of those. An illustrative 8–25 bps reflects that, and is not a claim about what any competitor charges.
2. The key method as a priced axis
Two key methods exist and they cost genuinely different amounts to produce. Standard is Shamir 3-of-4 across the node quorum. Advanced is two-party threshold ECDSA with 2048-bit Paillier, where the private key is never assembled anywhere, and each party's share is then Shamir-split across the quorum again.
The cost difference is real and already visible in the architecture: MPC-TSS keys run as a separate, smaller pre-generated pool that refills in smaller batches, precisely because they are expensive to produce. Wallets are generated ahead of demand, so an unclaimed MPC-TSS wallet is inventory Varnir has already paid to create.
An example structure:
| Standard | Advanced (MPC-TSS) | |
|---|---|---|
| Wallet creation | Free | Example: €5–15 per wallet, or bundled into a plan |
| Ongoing | Included | Example: a per-wallet monthly line |
This is the one axis where the pricing argument is not "we incur a cost" but "this is a materially better way to hold keys than the alternative and it is worth something." Whether a buyer agrees is a real commercial question, and Distribution and jurisdiction is candid that the deployment does not yet deliver the separation the protocol is capable of. Until it does, this tier is worth less than it will be.
3. Platform — the plan tiers
Invoices, webhooks and the scoped keys that authenticate them are built, and they are the parts an integrator uses most. Rather than a separate SaaS price list, these are gated by the plan tiers in Subscription pricing — Free, Lite, Hobbyist, Trader and Enterprise — which set limits such as pending invoices, deposit callbacks, AI agents and support level. The limits are on the homepage.
Two honest notes. First, this layer is the least defensible of the four — invoicing and webhooks are commodity, and nothing here is hard to replicate. Second, a plan boundary is only enforceable if it is metered, and today the invoice API does not count against a quota. Charging for this would mean building the metering first.
4. Treasury verification — the layer that is mostly not built
The introduction states the direction plainly: an AI agent proposes a payment, independent verifying agents check it against policy, and only an approved proposal becomes a settled transaction. Today the smallest form of that exists — one proposing key, one confirming key, enforced on the ledger. The multi-verifier form, where more than one confirmer has to agree, does not exist. Nothing in these docs describes it as available, and this page does not either.
If it is built, it is the layer where pricing stops being a commodity question, because it is the layer where the customer is buying a control rather than a transfer. An example structure:
| Line | Example basis |
|---|---|
| Policy seats | Per verifying agent under management, per month |
| Verified payments | Per payment that passes through the approval flow |
| Policy complexity | Higher tier for multi-party approval, spend limits, counterparty allow-lists |
| Audit export | Signed, timestamped approval trails for compliance |
The reason to state this now, even unbuilt, is that it explains why the settlement bps in section 1 can be low. Bps on a stablecoin rail compress toward the cost of the chain interaction over time; that is what happened to every payment rail before it. A verification and policy layer does not compress the same way. See How the network makes money for that argument in full.
What would stay free
An example structure only means something alongside what it excludes. In this one:
- Identity onboarding and wallet claiming. Already free, and the code shape makes it awkward to charge for — claiming a wallet id is an unauthenticated read, and ownership is established by a transaction you sign yourself.
- The SDK.
@varnir/chain-client. - All reads. The scanner, the public API, deposit and transaction history.
- Consumer transfers. Non-business identities moving value between themselves. This is already how the contracts behave.
- Trading on the exchange. Free in v1, deliberately — see exchange pricing for what might change and why.
- Deposits. $1 or $1M, always credited in full, never refused, and nobody is charged for the sweeps that follow. See Deposits and sweeps are free and How sweeps work below.
- Testnet, entirely. For as long as this is a testnet.
Deposits and sweeps are free
Deposits are free. Depositing $1 or $1M costs nothing: every deposit is credited in full, never refused, with no minimum. And nobody is charged for a sweep, the step where Varnir gathers deposited tokens into its pool before sending them out on-chain. Sweeps are Varnir's cost, not yours.
Varnir decides when to sweep (how sweeps work). Trading never triggers a sweep and never pays for one. Deposits of a network's own coin (ETH, TRX, BNB and so on) never cost a sweep, and nor does Bitcoin.
Two limits keep that sustainable.
Wallet limits. Today's plans cap wallets per network as the plan cards show: Free 1 standard wallet, Lite 1 advanced, Hobbyist 25 standard and 1 advanced, Trader 100 standard. With the new pricing, a sweep costs Varnir most on Tron, so the cap moves to one limit per network, set against Tron and the same on every network, with standard and advanced wallets counting together.
| Plan | Wallets per network, new pricing (planned) |
|---|---|
| Free | 1 |
| Lite | 2 |
| Hobbyist | 5 |
| Trader | 25 |
| Enterprise | By contract |
An extra wallet will be an add-on at 130 credits a month. Retiring a wallet is free, and its place comes back at your next renewal, so opening and retiring wallets can't be used to get round the limit. Retiring an add-on wallet ends its charge from then too.
Single-use invoice addresses (invoices only, planned). If you want a new address for every payment, give the invoice its own address instead. An address that is never paid costs nothing on-chain, so you are charged only for the network the customer actually pays on, at settlement, on top of the usual invoice prices: about 250 credits on Tron, 10 on Base, Arbitrum, Polygon and BSC, and gas-based on Ethereum. The sweep is included. These addresses are swept whatever they hold, then retired, and they sit outside the wallet limit.
Planned, not enforced. The new
wallet limits are not built yet. Single-use invoice wallets are built and
priced in credits (How credits work). The
design is in the consolidation spec
(docs/superpowers/specs/2026-10-10-consolidation-design.md, sections 4.3.2,
4.3.2a and 4.5.2) and the decision file
docs/decisions/2026-10-13-credits-token.md. The new wallet limits and the
single-use address prices belong to the planned new pricing.
How sweeps work
Why a sweep is needed. A transfer on the Varnir ledger moves a balance, not coins: the USDT behind it stays in whichever pool wallet received it. After a while the coins that back one balance can sit in several deposit addresses, and a payout out to a chain needs them in one place. Gathering them is a sweep.
Varnir decides when. An address is swept only when two things are true: it holds enough to be worth it, about 50 times the sweep's own gas, and the pool needs that liquidity for payouts. If the pool already holds enough for the next payouts, nothing is swept, and small deposits simply wait.
Why waiting batches deposits into one sweep. A sweep waits about 12 hours after a deposit and happens at least 24 hours after the last sweep of the same address. One sweep collects everything the address has received since, so ten payments to one address in a day are one sweep, not ten.
Why it may never happen. If a payout is sent from the address the coins are already in, or the coins never leave Varnir, there is no sweep.
What trading does. Nothing. Trading never triggers a sweep and never pays for one.
Why native-coin deposits never count. A network's own coin (TRX, ETH, BNB, POL) pays its own way: moving it needs no energy rental or gas top-up, so sweeping it costs Varnir almost nothing.
Why Bitcoin never counts. Bitcoin works differently: a payout can draw on many wallets at once, so there's nothing to sweep. Bitcoin deposits never cost a sweep.
What you see. Usage & Billing shows your credits and your token deposits against the month's cap. A deposit's detail line shows when it was swept and with how many other payments, or "not swept yet". Past 80% of a cap you get an email, the same as for credits. The phone app shows the counts only.
All of this is planned: nothing is charged or held today.
Where this leaves you as an integrator
If you are sizing up whether to build on this: no on-ledger fee mechanism runs at all, on deposits, transfers, or withdrawals. Native withdrawals still cost you real L1 gas, paid in-kind from the same coin on top of the amount sent; token withdrawals cost you nothing on-ledger, because Varnir fronts that gas (to be recovered through credits once they are charged). Nothing you build today will incur a Varnir charge, and if billing ever starts it will be off-ledger and metered after the fact — see Subscription pricing for the direction being explored — or announced as commercial terms, rather than appearing as a silent deduction on your ledger streams.
The thing to model before you build, for now, is L1 gas on native withdrawals — the one place a real deduction still happens, and it scales with the chain's own gas price, not with anything Varnir sets.
Under the subscription model the thing to model is different: L2 transfers and swaps cost 0 credits, and what you pay for is L1 withdrawals, in credits set by network, asset and payout speed. How credits work explains how that splits between the network fee and the credit charge.
Next
- Subscription pricing — the current plan tiers, credits and withdrawal costs, now that no fee runs on-ledger.
- How the network makes money — the same material from the business-model side: where revenue would accrue, what it has to cover, and which layers are defensible.
- How Varnir compares — what other stablecoin settlement companies actually publish as their pricing and custody model, sourced and dated, including the axes where Varnir is behind.
- How keys are held — what the key-method tier above is actually pricing.
- How credits work — the credit model on one page: what costs credits, and native versus token withdrawals.