Blockchain selection: L1/L2 and commissions

1) What exactly we choose and why

• fees and rate of enrollment/withdrawal,
• availability of stablecoins/providers,
• infrastructure resilience and operational risks,
• KYT/Travel Rule and UX requirements (addresses, memos/tags).

2) Basic concepts: L1 vs. L2

L1 (base layer): own consensus and security (Ethereum L1, Bitcoin, Solana, BNB Smart Chain, TRON, etc.).
L2 (over Ethereum): scaling with legacy L1 security (Optimistic rollups: Arbitrum/Optimism/Base; ZK rollups: zkSync/Linea/Polygon zkEVM и др.).

• Finalization/confirmation: L2 gives fast UX, but final security binds to L1 (challenge/commit period for optimistic; validity-proof for ZK).
• Cost: L2 is usually cheaper than L1 (especially vs Ethereum L1).
• Conclusions on L1: optimistic - delayed finalization (challenge period) for the bridge; ZK is faster.

3) Network selection criteria (rating matrix)

1. Commissions and variability

Average deposit/withdrawal/domestic transfer fee; volatility fee at peaks.

2. Time to finalization

p50/p95 to credited/ready for withdrawal status in the product; probability of reorganizations.

3. Reliability and ecosystem

Uptime, maturity of nodes/RPC, monitoring tools, availability of on/off-ramp providers.

4. Availability of stablecoins and liquidity

Availability of USDT/USDC/FDUSD, depth of pairs at your providers and exchanges.

5. Compliance and operational features

Support for Travel Rule among custodians, quality of KYT signals, risks of sanctions labels.

6. UX factors

Address format/need for memo/tag, QR/deeplink support, user error rate.

4) Typical networks and their profile (by payment)

TRON (USDT/USDC): extremely low fees, fast finalization, wide support by providers. Popular for mass deposits in cost-sensitive regions.
Ethereum L2 (Arbitrum/Optimism/Base): price/speed balance, strong integration with infrastructure and USDC. Good for markets with a focus on reporting/interoperability.
BNB Smart Chain (BSC): low cost, broad wallet ecosystem; monitor provider coverage and compliance requirements.
Solana: high bandwidth and low fees; check provider maturity, RPC stability, and your DevOps processes.

Ethereum L1: reliable and compatible with banks/reporting, but expensive; appropriate for VIP/corporate settlements or as a liquidity "anchor."

Networks with memo/tag (XRP/XLM/TON, etc.): cheap and fast, but require strict validation of tags → the risk of UX errors without protection.

5) Cost per Approved

• networks (gas/fee) for deposit/withdrawal,
• fees at the provider/exchange (input/output/conversion),
• KYT/Travel Rule/webhooks,
• transaction costs (manual cases, support),
• losses from network/memo errors (if there are no validations).

Practice: Count all-in on each net, not "naked gas." Keep the switch-over threshold - when the median fee/time increases, switch to the backup network.

6) Confirmation policy and finalization

Dynamic confirmation windows: N blocks depend on the sum/risk segment and the current network load.
RBA logic: Low Risk + stable on a low-floor network → minimal confirmations; High Risk/new address book → more confirmations/hold.
UX statuses: "Address received → Awaiting confirmation → Credited." Show timer/progress.

7) Multi-chain routing and feilover

Primary + Secondary per asset: напр., USDT на TRON (primary) и BSC (secondary); USDC на Arbitrum (primary) и Base (secondary).
Auto-switching rules: for latency, fee, RPC incidents, KYT failure growth.
Liquidity pools: keep a working float on 2 + networks, automate rebalancing via RFQ with multiple exchanges.
Idempotence: keys' invoice _ id/within _ id'and anti-duplicates when retracting.

8) Compliance and safety

KYT + sanctions: pre-check addresses/exchanges/clusters before enrollment and before withdrawal; different networks → different risk profiles.
Travel Rule: keep the VASP↔VASP and gateway for IVMS101; policy for unhosted (address signature/micro-translation, white-list).
Storage and keys: HSM/KMS, multisig, withdrawal limits, 4-eye.
Data: decision logs, course source, PII tokenization, separate storage from PAN.

9) UX patterns that save money

Auto-detection of the network at/QR, warnings in case of non-compliance.
Memo/tag is "strongly required" where required: validator in UI + API, checklist before sending.
Address Book/Whitelist with Reverification, TTL and KYT.
Explanation of fees and ETA before payment to reduce tickets to support.
Deeplink to wallet and autocomplete fields.

10) Sample selection policy (thumbnail)

11) Accounting, reconciliation, course

Lager by networks/assets, mapping 'invoice/within ↔ txid ↔ subaccount'.
Courses (VWAP/multi-feed) with fixed timestamp; rounding rules.
Reporting T + 0/T + 1: networks, commissions, KYT solutions, Travel Rule events.

12) Metrics and OKR

Approval Rate, Time-to-Finality p50/p95, cost/transaction over the network.
KYT reject %/sanctions hits/SAR-conversion.
Share of network/tag errors, recurrence of problem addresses.
Shares of streams over networks, number of auto switch-over, RPC uptime.
Exposure by assets/networks, rebalance rate.

13) Anti-patterns

"Accepted in any network" without strict validation - guaranteed losses.
One provider/one network without reserves - single point of failure.
Estimate only gas, ignore all-in cost and SLA.
No dynamic confirmations/ETA - avalanche of tickets.
No RBA/Travel Rule/KYT - partner locks.
Storage of keys without HSM/multisig and limits - operational risks.

14) Implementation checklist (short)

• Grid matrix: Primary/Secondary per asset; switch-over rules.
• Dynamic confirmations + UX statuses and ETA.
• Address/memo/tag validation (UI + API), QR/deeplink.
• TAC/pre-check sanctions, unhosted policy and address book.
• Travel Rule gateway (IVMS101) for VASP↔VASP.
• Liquidity pools on 2 + networks, RFQ/multi-margin, T0-conversion.
• Lager and reconsilation over networks; course sources.
• Idempotency, anti-takes, backoff + jitter retreats.
• Fee/ETA/SLA monitoring, degradation alerts, incident playbooks.
• Support training: common network/tag errors, response patterns.

15) Summary

Network selection is an operational strategy, not a list of logos. Keep minimum approval costs, fast and predictable finalization, backup networks, and compliance discipline. Combine L1/L2 for geo and segments, automate routing and confirmation, protect UX with validations - and payment crypto rails will be fast, secure and profitable.