Skip to main content

Subscription pricing: plans bought with credits

Varnir sells plans, not a fee on each send. A plan is bought every 30 days with credits, from your credit balance on the ledger. It includes no credits. It buys discounts, higher limits and, once payout speeds ship, faster payouts. Every charged action then costs its listed credits. The homepage lists every price.

Why this matters​

For a business, the point is a predictable bill. Payments and trades between Varnir accounts are free. You pay in credits only for what costs Varnir real money outside the ledger, such as a withdrawal to a blockchain or a new wallet, and a plan lowers those prices. Nothing is billed after the fact: each charge is taken from your balance as the action happens, and an action your balance can't cover is refused, never run up as a debt.

The plans​

TierCredits a monthDiscount on wallets and invoices
Free00%
Lite50010%
Hobbyist2,90020%
Trader19,90030%
  • Free has no fee and the base limits. Every action is at list price.
  • Every plan gets 400 free credits a month as a launch promotion, spent on withdrawals and wallets before your balance (see How credits work).
  • Lite, Hobbyist and Trader take their price from your credit balance every 30 days. Each adds its discount and higher limits. Their payout-speed perks (Hobbyist's 1-hour payouts at the 24-hour price, Trader's instant payouts at the 1-hour price) arrive with speed-based delivery, which is not built yet.
  • Enterprise is priced by agreement with each customer; see below.

The plan limits (wallets per network, open invoices and orders, CSV export history, AI agents and others) are on the homepage. Pending invoices, open orders, CSV export and wallet claims are checked when something is created, from the table in packages/plan-limits; a refusal is HTTP 403 with code: "plan_limit". On the testnet the wallet caps are lifted, because each wallet added after sign-up costs credits on the ledger.

Buying a plan​

  • Subscribe from the web wallet's billing page. The plan's price is taken from your balance and a 30-day period starts. If the balance is short, the ledger refuses it and nothing changes.
  • Price protection. The transaction names the price you confirmed, and the ledger refuses it if the price has gone up since.
  • Moving up mid-month charges the new plan's full price and starts a fresh 30-day period, with no part-month maths. If you had already paid for the next month, that payment is refunded first.
  • Moving down: in the last 7 days of the month, renew to the lower plan. It starts when the current month ends.

Renewal​

  • Auto-renew is on by default. In the last 24 hours of the period, the next month's price is taken from your balance, and the new month starts when the current one ends. Varnir's gateways do this when their plan-reminder job is switched on (PLAN_REMINDERS_ENABLED, with PLANS_CONTRACT and PLANS_CONFIG_STREAM set); without it, the plan isn't renewed and drops to Free at the end of its month.
  • You can renew by hand from 7 days before the period ends.
  • If the price goes up, auto-renew agreed to the old price, so it stops. The renewal warning says so, and you renew by hand to accept the new price.
  • Turning auto-renew off lets the plan run to the end of its month, then drop to Free. A month already paid for is not refunded.

Emails​

  • 7 days before the period ends: what will be taken, from which date, and your current balance. It says plainly if the balance is short, if auto-renew is off, or if the price has risen.
  • When auto-renew takes a renewal: a short note that the next month is paid.
  • When a plan ends without a renewal: a short note that it is now Free.

They go to your recovery email or, failing that, your verified notification address, and need the gateway's email settings (RESEND_API_KEY, PLAN_MAIL_FROM). Each gateway sends each email at most once per period; if more than one gateway is tracking your plan, you can get a copy from each.

When the balance is short​

There is no grace period. If the balance can't pay the fee when it is due, the plan drops to Free that day. Paid perks stop, and nothing new that needs a paid plan can be added. Your wallets, balances, deposits, withdrawals, API keys and AI/SDK access keep working within Free's limits. Withdrawals beyond the month's 400 free credits cost credits as usual. Nothing is frozen: ledger transfers stay free, and a withdrawal is never blocked by the plan itself. It needs enough credits for its cost, counting the month's free credits (on the testnet, the daily testing button gives credits).

Where the build is​

  • Built, on the testnet: the credit balance and its history; plans bought and renewed with credits, auto-renew and price protection (Varnir.Plans); credits taken for withdrawals (Varnir.CryptoTransfer, refunded by Varnir.ConfirmWithdraw when a payout fails) and for wallets (Varnir.AssignOwner, Varnir.Create); the 400 free credits a month; the renewal emails; the testnet credits button.
  • Not built: buying credits (top-ups) and top-up bonuses; monthly add-ons; "free next month after enough use"; charges for invoices, the exchange taker fee, automatic payments, names, SMS, social recovery and the other actions on the homepage's price list; payout speeds and the plan speed perks; the low-fee payout queue; the 6-hourly weights job; sub-plans; annual billing.
  • Production charges nothing yet. Credits arrive there with top-ups.

Sub-plans: a plan for someone else (planned)​

Planned, not built

Sub-plans are designed, not built. Nothing in this section works today. The design is in the repository at docs/superpowers/specs/2026-09-27-sub-plans-white-label-design.md, and it was written before plans were bought with credits, so its details will change.

A Trader or Enterprise plan will be able to make another Varnir identity its sub and give it a plan of its own:

  • The parent sets the sub's limits: pending invoices, open orders, Standard and Advanced wallets, CSV export history and payout speeds. What the parent hands out, added up, fits inside the parent's own limits.
  • Trader: up to 5 subs, managed in the web wallet.
  • Enterprise: unlimited subs, a management API and branding. This is Varnir's white-label offering, sold under an Enterprise contract. See White-label.
  • One level only. A sub can't have subs of its own.
  • The sub agrees. The parent offers, and the sub accepts with its own key. Either side can end it, and the sub goes back to Free. Its open invoices, orders and wallets are never cancelled, and its funds are never locked.
  • Credits. Today each identity pays from its own balance. Shared credits between a parent and its subs are not built.
  • The parent sees usage counts, not money. Varnir's own wallet and API show a parent what a sub uses, not its balances or transactions, unless the sub shares them. Ledger records are readable today, so this is not a guarantee against someone reading the ledger directly.

Verified names​

Trader (and so Enterprise) would carry a verified name: once the name an identity has set is approved, a badge shows beside it — on its identity page and on every wallet it owns — so a counterparty who sees "Kraken" knows it is Kraken. The model is the old Twitter verified badge. Not built.

It verifies a name, not a person. Checking who someone is (KYC/KYB) is a regulated activity and is deliberately not what this is; the badge says "Varnir checked that this identity may use this name", nothing about the holder's standing. That keeps it inside the line Varnir holds everywhere: it describes how keys are held and makes no claim about regulatory status.

How a name gets verified (proposal):

  • Domain proof (default, largely automatic). The identity proves control of a domain — a DNS TXT record or a file at a well-known path on the domain, containing a statement signed by the identity's key. The verified name is then tied to that domain ("Kraken · kraken.com"), which is what makes it meaningful: anyone can type "Kraken", only Kraken controls kraken.com.
  • Manual review for names with no domain, or disputes — slower, by hand.
  • Re-checked periodically; a lapsed domain proof removes the badge.

Rules that keep the badge honest:

  • Drawn by the app, never typed. The badge is an icon rendered next to the name, outside the name text. Names may not contain check marks, seals or other badge-like characters (and emoji look-alikes are refused), or anyone could write "Kraken ✓" into their own name.
  • A name change drops the badge until the new name is verified.
  • Look-alikes are refused for verified names (mixed scripts, homoglyphs: "Krаken" with a Cyrillic а), not just exact duplicates.
  • Revocable, with a reason, and the plan lapsing removes it.
  • Where it shows: identity page, every wallet the identity owns, invoice pay pages ("Pay Kraken"), and search results. Hovering it says what was verified and how ("Name verified · controls kraken.com").

Icon: a check inside a scalloped seal (not a bare tick, which reads as "done" and is easy to imitate in text), in the brand accent, with the explanation on hover and in its accessible label.

Open: whether verification is a paid-tier perk or available to anyone for a fee; who reviews disputes; whether a parent's sub-plans inherit its badge (proposal: no — the badge belongs to one identity's name).

Enterprise: netting, and what surrounds it​

The agent guardrails are not an Enterprise feature. Ledger keys with per-key spend limits, co-sign thresholds and propose-and-verify — the roles an AI assistant works through — are on every tier, Free included, within that tier's limits. Enterprise is priced by agreement with each customer.

What Enterprise is for is below. None of it is built yet; each item is scoped with the customer, and the homepage footnote says the same.

  • Atomic netting (the lead). Offsetting flows settle together in one atomic step on the ledger, and only the net difference is sent to L1. It starts across a customer's own identities and accounts; the direction is across the businesses they trade with, so only the minimum amount needed settles on-chain. Every L1 transaction avoided is gas not paid, and less activity exposed on-chain.
  • Gross-to-net record. Netting hides the gross flows, but a business still has to prove every underlying obligation and know what was owed, paid and received — for its books and its tax. Every obligation that went into a net settlement stays on the ledger, traceable back from the amount that reached L1, so exact figures can go to the customer's accountants and tax advisers. This is the companion to netting, not an extra: netting without it is not usable by a business. (It is a record, not tax advice.)
  • Settlement on your schedule. Net positions settle to L1 in windows the customer chooses — daily, or per batch — rather than per transaction. Comparable: settlement cycles in Copper ClearLoop and CLS.
  • Private counterparty network. Trade and settle only with approved counterparties: a private order book, or request-for-quote between them. Comparable: the Fireblocks Network, BitGo's Go Network, Coinbase Prime OTC.
  • Signed proof of reserves. A signed attestation feed that the balances behind a customer's identities are held. An attestation at a point in time — not an audit, and not a guarantee.
  • Organisations and teams. Many identities under one organisation, single sign-on, roles, one consolidated view.
  • Accounting feeds and durable webhooks. Scheduled exports and accounting-tool integrations; retried, replayable event delivery.
  • Dedicated capacity and support. Reserved capacity, priority onboarding for the networks and tokens the customer needs, custom limits, and support on agreed terms (no SLA is implied here).

Next​