The user's chain selection is the only routing decision tknz ever makes. Solana orders are routed exclusively to DFlow. EVM orders are routed exclusively to Li.Fi. The two engines never overlap — Li.Fi is never invoked for Solana, and DFlow is never invoked for any EVM chain.
On EVM, the interface fee is passed to Li.Fi as fee: 0.0015 (a float, not basis points). On Solana, the same fee is passed to DFlow as platformFeeBps: 15 (an integer in basis points). EVM fees accumulate in Li.Fi's on-chain fee collector and are claimed periodically; Solana fees land in the configured fee account on every swap.
Both engines surface price improvement structurally — embedded in the toAmountthe user sees in the quote. There is no separate rebate cashflow, no offset meter, and no savings badge. The number you see is the number you receive.
Solana transactions return as base64-encoded VersionedTransactions; the client deserializes, signs with the connected wallet, and broadcasts. EVM transactions are executed via Li.Fi's SDK using the connected wallet client. tknz never holds or signs on behalf of the user.
EVM token approvals are constrained to the exact swap amount via Li.Fi's default behavior. tknz does not request unbounded ERC-20 allowances and does not override the SDK's approval safeguards.
See .env.local.example. DFLOW_API_KEY is server-only and must never be prefixed NEXT_PUBLIC_. LIFI_INTEGRATOR must match the string registered at portal.li.fi exactly.