Crypto volatility and hedging

TL; DR

Crypto payments provide fast TtW, low cost and global coverage, but carry price risk. The basic strategy is instant conversion (auto-sell to stable/fiat) and NWP hedge (hedge only net payments). To hold risk: exposure limits (in minutes/hours), hedge instruments (spot/perp/futures/options), on/off ramp discipline, VaR/TtH dashboards (time-to-hedge) and strict operational idempotency.

1) Sources of volatility in the payment loop

Underlying asset price: BTC/ETH/TON, etc.
Depeg stablecoins: UST case → managed share per issuer/chain.
Futures base and funding: perps ↔ spot (premium/discount).
Liquidity and slippage: night hours, local markets, thin pairs/chains.
FX over crypto: fiat currency balance vs USD-asset nomination.
Operating window: on/off ramp delays, blockchain (confa) confirmations.

2) Custody policy (reference model)

Purpose: Minimize P&L from price while maintaining UX and margin.

2. 1 Principles

1. Auto-hedge on receipt: convert to stable at the time of deposit (USDC/USDT/... with issuer limits) or fiat.

2. NWP-hedge (Net Within Position): Hedge net payouts: 'net = expected takeaways - stables'

3. Time-to-Hedge (TtH) SLO: p95 ≤ 2 min (liquid pairs), ≤ 10 min (thin networks).
4. Live market limits: max. notaional on a non-hedged underlying asset (e.g. ≤ 0. 5% daily GGR).
5. Diversification of stables: no more than X% per issuer/chain, balance on-chain/offline-custom.

6. Fail-safe: if liquidity falls, the temporary switch "deposit→steybl only on network Y."

2. 2 Organizational matrix

Treasury - responsible for hedge book, limits, SOR/exec.
Risk/MLRO - counterparty limits, sanctions compliance, SoF/SoW.
Ops - it/off-ramp operations, configuration of wallets, monitoring of confs.
Finance - accounting, reporting, revaluation, P&L attribution.

3) Tools and their role

4) Risk metrics and target SLOs

Exposure: 'E = Σ net balance of the underlying asset' (in USD). Purpose: 'E ≤ limit L'.
VaR (99%, 1d): historical/par. for a basket of assets/stables.
TtH p95: time from receipt of deposit to hedge.

5) Typical strategies

5. 1 "Auto-sell to Stable"

At the entrance (deposit in BTC/ETH/etc) → instantly sell to the selected stable via SOR (several CEX/OTC).
Store stables according to issuer/chain limits; part - in fiat on off-ramp.
For conclusions in crypto - buy "back" as needed.

Pros: simplicity, almost zero delta exposure.
Cons: turnover costs, stable risk (depeg), operating lags.

5. 2 "Perp-hedge" (delta neutralization)

We hold the spot crypt as a reverse position (for conclusions), short perp is equivalent to net.
Balancing funding: if funding> target, partially convert to stables/fiat.

Pros: You can keep a liquid spot for UX; flexibility.
Cons: funding value and exchange risk.

5. 3 "Collar" for forecast net payments

Buying puts on the underlying asset + selling calls (or short perp) in the amount of net payments per T window (for example, 7-14 days).
The premium budget limits tail-risk.

Pros: drawdown limitation; managed value.
Cons: options liquidity, more difficult operationally.

5. 4 «NWP-hedge» (Net Withdrawal Position)

We calculate the net need for crypto on the 'T' horizon from behavioral models (seasonality, cash-out rate).
We hedge only this volume; incoming deposits park in stables.

Pros: less turnover; hedge "on the case."

Cons: Model forecast risk.

6) Execution and accounting architecture

6. 1 Components

Crypto Payments Gateway: addresses/invoices, confs, AML screening.
Treasury Router/SOR: exchange selection/OTS, algo execution (TWAP/VWAP/POV), limits.
Hedge Engine: exposure calculation, placement of perp/future/options, HR/VaR monitoring.
Ledger/Accounting: positions, mark-to-market revaluation, P&L attribution: 'Trading P&L', 'Funding', 'Slippage', 'Fees'.
Risk & Compliance: counterparty limits, sanction screening, SoF/SoW, on/off-ramp policies.

6. 2 Flow (auto-sell example)

1. Deposit. detected → konfa ≥ N → AML_ok → 'SOR. quote()`

2. Execute TWAP (idempotent exec_id) → 'trade. fills` → `convert→stable`

3. Hedge. update (): 'E↓', 'HR→1' → events in Kafka

4. Ledger. mark2mkt: closing price/indicator, P&L calculation

5. Dashboard: TtH, VaR, HR, funding, slippage/fees

6. 3 Idempotency and execution risks

Idempotent keys for orders and conclusions (repeat webhook ≠ re-deal).
Kill-switch for liquidity degradation (latency alerts/fils).
Circuit-breakers for slipping and diverging quotes (oracle vs book).

7) Data model (simplified)

json
{
"ts": "2025-11-03T12:15:42Z",
"asset": "BTC",
"side": "SELL",
"notional_usd": 25000.0,
"avg_px": 68250.5,
"slippage_bps": 3.2,
"fees_usd": 7.5,
"venue": "CEX_A",
"exec_algo": "TWAP_2min",
"exposure_after_usd": 1200.0,
"hedge_ratio": 0.98,
"funding_24h_bps": 8,
"var_99_1d_usd": 5200.0
}

8) Limits and controls

9) Accounting and reporting

Mark-to-Market (MtM): daily revaluation of positions by independent price (price oracles/indices).
P&L Attribution: decomposition into 'Price P&L', 'Funding', 'Fees', 'Slippage', 'FX'.
Hedge Effectiveness: '(Δ P&L portfolio without hedge − Δ P&L actual )/ Δ P&L without hedge'.

Mapping to GGR: separately store the "payment result" vs "term result."

Audit of trades: exec_id, clearing reports, uploads by sites.

10) Compliance, KYC/AML and Sanctions

On/off ramp policy: only whitelisted counterparties, KYC-verified accounts are allowed.
Sanction screening on-chain: addresses/clustering, "high risk" tags, interoperability ban.
Source of Funds/Wealth: escalation thresholds for large I/O.
Regional rules: status of crypto payments, taxation, reporting.
Custody: provider/self-storage, multisig/HSM, withdrawal limit policies.

11) Dashboard and alerts (minimum set)

1. Exposure & HR: by assets and in aggregate.
2. VaR/ES: daily update, stress scenarios (− 20%, + 20%, depeg − 2%).
3. TtH p50/p95, exec latency, fill ratio.
4. Funding/Carry and Fees/Slippage by site.
5. Stable Diversification: by issuer/network, depeg index.
6. Venue Risk: Balances/Margins/Limits/Incidents.

• `E > 0. 8L_asset' → P1; 'E> L_asset' → P0 with auto-hedge.
• `VaR > L_VaR` → P1; `TtH p95 > SLO` → P1.
• `Depeg spread > 0. 5% '(by issuer) → auto-rebalance of stables.

12) Playbooks

A sharp collapse (− 10% per hour): auto-sell into a stable, close the remainder with a short break, narrow the limits, turn on TWAP with a small step.
Depeg stable: instant rebalance to alternate stable/fiat, issuer limit = 0, close perps against this stable.
Exchange withdrawal freeze: SOR switches execution to alternatives, OTC RFQ, reducing the size of orders, partitioning applications.
Surge funding: partial transition from perps to spot + partial sell, recalculation of carry-value.
Thin market/night: increase TWAP window, limit on slippage bps, postpone large rebalances.

13) Test cases (UAT/Prod-ready)

1. Idempotent Exec: repeat webhook → 1 deal, not two.
2. TtH SLO: simulate 100 deposits → p95 ≤ target.
3. Kill-switch: exchange delay simulation → SOR switches.
4. Depeg Drill: − 1% to the parity of the stable → auto-rebalance is triggered.
5. Stress VaR: price jump ± 20% → VaR/ES within limits.
6. Ledger Reprice: daily revaluation and reconciliation with exchange/UTS reports.
7. Limits Enforcement - attempt to exceed L_asset → waiver/auto hedge.

14) Frequent mistakes and how to avoid them

Long window without hedge (integration lags): fix 'TtH' as SLO, keep "fast" it ramp.
MonoProvider: Diversify sites/issuers, venue/stable limits.
Lack of MtM and P&L attribution: no transparency on hedge effectiveness.
Blind belief in perps: ignore funding → negative carry.
There is no depeg script: a high proportion of one stable without an exit plan.
Non-idempotent operations: duplicate orders/conclusions when chatting webhooks.

15) Summary

Successful crypto monetization in iGaming relies on three pillars: instant price risk neutralization, strict limit discipline/dashboards, and on/off ramp operational reliability. By combining auto-sell, NWP hedge and perp/options tools - with tight compliance and accounting - you keep TtW low, P&L stable and UX fast and predictable.