How Omniston Handles Referral Fees for Integrators
Omniston, TON's liquidity aggregation protocol, lets wallets, trading interfaces and bots earn revenue on swaps they route through it. Integrators attach a referral address and fee rate to the quote request; Omniston bakes that fee in before resolvers compete, so the rate is locked before the trader signs.
Post image
Setting It Up
Two fields carry the fee: referrer_address (the TON wallet to be paid) and referrer_fee_bps, where 1 bps equals 0.01% — 10 bps is 0.1%, 50 bps is 0.5%. SDKs use referrerAddress/referrerFeeBps; the Widget mirrors these fields.
Quote to Settlement
1. Trader picks assets and amount.
2. App requests a quote with referral data attached.
3. Resolvers compete, fee already priced in.
4. Trader signs the winning quote.
5. The winning liquidity source settles the fee.
Why Route Matters
DEX v1 pays a fixed 0.1% instantly in the swap. DEX v2 supports 0.01%–1%, but fees accrue in per-token vaults claimed manually or via SDK. DeDust, Tonco and CoffeeSwap pay TON instantly but hold jetton fees in separate vaults needing on chain calls. Escrow uses its own distinct vault contracts entirely.
Flexible Fees
flexible_referrer_fee, off by default, lets Omniston lower never raise your fee so a better-priced v1 route can still win when your requested rate exceeds v1's 10 bps cap.
Tracking Revenue
Wallet balances alone miss vault-held fees. STON.fi's API covers DEX v2 vaults only; DeDust, Tonco, CoffeeSwap and Escrow fees need on chain checks or custom indexing until a unified API arrives.
The Real Choice
A strict rate gives predictable revenue but can exclude the best v1 route. Flexible fees protect execution quality while still paying the route's maximum. Strict rate or flexible fee which better serves your users?
#BTC $BTC $BASE
Omniston, TON's liquidity aggregation protocol, lets wallets, trading interfaces and bots earn revenue on swaps they route through it. Integrators attach a referral address and fee rate to the quote request; Omniston bakes that fee in before resolvers compete, so the rate is locked before the trader signs.
Post image
Setting It Up
Two fields carry the fee: referrer_address (the TON wallet to be paid) and referrer_fee_bps, where 1 bps equals 0.01% — 10 bps is 0.1%, 50 bps is 0.5%. SDKs use referrerAddress/referrerFeeBps; the Widget mirrors these fields.
Quote to Settlement
1. Trader picks assets and amount.
2. App requests a quote with referral data attached.
3. Resolvers compete, fee already priced in.
4. Trader signs the winning quote.
5. The winning liquidity source settles the fee.
Why Route Matters
DEX v1 pays a fixed 0.1% instantly in the swap. DEX v2 supports 0.01%–1%, but fees accrue in per-token vaults claimed manually or via SDK. DeDust, Tonco and CoffeeSwap pay TON instantly but hold jetton fees in separate vaults needing on chain calls. Escrow uses its own distinct vault contracts entirely.
Flexible Fees
flexible_referrer_fee, off by default, lets Omniston lower never raise your fee so a better-priced v1 route can still win when your requested rate exceeds v1's 10 bps cap.
Tracking Revenue
Wallet balances alone miss vault-held fees. STON.fi's API covers DEX v2 vaults only; DeDust, Tonco, CoffeeSwap and Escrow fees need on chain checks or custom indexing until a unified API arrives.
The Real Choice
A strict rate gives predictable revenue but can exclude the best v1 route. Flexible fees protect execution quality while still paying the route's maximum. Strict rate or flexible fee which better serves your users?
#BTC $BTC $BASE
