Session klíče a limity výdajů: Komfort transakcí bez rizika pro celé portfolio

Session klíče a spending limity: pohodlí bez hazardu

Session klíče a spending limity jsou klíčovými nástroji, které přinášejí pohodlí web2 do světa web3, aniž by narušily bezpečnostní záruky vlastního klíče. Cílem je umožnit opakované podepisování a utrácení v přesně vymezeném rámci – bez nutnosti odemykat primární klíč při každé interakci. V článku rozebereme architektury (smart kontrakt peněženky, account abstraction), design oprávnění, kryptografické a provozní detaily a „edge cases“ typické pro DeFi a on-chain hry.

Problém: tření vs. bezpečnost

• Každé kliknutí na „Sign/Confirm“ zvyšuje tření a riziko chyb uživatele (slepé podepisování, phishing).
• Trvalá unlimited approvals (neomezená povolení) jsou pohodlná, ale při kompromitaci dApp/approve kontraktu vedou ke katastrofám.
• Cíl: najít bezpečný střed mezi manuálním podepisováním všeho a nechat otevřené dveře – časově a rozsahově omezená oprávnění.

Co je session klíč

Session klíč je dočasný kryptografický klíč (nebo pár klíčů), kterému primární vlastník deleguje přesně vymezená práva k podepisování transakcí jménem účtu/peněženky. Typicky je vázán na:

• Čas (expirace, TTL),
• Rozsah (konkrétní kontrakty, funkce, kolekce tokenů),
• Limity (denní/mimořádné, per-tx stropy),
• Prostředí (chain ID, dApp doména, relayer/propojovací logika).

Po expiraci nebo odvolání je session klíč bezcenný, což minimalizuje „blast radius“ úniku.

Kde se session klíče používají

• On-chain hry a sociální dApps: plynulé podepsání desítek úkonů bez odemykání hlavního klíče.
• DeFi exekuce: sériové swapy, rebalancování, DCA/TWAP strategie s limity bez uživatelské interakce.
• Firemní prostředí: oddělení provozních práv od pokladního klíče (treasury/ops model).

Architektury: EOAs vs. smart kontrakt peněženky

• EOA-simulace: delegace pomocí podpisu meta-transakcí nebo „permit“ standardů; oprávnění se uplatní v cílovém kontraktu.
• Smart kontrakt peněženky: autorizační pravidla jsou on-chain (modulární politiky, guardi). To umožňuje jemné řízení oprávnění, spending limity, odvolání a audit trail.
• Account Abstraction: transakce jsou user operations s validátorem, který kontroluje session pravidla a limity před vykonáním.

Spending limity: design a dimenze

Spending limit je formální rozpočet nad objemem, frekvencí a adresáty. Pro bezpečné nastavení doporučujeme kombinovat:

• Objem: max. částka v nativní měně, max. nominál v stablecoinech (např. 500 USDC/den), max. počet NFT převodů.
• Frekvence: per-tx limit, per-block strop, per-časové okno (minuta/hodina/den), „cool-down“ po vyčerpání limitu.
• Adresy a funkce: allowlist kontraktů, selektivní ABI funkce (např. swapExactTokensForTokens), zákaz „call arbitrary“.
• Směry: pouze pull (permit) nebo push (přímé převody); často obojí s rozdílnými limity.
• Oracly: nominál kalkulovaný z on-chain/spolehlivého oracle, nikoli ze subjektivního „spotu“ dApp.

Politiky ověřování: před transakcí vs. po transakci

• Pre-check: pravidla se uplatní v peněžence/validátoru před vykonáním (preferované; žádný „rollback“ hazard).
• Post-check: monitor a zpětné zrušení práv po detekci anomálie (fallback; vyžaduje pausable/guard hooky).

Designové vzory oprávnění

• Session jako modul: peněženka načte „policy modul“ s mapou sessionKey → ACL/limity/expirace.
• Permit-driven exekuce: podpis „voucheru“ (permit) s doménou, funkcí, parametry, deadlinem a nonce; dApp/relayer jej vykoná až po kontrole limitu.
• Rollback-resistant approvals: schválení (allowance) jsou vázána na spender kontrakt s vlastní politikou, nikoli na „neomezené“ ERC-20 allowances.

Provozní aspekty: generování, uložení a rotace

• Generování: session klíč vytváří klient lokálně (WebCrypto/SE), podepíše jej primární klíč jako delegaci.
• Uložení: v zabezpečeném úložišti (Secure Enclave, Android Keystore) nebo v HSM; nikdy ne v plain localStorage.
• Rotace: expirace tvořená TTL + „idle timeout“; revokace on-chain (záznam o zrušení) i off-chain (zapomenutí v klientech/relayerech).

Threat model: na co si dát pozor

• Phishing UI: session vytvořená pro jiný kontrakt/doménu. Řešení: doménové vázání (EIP-712 domain separator), „origin pinning“.
• Parameter smuggling: benigní funkce s neočekávanými calldata. Řešení: striktně validovat selector, rozsah parametrů a příjemců.
• Reentrancy přes modul: volání třetích stran v rámci policy hooku. Řešení: checks-effects-interactions, guardi a reentrancy lock.
• Oracle drift: nominál kontrolovaný slabým oracle. Řešení: vícezdrojové feedy, procentuální odchylky a havarijní limity.
• Relayer kompromitace: vynucení podpisu/odhalení metadat. Řešení: šifrované kanály, podepisování „intentu“ a schválení on-chain policy.

Spending limity pro tokeny: praktické vzory

• Per-asset cap: např. 200 USDC/den, 0,05 ETH/den; reset v pevném okně (UTC) nebo klouzavém okně (rolling).
• Per-protocol cap: celkový nominál přes konkrétní router (DEX) – brání „approval driftu“ na jiné směry.
• Per-destination cap: silná ochrana proti úniku – only-to-vault/allowlist; užitečné pro pokladny (treasuries).
• Procentuální limity: max. X % zůstatku nebo TVL účtu; dynamické přizpůsobení při volatilitě.

Funkční limity: granularita na úrovni ABI

Kromě tokenových stropů zavádějte funkční politiky:

• povolit pouze konkrétní function selectors,
• ověřovat rozsah parametrů (minOut, deadline <= N minut),
• zakázat delegatecall, create a volání bez cílového příjemce (call to EOA).

Bezpečné UX pro session klíče

• Čitelná karta oprávnění: „Kdo → Co → Kolik → Kdy“ na jedné obrazovce; nezahltit ABI detaily.
• Výstrahy a precap: pokud jsou požadována „unlimited“ práva, nutit uživatele manuálně změnit limit.
• Živý měřič: vizualizace vyčerpání denního stropu (např. 120/500 USDC).
• Rychlá revokace: tlačítko „Zrušit všechny sessions“ + granularní revokace pro jednotlivé klíče.

Observabilita a audit

• Eventy: SessionCreated, SessionRevoked, Spend s metadaty (chain, kontrakt, částka, policyID).
• On-chain metriky: procento zamítnutých volání (policy reject rate), využití limitu, počet aktivních session klíčů.
• Off-chain logy: mapování domén, relayer ID, otisky klienta (device fingerprint) při změně chování.

Incident response a „kill-switch“

• Globální pauza peněženky nebo konkrétní policy.
• Cap-cut: okamžité snížení limitů na nulu pro rizikový protokol.
• Time-lock odvolání opačně (pro treasury): velké změny vyžadují zpoždění a vícenásobné podpisy.

Integrace s multi-sig a MPC

• Multi-sig & sessions: multi-sig schvaluje zřízení policy, ne každé volání – vysoké pohodlí, zachovaná kolektivní kontrola.
• MPC primární klíč + lokální session klíče: minimalizuje frekvenci interakcí s MPC a chrání před rizikem single-device.

Implementační zásady pro vývojáře

• Deterministické policy ID (hash parametrů) pro audit a reprodukovatelnost.
• Jednoznačný domain separator (chainID, name, version) proti „sign-in another app“ útokům.
• Nonce a replay ochrana: monotónní nonce per session/funkci; v kombinaci s deadlinem.
• Fail-closed logika: pokud oracle/relayer selže, transakce se zamítne.
• Gas policy: limit na gasPrice/priorityFee a fallback na sponzorování přes paymaster s limitem.

Testování: scénáře a metriky

• Pozitivní cesty: sériová volání v limitu, překročení limitu → očekávaný „revert“ s důvodem.
• Mutace parametrů: extrémní hodnoty (max uint, nulové adresy), substituce příjemce, změna chainID.
• Výkonnostní: latence validace policy vs. baseline; overhead na gas a relayer infrastrukturu.
• Bezpečnostní: reentrancy, storage collision v modulech, zneužití delegatecall.

Tabulka: porovnání přístupů k pohodlí a riziku

Checklist pro uživatele

• Session karta zobrazuje konkrétní kontrakty, limity, expiraci a doménu dApp?
• Je dostupné rychlé zrušení a přehled aktivních sessions?
• Jsou limity denní a per-tx, ne pouze „měsíční strop“?
• Je pro výpočty nominálu použit spolehlivý oracle s odchylkovými pojistkami?

Checklist pro integrátory

• Implementovali jste policy modul s allowlistou funkcí a adresátů?
• Jsou eventy a monitoring nastaveny na detekci překročení limitu a anomálií?
• Testujete phishing scénáře (špatná doména, jiný chainID) v CI?
• Máte kill-switch a cap-cut pro incidenty?

Pohodlí bez hazardu je inženýrská disciplína

Session klíče a spending limity umožňují web3 aplikacím nasadit plynulé UX, aniž by obětovaly bezpečnost. Klíčem je přesná specifikace oprávnění, exaktní limity, audovatelnost a okamžitá revokace. Designujte politiky jako kód, měřte jejich dopad na riziko a udržujte minimální nezbytná oprávnění. Takto dosáhnete, že pohodlí nebude hazard, ale řízené riziko – přesně tak, jak má být v profesionálním krypto a trading stacku.