Designing a fee model that doesn't tax small commissions to death

When we sat down to design Njord’s fee model, we had a constraint that the existing affiliate networks did not: the protocol had to make economic sense for a $0.40 commission as well as a $400 commission. That single requirement closes off most of the answers that existing networks use, because the existing networks were built when the cost of processing a single payout was high enough that small commissions were not worth chasing.

This post is the design walkthrough — what we tried, what we ruled out, and what we ended up with.

What the existing fee models look like

There are three patterns in the existing market:

Percentage of commission. This is what the major affiliate networks do — Impact, CJ, Rakuten Advertising. The network takes between 15% and 30% of every commission as their fee. A $100 commission becomes $70–$85 to the affiliate, and the rest is the network’s revenue. The percentage scales with the commission, so the small case (a $1 commission becomes $0.70–$0.85 to the affiliate) is technically supported, but the network’s margin on that transaction is too small to be worth the manual review and payout overhead, so small commissions are often just declined.

Fixed SaaS subscription plus per-conversion fee. This is what affiliate-tracking plugins like Rewardful and Tapfiliate do. The merchant pays $50–$300 a month for the tracking plugin and the network’s piece is fixed regardless of commission volume. This pattern works fine at scale — a $200/month fee against $20,000/month of commission volume is 1% — but it is hostile to merchants who want to test the waters with a small program because the floor cost is fixed.

Transaction-fee-per-payout. This is what direct payment rails (PayPal Mass Payout, Wise, Stripe Connect) do when used as affiliate payout rails. The fee is roughly $0.25–$2 per payout depending on the rail and the currency. This is the model that forces 30-day batching: paying $1 in fees on a $2 commission is unworkable, but paying $1 in fees on a $200 batched payout is fine.

All three are reasonable answers to “how do you process affiliate payouts cost-effectively” given legacy rails. None of them are reasonable answers if your protocol’s per-attribution chain cost is $0.00025.

The constraint set we worked from

We wrote four constraints down at the start:

1. The fee at $1 commission should be no more than 10% of the commission. (So small-commission programs are still worth running.)
2. The fee at $100 commission should be competitive with the best percentage-of-commission networks. (So enterprise programs do not pay a premium for the new rail.)
3. The fee at $10,000 commission should not be punitive. (So large enterprise deals are not penalized.)
4. The bridge operator running the fiat rail should earn enough from the bridge fee to be commercially viable across the regions we care about.

Constraint 1 ruled out fixed-fee models. Constraint 2 said the percentage had to be in the low-single-digit range, not the 15–30% range. Constraint 3 said the percentage should not increase with commission size. Constraint 4 told us the bridge fee should be a separate line item from the protocol fee, because the bridge has real fiat-processing costs that the protocol does not.

The 2.5% + 1% answer

We landed on a 2.5% protocol fee plus a 1% bridge fee, both expressed as a percentage of the commission. That is a 3.5% combined fee at every commission size, which is meaningfully better than the 15–30% the major networks charge, and competitive with the floor of the SaaS-plugin pattern at any meaningful volume.

The breakdown on a worked example:

Customer purchases a $100 product at 10% commission
  Commission gross:        $10.00
  Protocol fee (2.5%):     -$0.25
  Bridge fee (1%):         -$0.10
  Affiliate receives:       $9.65

That ratio holds at any commission size. A $1 commission becomes $0.965 to the affiliate; a $10,000 commission becomes $9,650 to the affiliate. The protocol does not penalize small or large transactions disproportionately.

Two more design choices to call out:

The protocol fee is governance-adjustable within a bounded range. The protocol governance can vote the protocol fee anywhere in the 0.5%–5% band. We picked 2.5% as the starting value because it covers the fee-distribution targets (treasury, staking, buyback) at sustainable network volume; we did not want to lock the network into 2.5% forever if the economics shift.

The campaign-creation fee is fixed in SOL, not percentage. Creating a campaign costs a flat 0.1 SOL to the treasury. This is a deliberate friction parameter, not a revenue source — it stops spam-campaign creation, and 0.1 SOL is small enough that any real campaign owner does not feel it.

Where the 2.5% goes inside the protocol

The protocol fee is not a black box; it splits three ways:

• 50% to Treasury — funds protocol development, ecosystem grants, audits, operations. Treasury spend is governance-approved.
• 30% to Staking Rewards — pays out to bridge operator stakers, weighted by processed volume and reliability.
• 20% to Buyback & Burn — tied directly to protocol fee revenue. The more volume the network processes, the more NJORD is bought from the market and burned. This is the deflationary pressure that, combined with the inflation schedule, targets net-neutral or deflationary supply after Year 3.

The interesting one is the 20% buyback. It is the lever that ties token-holder economics to protocol usage. If protocol volume doubles, buyback-and-burn doubles. If protocol volume drops, buyback drops. The token’s deflationary pressure is not a marketing promise; it is a function of actual fees collected.

Why bridge fees live with the bridge, not the protocol

The 1% bridge fee is a separate flow. It goes to the bridge operator who processed the fiat side of the transaction. We split it out of the protocol fee on purpose, because bridge operators have real, variable per-region costs (card-acceptance costs, payout-rail costs, KYC obligations) that the on-chain protocol does not.

The bridge tier system layers on top of the 1%: Bronze, Silver, Gold, Platinum tiers gate the daily volume a bridge can process based on the NJORD stake. The stake aligns the bridge’s interests with the protocol — if a bridge cuts corners on KYC or under-reports volume, its stake is at risk.

The practical effect is that the bridge is a separate market from the protocol. Multiple bridges compete in the same region; the campaign owner or affiliate can choose which bridge to use; the 1% fee is the bridge’s revenue line; the protocol does not get involved in setting bridge pricing or terms.

What we explicitly did not do

A few things we ruled out:

Tiered protocol fees by volume. We considered a “first $X of commission processed gets a discount” model and rejected it. It would have been a small-merchant subsidy, but it would also have introduced opacity into the fee math (the merchant has to track lifetime volume to predict their fee) and given the protocol governance a lever that is too easy to misuse.

Variable fees per category. We considered different fees for SaaS vs digital content vs physical goods and rejected it for the same reason — too many moving parts, too much opportunity for governance capture. One protocol fee, one bridge fee, both percentages of commission.

Subsidising the bridge from the protocol fee. We considered moving some of the 1% bridge fee into the protocol pool and letting governance subsidise high-volume bridges. We rejected this because it would have made the protocol implicitly responsible for bridge profitability, which is not a position we want the protocol governance to be in.

How to know if this fee model is right for you

If you run a SaaS company with a small affiliate program today and you pay an existing network 15–20% of commission, the math is straightforward: Njord is cheaper. The break-even is around 3.5% combined network take.

If you run a large affiliate program with a high-touch account manager relationship, the fee math still favours Njord but you need to consider the unbundled overhead. The protocol does not provide a dedicated AM. If that relationship is mission-critical, the existing networks earn their cut on the service layer that Njord does not replace.

If you are building a program that is only economic at fee rates below 5% — micropayment-scale affiliate flows, AI agent attribution, per-action creator commissions — then Njord is one of the only protocols where the math closes. The legacy rails simply cannot offer 3.5% combined at any volume.

The numbers are in the protocol. They are governance-adjustable within published ranges. They are the same for everyone. Read the tokenomics page for the full breakdown, and the GitHub repo for the Anchor source that enforces them.