CLARITY Act és fejlesztői védelem: miért számít az open-source kriptónak?

Röviden

A CLARITY Act körüli vita első ránézésre amerikai jogalkotási részletkérdésnek tűnhet. Valójában a kripto egyik legfontosabb kérdését érinti: mikor felelős egy fejlesztő azért, amit egy nyílt forrású protokollal mások csinálnak?

Ha a jog minden szoftverfejlesztőt úgy kezel, mintha ügyfélpénzt kezelő pénzügyi szolgáltató lenne, az visszafoghatja az open-source innovációt. Ha viszont túl széles immunitást ad, akkor a rosszhiszemű szereplők könnyen bújhatnak technológiai címkék mögé. A nehéz rész pont a határ meghúzása.

Miről szól a fejlesztői védelem?

A jogalkotói anyagok alapján a CLARITY Act célja többek között az, hogy elkülönítse a valóban letétkezelő, közvetítő, piacszervező szereplőket azoktól, akik nem őriznek ügyféleszközt és nem kontrollálják a felhasználók tranzakcióit. Ez az elválasztás kulcsfontosságú a DeFi, a wallet-fejlesztés és a protokoll-infrastruktúra szempontjából.

Az open-source kriptó nagy része úgy működik, hogy a fejlesztő publikál egy kódot, a közösség auditálja, mások integrálják, a felhasználók pedig saját tárcából lépnek interakcióba vele. Ez egészen más kockázati profil, mint amikor egy cég ügyfélpénzt tart, order bookot kezel és ígéretet tesz végrehajtásra.

Miért fontos ez Európából nézve?

A CLARITY Act amerikai törvényjavaslat, de a hatása nem áll meg az Egyesült Államok határán. A nagy protokollok, fejlesztői csapatok, auditcégek, VC-k és infrastruktúra-szolgáltatók döntései globálisak. Ha az Egyesült Államok tisztább keretet ad a nem letétkezelő fejlesztőknek, az vonzhatja a tehetséget és a tőkét.

Ez nem jelenti azt, hogy Európának másolnia kell az amerikai modellt. A tanulság inkább az, hogy a szabályozásnak különbséget kell tennie a kód, a szolgáltatás, a letétkezelés és a kontroll között. Ha mindenre ugyanazt a sablont húzzuk rá, akkor a felhasználóvédelem erősítése közben pont az átláthatóbb, nyíltabb technológiai réteg sérülhet.

KriptoBlog.hu álláspont

A jó kriptoszabályozás nem attól jó, hogy mindent enged, és nem is attól, hogy mindent pénzügyi közvetítőként kezel. Attól jó, hogy felismeri a kontrollpontokat. Aki ügyfélvagyont tart, piaci hozzáférést szervez vagy aktívan közvetít, az más kockázatot jelent, mint aki nyílt forrású kódot ír és nem tudja megállítani, módosítani vagy lefoglalni a felhasználói eszközöket.

A CLARITY Act fejlesztői védelme ezért nem technológiai kivételezésként érdekes, hanem mint teszt: képes-e a jog különbséget tenni infrastruktúra és pénzügyi szolgáltatás között?

Mire figyelj?

• A végleges szöveg pontosan hogyan definiálja a nem letétkezelő fejlesztőt?
• Kiterjed-e a védelem walletre, node-ra, frontendre és auditálásra is?
• Hol húzza meg a határt a passzív kód és az aktív szolgáltatói kontroll között?
• Az amerikai irány hogyan hat az EU-s MiCA- és DeFi-vitákra?

Források

• House Financial Services: CLARITY Act
• House Financial Services: House passage update
• Senate Banking Committee markup
• Senate market structure draft PDF

Nem pénzügyi vagy jogi tanácsadás.