Exchange pricing — potential models

Exchange v1 is free

There are no swap, fill or matching fees today. The pricing below is a possible future model, shown for illustration only.

Where a fee would plug in

Varnir.Fees / Varnir.FeeWithdraw still exist as contracts, but nothing accrues into them: no deposit, transfer or withdrawal takes an on-ledger Varnir fee today — see Pricing. An exchange fee is not reusing a live mechanism; it would be building one, in the same shape those now-dormant contracts were built for:

• A swap or resting-order fill (Varnir.Swap's swap / fill entries) moves value through the exact same layer2[network][token] partitions that transferOnLedger does. If an on-ledger exchange fee is ever built, the natural place for it is that same accrual shape, applied to one (or both) of a trade's legs instead of a single transfer's one leg.
• An on-ledger fee accrual — deducted from the credited amount as part of the atomic settlement transaction — is one option; an off-ledger, credit-metered charge like the one explored in Subscription pricing is another. Neither is built for the exchange.

Today, Varnir.Swap charges nothing, and nothing else on the ledger does either. Wiring any fee path to the exchange is unbuilt work, not a flag to flip.

Candidate models

Six shapes worth naming, each with a different answer to "who pays, and for what?" Numbers like "5–30 bps" are there to make a shape concrete, not to propose a rate.

1. Taker fee — bps of notional

The taker (whoever fills a resting order, or whichever side of a live co-signed swap is treated as the aggressor) pays a small percentage of the trade's value, e.g. 5–30 bps.

• Pro: simple, proportional to value moved, and mirrors how most exchanges and card rails charge — easy for an integrator to model.
• Con: on Varnir's exact-counterpart full-fill model (today), "taker" is just whoever submits the fill transaction — there is no separate maker/taker asymmetry in cost yet, so the label is more about who initiated than who benefited.

2. Maker rebate / maker-taker split

The taker pays a fee; some or all of it is rebated to the maker whose resting order supplied liquidity. Common in traditional exchanges to encourage resting orders over aggressive ones.

• Pro: directly incentivizes makers to post resting orders — which is the thing Varnir needs most while it has no internal volume — rather than everyone waiting for an immediate external-DEX fill.
• Con: more moving parts (two legs of accounting instead of one), and its value depends on there being enough flow that makers actually compete on price; with thin books it is more machinery than benefit.

3. Spread capture

Instead of a visible fee line, the matcher (or a market-making pool wallet) prices two sides of a trade slightly apart and keeps the difference — the way a traditional market maker earns.

• Pro: no visible per-trade fee for the user to reason about; can be tuned continuously rather than in discrete tiers.
• Con: requires Varnir (or a pool wallet) to actually take the other side of trades, which is a different risk profile than pure routing — it starts to look like Varnir holding inventory, which cuts against the "aggregator, not a liquidity provider" framing of the exchange design. Least aligned with the current design, where trades settle only on users' signatures and Varnir holds no inventory.

4. Flat per-trade fee

A fixed amount per swap or fill, regardless of size — e.g. a flat fee denominated in a stablecoin leg, similar in spirit to the illustrative per-deposit minimum described in Pricing.

• Pro: simplest possible model; predictable for high-value trades.
• Con: the same problem any flat floor has — proportionally brutal on small trades and invisible on large ones. Not a natural fit for a market that wants to attract both agent-sized micro-trades and larger transfers.

5. External-DEX-routed markup

A fee only on fills that route through an external DEX (the aggregation path in the exchange design), charged as a small markup over the external venue's quoted price — e.g. the user's signed slippage floor is set at "external quote minus 10–20 bps" and Varnir keeps the difference between the floor and what the pool wallet actually achieves.

• Pro: the most naturally justified of the six models, because that path is the one that actually costs Varnir real money — L1 gas for the pool wallet's swap transaction, plus the operational and review burden of a money-critical delegated executor. Internal L2 matches, by contrast, cost nothing to run.
• Con: only monetizes the fallback path, not the instant/free internal book — which may be exactly the point (charge where there's real cost; leave the cheap path free) or may be too narrow a base to fund the platform on its own. See How the network makes money for the broader argument about why transaction fees alone rarely carry a rail's economics.

6. Subscription / volume tier for integrators and agents

A flat monthly fee, or a volume-tiered plan, for high-frequency integrators or autonomous agents that trade often enough that per-trade fees would be noisy — mirrors the plan tiers (Free, Lite, Hobbyist, Trader, Enterprise) that already gate invoices, webhooks and agent keys.

• Pro: predictable for both sides; fits agent-driven trading, where an agent might fire many small orders and a per-trade percentage fee would be awkward to reason about or budget for.
• Con: requires usage metering for trade volume that does not exist yet (the same gap Pricing already flags for invoices and API keys — a plan boundary is only enforceable once it's metered).

The fee-leg question

Every one of the models above still has to answer a more basic question: which side, and which asset, actually pays?

• Today's exact-counterpart full-fill model makes this simple. A swap or a full-fill settles both legs completely in one atomic transaction — there is no leftover partial amount to account for, so a fee, if one is ever built, only has to be deducted from one or both of the two amounts already being credited — the same accrual shape Varnir.Fees was built for, even though it deducts nothing today.
• Partial fills (a follow-up, not yet built) complicate it. Once a resting order can be filled across multiple takers at different times, a fee has to be computed per fill-slice rather than once against the whole order, and the maker's originally-signed rate has to still hold after the fee is taken out — otherwise the maker receives a worse effective price than they signed for. This is the same "immutable stored terms" property the design doc leans on elsewhere, and a fee model has to respect it rather than erode it after the fact.
• Chargeable-token asymmetry. The chargeable/non-chargeable asset split the old deposit and transfer fee logic used (see Pricing) is still visible on the token registry, even though nothing reads it for a fee decision anymore. A swap with one chargeable leg and one native leg (e.g. TRX for USDT) raises the question of whether a future exchange fee would come out of the chargeable leg only, or whether it needs its own, broader chargeable-asset rule.

None of this is decided. It is here because it is a real question any fee model has to answer up front, not a detail that can be sorted out afterwards.

Cost-of-operation drivers to weigh before pricing

Before assigning a number to any of the models above, the same reasoning How the network makes money applies to settlement generally applies specifically to the exchange:

Driver	Why it matters for exchange pricing
L1 gas for external routing	The pool wallet's swap transaction on an external DEX router is a real, variable L1 cost — the strongest argument for model 5 (external-routed markup) above.
L1 gas for withdrawals	Any credited want-asset eventually leaves L2 via send, carrying its own gas cost, independent of the swap itself.
Faucet / gas sponsorship	Pool wallets need funded gas reserves to execute delegated swaps at all; that reserve is itself an operating cost, same as it is for withdrawals today.
Infra (gateways / nodes)	The matcher runs in minigate, fanned out across the node quorum — roughly fixed cost, not scaling with trade count.
Internal L2 matches cost nothing to run	A resting-order fill or a co-signed swap that settles internally touches no chain, pays no gas, and costs Varnir nothing beyond the fixed infra above — a genuine commercial advantage over a rail that has to route every trade externally, and the strongest argument for keeping the internal path free even if an external-routed fee is eventually added.

Regulatory note

Charging a fee on a swap does not, by itself, change how this exchange settles: the pool still only ever executes within a user's signed bounds, proceeds still land on the user's own L2 stream, and KYC still sits with the third-party fiat ramp rather than with Varnir.

Adding any fee can still shift a regulatory analysis — a paid service can read differently than a free one under some frameworks, and a fee on the external-DEX path makes Varnir, on that path, an intermediary earning from executing a trade on a client's behalf. This page does not assert a fee is compliant; see the MiCA position for the equivalent question on settlement, and get independent counsel before treating a fee model here as settled.

Next

• Pricing — what deposits, transfers and withdrawals actually charge today (nothing on-ledger) and the illustrative model an exchange fee would follow if it is ever built.
• How the network makes money — the broader argument for why transaction fees alone rarely carry a rail's economics, applied above to the exchange specifically.
• Subscription pricing — the platform/subscription tier this page's model 6 mirrors.
• The MiCA position — the regulatory framing an exchange fee has to be checked against before it is anything more than a design note.