article

Privacidad con salida: conjuntos de asociación tras la tormenta

Pools de privacidad, Railgun, y qué resuelven realmente el veredicto dividido del caso Storm y el nuevo juicio de octubre de 2026 sobre el diseño de privacidad onchain.

16 min de lectura
Share 공유 共有 分享 Compartir X LinkedIn

cover

Introduction

On August 6, 2025, after roughly a week of deliberation following a four-week trial in the Southern District of New York, a jury returned a split verdict on Roman Storm. It convicted him of conspiracy to operate an unlicensed money transmitting business. It hung on conspiracy to commit money laundering and conspiracy to violate IEEPA sanctions. The hung counts produced a partial mistrial, not an acquittal, and the government has since requested a retrial reported for October 2026.

The split matters because each side of it points at a different design question. The conviction says something narrow but concrete: at least some conduct around operating and promoting Tornado Cash met a jury’s threshold for unlicensed money transmission. The mistrial says the harder questions, whether that conduct also crossed into laundering and sanctions violations, remain legally open. Protocol designers building the next generation of onchain privacy have to plan against both, without knowing how the second half will resolve.

Two systems anchor that design conversation. Privacy Pools, live on Ethereum since March 2025 per the project’s own communications, tries to answer the Tornado question directly by attaching a curated association-set layer to a zero-knowledge pool, with a public exit for depositors whose funds are not approved. Railgun, deployed across Ethereum, BSC, Polygon, and Arbitrum, takes a structurally different path: no mixing, no association-set curator, privacy generated as a side effect of DeFi activity conducted from inside a shielded environment. Both are alive. Neither has been blessed by a regulator. The question is whether either equilibrium holds once the Storm retrial lands and the second half of the developer-liability question gets answered.

What the Storm Verdict Actually Decided

img1

The indictment charged Storm with three conspiracies: unlicensed money transmission, money laundering, and IEEPA sanctions violations. The parties stipulated some facts that narrowed the trial. Storm did not personally launder funds. Tornado Cash was used for legitimate transactions as well as illicit ones. Storm became aware, at some point during his tenure, that criminal actors were using the protocol. The government’s theory was that continuing to operate and promote Tornado Cash after that awareness, and declining to implement adequate safeguards, was itself criminal conduct.

The defense ran the neutral-tool argument. Tornado Cash, on this view, sits alongside VPNs, encrypted messengers, or a hammer: builders of general-purpose infrastructure cannot be criminally liable merely because they know someone, somewhere, will misuse it. The jury credited that argument in part. It hung on the two counts where the harm is defined by what users did, laundering the proceeds of specified unlawful activity, transferring value to sanctioned parties. It convicted on the count where the harm is defined by what Storm did, running a business that transmitted value for others without the licensing FinCEN requires.

That is a narrower verdict than the pre-trial coverage suggested and a wider one than the defense hoped for. The Mayer Brown analysis of the outcome reads the money-transmission conviction as an instruction to developers and operators of mixers and exchanges: assess whether you are operating a money transmitting business under FinCEN’s definition, and if so, obtain the appropriate federal and state licenses. That is not a settled legal rule, it is one law firm’s read of a jury verdict in one district, but it is the working assumption most compliance-oriented protocol teams appear to be operating under.

Two other legal facts sit alongside the verdict. In August 2022, OFAC sanctioned Tornado Cash and alleged the protocol had facilitated more than $7B in laundered value, including roughly $600M attributed to North Korea’s Lazarus Group from the Axie Infinity hack. Those are government allegations from a sanctions filing, not adjudicated findings. In December 2024, the Fifth Circuit ruled that OFAC exceeded its authority in sanctioning certain autonomous Tornado Cash protocols. The precise scope of “certain autonomous protocols” in that ruling is narrower than the shorthand suggests and requires reading against the full opinion, but the ruling addressed civil sanctions authority, not criminal liability. It did not disturb the DOJ’s ability to prosecute Storm, and it did not save him from the money-transmission count.

What the retrial puts back at stake

The October 2026 retrial, as far as available reporting indicates, will cover the hung counts. That means the laundering and sanctions theories return to a jury, and a different set of instructions, evidentiary rulings, and jurors may produce a different outcome. A conviction on either count would push the line for developer liability well past where the first verdict left it. The money-transmission conviction implicates protocol operators; a laundering or sanctions conviction based on knowing facilitation would implicate a wider set of developer conduct, particularly around what protocols do after they learn of specific illicit use.

Two things follow. First, the current post-Storm design consensus, that mixer-style protocols should either register as money service businesses or restructure around some form of compliance filtering, rests on a verdict that has not fully resolved. Second, any privacy protocol claiming to have designed around the Storm risk has designed around only half of what Storm might eventually establish. That is worth holding in mind before treating association-set architectures as a legal answer rather than a legal hypothesis.

Why the Mixer Architecture Failed the Compliance Test

img2

Tornado Cash’s architecture had a single feature that structured the entire prosecution: deposits and withdrawals were commingled in shared pools. A withdrawer proved, via zero-knowledge circuit, that they had previously deposited into the pool, without revealing which deposit was theirs. This is the source of the privacy guarantee and, simultaneously, the source of the compliance problem. Once funds enter the pool, the protocol itself cannot distinguish clean deposits from proceeds of a Lazarus Group hack. Any withdrawal is a withdrawal against the pool as a whole.

From a regulator’s perspective, that design is functionally a value-transmission service that provides no meaningful ability to screen counterparties. From the developer’s perspective, it is exactly the property that gives the protocol its social value: a privacy set that cannot be selectively pierced is a privacy set that cannot be selectively pierced by anyone, including a state actor. The two framings do not admit a compromise inside the pool-and-withdraw model. The protocol either commingles or it does not; if it commingles, the operator either screens deposits at the door or accepts that it cannot screen at all.

Voluntary front-end screening, blocking sanctioned addresses at a web interface, was tried and did not resolve the underlying issue. The smart contracts remained callable directly, and the pooled architecture meant that even filtered deposits could not un-commingle from previously deposited illicit funds. The Fifth Circuit’s 2024 ruling addressed the specific question of whether immutable smart contracts count as “property” that OFAC can sanction, and answered no for certain autonomous components. But that was a limit on OFAC’s civil authority, not a shield against a criminal money-transmission charge premised on what the developers did while the protocol was operating.

The design lesson the post-Tornado projects appear to have drawn is that compliance must be a first-class architectural feature, not a front-end policy. Privacy Pools operationalizes this by moving the screening upstream, before a deposit is considered “approved” for withdrawal into the anonymous set, while trying to preserve a cryptographic privacy guarantee for approved funds. Railgun operationalizes it by avoiding the commingling model altogether. Both are attempts to answer the objection that made Tornado indefensible in front of a Manhattan jury.

Privacy Pools and the Association-Set Model

img3

Privacy Pools is structured in three layers. A smart-contract layer centered on an upgradeable Entrypoint contract handles deposits, withdrawals, and coordination. A zero-knowledge layer manages commitment schemes and withdrawal circuits, so that a withdrawer proves membership in a set without revealing which commitment is theirs. An Association Set Provider (ASP) layer maintains a curated set of approved deposit labels, the compliance surface, and updates state through authorized accounts. The protocol is non-custodial in the standard sense: user funds are held by cryptographic commitments in the contracts, not by any operator’s keys.

The user experience is straightforward. A depositor commits funds into the pool. The ASP evaluates the deposit against its criteria and either includes it in the current approved association set or does not. If included, the depositor (or their designated recipient) can later withdraw using a zero-knowledge proof of membership in the approved set, the withdrawal is unlinkable to the specific deposit, but only among deposits the ASP has approved. Partial withdrawals are supported, preserving privacy on the remaining balance. Multiple asset types, native ETH and ERC-20 tokens, are supported.

The mechanism that makes this something other than KYC-by-another-name is ragequit. If the ASP declines to approve a deposit, the original depositor can exit publicly, revealing the specific deposit and recovering the funds. The privacy of that transaction is forfeited, but custody is preserved. This is the censorship-resistance backstop: the ASP cannot trap a depositor’s funds by refusing approval. It can only force the depositor to choose between remaining unapproved (and unable to withdraw privately) or exiting in public.

Where the design has to survive contact with regulators

Ragequit is doing more work in the marketing than it can do in practice. A depositor with a legitimate but sensitive transaction, the kind of transaction the whole system is meant to serve, cannot use the public exit without defeating the reason for depositing. The threat of ragequit is therefore not really a threat: it is a fallback that preserves financial custody at the cost of what the depositor came for. In practice, ragequit functions less as an equalizer between depositor and ASP and more as a bankruptcy option. The ASP’s approval decision is the operative one.

That raises a question the Privacy Pools documentation does not resolve: what is an ASP, legally? An ASP operator screens deposits against some criteria, presumably chain-analytics signals, sanctions lists, and heuristics for known illicit sources, and produces a list of approved labels. That looks like a compliance service being sold to, or embedded in, a value-transmission protocol. Whether FinCEN would characterize an ASP operator as itself running a money services business, or as a compliance vendor to one, or as neither, has not been publicly tested. If the answer is “money services business,” the ASP layer inherits the licensing burden the pool architecture was meant to distribute away from.

Two further caveats sit inside the architecture. The Entrypoint is upgradeable, which the documentation notes but does not analyze. Upgrade authority is a regulatory chokepoint: if a court or agency can compel the upgrade administrators to alter ASP logic, blocklist specific addresses, or modify withdrawal circuits, the protocol’s censorship resistance ultimately depends on the legal posture of whoever holds those keys. The public governance details around the Entrypoint’s upgrade path, key holders, multisig composition, timelock parameters, are not in the excerpt we worked from and would need direct verification from the deployed contracts.

The second caveat is that the ASP’s approval criteria are, as a matter of protocol design, exogenous. Nothing in the cryptography prevents an ASP from tightening criteria under pressure, adding retrospective removals, or being pressured to converge with other ASPs into a de facto shared blocklist. The censorship-resistance story rests on the assumption that either multiple ASPs will compete, or that the ragequit exit meaningfully constrains a single ASP’s behavior. Both assumptions are empirical, not architectural.

The Privacy Pools model has attracted attention within the Ethereum Foundation’s Kohaku privacy-wallet effort, which the topic brief describes as the EF’s initiative to make privacy a default at the wallet layer. The precise relationship between Kohaku and Privacy Pools, whether it is integration, endorsement, or something looser, is not documented in the sources we could verify, and the article treats it as directional rather than definitive.

Railgun’s Noise-over-Mixing Architecture

img4

Railgun takes a different structural position. Its documentation describes the system as ownerless smart contract code deployed on Ethereum, BSC, Polygon, and Arbitrum. Users receive a “0zk address” that is confidential on standard block explorers. The critical architectural claim is that Railgun does not mix funds between users. Tokens and wallets become indistinguishable through zero-knowledge cryptography without being commingled in a shared pool the way Tornado Cash pooled deposits.

The consequence is that the anonymity set is generated primarily by activity, not by liquidity. Users can swap, lend, borrow, and make dApp calls from inside the shielded environment. Each of those interactions adds noise. A private swap between two Railgun users looks, on chain, like a Railgun transaction; a private payment looks like a Railgun transaction; a private DeFi position adjustment looks like a Railgun transaction. The privacy set for any single action grows with the total volume of unrelated actions happening in the same shielded environment, without requiring users to leave their funds parked in a mixing pool.

The topic brief cites cumulative shielded volume of roughly $4.5–5B for Railgun as of the research period. We have not independently confirmed that figure against an onchain data source in the materials available for this piece; the number should be read as directionally consistent with public reporting but requires verification against a dashboard such as Dune before being treated as precise. What is defensible from the primary documentation is the architectural claim: the system is deployed live across four chains, has been operating throughout the enforcement era against mixers, and positions its non-mixing design as a compliance-relevant differentiator.

Why growth is not evidence of legitimacy

The interesting question is not whether Railgun grew, it did, but what to attribute the growth to. Three explanations are consistent with the same data. The first is that Railgun’s non-mixing architecture and its documentation’s emphasis on legitimate use cases (professional confidentiality, HIPAA, GDPR, private payroll, protection from wallet-labeling services) genuinely occupy a different legal position than Tornado Cash. The second is that mixer demand did not disappear when Tornado Cash was sanctioned; it displaced to whatever privacy infrastructure remained live. The third is that Railgun’s DeFi-native shielded environment attracted users whose primary interest was not privacy from law enforcement but privacy from front-runners, MEV, and wallet-tracking services, a distinct market that Tornado Cash was poorly suited to serve.

The three explanations are not mutually exclusive, and none of them is equivalent to regulatory acceptance. No U.S. regulator has publicly blessed Railgun’s architecture as satisfying AML or BSA obligations. Railgun’s own framing, non-custodial, ownerless, no required governance token, privacy as a compliance tool for regulated professionals, is a legal posture, not a legal ruling. The Storm case is a reminder that “no owner” and “no custody” do not resolve the developer-liability question. The unlicensed money transmission charge did not require Storm to have custody of user funds. It required that Tornado Cash transmit value for others and that Storm’s conduct meet a conspiracy standard. A protocol that transmits value privately without custody remains within the ambit of that theory.

Railgun’s stronger structural position, if it has one, is that its non-mixing design gives it a plausible argument that it is not a mixer in the technical sense the government’s Tornado theory relied on. Whether that argument survives contact with a determined prosecutor is untested.

Three Failure Modes for Compliant Privacy

img5

The framing of “compliant privacy” as an established design pattern presumes a stability that the current legal environment does not supply. Three failure modes deserve to be named specifically.

The first is regulatory recharacterization of the compliance layer. If an ASP operator is deemed a money services business under FinCEN’s definition, or a compliance intermediary subject to state-by-state licensing, the ASP layer inherits exactly the licensing burden that the pool architecture displaced. This does not necessarily kill the design, it may push toward a licensed-ASP ecosystem with clearer legal status, but it invalidates the current premise that the compliance layer is a lightweight bolt-on. It also collapses the “no KYC” claim insofar as licensed compliance intermediaries typically need to know who they are approving.

The second is censorship creep. A single dominant ASP under sustained regulatory pressure has strong incentives to over-exclude. Legitimate but sensitive deposits, activist donations, whistleblower payments, transactions from jurisdictions the ASP treats as high-risk, can be denied approval at very low cost to the ASP and very high cost to the depositor, whose only recourse is a public ragequit that defeats the reason for using the protocol. The Privacy Pools censorship-resistance story depends on either genuine ASP competition or a meaningful cost to over-exclusion. Neither is guaranteed by the architecture. Both are policy outcomes that will be shaped by the retrial, by FinCEN guidance, and by the response of ASP operators to civil and criminal risk.

The third is direct precedent from the Storm retrial. A conviction on either the laundering or the sanctions conspiracy count in October 2026 would extend the developer-liability frontier past unlicensed money transmission into knowing facilitation. A protocol like Privacy Pools that has an identifiable compliance layer is arguably better positioned against that theory than Tornado Cash was, because the ASP’s role documents an ongoing attempt to prevent illicit use. But “arguably better positioned” is not the same as “safe.” Every architectural feature that documents intent to screen is also evidence, in an adverse proceeding, of what the developers knew and when. The retrial will shape which posture, Railgun’s ownerless non-mixing design, Privacy Pools’ explicit compliance layer, or some third approach, is best-suited to the legal environment the second verdict produces.

The honest read of the current design space is that neither Privacy Pools nor Railgun has been tested by an enforcement action of the kind that shaped Tornado Cash. Both are operating in the interval between the August 2025 verdict and the October 2026 retrial, with the practical outcome of that interval genuinely undetermined. The Ethereum Foundation’s interest in the Privacy Pools model through Kohaku suggests the broader ecosystem is treating association-set curation as the more likely convergence point at the wallet layer, but that bet is being placed against a legal question that has not been fully answered.

What can be said with some confidence is what to watch for. Any FinCEN guidance addressing zero-knowledge privacy protocols, whether formal or informal, would materially change the calculation for ASP operators. Any subpoena or civil action directed at Railgun would test whether its non-mixing architecture actually occupies the different legal position its documentation implies. Any change in the composition of the Privacy Pools Entrypoint’s upgrade authority, or in the ASP operator’s approval criteria, would reveal how the protocol responds to pressure short of formal enforcement. The October 2026 retrial will either confirm the current design consensus by leaving the laundering and sanctions theories unresolved, extend it by acquitting Storm on those counts, or unsettle it by convicting. Until then, the current generation of privacy protocols is running a live experiment about which architectural bets survive a legal environment that has not yet finished defining itself.

cover

서론

2025년 8월 6일, 뉴욕 남부지구 연방법원에서 4주간의 재판이 끝난 뒤 약 1주일간의 심의 끝에 배심원단은 로만 스톰에 대해 분할 평결을 내렸다. 무허가 자금 전송 사업 운영 공모 혐의에 대해서는 유죄를 선고했다. 자금 세탁 공모 및 IEEPA 제재 위반 공모 혐의에 대해서는 평결이 불일치로 끝났다. 불일치 항목은 무죄 판결이 아니라 부분 심리무효(mistrial)를 낳았으며, 검찰은 2026년 10월로 예정된 재심을 신청한 상태다.

분할 평결이 중요한 이유는 양쪽 결과가 각기 다른 설계 문제를 가리키기 때문이다. 유죄 판결은 좁지만 구체적인 사실을 말해준다. 토네이도 캐시를 운영하고 홍보한 특정 행위가 무허가 자금 전송에 관한 배심원의 기준을 충족했다는 것이다. 심리무효는 더 어려운 질문, 즉 그 행위가 자금 세탁 및 제재 위반으로도 이어지는지 여부가 법적으로 여전히 열려 있음을 뜻한다. 온체인 프라이버시 차세대 프로토콜을 설계하는 개발자들은 두 번째 쟁점이 어떻게 해소될지 모르는 상황에서도 두 가지 모두에 대비해야 한다.

이 설계 논의를 구체화하는 두 시스템이 있다. Privacy Pools는 프로젝트 측 발표에 따르면 2025년 3월부터 이더리움에서 운영 중이며, 영지식 풀에 큐레이션된 연관 집합(association-set) 레이어를 결합하고 승인되지 않은 자금에 대해 공개 출금 경로를 제공하는 방식으로 토네이도 문제에 직접 답하려 한다. Railgun은 이더리움, BSC, Polygon, Arbitrum에 배포된 구조적으로 다른 경로를 택했다. 믹싱 없음, 연관 집합 큐레이터 없음, 차폐된 환경 안에서 DeFi 활동을 수행하는 부산물로 프라이버시가 생성된다. 두 시스템 모두 실제로 작동하고 있다. 어느 쪽도 규제 당국의 승인을 받지 못했다. 핵심 질문은 스톰 재심이 결론 나고 개발자 책임 문제의 두 번째 절반이 답을 얻었을 때 어느 균형점이 유지될 수 있는가다.

스톰 평결이 실제로 결정한 것

img1

기소장은 스톰에게 세 가지 공모 혐의를 적용했다. 무허가 자금 전송, 자금 세탁, 그리고 IEEPA 제재 위반이다. 양측은 일부 사실을 사전 합의로 인정해 재판 범위를 좁혔다. 스톰은 직접 자금을 세탁하지 않았다. 토네이도 캐시는 불법 거래뿐 아니라 합법적인 거래에도 사용됐다. 스톰은 재직 기간 어느 시점부터 범죄자들이 프로토콜을 사용하고 있다는 사실을 인지했다. 검찰의 논리는 그 인지 이후에도 토네이도 캐시를 계속 운영·홍보하고 적절한 안전장치 도입을 거부한 행위 자체가 범죄라는 것이었다.

변호인 측은 중립적 도구 논리를 폈다. 이 관점에서 토네이도 캐시는 VPN, 암호화 메신저, 혹은 망치와 다를 바 없다. 범용 인프라 구축자는 누군가가 그것을 남용할 것임을 알았다는 이유만으로 형사 책임을 지지 않는다는 논리다. 배심원단은 이 주장을 부분적으로 받아들였다. 피해가 사용자의 행위, 즉 특정 불법 행위 수익 세탁과 제재 대상에 대한 가치 전송으로 정의되는 두 항목에서는 평결이 갈렸다. 피해가 스톰 자신의 행위, 즉 FinCEN이 요구하는 면허 없이 타인의 자금을 전송하는 사업 운영으로 정의되는 항목에서는 유죄를 선고했다.

이는 재판 전 언론 보도가 시사한 것보다 좁은 평결이며, 변호인 측이 바란 것보다는 넓은 평결이다. Mayer Brown의 결과 분석은 자금 전송 유죄 판결을 믹서 및 거래소 개발자·운영자에 대한 하나의 지침으로 읽는다. FinCEN의 정의에 따라 자신이 자금 전송 사업을 운영하고 있는지 여부를 판단하고, 그렇다면 연방 및 주 면허를 취득하라는 것이다. 이는 확립된 법규가 아니라 한 법무법인이 한 지구의 배심원 평결을 해석한 견해다. 그러나 컴플라이언스를 중시하는 대부분의 프로토콜 팀이 실제로 이를 기본 전제로 삼아 움직이고 있는 것으로 보인다.

평결과 함께 살펴봐야 할 다른 두 가지 법적 사실이 있다. 2022년 8월 OFAC은 토네이도 캐시를 제재하면서 프로토콜이 70억 달러 이상의 세탁된 자금, 그중 액시 인피니티 해킹 사건과 관련해 북한 라자루스 그룹에 귀속된 ~6억 달러를 포함한 금액의 이동을 용이하게 했다고 주장했다. 이는 제재 신청서에 담긴 정부 주장이지 법원에서 확정된 사실이 아니다. 2024년 12월 제5순회항소법원은 OFAC이 특정 자율형 토네이도 캐시 프로토콜을 제재하면서 권한을 초과했다고 판결했다. 그 판결에서 “특정 자율형 프로토콜”의 정확한 범위는 통용되는 축약 표현보다 좁으며, 전체 판결문을 읽어야 제대로 이해할 수 있다. 또한 이 판결은 OFAC의 민사 제재 권한을 다뤘을 뿐, 형사 책임에 관한 판단이 아니었다. DOJ가 스톰을 기소하는 능력에는 영향을 주지 않았고, 자금 전송 항목의 유죄 판결도 막지 못했다.

재심이 다시 테이블에 올려놓는 것들

현재까지 보도에 따르면 2026년 10월 재심은 평결이 갈렸던 항목을 다룰 것이다. 자금 세탁 및 제재 관련 이론이 다시 배심원 앞에 서게 되고, 다른 심리 지침, 증거 결정, 배심원 구성이 다른 결과를 만들어낼 수 있다. 어느 항목에서든 유죄 판결이 나온다면 개발자 책임의 경계는 첫 번째 평결이 설정한 것보다 훨씬 앞으로 나아간다. 자금 전송 유죄는 프로토콜 운영자에게 적용되지만, 알면서도 용이하게 했다는 논리에 기반한 자금 세탁이나 제재 위반 유죄는 더 넓은 범위의 개발자 행위, 특히 특정 불법 사용을 인지한 이후 프로토콜이 취한 조치에 관한 행위로까지 확장된다.

두 가지 함의가 뒤따른다. 첫째, 믹서 방식 프로토콜은 자금 서비스 사업자로 등록하거나 어떤 형태든 컴플라이언스 필터링을 중심으로 재구성해야 한다는 현재의 포스트-스톰 설계 합의는, 아직 완전히 해소되지 않은 평결 위에 서 있다. 둘째, 스톰 리스크를 설계적으로 해결했다고 주장하는 어떤 프라이버시 프로토콜도 스톰이 결국 확립할 수 있는 것의 절반에만 대응한 셈이다. 연관 집합 아키텍처를 법적 해답이 아니라 법적 가설로 취급하기 전에 이 점을 염두에 둬야 한다.

믹서 아키텍처가 컴플라이언스 기준을 통과하지 못한 이유

img2

토네이도 캐시의 아키텍처에는 기소 전체의 구조를 결정지은 단 하나의 특성이 있었다. 예금과 출금이 공유 풀에서 혼합된다는 것이다. 출금자는 영지식 회로를 통해 이전에 풀에 예금했다는 사실만 증명하고, 어느 예금이 자신의 것인지는 드러내지 않는다. 이것이 프라이버시 보장의 원천이자, 동시에 컴플라이언스 문제의 원천이다. 자금이 풀에 들어가는 순간, 프로토콜 자체는 깨끗한 예금과 라자루스 그룹 해킹 수익을 구분할 수 없다. 모든 출금은 풀 전체를 대상으로 한 출금이다.

규제 당국의 시각에서 이 설계는 거래상대방을 사실상 걸러낼 수 없는 가치 전송 서비스다. 개발자의 시각에서는 프로토콜의 사회적 가치 바로 그것이다. 선택적으로 들여다볼 수 없는 프라이버시 집합은 국가 행위자를 포함한 누구도 선택적으로 들여다볼 수 없다. 두 관점은 풀-앤-위드드로우 모델 안에서 타협점이 없다. 프로토콜은 혼합하거나 하지 않거나 둘 중 하나다. 혼합한다면, 운영자는 입구에서 예금을 걸러내거나 전혀 걸러내지 못하는 것을 받아들이거나 둘 중 하나다.

웹 인터페이스에서 제재 대상 주소를 차단하는 자발적 프론트엔드 필터링을 시도했지만 근본적인 문제를 해결하지 못했다. 스마트 컨트랙트는 직접 호출할 수 있었고, 풀 아키텍처 특성상 필터를 거친 예금조차 이전에 예금된 불법 자금과 분리할 수 없었다. 제5순회항소법원의 2024년 판결은 불변 스마트 컨트랙트가 OFAC이 제재할 수 있는 “재산”에 해당하는지라는 특정 문제를 다뤘고, 특정 자율적 구성 요소에 대해서는 아니라고 답했다. 그러나 이는 OFAC의 민사 권한에 대한 제한이었을 뿐, 프로토콜이 운영되는 동안 개발자들의 행위를 근거로 한 형사 자금 전송 혐의를 막아주는 방패가 아니었다.

포스트-토네이도 프로젝트들이 끌어낸 설계 교훈은 컴플라이언스가 프론트엔드 정책이 아니라 아키텍처의 핵심 요소여야 한다는 것이다. Privacy Pools는 예금이 익명 집합에서 출금 가능한 “승인” 상태가 되기 전에 필터링을 앞으로 이동시키면서도 승인된 자금에 대한 암호학적 프라이버시 보장을 유지하려 한다. Railgun은 혼합 모델 자체를 피하는 방식으로 이에 응한다. 두 가지 모두 맨해튼 배심원 앞에서 토네이도 캐시를 변호 불가능하게 만든 문제에 답하려는 시도다.

Privacy Pools와 연관 집합 모델

img3

Privacy Pools는 세 개의 레이어로 구성된다. 업그레이드 가능한 Entrypoint 컨트랙트를 중심으로 한 스마트 컨트랙트 레이어가 예금, 출금, 조율을 담당한다. 영지식 레이어는 커밋먼트 스킴과 출금 회로를 관리해, 출금자가 어느 커밋먼트가 자신의 것인지 밝히지 않으면서 집합의 구성원임을 증명한다. 연관 집합 제공자(ASP) 레이어는 승인된 예금 레이블의 큐레이션 집합, 즉 컴플라이언스 접면을 유지하고 권한 있는 계정을 통해 상태를 업데이트한다. 프로토콜은 일반적인 의미에서 비수탁형이다. 사용자 자금은 운영자의 키가 아니라 컨트랙트의 암호학적 커밋먼트로 보관된다.

사용자 경험은 직관적이다. 예금자가 풀에 자금을 커밋한다. ASP가 자체 기준에 따라 예금을 평가해 현재 승인 연관 집합에 포함하거나 제외한다. 포함되면 예금자(또는 지정된 수신자)가 나중에 승인된 집합의 구성원임을 증명하는 영지식 증명으로 출금할 수 있다. 출금은 특정 예금과 연결되지 않지만, 오직 ASP가 승인한 예금들 사이에서만 익명성이 보장된다. 부분 출금도 지원되어 잔여 잔액에 대한 프라이버시가 유지된다. 네이티브 ETH와 ERC-20 토큰 등 여러 자산 유형이 지원된다.

이것을 단순한 KYC의 다른 이름이 아니게 만드는 메커니즘이 ragequit이다. ASP가 예금 승인을 거부하면, 원래 예금자는 특정 예금을 공개적으로 드러내고 자금을 회수하는 공개 출금을 할 수 있다. 그 거래의 프라이버시는 포기되지만 자금 통제권은 유지된다. 이것이 검열 저항 안전장치다. ASP는 승인을 거부해 예금자의 자금을 가두어 둘 수 없다. 예금자에게 미승인 상태(비공개 출금 불가)로 남거나 공개 출금을 선택하도록 강제할 수 있을 뿐이다.

이 설계가 규제 당국 앞에서 버텨야 하는 부분

ragequit은 마케팅에서 담당하는 역할보다 실제로 할 수 있는 것이 적다. 민감하지만 합법적인 거래를 가진 예금자, 즉 이 시스템이 보호하려는 바로 그 예금자는 공개 출금을 사용하는 순간 예금한 이유 자체를 잃게 된다. 따라서 ragequit의 위협은 사실상 위협이 아니다. 재정적 통제권은 보존하지만 예금자가 원한 것을 대가로 치러야 하는 최후 수단에 불과하다. 실제로 ragequit은 예금자와 ASP 사이의 힘의 균형추라기보다 파산 선택지에 가깝다. ASP의 승인 결정이 실질적인 결정이다.

이는 Privacy Pools 문서가 해소하지 못한 질문을 제기한다. ASP는 법적으로 무엇인가? ASP 운영자는 어떤 기준, 아마도 체인 분석 신호, 제재 목록, 알려진 불법 출처에 대한 휴리스틱에 따라 예금을 심사하고 승인 레이블 목록을 생성한다. 이는 가치 전송 프로토콜에 판매되거나 내장된 컴플라이언스 서비스처럼 보인다. FinCEN이 ASP 운영자를 자금 서비스 사업자, 자금 서비스 사업자의 컴플라이언스 벤더, 혹은 둘 다 아닌 것으로 규정할지는 공개적으로 검토된 바 없다. 만약 “자금 서비스 사업자”라는 답이 나온다면, ASP 레이어는 풀 아키텍처가 분산시키려 했던 면허 부담을 그대로 안게 된다.

아키텍처 안에 두 가지 추가 주의 사항이 있다. Entrypoint가 업그레이드 가능하다는 점은 문서에 언급되어 있지만 분석은 없다. 업그레이드 권한은 규제적 압력 지점이다. 법원이나 규제 기관이 업그레이드 관리자에게 ASP 로직 변경, 특정 주소 차단 목록 추가, 출금 회로 수정을 강제할 수 있다면, 프로토콜의 검열 저항은 궁극적으로 해당 키를 보유한 자의 법적 입장에 달려 있다. Entrypoint 업그레이드 경로에 관한 공개 거버넌스 세부 사항, 즉 키 보유자, 멀티시그 구성, 타임락 파라미터는 우리가 검토한 발췌본에 없으며 배포된 컨트랙트에서 직접 확인이 필요하다.

두 번째 주의 사항은 ASP의 승인 기준이 프로토콜 설계 차원에서 외생적이라는 점이다. 암호학적 구조 자체는 ASP가 압력 하에 기준을 강화하거나, 소급 삭제를 추가하거나, 다른 ASP들과 사실상 공유 차단 목록으로 수렴하도록 강요받는 것을 막지 않는다. 검열 저항 논리는 여러 ASP가 실제로 경쟁하거나 단일 ASP에 대해 과도한 배제가 의미 있는 비용을 수반한다는 가정 위에 서 있다. 두 가정 모두 아키텍처적 보장이 아니라 경험적 가정이다.

Privacy Pools 모델은 이더리움 재단의 Kohaku 프라이버시 지갑 이니셔티브, 주제 브리프에서 지갑 레이어에서 프라이버시를 기본값으로 만들려는 EF의 이니셔티브로 소개된 프로젝트의 주목을 받고 있다. Kohaku와 Privacy Pools의 정확한 관계, 즉 통합인지, 지지인지, 더 느슨한 관계인지는 우리가 검증할 수 있는 자료에서 확인되지 않으며, 이 글은 그것을 확정적 사실이 아닌 방향성으로 다룬다.

Railgun의 노이즈 기반 아키텍처

img4

Railgun은 구조적으로 다른 위치를 취한다. 문서에 따르면 이더리움, BSC, Polygon, Arbitrum에 배포된 소유자 없는 스마트 컨트랙트 코드다. 사용자는 일반 블록 익스플로러에서 확인되지 않는 “0zk 주소”를 받는다. 아키텍처상 핵심 주장은 Railgun이 사용자 간 자금을 혼합하지 않는다는 것이다. 토네이도 캐시가 예금을 공유 풀에 혼합한 방식 없이, 영지식 암호화를 통해 토큰과 지갑이 식별 불가능해진다.

그 결과 익명 집합은 유동성이 아니라 주로 활동량에 의해 생성된다. 사용자는 차폐된 환경 안에서 스왑, 대출, 차입, dApp 호출을 할 수 있다. 각각의 상호작용이 노이즈를 더한다. 두 Railgun 사용자 간의 비공개 스왑은 온체인에서 Railgun 트랜잭션처럼 보이고, 비공개 결제도 Railgun 트랜잭션처럼 보이며, 비공개 DeFi 포지션 조정도 Railgun 트랜잭션처럼 보인다. 단일 행위에 대한 프라이버시 집합은 자금을 믹싱 풀에 묶어두지 않아도, 같은 차폐 환경에서 발생하는 무관한 행위들의 총 거래량과 함께 커진다.

주제 브리프는 연구 시점 기준 Railgun의 누적 차폐 거래량을 ~45억~50억 달러로 제시한다. 이 수치를 이 글에서 검토할 수 있는 온체인 데이터 소스와 독립적으로 확인하지 못했다. 이 수치는 공개 보도와 방향성이 일치하는 것으로 읽어야 하며, 정확한 수치로 사용하려면 Dune 같은 대시보드에서 직접 확인이 필요하다. 1차 문서에서 방어할 수 있는 것은 아키텍처적 주장이다. 시스템은 네 개 체인에서 실제로 배포되어 있고, 믹서에 대한 집행 시대 전반에 걸쳐 운영 중이며, 비혼합 설계를 컴플라이언스와 관련된 차별점으로 제시한다.

성장이 정당성의 증거가 아닌 이유

흥미로운 질문은 Railgun이 성장했는지 여부가 아니라, 그 성장의 원인이 무엇이냐는 것이다. 동일한 데이터와 양립하는 세 가지 설명이 있다. 첫째, Railgun의 비혼합 아키텍처와 합법적 사용 사례에 대한 문서의 강조, 전문직 기밀 유지, HIPAA, GDPR, 비공개 급여 지급, 지갑 레이블링 서비스로부터의 보호가 실제로 토네이도 캐시와 다른 법적 위치를 점한다는 것이다. 둘째, 토네이도 캐시가 제재된 뒤에도 믹서 수요는 사라지지 않았고, 살아남은 프라이버시 인프라로 옮겨갔다는 것이다. 셋째, Railgun의 DeFi 네이티브 차폐 환경이 법 집행기관으로부터의 프라이버시보다 프론트러닝, MEV, 지갑 추적 서비스로부터의 프라이버시에 관심 있는 사용자들을 끌어들였다는 것이다. 이는 토네이도 캐시가 제대로 서비스하지 못한 별개의 시장이다.

세 가지 설명은 상호 배타적이지 않으며, 어느 것도 규제 승인과 동등하지 않다. 미국 규제 당국 중 Railgun의 아키텍처가 AML이나 BSA 의무를 충족한다고 공개적으로 승인한 곳은 없다. Railgun 자체의 프레이밍, 비수탁형, 소유자 없음, 거버넌스 토큰 불필요, 규제받는 전문가를 위한 컴플라이언스 도구로서의 프라이버시는 법적 입장이지 법적 판결이 아니다. 스톰 사건은 “소유자 없음”과 “비수탁형”이 개발자 책임 문제를 해소하지 못한다는 점을 상기시킨다. 무허가 자금 전송 혐의는 스톰이 사용자 자금을 보관할 것을 요구하지 않았다. 토네이도 캐시가 타인을 위해 가치를 전송하고 스톰의 행위가 공모 기준을 충족할 것을 요구했다. 비수탁형으로 비공개 가치를 전송하는 프로토콜은 여전히 그 이론의 적용 범위 안에 있다.

Railgun의 더 강한 구조적 위치가 있다면, 비혼합 설계가 정부의 토네이도 이론이 의존한 기술적 의미의 믹서가 아니라는 그럴듯한 주장을 가능하게 한다는 점이다. 그 주장이 결의에 찬 검사 앞에서도 유효한지는 아직 검증되지 않았다.

컴플라이언스 프라이버시의 세 가지 실패 시나리오

img5

“컴플라이언스 프라이버시”를 확립된 설계 패턴으로 보는 시각은 현재 법적 환경이 공급하지 못하는 안정성을 전제한다. 구체적으로 세 가지 실패 시나리오를 명시해야 한다.

첫 번째는 컴플라이언스 레이어의 규제적 재규정이다. ASP 운영자가 FinCEN의 정의에 따라 자금 서비스 사업자, 혹은 주별 면허 의무가 있는 컴플라이언스 중개자로 판단된다면, ASP 레이어는 풀 아키텍처가 분산시키려 했던 면허 부담을 그대로 안게 된다. 이것이 반드시 설계 자체를 죽이지는 않는다. 더 명확한 법적 지위를 가진 면허 받은 ASP 생태계로의 이행을 촉진할 수 있다. 그러나 컴플라이언스 레이어가 가벼운 부가 요소라는 현재의 전제를 무효화하고, 면허 받은 컴플라이언스 중개자는 일반적으로 자신이 승인하는 당사자를 알아야 하므로 “KYC 없음” 주장도 무너진다.

두 번째는 검열의 점진적 강화다. 지속적인 규제 압력 하에 놓인 단일 지배적 ASP는 과도하게 배제할 강력한 유인을 갖는다. 합법적이지만 민감한 예금, 활동가 기부금, 내부고발자 결제, ASP가 고위험으로 분류하는 지역에서의 거래는 ASP에게는 매우 낮은 비용으로, 예금자에게는 매우 높은 비용으로 승인 거부될 수 있다. 예금자의 유일한 구제 수단은 프로토콜 사용 이유 자체를 무효화하는 공개 ragequit뿐이다. Privacy Pools의 검열 저항 논리는 진정한 ASP 경쟁이 존재하거나 과도한 배제에 의미 있는 비용이 따른다는 가정에 달려 있다. 어느 쪽도 아키텍처가 보장하지 않는다. 두 가지 모두 재심, FinCEN 지침, 민형사상 리스크에 대한 ASP 운영자의 반응에 의해 형성될 정책적 결과다.

세 번째는 스톰 재심의 직접적 선례다. 2026년 10월 재심에서 자금 세탁 또는 제재 위반 공모 항목 중 어느 하나라도 유죄 판결이 나온다면, 개발자 책임의 경계는 무허가 자금 전송을 넘어 알면서도 용이하게 한 행위로까지 확장된다. Privacy Pools처럼 식별 가능한 컴플라이언스 레이어를 가진 프로토콜은 ASP의 역할이 불법 사용을 방지하려는 지속적인 시도를 문서화하기 때문에 그 이론에 대해 토네이도 캐시보다 유리한 위치에 있다고 볼 수 있다. 그러나 “유리한 위치에 있다고 볼 수 있다”는 것이 “안전하다”와 같지 않다. 필터링 의도를 문서화하는 모든 아키텍처 요소는 불리한 소송에서 개발자들이 무엇을 언제 알았는지에 대한 증거가 될 수도 있다. 재심은 Railgun의 소유자 없는 비혼합 설계, Privacy Pools의 명시적 컴플라이언스 레이어, 혹은 제3의 접근 방식 중 어느 것이 두 번째 평결이 만들어낼 법적 환경에 가장 적합한지를 결정할 것이다.

현재 설계 공간에 대한 솔직한 평가는 이렇다. Privacy Pools도 Railgun도 토네이도 캐시를 형성한 것과 같은 종류의 집행 조치를 받아본 적이 없다. 두 시스템 모두 2025년 8월 평결과 2026년 10월 재심 사이의 간격에서 운영 중이며, 그 간격의 실질적 결과는 진정으로 미정이다. Kohaku를 통한 이더리움 재단의 Privacy Pools 모델에 대한 관심은 더 넓은 생태계가 연관 집합 큐레이션을 지갑 레이어에서의 더 유력한 수렴 지점으로 보고 있음을 시사하지만, 그 베팅은 완전히 답이 나오지 않은 법적 질문 앞에 놓여 있다.

어느 정도 확신을 갖고 말할 수 있는 것은 무엇을 주시해야 하는가다. 영지식 프라이버시 프로토콜을 다루는 FinCEN의 어떠한 지침이든, 공식이든 비공식이든, ASP 운영자의 셈법을 실질적으로 바꿀 것이다. Railgun을 향한 소환장이나 민사 소송은 그 비혼합 아키텍처가 문서가 암시하는 다른 법적 위치를 실제로 점하고 있는지를 시험할 것이다. Privacy Pools Entrypoint 업그레이드 권한 구성의 변화, 또는 ASP 운영자의 승인 기준 변화는 프로토콜이 정식 집행 이전의 압력에 어떻게 반응하는지를 드러낼 것이다. 2026년 10월 재심은 자금 세탁 및 제재 이론을 미해결 상태로 남겨 현재의 설계 합의를 확인하거나, 스톰을 무죄로 풀어 이를 확장하거나, 유죄 판결로 뒤흔들 것이다. 그때까지 현 세대의 프라이버시 프로토콜은 어떤 아키텍처적 베팅이 아직 스스로를 완전히 정의하지 못한 법적 환경에서 살아남는지를 두고 살아있는 실험을 하고 있다.

cover

はじめに

2025年8月6日、ニューヨーク南部地区で4週間の裁判が行われ、その後約1週間の評議を経て、陪審はRoman Stormに対して分割評決を下した。無許可の資金送金事業を運営する共謀については有罪。マネーロンダリングの共謀とIEEPA制裁違反の共謀については評決不一致となった。不一致となった訴因は無罪放免ではなく部分的な無効審判を意味し、政府は2026年10月に再審を求めたと報じられている。

この分割評決が重要なのは、それぞれの側が異なる設計上の問いを指し示しているからだ。有罪評決は狭いが具体的なことを示している。Tornado Cashの運営と宣伝に関わる一部の行為が、陪審にとって無許可の資金送金の基準を満たした、ということだ。評決不一致は、より難しい問い、つまりその行為がマネーロンダリングや制裁違反にも該当するかどうか、が法的に未解決のまま残ることを意味する。次世代のオンチェーンプライバシーを構築するプロトコル設計者は、後半部分がどう決着するかわからない状態で、両方に備えなければならない。

この設計上の議論を支える二つのシステムがある。Privacy Poolsは、プロジェクト自身のコミュニケーションによれば2025年3月にEthereumで稼働しており、ゼロ知識プールにキュレートされたアソシエーション・セット・レイヤーを付加することでTornadoの問いに直接答えようとしている。承認されなかった資金を持つ預金者には公開出口が用意されている。Railgunは、Ethereum、BSC、Polygon、Arbitrumにデプロイされており、構造的に異なる経路をとる。ミキシングなし、アソシエーション・セット・キュレーターなし、シールドされた環境内で行われるDeFi活動の副産物としてプライバシーが生成される。どちらも稼働中だ。どちらも規制当局のお墨付きを得ていない。問題は、Stormの再審が決着し、開発者責任の問いの後半部分に答えが出たとき、いずれかの均衡が保たれるかどうかだ。

Storm評決が実際に決定したこと

img1

起訴状はStormに三つの共謀を問うた。無許可の資金送金、マネーロンダリング、およびIEEPA制裁違反だ。当事者は裁判を絞り込む一部の事実を合意した。Stormは自ら資金を洗浄していない。Tornado Cashは正当な取引にも違法な取引にも使われていた。Stormは在職中のある時点で、犯罪者がプロトコルを利用していることを認識した。政府の理論は、その認識の後もTornado Cashを運営・宣伝し続け、適切な安全策の実装を怠ったこと自体が犯罪行為だというものだった。

弁護側は中立的ツール論を展開した。この見方によれば、Tornado CashはVPN、暗号化メッセンジャー、あるいはハンマーと同列に位置する。汎用インフラの構築者は、誰かがどこかでそれを悪用すると知っているだけで刑事責任を問われることはない、というわけだ。陪審はその主張を部分的に支持した。害が「ユーザーの行為」によって定義される二つの訴因、特定の違法活動の収益の洗浄と制裁対象者への送金、については評決不一致となった。害が「Stormの行為」によって定義される訴因、FinCENが要求するライセンスなしに他者のために価値を送金する事業を運営したこと、については有罪となった。

これは裁判前の報道が示唆したよりも狭い評決であり、弁護側が望んだよりも広い評決だ。Mayer BrownのこのケースへのアナリシスはMayer Brown、マネー送金の有罪評決をミキサーや取引所の開発者・運営者への指示として読む。FinCENの定義に照らして自分たちが資金送金事業を運営しているかどうかを評価し、もしそうであれば、適切な連邦・州のライセンスを取得せよ、ということだ。これは確定した法的ルールではなく、ある地区の陪審評決に対する一法律事務所の解釈だが、コンプライアンスを重視するプロトコルチームの多くが現在の作業前提としているものだ。

評決と並んで二つの法的事実が存在する。2022年8月、OFACはTornado Cashを制裁し、プロトコルが70億ドル超のロンダリングを促進したと主張した。その中にはAxie Infinityハッキングにより北朝鮮のLazarus Groupに帰属するとされる約6億ドルも含まれる。これらは制裁申請における政府の主張であり、法的に確定した事実認定ではない。2024年12月、第五巡回区控訴裁判所は、OFACが特定の自律的Tornado Cashプロトコルを制裁した際に権限を逸脱したと判断した。この判決における「特定の自律的プロトコル」の正確な範囲は、よく言われる短縮表現よりも狭く、判決全文を読む必要があるが、当該判決が扱ったのは民事制裁権限の問題であり、刑事責任に対する盾ではない。DOJによるStorm訴追の能力に影響を与えず、マネー送金の訴因からStormを救いもしなかった。

再審が再び問いに付すもの

入手可能な報道が示す限り、2026年10月の再審は評決不一致となった訴因を対象とする。つまり、マネーロンダリングと制裁違反の理論が再び陪審に委ねられ、異なる陪審説示、証拠採否の判断、陪審員の組み合わせによって異なる結果が生まれるかもしれない。いずれかの訴因で有罪となれば、開発者責任の境界線は最初の評決が残した地点をはるかに越えることになる。マネー送金の有罪評決がプロトコル運営者に関わるものであるとすれば、故意の幇助を根拠とするマネーロンダリングまたは制裁違反の有罪評決は、より広い範囲の開発者の行為、特に具体的な違法利用を知った後にプロトコルが何をするかという点、に関わってくる。

二つの帰結がある。第一に、Storm後の現在の設計コンセンサス、つまりミキサー型プロトコルは資金サービス事業者として登録するか、何らかのコンプライアンス・フィルタリングを中心に再設計すべきだという考え方は、まだ完全に決着していない評決の上に成り立っている。第二に、Storm訴訟のリスクを回避したと主張するプライバシープロトコルは、Stormが最終的に確立するかもしれないものの半分にしか対処していない。アソシエーション・セット・アーキテクチャを法的な回答として扱う前に、それが法的な仮説に過ぎないことを念頭に置く必要がある。

ミキサーのアーキテクチャがコンプライアンス・テストに失敗した理由

img2

Tornado Cashのアーキテクチャには、訴追全体の構造を規定した一つの特徴があった。入金と出金が共有プールで混合されることだ。出金者は、自分のどの入金であるかを明かすことなく、以前にプールに入金したことをゼロ知識回路で証明した。これがプライバシー保証の源泉であり、同時にコンプライアンス問題の源泉でもある。資金がプールに入ると、プロトコル自体がクリーンな入金とLazarus Groupのハッキング収益を区別できなくなる。すべての出金はプール全体に対する出金となる。

規制当局の視点から見れば、この設計は取引相手を選別する実質的な能力を持たない価値送金サービスだ。開発者の視点から見れば、それこそがプロトコルに社会的価値を与える特性だ。選択的に破ることのできないプライバシー・セットは、国家機関を含む誰によっても選択的に破ることができない。この二つのフレームは、プール&ウィズドローモデルの内部では妥協点を見いだせない。プロトコルは混合するかしないか。混合する場合、運営者は入口で入金をスクリーニングするか、まったくスクリーニングできないことを受け入れるか、のどちらかだ。

ウェブインターフェースで制裁対象アドレスをブロックする自発的なフロントエンド・スクリーニングは試みられたが、根本的な問題を解決しなかった。スマートコントラクトは直接呼び出し可能なままであり、プールの構造上、フィルタリングされた入金であっても既存の違法資金から分離することはできなかった。第五巡回区控訴裁判所の2024年判決は、不変のスマートコントラクトがOFACが制裁できる「財産」に当たるかという特定の問いを扱い、特定の自律的コンポーネントについては否と答えた。しかしそれはOFACの民事権限に対する制限であり、プロトコルの運営中に開発者が行ったことを根拠とする刑事的なマネー送金の訴追に対する盾ではなかった。

Tornado後のプロジェクトが引き出したように見える設計上の教訓は、コンプライアンスはフロントエンドのポリシーではなく、第一級のアーキテクチャ上の特性でなければならない、ということだ。Privacy Poolsは、入金が匿名セットへの出金のために「承認済み」と見なされる前にスクリーニングを上流に移動させることでこれを実現しつつ、承認された資金に対する暗号論的なプライバシー保証を維持しようとしている。Railgunは、混合モデルを完全に回避することでこれを実現する。どちらもマンハッタンの陪審の前でTornadoを弁護不可能にした反論に答えようとする試みだ。

Privacy Poolsとアソシエーション・セット・モデル

img3

Privacy Poolsは三つのレイヤーで構成されている。アップグレード可能なEntrypointコントラクトを中心とするスマートコントラクト・レイヤーが、入金、出金、調整を担う。ゼロ知識レイヤーがコミットメント・スキームと出金回路を管理し、出金者はどのコミットメントが自分のものかを明かすことなく、セットへのメンバーシップを証明する。**Association Set Provider(ASP)**レイヤーが承認済み入金ラベルのキュレートされたセット、つまりコンプライアンス・サーフェス、を維持し、認可されたアカウントを通じて状態を更新する。プロトコルは標準的な意味で非カストディアルだ。ユーザーの資金はいかなる運営者の鍵でもなく、コントラクト内の暗号論的コミットメントによって保持される。

ユーザー体験はわかりやすい。預金者はプールに資金をコミットする。ASPがその入金を基準に照らして評価し、現在の承認済みアソシエーション・セットに含めるかどうかを判断する。含まれれば、預金者(または指定した受取人)は後に承認済みセットへのメンバーシップのゼロ知識証明を使って出金できる。出金は特定の入金とリンクできないが、それはASPが承認した入金の中においてのみだ。部分出金がサポートされており、残高のプライバシーが保たれる。ネイティブETHとERC-20トークンという複数の資産タイプに対応している。

これをKYCの言い換えでないものにしているメカニズムがragequitだ。ASPが入金の承認を拒否した場合、元の預金者は公開出口を使い、特定の入金を明かして資金を回収できる。そのトランザクションのプライバシーは失われるが、カストディは保全される。これが検閲耐性のバックストップだ。ASPは承認を拒否することで預金者の資金を閉じ込めることができない。未承認のまま(プライベートに出金できない状態)か、公開で退出するかを預金者に選ばせることしかできない。

設計が規制当局との接触において成立しなければならない点

ragequitはマーケティング上で実態以上の仕事を担わされている。正当だが敏感なトランザクションを持つ預金者、システム全体が本来サービスを提供しようとしているユーザー、は公開出口を使えばそもそも入金した理由が失われる。ragequitの脅しは、したがって本当の意味での脅しではない。財務的なカストディを保全するが、そのために預金者が求めてきたものを犠牲にするフォールバックだ。実際には、ragequitは預金者とASPの間の均衡装置というより、破産手続きのような選択肢として機能する。ASPの承認決定が実質的な権限を持つ。

これはPrivacy Poolsのドキュメントが解決していない問いを提起する。ASPとは法的に何者か?ASP運営者は何らかの基準、おそらくチェーン分析のシグナル、制裁リスト、既知の違法資金源に関するヒューリスティック、に照らして入金をスクリーニングし、承認済みラベルのリストを作成する。それは価値送金プロトコルに組み込まれる、あるいはそれに販売されるコンプライアンス・サービスのように見える。FinCENがASP運営者を資金サービス事業者として分類するのか、その事業者向けのコンプライアンス・ベンダーとして分類するのか、あるいはどちらでもないとするのか、は公に検証されていない。答えが「資金サービス事業者」であれば、ASPレイヤーはプール・アーキテクチャがそこから分散させようとしていたライセンスの負担をそのまま引き継ぐことになる。

アーキテクチャの内部にさらに二つの留保がある。Entrypointはアップグレード可能であり、ドキュメントはその点を記載しているが分析していない。アップグレード権限は規制上の急所だ。裁判所や機関がアップグレード管理者にASPロジックの変更、特定のアドレスのブロックリスト追加、あるいは出金回路の修正を強制できるとすれば、プロトコルの検閲耐性は最終的にその鍵を持つ者の法的立場に依存することになる。Entrypointのアップグレード・パス、鍵の保有者、マルチシグの構成、タイムロックのパラメータに関する公開ガバナンスの詳細は、我々が参照した抜粋には含まれておらず、デプロイ済みコントラクトを直接確認する必要がある。

第二の留保は、ASPの承認基準がプロトコル設計上、外生的だということだ。ASPが圧力を受けて基準を厳しくすること、遡及的な削除を追加すること、あるいは他のASPと事実上の共有ブロックリストへの収束を迫られることを、暗号技術は何ら妨げない。検閲耐性のストーリーは、複数のASPが競争するか、ragequitの出口が単一ASPの行動を実質的に制約するという前提に依拠している。どちらの前提もアーキテクチャによって保証されているのではなく、実証的な問いだ。

Privacy Poolsモデルは、Ethereum FoundationのKohakuプライバシー・ウォレットの取り組みの中で注目を集めている。トピック・ブリーフはKohakuをEFがウォレット層でプライバシーをデフォルトにしようとする取り組みとして説明している。KohakuとPrivacy Poolsの正確な関係、統合なのか、推薦なのか、あるいはもっとゆるやかなものなのか、は我々が確認できるソースには文書化されておらず、この記事では方向性の示唆として扱うに留める。

Railgunのノイズ・オーバー・ミキシング・アーキテクチャ

img4

Railgunは異なる構造的立場をとる。そのドキュメントはシステムを、Ethereum、BSC、Polygon、Arbitrumにデプロイされた、所有者のないスマートコントラクト・コードとして説明する。ユーザーは標準的なブロック・エクスプローラーでは非公開となる「0zkアドレス」を受け取る。アーキテクチャ上の核心的な主張は、Railgunがユーザー間で資金を混合しないということだ。Tornado Cashが入金をプールで混合した方法とは異なり、トークンとウォレットはコミングルなしにゼロ知識暗号技術によって判別不可能になる。

その結果、匿名セットは流動性ではなく主として活動によって生成される。ユーザーはシールドされた環境の内側からスワップ、レンディング、借入、dAppへの呼び出しを行える。それぞれのインタラクションがノイズを加える。二人のRailgunユーザー間のプライベートなスワップはオンチェーンではRailgunトランザクションに見え、プライベートな支払いもRailgunトランザクションに見え、プライベートなDeFiポジションの調整もRailgunトランザクションに見える。単一の行動のプライバシー・セットは、同じシールドされた環境で行われる無関係な行動の総量とともに拡大する。ユーザーは資金をミキシング・プールに預け置く必要がない。

トピック・ブリーフは調査期間時点のRailgunの累積シールド・ボリュームとして~45億〜50億ドルという数字を挙げている。本稿で入手できた資料では、この数字をオンチェーンのデータソースと照合して独自に確認していない。精確な数値として扱うにはDuneなどのダッシュボードで検証が必要だが、公開報道と方向的に整合しているとは言える。一次ドキュメントから擁護できるのはアーキテクチャ上の主張だ。システムはミキサーへの執行が続く時代を通じて四つのチェーンにまたがって稼働し続けており、非混合設計をコンプライアンス上の差別化要因として位置づけている。

成長は正当性の証拠ではない

興味深い問いはRailgunが成長したかどうかではなく、その成長を何に帰属させるかだ。同じデータと整合する三つの説明がある。第一は、Railgunの非混合アーキテクチャと、正当なユースケース(職業上の守秘義務、HIPAA、GDPR、プライベートな給与支払い、ウォレット・ラベリング・サービスからの保護)を強調するドキュメントが、Tornado Cashとは本当に異なる法的立場を占めているというものだ。第二は、Tornado Cashが制裁されたときにミキサーへの需要は消えず、稼働中のプライバシー・インフラへと移動したというものだ。第三は、RailgunのDeFi・ネイティブなシールド環境が、法執行機関からのプライバシーではなく、フロント・ランナー、MEV、ウォレット・トラッキング・サービスからのプライバシーを主に求めるユーザーを引きつけたというものだ。これはTornado Cashが不得意としていた別個の市場だ。

三つの説明は相互に排他的ではなく、いずれも規制当局による承認と同義ではない。米国の規制当局はRailgunのアーキテクチャがAMLやBSAの義務を満たすと公式に認めていない。Railgunの自己定義、非カストディアル、所有者なし、ガバナンストークン不要、規制を受ける専門家向けのコンプライアンス・ツールとしてのプライバシー、は法的な立場であって法的な裁定ではない。Storm訴訟は、「所有者なし」「カストディなし」が開発者責任の問いを解決しないことを示した。無許可のマネー送金の訴因はStormがユーザーの資金を管理することを必要とせず、Tornado Cashが他者のために価値を送金し、Stormの行為が共謀の基準を満たすことを必要としただけだ。カストディなしでプライベートに価値を送金するプロトコルはその理論の射程に入り続ける。

Railgunがより強固な構造的立場を持つとすれば、その非混合設計により、政府のTornado理論が依拠した技術的な意味でのミキサーではないという議論が成立しうることだ。その議論が断固とした検察官に耐えうるかどうかは未検証だ。

コンプライアント・プライバシーの三つの失敗モード

img5

「コンプライアント・プライバシー」を確立された設計パターンとして枠組みすることは、現在の法的環境が提供していない安定性を前提とする。三つの失敗モードは具体的に名指しする価値がある。

第一は、コンプライアンス・レイヤーの規制上の再分類だ。ASP運営者がFinCENの定義の下で資金サービス事業者とみなされる場合、あるいは州ごとのライセンスが必要なコンプライアンス仲介者とみなされる場合、ASPレイヤーはプール・アーキテクチャが回避しようとしていたライセンスの負担をそのまま引き継ぐ。これは必ずしも設計を台無しにするわけではなく、より明確な法的地位を持つ認可ASPエコシステムへの移行を促すかもしれないが、コンプライアンス・レイヤーが軽量なアドオンだという現在の前提を無効にする。また、認可された仲介者は通常、承認する相手を知る必要があることから、「KYCなし」という主張も崩れる。

第二は検閲の忍び寄りだ。持続的な規制圧力にさらされた単一の支配的ASPは、過剰に排除する強い動機を持つ。正当だが敏感な入金、活動家への寄付、内部告発者への支払い、ASPが高リスクと判断する地域からのトランザクション、はASPにとってはほぼコストなく、預金者にとっては高コストで否認できる。預金者の唯一の手段は、プロトコルを使った理由を失わせる公開ragequitだ。Privacy Poolsの検閲耐性のストーリーは、真の意味でのASP競争か、過剰排除に対する実質的なコストのどちらかに依存する。どちらもアーキテクチャによって保証されていない。いずれも、再審と、FinCENのガイダンスと、民事・刑事リスクに対するASP運営者の対応によって形作られる政策上の結果だ。

第三は、Stormの再審からの直接の先例だ。2026年10月にマネーロンダリングまたは制裁違反の共謀の訴因のいずれかで有罪となれば、開発者責任の境界線は無許可の資金送金を越え、故意の幇助にまで及ぶ。識別可能なコンプライアンス・レイヤーを持つPrivacy Poolsのようなプロトコルは、ASPの役割が違法利用を防ぐ継続的な試みを文書化しているため、その理論に対してTornado Cashよりも有利な立場にあると言えるかもしれない。しかし「おそらく有利」は「安全」ではない。スクリーニングの意図を文書化するすべてのアーキテクチャ上の特徴は、不利な訴訟においては、開発者が何を知っていてそれをいつ知ったかの証拠でもある。再審は、Railgunの所有者なしの非混合設計、Privacy Poolsの明示的なコンプライアンス・レイヤー、あるいは第三のアプローチのうち、どれが第二の評決が生み出す法的環境に最も適合するかを形作ることになる。

現在の設計空間を正直に読めば、Privacy PoolsもRailgunも、Tornado Cashを形作った種類の執行措置でテストされていない。どちらも2025年8月の評決と2026年10月の再審の間隔で運営されており、その期間の実際の結果は本当に未確定だ。KohakuによるEthereumファウンデーションのPrivacy Poolsモデルへの関心は、より広いエコシステムがウォレット層の収束点としてアソシエーション・セット・キュレーションを有力視していることを示唆しているが、そのベットは完全に答えが出ていない法的問いに対して置かれている。

ある程度の確信を持って言えるのは、何を注視すべきかだ。ゼロ知識プライバシー・プロトコルを対象とするFinCENのガイダンスは、正式なものであれ非公式なものであれ、ASP運営者の計算を大きく変えうる。Railgunに向けられた召喚令状や民事訴訟は、その非混合アーキテクチャがドキュメントの示す異なる法的立場を実際に占めているかを検証することになる。Privacy PoolsのEntrypointのアップグレード権限の構成変更、あるいはASP運営者の承認基準の変更は、正式な執行に至らない圧力に対してプロトコルがどう反応するかを明らかにする。2026年10月の再審は、マネーロンダリングと制裁違反の理論を未解決のまま残すことで現在の設計コンセンサスを確認するか、Storm無罪によってそれを強化するか、あるいは有罪によってそれを揺るがすかのいずれかだ。それまでの間、現世代のプライバシー・プロトコルは、まだ自らの定義を終えていない法的環境においてどのアーキテクチャ上の賭けが生き残るかについて、ライブな実験を走らせている。

cover

引言

2025年8月6日,在纽约南区为期四周的庭审结束后,陪审团经过约一周的审议,对Roman Storm作出了分裂裁决:认定其共谋经营无牌货币传输业务罪名成立;共谋洗钱罪与共谋违反IEEPA制裁罪两项指控则陷入僵局。悬而未决的指控导致部分无效审判,而非无罪释放,检察官此后已申请重审,据报道定于2026年10月进行。

这一分裂裁决之所以重要,在于它的两面各自指向不同的设计命题。定罪部分说明了一件具体但范围有限的事:至少就经营和推广Tornado Cash的某些行为而言,已足以达到陪审团认定无牌货币传输罪的门槛。僵局部分则说明,更难回答的问题——上述行为是否同样构成洗钱和违反制裁——在法律层面仍未有定论。正在构建下一代链上隐私协议的协议设计者,必须同时应对这两种可能,而无法预知后半场将如何收场。

当前这场设计讨论围绕两个系统展开。Privacy Pools根据项目方公开通讯已于2025年3月在以太坊上线,它试图直接回应Tornado问题:在零知识池上附加一个经过筛选的关联集层,为资金未获批准的存款人提供公开退出通道。Railgun已部署在以太坊、BSC、Polygon和Arbitrum上,走的是结构性不同的路径:无混币、无关联集管理者,隐私性作为在屏蔽环境内开展DeFi活动的副产品自然生成。两者均已上线,均未获任何监管机构背书。问题在于:一旦Storm重审落幕、开发者责任问题的后半场得到裁定,这两种均衡态还能否维持。

Storm裁决究竟裁定了什么

img1

起诉书对Storm提出三项共谋指控:无牌货币传输、洗钱,以及违反IEEPA制裁。双方就部分事实达成协议,缩小了庭审范围。Storm本人并未亲自洗钱;Tornado Cash同时被用于合法交易和非法交易;Storm在任职期间的某个时间点意识到有犯罪行为者在使用该协议。检察官的理论是:在知悉上述情况后仍继续经营和推广Tornado Cash,且未能实施充分防护措施,本身即构成犯罪行为。

辩护方采用了”中性工具”论点。在这一框架下,Tornado Cash与VPN、加密通讯软件或一把锤子并无二致:构建通用基础设施的开发者,仅凭知道有人会滥用该工具这一事实,不应承担刑事责任。陪审团部分接受了这一论点。在两项以用户行为界定危害的指控上出现僵局——洗钱(将特定违法活动所得转移)和向受制裁方转移价值。在以Storm自身行为界定危害的指控上则作出定罪——即在未获FinCEN要求的牌照的情况下,经营一家替他人传输价值的业务。

这一裁决比庭前报道所暗示的更窄,也比辩护方所期望的更宽。Mayer Brown对该裁决的分析认为,货币传输定罪向混币器和交易所的开发者及运营者传递了一个信号:评估自己是否在FinCEN定义下经营货币传输业务,如果是,则须取得相应的联邦和州级牌照。这不是确立的法律规则,而是一家律所对某一地区陪审团裁决的解读,但它是大多数注重合规的协议团队目前所依据的工作假设。

此外还有两个法律事实与该裁决并存。2022年8月,OFAC对Tornado Cash实施制裁,声称该协议协助洗钱逾70亿美元,其中约6亿美元源自Lazarus Group在Axie Infinity黑客事件中的所得。这些是制裁文件中的政府指控,并非经司法认定的事实。2024年12月,第五巡回法院裁定OFAC在对某些自主运行的Tornado Cash协议实施制裁时超越了其职权范围。该裁决中”某些自主协议”的具体范围比通常的简化表述更窄,需结合完整判决意见来理解,且该裁决针对的是民事制裁权,而非刑事责任。它既未动摇司法部对Storm提起诉讼的能力,也未使他免于货币传输罪的定罪。

重审将哪些问题重新置于风险之中

据现有报道,2026年10月的重审将审理悬而未决的指控。这意味着洗钱和制裁理论将再度提交陪审团,而不同的庭审指示、证据裁定和陪审员组成,可能导致不同的结果。任何一项指控若获定罪,开发者责任的边界将远超第一次裁决所划定的位置。货币传输定罪涉及协议运营者;若基于知情协助的洗钱或制裁定罪成立,则将涵盖更广泛的开发者行为,尤其是协议在知悉特定非法使用后的应对方式。

由此引出两点结论。第一,当前后Storm时代的设计共识——混币风格的协议应么以货币服务企业身份注册,要么围绕某种合规过滤机制重构——所依据的裁决尚未完全盖棺定论。第二,任何声称已针对Storm风险进行设计的隐私协议,实际上只针对Storm案最终可能确立的结论的一半进行了设计。在将关联集架构视为法律答案而非法律假设之前,这一点值得认真考量。

混币架构为何未能通过合规检验

img2

Tornado Cash的架构有一个特征构成了整个起诉的基础:存款和提款在共享池中混合。提款人通过零知识电路证明自己曾向该池存款,但不披露具体是哪笔存款。这既是隐私保障的来源,也同时是合规问题的根源。一旦资金进入池子,协议本身就无法区分干净的存款与Lazarus Group黑客所得。任何提款都是对整个池子的提款。

从监管者的角度来看,这种设计在功能上是一种价值传输服务,根本无法筛查交易对手。从开发者的角度来看,这恰恰是赋予协议社会价值的属性:一个无法被选择性破解的隐私集,就是对任何人都无法被选择性破解,包括国家行为者。这两种框架在”存入-提取”模型内部不存在妥协空间。协议要么混合,要么不混合;如果混合,运营者要么在入口处筛查存款,要么接受自己根本无法筛查的现实。

自愿性前端筛查——在网页界面屏蔽受制裁地址——已被尝试过,但未能解决根本问题。智能合约仍可直接调用,而池化架构意味着即便经过过滤的存款,也无法与此前存入的非法资金脱钩。第五巡回法院2024年的裁决所针对的,是不可变智能合约是否构成OFAC可以制裁的”财产”这一具体问题,并就某些自主组件给出了否定答案。但那是对OFAC民事权力的限制,而非针对开发者运营协议期间行为的刑事货币传输指控的挡箭牌。

后Tornado项目所汲取的设计教训似乎是:合规必须是一等架构特性,而非前端政策。Privacy Pools通过将筛查移至上游来实现这一点——在存款被视为”已批准”可进入匿名集提取之前完成筛查,同时尝试为已批准资金保留密码学隐私保障。Railgun则通过彻底规避混合模型来实现这一点。两者都是针对那个在曼哈顿陪审团面前令Tornado无从辩驳的质疑所作出的回应。

Privacy Pools与关联集模型

img3

Privacy Pools由三层结构组成。以可升级的Entrypoint合约为核心的智能合约层负责处理存款、提款和协调工作。零知识层管理承诺方案和提款电路,使提款人能够证明自己属于某个集合的成员,而不披露具体是哪个承诺。**关联集提供者(ASP)**层通过授权账户维护一套经过筛选的已批准存款标签,即合规层,并更新状态。该协议在通常意义上是非托管的:用户资金由合约中的密码学承诺持有,而非任何运营者的密钥。

用户体验相对直接:存款人将资金提交到池中;ASP根据其标准评估该笔存款,并决定是否将其纳入当前已批准的关联集。若纳入,存款人(或其指定接收方)日后可使用关于已批准集合成员资格的零知识证明进行提款——提款行为无法与具体存款相关联,但仅限于ASP已批准的存款范围内。支持部分提款,以保留剩余余额的隐私。支持多种资产类型,包括原生ETH和ERC-20代币。

使这套机制有别于换了马甲的KYC的,是ragequit功能。若ASP拒绝批准某笔存款,原始存款人可以公开退出,披露具体存款记录并取回资金。该交易的隐私性就此丧失,但资金托管权得以保留。这是抗审查的后备机制:ASP无法通过拒绝批准来扣押存款人的资金,只能迫使存款人在继续处于未批准状态(无法私密提款)与公开退出之间作出选择。

该设计必须在监管者面前站得住脚的地方

ragequit在市场宣传中承担的功能,超出了它在实践中所能实现的。一个拥有合法但敏感交易的存款人——恰恰是整个系统本应服务的那类存款人——一旦选择公开退出,便等于放弃了存款的初衷。因此,ragequit的威慑力其实是虚的:它是一种保留资金托管权但牺牲存款目的的后备选项。在实践中,ragequit与其说是平衡存款人与ASP之间权力关系的均衡器,不如说是一条破产通道。ASP的批准决定才是实质性的那一个。

这引出了一个Privacy Pools文档没有回答的问题:ASP在法律上是什么?ASP运营者根据某些标准——大概是链上分析信号、制裁名单以及已知非法来源的启发式规则——对存款进行筛查,并生成一份已批准标签列表。这看起来像是一项正在向价值传输协议出售或嵌入其中的合规服务。FinCEN是否会将ASP运营者本身认定为货币服务企业、认定为其合规供应商,抑或两者都不是,尚未经过公开检验。如果答案是”货币服务企业”,ASP层就继承了池化架构原本试图分散掉的牌照义务。

架构内部还存在两个进一步的注意事项。Entrypoint是可升级的,文档对此有所说明但未作分析。升级权限是监管的关键咽喉:若法院或机构能够强制升级管理者修改ASP逻辑、将特定地址列入黑名单或修改提款电路,该协议的抗审查能力最终取决于持有这些密钥的人的法律处境。关于Entrypoint升级路径的公开治理细节——密钥持有者、多签组成、时间锁参数——不在我们所参考的文件摘录中,需要直接对照已部署合约进行核实。

第二个注意事项在于:ASP的批准标准在协议设计上是外生的。密码学本身并不阻止ASP在压力下收紧标准、追溯移除已批准条目,或被迫与其他ASP趋同,形成事实上的共享黑名单。抗审查的叙事依赖于以下假设:要么多个ASP之间存在真实竞争,要么ragequit退出机制能对单一ASP的行为构成有效约束。这两个假设都是经验性的,而非架构性的。

Privacy Pools模型在以太坊基金会Kohaku隐私钱包项目内部引发了关注,简报将其描述为以太坊基金会将隐私设为钱包层默认功能的举措。Kohaku与Privacy Pools之间的具体关系——究竟是集成、背书还是更松散的关联——在我们能够核实的来源中尚未记录在案,本文将其视为方向性信号,而非确定性结论。

Railgun的噪声替代混合架构

img4

Railgun的立场在结构上与前者不同。其文档将该系统描述为部署在以太坊、BSC、Polygon和Arbitrum上的无主智能合约代码。用户获得一个”0zk地址”,在标准区块浏览器上不可见。其核心架构主张是:Railgun不在用户之间混合资金。代币和钱包通过零知识密码学实现不可区分,而无需像Tornado Cash那样将存款混合在共享池中。

由此产生的结果是:匿名集主要由活动而非流动性生成。用户可以在屏蔽环境内进行兑换、借贷和dApp调用。每一笔交互都增加噪声。两个Railgun用户之间的私密兑换在链上呈现为一笔Railgun交易;一笔私密支付呈现为一笔Railgun交易;一次私密DeFi仓位调整也呈现为一笔Railgun交易。任何单一操作的隐私集,随着同一屏蔽环境中不相关操作总量的增加而扩大,而无需用户将资金停放在混币池中。

简报援引的数据显示,截至研究期,Railgun的累计屏蔽交易量约为45~50亿美元。我们未能在本文可用材料中针对链上数据源独立核实这一数字;该数字应被视为与公开报道方向一致,但在被视为精确数据之前,需要对照Dune等数据仪表盘进行验证。从主要文档中可以得到支持的是架构层面的主张:该系统已在四条链上部署上线,在针对混币器的执法时代全程运营,并将其非混合设计定位为与合规相关的差异化优势。

增长不等于合法性的证明

有趣的问题不是Railgun是否在增长——它确实在增长——而是该将这种增长归因于什么。三种解释与同一组数据都相符。第一种:Railgun的非混合架构及其文档对合法用例的强调(职业保密、HIPAA、GDPR、私密薪资发放、防范钱包标记服务),确实使其在法律上处于与Tornado Cash不同的位置。第二种:混币器需求在Tornado Cash被制裁后并未消失,只是转移到了仍在运营的任何隐私基础设施上。第三种:Railgun的DeFi原生屏蔽环境吸引的用户,其主要诉求并非逃避执法监控,而是规避抢先交易、MEV和钱包追踪服务——这是一个Tornado Cash根本不擅长服务的独立市场。

这三种解释并不相互排斥,也没有任何一种等同于监管认可。目前没有任何美国监管机构公开表示Railgun的架构满足AML或BSA义务。Railgun自身的定位——非托管、无主、无强制治理代币、隐私作为合规专业人士的合规工具——是一种法律姿态,而非法律裁定。Storm案提醒我们,“无主”和”无托管”并不能解决开发者责任问题。无牌货币传输罪的指控并不要求Storm托管用户资金,只需要Tornado Cash替他人传输价值,且Storm的行为达到共谋标准。一个无托管但私密传输价值的协议,仍处于该理论的射程之内。

如果Railgun有更强的结构性立场,那大概在于:其非混合设计使其有合理的理由主张,自己并非检察官Tornado理论所依赖的技术意义上的混币器。这一论点能否经受住坚决的检察官的检验,尚未经历实战。

合规隐私的三种失效模式

img5

将”合规隐私”视为已确立的设计范式,预设了一种当前法律环境并不具备的稳定性。以下三种失效模式值得明确点出。

第一种:监管对合规层的重新定性。若ASP运营者被认定为FinCEN定义下的货币服务企业,或须承担逐州牌照义务的合规中介,则ASP层将继承池化架构原本试图从中分散的牌照负担。这未必会扼杀这一设计——它可能推动形成一个具有更清晰法律地位的持牌ASP生态——但它使当前”合规层是轻量级附加组件”的前提失效。它也在一定程度上瓦解了”无KYC”的主张,因为持牌合规中介通常需要了解其正在批准的对象。

第二种:审查蔓延。在持续监管压力下,单一主导ASP有强烈动机过度排除。合法但敏感的存款——活动人士捐款、举报人付款、来自ASP视为高风险司法管辖区的交易——可能以极低的成本被拒绝批准,而存款人付出的代价极高,其唯一出路是公开ragequit,而这恰恰违背了使用该协议的初衷。Privacy Pools的抗审查叙事依赖于真实的ASP竞争,或对过度排除的有意义约束成本。两者均不由架构保障,均属政策层面的结果,将由重审进程、FinCEN指引,以及ASP运营者应对民事和刑事风险的方式共同塑造。

第三种:Storm重审的直接先例效应。若2026年10月重审在洗钱或制裁共谋罪中有任何一项定罪,开发者责任的边界将从无牌货币传输延伸至知情协助。像Privacy Pools这样拥有可识别合规层的协议,相对于Tornado Cash,在应对这一理论时处于更有利的位置,因为ASP的角色记录了一种持续防范非法使用的努力。但”处于更有利的位置”与”安全”并非同一概念。每一个记录筛查意图的架构特征,在不利诉讼程序中同样是开发者知悉何事、知悉于何时的证据。重审将决定,哪种姿态——Railgun的无主非混合设计、Privacy Pools的显式合规层,抑或某种第三路径——最适合第二次裁决所塑造的法律环境。

对当前设计空间的诚实判断是:Privacy Pools和Railgun都未曾经历过塑造了Tornado Cash命运的那类执法行动。两者都在2025年8月裁决与2026年10月重审之间的窗口期内运营,而这个窗口期的实际结果仍真正未定。以太坊基金会通过Kohaku对Privacy Pools模型的关注,表明更广泛的生态系统正在将关联集筛选视为钱包层更可能的收敛方向,但这个赌注是在一个尚未完整作答的法律问题上下注。

有几件事是可以相对确定地说需要关注的:任何FinCEN针对零知识隐私协议——无论正式还是非正式——发布的指引,都将实质性地改变ASP运营者的判断。任何针对Railgun的传票或民事诉讼,都将检验其非混合架构是否真的占据了文档所声称的不同法律位置。Privacy Pools Entrypoint升级权限的任何变化,或ASP运营者批准标准的任何调整,都将揭示该协议在正式执法之前如何应对压力。2026年10月的重审,将通过以下三种方式之一影响当前设计共识:保留洗钱和制裁理论悬而未决,从而确认现有共识;对这两项罪名宣判Storm无罪,从而强化现有共识;或通过定罪来打破现有共识。在此之前,当前这代隐私协议正在进行一场关于哪些架构赌注能够在一个尚未完成自我定义的法律环境中存活下来的活体实验。

cover

Introducción

El 6 de agosto de 2025, tras aproximadamente una semana de deliberaciones después de un juicio de cuatro semanas en el Distrito Sur de Nueva York, un jurado emitió un veredicto dividido sobre Roman Storm. Lo declaró culpable de conspiración para operar un negocio de transmisión de dinero sin licencia. Quedó en punto muerto respecto a la conspiración para cometer lavado de dinero y la conspiración para violar las sanciones de la IEEPA. Los cargos en punto muerto produjeron un juicio nulo parcial, no una absolución, y desde entonces el gobierno ha solicitado un nuevo juicio previsto para octubre de 2026.

La división importa porque cada lado apunta a una pregunta de diseño distinta. La condena dice algo concreto aunque acotado: al menos parte de la conducta asociada a operar y promover Tornado Cash superó el umbral de un jurado para la transmisión de dinero sin licencia. El juicio nulo dice que las preguntas más difíciles —si esa conducta también cruzó hacia el lavado de dinero y las violaciones de sanciones— siguen abiertas legalmente. Los diseñadores de protocolos que construyen la próxima generación de privacidad onchain tienen que planear contra ambos frentes, sin saber cómo se resolverá la segunda mitad.

Dos sistemas anclan esa conversación de diseño. Privacy Pools, activo en Ethereum desde marzo de 2025 según las comunicaciones del propio proyecto, intenta responder directamente la pregunta de Tornado añadiendo una capa de conjunto de asociación curada a un pool de conocimiento cero, con una salida pública para los depositantes cuyos fondos no sean aprobados. Railgun, desplegado en Ethereum, BSC, Polygon y Arbitrum, toma un camino estructuralmente diferente: sin mezcla, sin curador de conjuntos de asociación, privacidad generada como efecto secundario de la actividad DeFi realizada desde dentro de un entorno protegido. Ambos están activos. Ninguno ha recibido el visto bueno de un regulador. La pregunta es si alguno de los dos equilibrios aguanta una vez que el nuevo juicio de Storm llegue y se responda la segunda mitad de la pregunta sobre responsabilidad de los desarrolladores.

Lo que el veredicto Storm realmente decidió

img1

La acusación imputó a Storm tres conspiraciones: transmisión de dinero sin licencia, lavado de dinero y violaciones de sanciones de la IEEPA. Las partes estipularon algunos hechos que acotaron el juicio. Storm no lavó fondos personalmente. Tornado Cash se utilizó tanto para transacciones legítimas como ilícitas. Storm tomó conciencia, en algún momento durante su etapa, de que actores criminales estaban usando el protocolo. La teoría del gobierno era que continuar operando y promoviendo Tornado Cash tras esa toma de conciencia, y negarse a implementar salvaguardas adecuadas, constituía en sí misma una conducta criminal.

La defensa argumentó que se trataba de una herramienta neutral. Tornado Cash, desde esa perspectiva, se ubica junto a las VPN, los mensajeros cifrados o un martillo: los constructores de infraestructura de propósito general no pueden ser penalmente responsables simplemente porque sepan que alguien, en algún lugar, la utilizará mal. El jurado aceptó ese argumento en parte. Quedó en punto muerto en los dos cargos donde el daño se define por lo que hicieron los usuarios: lavar el producto de actividades ilícitas específicas y transferir valor a partes sancionadas. Condenó en el cargo donde el daño se define por lo que hizo Storm: operar un negocio que transmitía valor para terceros sin la licencia que exige FinCEN.

Es un veredicto más acotado de lo que sugería la cobertura previa al juicio y más amplio de lo que la defensa esperaba. El análisis de Mayer Brown sobre el resultado lee la condena por transmisión de dinero como una instrucción a los desarrolladores y operadores de mixers e intercambios: evalúen si están operando un negocio de transmisión de dinero según la definición de FinCEN y, de ser así, obtengan las licencias federales y estatales correspondientes. No es una regla legal establecida —es la lectura de un bufete sobre el veredicto de un jurado en un distrito—, pero es el supuesto de trabajo con el que parecen estar operando la mayoría de los equipos de protocolos orientados al cumplimiento normativo.

Otros dos hechos legales conviven con el veredicto. En agosto de 2022, la OFAC sancionó Tornado Cash y alegó que el protocolo había facilitado más de 7.000 millones de dólares en valor lavado, incluyendo ~600 millones de dólares atribuidos al Grupo Lazarus de Corea del Norte a partir del hackeo de Axie Infinity. Son alegaciones gubernamentales de una resolución de sanciones, no conclusiones judiciales. En diciembre de 2024, el Quinto Circuito resolvió que la OFAC excedió su autoridad al sancionar ciertos protocolos autónomos de Tornado Cash. El alcance preciso de “ciertos protocolos autónomos” en esa resolución es más estrecho de lo que sugiere el resumen habitual y requiere leerla contra la opinión completa, pero la resolución abordó la autoridad civil de sanciones, no la responsabilidad penal. No afectó la capacidad del DOJ para procesar a Storm ni lo salvó del cargo por transmisión de dinero.

Lo que el nuevo juicio vuelve a poner en juego

El nuevo juicio de octubre de 2026, según los informes disponibles, cubrirá los cargos en punto muerto. Eso significa que las teorías de lavado de dinero y sanciones vuelven ante un jurado, y que un conjunto diferente de instrucciones, resoluciones probatorias y jurados puede producir un resultado distinto. Una condena en cualquiera de esos cargos empujaría la línea de responsabilidad del desarrollador bastante más allá de donde la dejó el primer veredicto. La condena por transmisión de dinero implica a los operadores de protocolos; una condena por lavado de dinero o sanciones basada en facilitación consciente implicaría a un conjunto más amplio de conducta de los desarrolladores, especialmente en torno a lo que hacen los protocolos después de tomar conocimiento de usos ilícitos específicos.

De esto se derivan dos consecuencias. Primera: el consenso actual de diseño post-Storm —que los protocolos tipo mixer deben registrarse como negocios de servicios monetarios o restructurarse en torno a algún tipo de filtrado de cumplimiento— descansa en un veredicto que no ha quedado completamente resuelto. Segunda: cualquier protocolo de privacidad que afirme haber diseñado en torno al riesgo Storm solo ha diseñado en torno a la mitad de lo que Storm podría terminar estableciendo. Vale la pena tener esto en mente antes de tratar las arquitecturas de conjuntos de asociación como una respuesta legal en lugar de una hipótesis legal.

Por qué la arquitectura de mixer no superó el test de cumplimiento

img2

La arquitectura de Tornado Cash tenía una sola característica que estructuró toda la acusación: los depósitos y los retiros se mezclaban en pools compartidos. Un retirador demostraba, mediante un circuito de conocimiento cero, que había depositado anteriormente en el pool, sin revelar cuál era su depósito específico. Esta es la fuente de la garantía de privacidad y, simultáneamente, la fuente del problema de cumplimiento. Una vez que los fondos entran al pool, el propio protocolo no puede distinguir los depósitos limpios de los procedentes de un hackeo del Grupo Lazarus. Cualquier retiro es un retiro contra el pool en su conjunto.

Desde la perspectiva del regulador, ese diseño es funcionalmente un servicio de transmisión de valor que no ofrece ninguna capacidad real de verificar contrapartes. Desde la perspectiva del desarrollador, es exactamente la propiedad que le da al protocolo su valor social: un conjunto de privacidad que no puede ser vulnerado selectivamente no puede serlo por nadie, incluido un actor estatal. Las dos perspectivas no admiten compromiso dentro del modelo de pool-y-retiro. El protocolo o mezcla o no mezcla; si mezcla, el operador o bien filtra depósitos en la entrada o bien acepta que no puede filtrar en absoluto.

El filtrado voluntario en el front-end —bloquear direcciones sancionadas en una interfaz web— fue intentado y no resolvió el problema subyacente. Los contratos inteligentes seguían siendo invocables directamente, y la arquitectura de pool significaba que incluso los depósitos filtrados no podían descomponerse de los fondos ilícitos depositados previamente. La resolución del Quinto Circuito de 2024 abordó la pregunta específica de si los contratos inteligentes inmutables cuentan como “propiedad” que la OFAC puede sancionar, y respondió que no para ciertos componentes autónomos. Pero eso fue un límite sobre la autoridad civil de la OFAC, no un escudo frente a un cargo penal por transmisión de dinero basado en lo que hicieron los desarrolladores mientras el protocolo operaba.

La lección de diseño que los proyectos post-Tornado parecen haber extraído es que el cumplimiento debe ser una característica arquitectónica de primer nivel, no una política de front-end. Privacy Pools lo operacionaliza moviendo el filtrado hacia arriba, antes de que un depósito sea considerado “aprobado” para el retiro dentro del conjunto anónimo, intentando a la vez preservar una garantía criptográfica de privacidad para los fondos aprobados. Railgun lo operacionaliza evitando por completo el modelo de mezcla. Ambos son intentos de responder a la objeción que hizo indefendible a Tornado ante un jurado en Manhattan.

Privacy Pools y el modelo de conjuntos de asociación

img3

Privacy Pools está estructurado en tres capas. Una capa de contratos inteligentes centrada en un contrato Entrypoint actualizable se encarga de los depósitos, los retiros y la coordinación. Una capa de conocimiento cero gestiona los esquemas de compromiso y los circuitos de retiro, de modo que un retirador demuestra ser miembro de un conjunto sin revelar cuál es su compromiso específico. Una capa de Proveedor de Conjuntos de Asociación (ASP, por sus siglas en inglés) mantiene un conjunto curado de etiquetas de depósito aprobadas —la superficie de cumplimiento— y actualiza el estado a través de cuentas autorizadas. El protocolo no es custodio en el sentido estándar: los fondos de los usuarios están depositados mediante compromisos criptográficos en los contratos, no en las claves de ningún operador.

La experiencia de usuario es directa. Un depositante compromete fondos en el pool. El ASP evalúa el depósito según sus criterios y lo incluye o no en el conjunto de asociación aprobado actual. Si es incluido, el depositante (o su destinatario designado) puede luego retirar usando una prueba de conocimiento cero de membresía en el conjunto aprobado; el retiro no es vinculable al depósito específico, pero solo entre los depósitos que el ASP haya aprobado. Se admiten retiros parciales, lo que preserva la privacidad sobre el saldo restante. Se admiten múltiples tipos de activos: ETH nativo y tokens ERC-20.

El mecanismo que hace que esto sea algo distinto a KYC con otro nombre es el ragequit. Si el ASP se niega a aprobar un depósito, el depositante original puede salir públicamente, revelando el depósito específico y recuperando los fondos. La privacidad de esa transacción se pierde, pero se conserva la custodia. Este es el respaldo de resistencia a la censura: el ASP no puede atrapar los fondos de un depositante negándole la aprobación. Solo puede obligar al depositante a elegir entre permanecer no aprobado (y no poder retirar de forma privada) o salir en público.

Dónde el diseño tiene que sobrevivir al contacto con los reguladores

El ragequit carga con más peso en el marketing del que puede soportar en la práctica. Un depositante con una transacción legítima pero sensible —el tipo de transacción que todo el sistema pretende servir— no puede usar la salida pública sin sacrificar la razón por la que depositó. La amenaza del ragequit no es, por tanto, realmente una amenaza: es un recurso de último momento que preserva la custodia financiera a costa de lo que el depositante buscaba. En la práctica, el ragequit funciona menos como un equilibrador entre depositante y ASP, y más como una opción de quiebra. La decisión de aprobación del ASP es la que opera.

Eso plantea una pregunta que la documentación de Privacy Pools no resuelve: ¿qué es un ASP, legalmente? Un operador de ASP filtra depósitos según ciertos criterios —presumiblemente señales de analítica de cadena, listas de sanciones y heurísticas sobre fuentes ilícitas conocidas— y produce una lista de etiquetas aprobadas. Eso parece un servicio de cumplimiento que se vende a, o se integra en, un protocolo de transmisión de valor. Si FinCEN caracterizaría a un operador de ASP como él mismo operando un negocio de servicios monetarios, o como un proveedor de cumplimiento para uno, o como ninguno de los dos, no ha sido probado públicamente. Si la respuesta es “negocio de servicios monetarios”, la capa ASP hereda exactamente la carga de licencias que la arquitectura de pool pretendía distribuir.

Dentro de la arquitectura hay dos advertencias adicionales. El Entrypoint es actualizable, algo que la documentación menciona pero no analiza. La autoridad de actualización es un punto de estrangulamiento regulatorio: si un tribunal o una agencia puede obligar a los administradores de la actualización a alterar la lógica del ASP, incluir en lista negra direcciones específicas o modificar los circuitos de retiro, la resistencia a la censura del protocolo depende en última instancia de la postura legal de quien controle esas claves. Los detalles públicos de gobernanza en torno a la ruta de actualización del Entrypoint —titulares de claves, composición del multisig, parámetros de timelock— no figuran en el extracto con el que trabajamos y requerirían verificación directa contra los contratos desplegados.

La segunda advertencia es que los criterios de aprobación del ASP son, como cuestión de diseño del protocolo, exógenos. Nada en la criptografía impide que un ASP endurezca sus criterios bajo presión, añada eliminaciones retroactivas o sea presionado para converger con otros ASPs hacia una lista negra compartida de facto. El argumento de resistencia a la censura descansa en el supuesto de que o bien varios ASPs competirán entre sí, o bien la salida de ragequit limita de manera significativa el comportamiento de un ASP único. Ambos supuestos son empíricos, no arquitectónicos.

El modelo de Privacy Pools ha atraído atención dentro del esfuerzo de privacidad Kohaku de la Ethereum Foundation, que el brief del tema describe como la iniciativa de la EF para hacer de la privacidad un valor predeterminado en la capa de wallet. La relación precisa entre Kohaku y Privacy Pools —si es integración, respaldo o algo más laxo— no está documentada en las fuentes que pudimos verificar, y el artículo la trata como orientativa más que definitiva.

La arquitectura de ruido sobre mezcla de Railgun

img4

Railgun adopta una posición estructural diferente. Su documentación describe el sistema como código de contratos inteligentes sin propietario, desplegado en Ethereum, BSC, Polygon y Arbitrum. Los usuarios reciben una “dirección 0zk” que es confidencial en los exploradores de bloques estándar. La afirmación arquitectónica central es que Railgun no mezcla fondos entre usuarios. Los tokens y las wallets se vuelven indistinguibles mediante criptografía de conocimiento cero sin ser mezclados en un pool compartido como lo hacía Tornado Cash con sus depósitos.

La consecuencia es que el conjunto de anonimato se genera principalmente por la actividad, no por la liquidez. Los usuarios pueden hacer swaps, prestar, tomar prestado y llamar a dApps desde dentro del entorno protegido. Cada una de esas interacciones añade ruido. Un swap privado entre dos usuarios de Railgun se ve en la cadena como una transacción de Railgun; un pago privado se ve como una transacción de Railgun; un ajuste privado de una posición DeFi se ve como una transacción de Railgun. El conjunto de privacidad para cualquier acción individual crece con el volumen total de acciones no relacionadas que ocurren en el mismo entorno protegido, sin necesidad de que los usuarios dejen sus fondos aparcados en un pool de mezcla.

El brief del tema cita un volumen protegido acumulado de ~4.500~5.000 millones de dólares para Railgun durante el período de investigación. No hemos confirmado esa cifra de manera independiente frente a una fuente de datos onchain en los materiales disponibles para este artículo; el número debe leerse como coherente en términos de dirección con los informes públicos, pero requiere verificación frente a un dashboard como Dune antes de tratarlo como preciso. Lo que sí puede defenderse a partir de la documentación primaria es la afirmación arquitectónica: el sistema está desplegado en vivo en cuatro cadenas, ha estado operando durante la era de aplicación de la ley contra los mixers y posiciona su diseño sin mezcla como un diferenciador relevante para el cumplimiento normativo.

Por qué el crecimiento no es evidencia de legitimidad

La pregunta interesante no es si Railgun creció —lo hizo—, sino a qué atribuir ese crecimiento. Tres explicaciones son coherentes con los mismos datos. La primera es que la arquitectura sin mezcla de Railgun y el énfasis de su documentación en casos de uso legítimos (confidencialidad profesional, HIPAA, GDPR, nóminas privadas, protección frente a servicios de etiquetado de wallets) ocupan genuinamente una posición legal diferente a la de Tornado Cash. La segunda es que la demanda de mixers no desapareció cuando Tornado Cash fue sancionado; se desplazó hacia cualquier infraestructura de privacidad que permaneciera activa. La tercera es que el entorno DeFi protegido de Railgun atrajo a usuarios cuyo interés principal no era la privacidad frente a las fuerzas del orden, sino la privacidad frente a los front-runners, el MEV y los servicios de rastreo de wallets: un mercado distinto al que Tornado Cash servía mal.

Las tres explicaciones no son mutuamente excluyentes, y ninguna equivale a aceptación regulatoria. Ningún regulador estadounidense ha avalado públicamente la arquitectura de Railgun como satisfactoria para las obligaciones AML o de la BSA. El propio encuadre de Railgun —sin custodia, sin propietario, sin token de gobernanza obligatorio, la privacidad como herramienta de cumplimiento para profesionales regulados— es una postura legal, no una resolución legal. El caso Storm recuerda que “sin propietario” y “sin custodia” no resuelven la pregunta de responsabilidad del desarrollador. El cargo por transmisión de dinero sin licencia no requería que Storm hubiera tenido custodia de los fondos de los usuarios. Requería que Tornado Cash transmitiera valor para terceros y que la conducta de Storm cumpliera un estándar de conspiración. Un protocolo que transmite valor de forma privada sin custodia sigue estando dentro del ámbito de esa teoría.

La posición estructural más sólida de Railgun, si es que la tiene, es que su diseño sin mezcla le otorga un argumento plausible de que no es un mixer en el sentido técnico en que se basó la teoría del gobierno sobre Tornado. Si ese argumento sobrevive al contacto con un fiscal decidido es algo que no se ha puesto a prueba.

Tres modos de fallo para la privacidad con cumplimiento normativo

img5

El encuadre de la “privacidad con cumplimiento normativo” como un patrón de diseño establecido presupone una estabilidad que el entorno legal actual no ofrece. Tres modos de fallo merecen nombrarse específicamente.

El primero es la recaracterización regulatoria de la capa de cumplimiento. Si un operador de ASP es considerado un negocio de servicios monetarios según la definición de FinCEN, o un intermediario de cumplimiento sujeto a licencias estado por estado, la capa ASP hereda exactamente la carga de licencias que la arquitectura de pool pretendía desplazar. Esto no necesariamente destruye el diseño —puede empujar hacia un ecosistema de ASPs licenciados con un estatus legal más claro—, pero invalida la premisa actual de que la capa de cumplimiento es un complemento ligero. También derrumba el argumento de “sin KYC” en la medida en que los intermediarios de cumplimiento licenciados normalmente necesitan saber a quién están aprobando.

El segundo es la deriva hacia la censura. Un ASP dominante único bajo presión regulatoria sostenida tiene fuertes incentivos para sobre-excluir. Los depósitos legítimos pero sensibles —donaciones a activistas, pagos a denunciantes, transacciones de jurisdicciones que el ASP trata como de alto riesgo— pueden negarse a un costo muy bajo para el ASP y muy alto para el depositante, cuyo único recurso es un ragequit público que anula la razón de usar el protocolo. El argumento de resistencia a la censura de Privacy Pools depende de que haya competencia genuina entre ASPs o de que la sobre-exclusión tenga un costo real. Ninguna de las dos cosas está garantizada por la arquitectura. Ambas son resultados de política que serán moldeados por el nuevo juicio, por la orientación de FinCEN y por la respuesta de los operadores de ASP al riesgo civil y penal.

El tercero es el precedente directo del nuevo juicio de Storm. Una condena en cualquiera de los cargos de conspiración para lavado de dinero o sanciones en octubre de 2026 extendería la frontera de la responsabilidad del desarrollador más allá de la transmisión de dinero sin licencia hacia la facilitación consciente. Un protocolo como Privacy Pools que tiene una capa de cumplimiento identificable está, podría argumentarse, en una posición mejor frente a esa teoría que Tornado Cash, porque el papel del ASP documenta un intento continuo de prevenir el uso ilícito. Pero “posición argumentablemente mejor” no equivale a “seguro”. Cada característica arquitectónica que documenta la intención de filtrar es también evidencia, en un procedimiento adverso, de lo que los desarrolladores sabían y cuándo. El nuevo juicio determinará qué postura —el diseño sin mezcla y sin propietario de Railgun, la capa de cumplimiento explícita de Privacy Pools, o algún tercer enfoque— es la más adecuada para el entorno legal que produzca el segundo veredicto.

La lectura honesta del espacio de diseño actual es que ni Privacy Pools ni Railgun ha sido sometido a una acción coercitiva del tipo que moldeó a Tornado Cash. Ambos operan en el intervalo entre el veredicto de agosto de 2025 y el nuevo juicio de octubre de 2026, con el resultado práctico de ese intervalo genuinamente indeterminado. El interés de la Ethereum Foundation en el modelo de Privacy Pools a través de Kohaku sugiere que el ecosistema en sentido amplio está tratando la curación de conjuntos de asociación como el punto de convergencia más probable en la capa de wallet, pero esa apuesta se está haciendo contra una pregunta legal que aún no ha sido respondida completamente.

Lo que sí puede decirse con cierta confianza es qué hay que observar. Cualquier orientación de FinCEN que aborde los protocolos de privacidad de conocimiento cero, ya sea formal o informal, cambiaría materialmente el cálculo para los operadores de ASP. Cualquier citación o acción civil dirigida a Railgun pondría a prueba si su arquitectura sin mezcla ocupa realmente la posición legal diferente que implica su documentación. Cualquier cambio en la composición de la autoridad de actualización del Entrypoint de Privacy Pools, o en los criterios de aprobación del operador de ASP, revelaría cómo responde el protocolo a la presión antes de que haya una aplicación formal. El nuevo juicio de octubre de 2026 o bien confirmará el consenso de diseño actual dejando sin resolver las teorías de lavado de dinero y sanciones, o bien lo extenderá absolviendo a Storm en esos cargos, o bien lo desestabilizará condenándolo. Hasta entonces, la generación actual de protocolos de privacidad está ejecutando un experimento en vivo sobre qué apuestas arquitectónicas sobreviven a un entorno legal que aún no ha terminado de definirse.

Read next다음으로 읽기次に読む继续阅读Leer a continuación

Follow the next market structure breakdown 다음 시장 구조 분석 받기 次の市場構造分析をフォロー 关注下一篇市场结构分析 Sigue el próximo análisis de estructura de mercado

New Steadyrain research is published several times a week across DeFi risk, BTCFi, stablecoins, and RWA. Steadyrain은 DeFi 리스크, BTCFi, 스테이블코인, RWA 분석을 매주 여러 차례 발행합니다. SteadyrainはDeFiリスク、BTCFi、ステーブルコイン、RWAの分析を毎週公開しています。 Steadyrain 每周发布 DeFi 风险、BTCFi、稳定币和 RWA 研究。 Steadyrain publica análisis sobre riesgo DeFi, BTCFi, stablecoins y RWA varias veces por semana.