Liquid Network 해킹으로 3억 2,000만 달러 유출, 이후 대부분의 Bitcoin 반환
Liquid Network 해킹으로 9월 6일 사이드체인의 연합 지갑에서 약 4,000 BTC가 빠져나갔으며, 이는 보고된 준비금의 약 95%에 해당한다. 신원이 확인되지 않은 행위자들은 자신들을 화이트햇이라고 칭하며, 자금을 반환하기에 앞서 소프트웨어 수정이 이뤄져야 한다고 요구했다.
그러나 이 주장은 처음에는 거의 안심이 되지 않았다. 해당 인출은 승인된 peg-out 절차를 통해 명백히 담보가 없는 Liquid Bitcoin을 실제 bitcoin으로 이미 전환한 상태였다. Liquid는 네트워크 활동을 중단했고, 거래소들은 Bitcoin 담보 자산과 관련된 입출금을 중단했다.
이후 상황은 달라졌다. Blockstream이 영향을 받은 브리지 노드에 패치가 적용됐다고 밝힌 뒤, 행위자들은 3,400 BTC를 반환했다. 그러나 보도 시점 기준 약 4,700만 달러 상당인 약 598.5 BTC는 9월 8일에도 여전히 이들의 통제하에 남아 있었다.
이는 Bitcoin 네트워크 자체가 침해된 사건이 아니었다. 내부 자산을 Bitcoin과 연결하기 위해 소프트웨어와 지정 운영자를 사용하는 연합형 사이드체인 Liquid 내부의 실패였다. 이 구분은 이번 사건으로부터 Bitcoin의 베이스 레이어를 보호하지만, 동시에 Liquid가 이제 복구해야 할 핵심 약속을 드러낸다.
Liquid Network 해킹은 유효한 인출을 준비금 유출로 바꿨다
핵심 사실은 단순히 bitcoin이 이동했다는 점이 아니라, Liquid의 일반적인 상환 체계가 해당 이동을 승인했다는 보도다.
Liquid Network는 당시 약 3억 2,000만 달러 가치였던 약 4,000 BTC가 연합 지갑에서 인출됐다고 공개했다. 사건 전 이 지갑에는 약 4,200 BTC가 들어 있었던 것으로 전해진다.
따라서 이 인출로 지갑 잔액의 약 95%가 빠져나갔다. 초기 보안 사고 보도에 따르면, Liquid는 브리지 노드를 비활성화하고 거래소와 협력해 L-BTC 입출금을 중단했다.
통상 L-BTC 또는 LBTC로 표기되는 Liquid Bitcoin은 Liquid 사이드체인으로 이전된 bitcoin을 나타낸다. Liquid 문서에 따르면 각 LBTC는 연합이 보유한 동등한 양의 BTC로 뒷받침돼야 한다.
이 전환 과정은 양방향 peg라고 불린다. peg-in은 bitcoin을 잠그고 이에 상응하는 LBTC를 생성한다. peg-out은 LBTC를 소각하고 연합 지갑에서 bitcoin을 내보낸다.
행위자들은 지갑의 서명 키를 탈취한 것이 아니라, 인출 이전에 회계 체계를 공격한 것으로 보인다. SideSwap은 유효한 권한을 가진 4,000 LBTC가 자사의 peg-out 서비스에 도달했다고 밝혔다. 이 서비스는 해당 토큰을 소각했고, 연합은 제공된 Bitcoin 주소로 약 3,996 BTC를 전송했다.
SideSwap은 자사 시스템과 Peg-out Authorization Key가 침해되지 않았다고 밝혔다. Peg-out Authorization Key, 즉 PAK는 등록된 운영자와 승인된 목적지 형식으로 인출을 제한한다.
이 구분이 중요한 이유는 거래가 예상된 경로를 통과했기 때문이다. 연합이 명백하게 위조된 인출 요청을 본 것은 아닐 수 있다. 대신, 일치하는 담보 없이 존재해서는 안 될 토큰을 처리한 것으로 전해진다.
신원이 확인되지 않은 행위자들은 이후 Bitcoin 거래 안에 짧은 메시지를 남겼다. 이들은 “we are whitehats. contact us on chain.”이라고 주장했다.
Bitcoin의 OP_RETURN 필드는 거래에 소량의 임의 데이터를 담을 수 있게 한다. 이 사건에서 이는 행위자들과 Blockstream 사이의 공개 통신 채널이 됐다.
Blockstream은 연락 방법을 안내한 뒤 암호화되고 암호학적으로 서명된 메시지를 보냈다. 이후 행위자들은 영향을 받은 모든 노드에 수정 사항이 적용된 뒤 자금을 반환하겠다고 말했다.
이 일련의 과정은 Liquid Network 익스플로잇을 유난히 가시적인 사건으로 만들었다. 행위자들의 신원과 의도가 여전히 알려지지 않은 상황에서도 누구나 거래와 메시지를 검토할 수 있었다.
따라서 이번 유출은 두 가지 기록을 동시에 남겼다. Liquid와 SideSwap은 운영 대응을 설명했고, Bitcoin에는 인출, 이후 메시지, 그리고 최종적인 부분 반환이 기록됐다.
소프트웨어는 한 번도 예치되지 않은 Bitcoin을 받아들였다
보도된 실패는 연합의 키를 손상시키지 않은 채 LBTC 공급량과 bitcoin 준비금 간의 관계를 무너뜨렸다.
SideSwap은 Blockstream이 사건의 원인을 Liquid 기반 오픈소스 소프트웨어인 Elements의 버그로 추적했다고 밝혔다. 그 설명에 따르면, 이 취약점은 행위자들이 담보 없는 LBTC를 생성할 수 있게 했다.
이 메커니즘은 모든 자산 브리지에서 가장 중요한 불변 조건을 공격한다. 시스템은 사용자가 이전에 잠근 준비 자산보다 더 많은 자산을 절대 내보내서는 안 된다.
Liquid의 peg 문서는 엄격한 1대1 모델을 설명한다. 모든 LBTC는 연합이 보유한 bitcoin에 대응해야 하며, LBTC 한 개를 소각하면 BTC 한 개가 출금돼야 한다.
소프트웨어가 사이드체인 공급량을 늘리는 유효하지 않은 거래를 받아들인다면, 이 보장은 peg-out이 시작되기 전에 이미 무너진다. 이후 공격자는 새로 생성된 LBTC를 정상적인 인출 서비스에 제시할 수 있다.
인출 서비스는 승인된 토큰을 본다. 설계대로 이를 소각하고 연합에 실제 bitcoin 출금을 요청한다. 각 구성 요소는 맡은 역할을 수행하는 것처럼 보일 수 있지만, 시스템 전체의 결과는 유효하지 않다.
이것이 Liquid Network 해킹의 핵심적인 역전이다. 보도에 따르면 권한 통제는 작동했지만, 손상된 공급 회계를 기반으로 한 청구를 승인했다.
연합 지갑의 다중서명 설계는 이러한 결과를 막지 못했다. 다중서명이란 준비금이 이동하기 전 여러 지정 키 보유자가 거래를 승인해야 한다는 뜻이다.
이 구조는 하나의 탈취된 키나 단일 악성 서명자로부터 보호한다. 그러나 인출을 정당한 것으로 보이게 만드는 상위 단계의 합의 또는 검증 실패를 자동으로 감지하지는 못한다.
Bitquery가 공개한 온체인 분석은 대규모 인출 이전에 두 건의 소규모 peg-in이 있었음을 추적했다. 연구진은 최종 거래 이전 Liquid에서 테스트 활동과 반복되는 암호학적 패턴도 식별했다.
이들의 거래 재구성은 9월 6일 14:28 UTC에 3,996 BTC가 연합에서 지급됐다고 보고했다. 분석은 인출 이후 오간 메시지도 기록했다.
이러한 결과는 우발적 거래보다는 사전 준비를 시사한다. 그러나 행위자들은 공개적으로 신원을 밝히거나 완전한 기술적 공개를 제공하지 않았다.
일부 보도는 이 실패를 범위 증명 검증과 연결했다. 범위 증명은 기밀 거래의 숨겨진 금액이 유효하며 부적절하게 자산을 생성하지 않았음을 입증하는 암호학적 증거다.
Liquid는 이전 자산과 금액을 숨기면서도 네트워크 노드가 거래 유효성을 확인할 수 있게 하는 Confidential Transactions를 사용한다. 노드가 보이는 금액이 아니라 증명에 의존하기 때문에, 이 검증 과정의 결함은 특히 심각할 수 있다.
정확한 근본 원인은 여전히 Blockstream의 상세 사후 분석이 필요하다. 공개 보도는 담보 없는 LBTC가 peg-out 경로에 진입했다는 더 넓은 결론을 뒷받침하지만, 모든 기술적 단계를 확정하지는 않는다.
이 검증 공백은 분명히 남겨둬야 한다. 그럴듯한 재구성은 완전한 공급업체 공개, 감사된 패치 또는 독립적인 재현과 같지 않다.
Liquid Bitcoin의 보안은 이제 키 무결성 이상의 입증에 달려 있다. Blockstream은 노드가 왜 유효하지 않은 상태를 받아들였는지, 어떤 버전이 영향을 받았는지, 그리고 패치가 관련 변형을 어떻게 차단하는지를 보여야 한다.
Liquid의 1대1 약속은 이제 압박을 받고 있다
이번 사건은 Liquid의 제품 약속이 암호학적 검증과 연합의 운영 판단 모두에 의존한다는 점에서 Liquid를 압박한다.
Liquid는 Bitcoin의 베이스 네트워크보다 빠른 결제와 더 높은 거래 프라이버시를 제공하도록 설계됐다. 또한 스테이블코인과 토큰화 증권 같은 자산도 지원한다.
이러한 기능은 서로 다른 신뢰 가정을 가진 별도 블록체인에서 나온다. Bitcoin 채굴자들은 Liquid 거래를 검증하지 않으며, Bitcoin의 합의 규칙은 LBTC 공급량을 강제하지 않는다.
대신 Liquid는 블록에 서명하고 양방향 peg를 관리하는 functionary 연합에 의존한다. 다른 연합 참여자는 서비스를 제공할 수 있지만, 시스템의 보안은 Bitcoin 채굴과 동일한 방식으로 구성되지 않는다.
이 모델이 본질적으로 결함 있는 것은 아니다. 모든 사이드체인 또는 브리지는 추가적인 소프트웨어, 거버넌스, 수탁 가정을 도입한다. 사용자는 베이스 레이어에서 사용할 수 없는 기능을 얻는 대가로 이러한 가정을 받아들인다.
이번 사건은 실패 시 이러한 가정들이 어떻게 상호작용하는지를 드러냈다. Liquid는 네트워크를 중단하고, 브리지 노드를 비활성화하며, 거래소와 조율하고, 패치를 배포하고, 행위자들과 협상할 수 있었다.
이러한 조치는 추가 피해를 제한했다. 동시에 Liquid의 비상 대응이 인프라를 중단하고 자산 이동에 영향을 줄 수 있는 식별 가능한 운영자에게 의존한다는 사실도 보여줬다.
Bitcoin 자체는 멈추지 않았다. 채굴자들은 행위자들의 메시지와 반환 자금을 담은 거래를 포함해 블록 처리를 계속했다.
이러한 대비가 모든 애플리케이션이 Bitcoin 위에서 직접 실행돼야 한다는 뜻은 아니다. 사용자는 Bitcoin의 보안과 다른 곳에서 bitcoin을 나타내는 자산의 보안을 구분해야 한다는 의미다.
Liquid 자체의 기술 개요는 브리지 노드, functionary 하드웨어, 서명 통제 및 비상 복구 메커니즘을 설명한다. 이 아키텍처는 암호학과 기관 간 조율을 결합한다.
이제 Blockstream과 연합은 이러한 계층이 어떻게 함께 실패했는지 설명해야 하는 압박을 받고 있다. 개인 키가 침해되지 않았다고 말하는 것은 질문의 한 부분에만 답한다.
사용자는 부적절하게 생성된 LBTC를 근거로 서명자들이 왜 bitcoin을 내보냈는지도 알아야 한다. 거래소는 재개된 입금이 미해결 공급량 불일치에 노출되지 않는다는 증거를 필요로 한다.
자산 발행자들도 관련 우려에 직면한다. Liquid는 다른 발행 자산은 영향을 받지 않았다고 밝혔지만, 네트워크 중단은 이를 운반하는 공유 인프라를 여전히 중단시켰다.
자산이 기술적으로 온전하더라도 일시적으로 이전하거나 상환하기 어려워질 수 있다. 따라서 운영 가용성은 보안 평가의 일부가 된다.
부분 회수는 준비금 상태를 개선했지만 사건 자체를 지우지는 못했다. 1대1 담보를 표방한 시스템은 잠시 그 주장을 뒷받침하는 bitcoin의 대부분을 잃었다.
남은 598.5 BTC는 회계 문제도 남긴다. Blockstream은 미회수 금액이 LBTC 담보, 부채 및 모든 회수 약정에 어떤 영향을 미치는지 설명해야 한다.
반환된 자산이 가용성 손실, 시장 불확실성 또는 거래소 통제의 필요성을 되돌리지는 않는다. 관련 취약점이 다른 곳에 남아 있지 않다는 증거도 아니다.
Liquid 운영자들은 기술 감사와 신뢰성 시험 모두에 직면해 있다. 첫 번째는 버그가 수정됐는지를 묻는다. 두 번째는 사용자가 그 답을 독립적으로 검증할 수 있는지를 묻는다.
부분 반환으로 화이트햇 논란이 해결되지는 않는다
3,400 BTC의 반환은 행위자들이 밝힌 의도를 뒷받침하지만, 약 600 BTC를 보유하고 있다는 사실은 명확한 화이트햇 결론을 막는다.
Blockstream이 브리지 노드에 패치가 적용됐다고 밝힌 뒤, 행위자들은 3,400 BTC를 연합 주소로 되돌려 보냈다. 이 거래는 인출된 금액의 약 85%를 복구했다.
9월 8일 회수 업데이트에 따르면 약 4,700만 달러 상당의 bitcoin은 아직 회수되지 않은 상태였다. 잔액을 둘러싼 협상은 계속되고 있었다.
행위자들은 앞서 Blockstream에 먼저 버그를 수정하라고 지시했다. 모든 노드가 패치를 적용하기 전에는 자금을 안전하게 반환하지 않겠다고 밝혔다.
이 메시지는 화이트햇 보안 활동의 한 측면과 부합한다. 취약점이 수정되기 전에 이를 공개하거나 입증하면 다른 사용자가 모방 공격에 노출될 수 있다.
그러나 통상적인 책임 있는 공개는 보통 비공개 보고와 조율된 테스트로 시작한다. 문서화된 승인 없이 시스템 준비금의 95%를 빼내는 일로 시작하지는 않는다.
따라서 이들이 내세운 명칭은 주장일 뿐, 검증된 전문적 지위는 아니다. Liquid가 초기 대응에서 “자칭 화이트햇 해커”라는 표현을 사용한 것은 이러한 불확실성을 적절히 반영했다.
남은 자금은 이 문제를 더욱 선명하게 만든다. 이 글에서 검토한 공개 증거 가운데 Blockstream이 598.5 BTC의 포상금을 승인했다는 사실을 뒷받침하는 자료는 없다.
그러한 승인이 없다면, 코인을 보유하는 행위는 일방적인 수수료 부과나 협상용 지렛대, 또는 부당 취득 자산의 지속적 점유처럼 보일 수 있다. 부분 반환만으로는 동기나 법적 책임을 판단할 수 없다.
독자가 경험, 권한 또는 과거 행적을 평가할 수 있는 공개 신원 정보도 없다. 온체인 서명은 주소에 대한 통제권을 증명할 뿐, 그 통제자의 윤리적 성격을 증명하지는 않는다.
이 모호함에는 역사적 선례가 있다. 2021년 한 공격자는 Poly Network에서 6억 달러 이상을 빼돌린 뒤 대부분의 자산을 반환했다.
Poly Network는 그 공격자를 화이트햇이라고 부르며 포상금을 제안했다. 당시 Poly Network 보도는 대규모 반환이 법적·거버넌스상 의문을 해소하지 않은 채 여론의 서사를 어떻게 바꿀 수 있는지 보여줬다.
Liquid 사례는 동일하지 않다. 보고된 공격 방식, 자산, 운영 주체, 소통 방식이 모두 다르다. 그럼에도 두 사건 모두 자금 회수가 협력에 달려 있을 때 “해커”가 얼마나 빠르게 “화이트햇”으로 불리게 되는지를 보여준다.
그러한 표현은 협상 과정에서 실용적인 목적을 가질 수 있다. 협조적인 상대방을 공개적으로 공격하면 자금 회수 가능성이 낮아질 수 있다.
하지만 운영상 외교가 보안 분류를 대체해서는 안 된다. 승인된 연구자, 기회주의적 악용자, 갈취범은 모두 서로 다른 이유로 자금을 반환할 수 있다.
유용한 증거는 남은 BTC의 최종 처리와 공개되는 모든 합의에서 나올 것이다. 완전한 기술 보고서는 행위자들이 더 이른 시점에 비공개 접촉을 시도했는지도 명확히 할 수 있다.
그때까지 가장 정확한 설명은 자칭 또는 자칭 화이트햇이다. 이를 승인된 보안 테스트라고 부르는 것은 현재 उपलब्ध한 증거를 넘어서는 주장이다.
이번 공격은 Bitcoin 브리지의 오래된 문제를 되살린다
Liquid의 아키텍처는 많은 암호화폐 브리지와 다르지만, 이번 실패는 익숙한 패턴을 따른다. 실제 자산을 보유한 준비금으로 잘못된 청구가 넘어간 것이다.
크로스체인 시스템은 보안 규칙이 서로 다른 환경 사이의 활동을 변환하기 때문에 위험을 집중시킨다. 한 시스템은 다른 시스템의 이벤트가 가치 이전을 정당화하는지 판단해야 한다.
Liquid에서 이 판단은 사이드체인의 LBTC와 Bitcoin에 보관된 BTC를 연결한다. 연합체의 지갑은 준비금이고, Liquid의 검증 규칙은 이에 대한 청구를 관리한다.
보고된 버그는 이 두 원장 사이에 불일치를 만들었다. 사이드체인은 상응하는 bitcoin 없이 LBTC를 받아들였고, 이후 peg-out 절차는 그 잘못된 청구를 이행했다.
비슷한 경제적 패턴은 다른 브리지 사고에서도 나타났다. Wormhole의 2022년 공격은 공격자가 뒷받침해야 할 예치금 없이 래핑 자산을 만들 수 있도록 했다.
Ronin 브리지는 다른 경로로 실패했다. 공격자들은 준비금 인출을 승인할 수 있을 만큼 많은 검증자 키를 확보했다.
이 메커니즘들은 기술적으로 다르지만, 동일한 압박 지점에 도달한다. 브리지는 발행된 청구와 잠긴 담보 사이의 엄격한 관계를 유지해야 한다.
역사적 데이터는 이 경계가 지속적으로 엄격한 검토를 받는 이유를 보여준다. Chainalysis는 2022년 일부 기간 동안 13건의 브리지 해킹으로 공격자들이 20억 달러를 탈취했다고 추산했다.
브리지 위험 분석에 따르면, 이 사건들은 공개 당시 그해 탈취된 암호화폐의 69%를 차지했다. 이 수치는 현재 시장이 아닌 2022년을 설명하지만, 아키텍처 측면의 교훈은 여전히 유효하다.
브리지는 예측 가능한 위치에 자산을 축적한다. 검증 코드와 서명자 정책 역시 대규모 준비금이 이동할 수 있는 좁은 경로를 만든다.
Liquid의 연합체는 익명 스마트 계약 브리지보다 더 구조화된 운영자 집합을 제공한다. 업그레이드를 조율하고, 서비스를 중단하며, 거래소와 직접 소통할 수 있다.
이러한 장점은 대응에 도움이 됐다. 그러나 보고된 취약점은 어떤 거래가 유효한지를 결정하는 로직에 있었기 때문에 초기 준비금 유출을 막지는 못했다.
이 차이는 향후 감사를 설계할 때 반영돼야 한다. 키 보관과 접근 통제만 테스트하면 인플레이션, 증명 검증, 상태 일관성 실패를 놓치게 된다.
감사인은 전체 상환 경로도 테스트해야 한다. 이 경로에는 자산 생성, 검증, 승인, 소각, 연합체 서명, Bitcoin에서의 최종 지급이 포함된다.
Liquid Network 공격은 국지적 정확성만으로는 충분하지 않은 이유를 보여준다. SideSwap은 자신의 인증 키가 안전하게 유지됐다고 밝혔지만, 유효한 서비스가 여전히 유효하지 않은 시스템 결과의 일부가 됐다.
연합체 서명자들 역시 예상된 규칙을 따랐던 것으로 보인다. 결함은 그 규칙이 수신한 정보를 바꾼 것으로 전해진다.
따라서 운영자들은 여러 진실의 원천을 비교하는 통제 장치를 마련해야 한다. 비정상적인 인출이 완료되기 전에 공급량 변화, peg-in 이력, peg-out 규모, 준비금 이동이 서로 대조돼야 한다.
대부분의 준비금과 관련된 단일 요청은 프로토콜 규칙상 유효한 것으로 표시되더라도 예외적 검토를 받아야 한다. 소프트웨어상의 유효성과 운영상의 개연성은 서로 다른 검증 항목이다.
이 접근법은 마찰을 늘리며, Liquid는 부분적으로 그러한 마찰을 줄이기 위해 설계됐다. 더 빠른 결제가 하나의 경로를 통해 거의 전체 준비금을 이동시킬 수 있는 상황에서는 보안상 상충 관계를 피할 수 없다.
Liquid가 피해를 통제했는지는 세 가지 신호가 결정한다
다음 단계는 미회수 bitcoin, 재현 가능한 기술적 설명, 그리고 통제된 정상 운영 복귀에 달려 있다.
첫 번째 신호는 남은 598.5 BTC다. 전액 반환은 행위자들의 화이트햇 주장을 강화하겠지만, 사후적으로 승인을 입증하지는 못한다.
협상을 통한 포상금 지급도 잔액 문제를 해결할 수 있지만, Blockstream이 합의와 일방적 보유를 구분할 수 있을 만큼 충분한 정보를 공개해야 한다. 계속된 침묵이나 무관한 주소로의 이동은 화이트햇 해석을 약화할 것이다.
두 번째 신호는 Blockstream의 기술적 사후 분석이다. 여기에는 취약한 Elements 버전, 실패한 검증 규칙, 영향을 받은 거래 경로, 패치가 제공하는 정확한 보호가 명시돼야 한다.
유용한 공개는 독립 개발자들이 버그를 재현했는지도 설명해야 한다. 폐쇄적인 설명은 사용자들을 소프트웨어가 실패한 바로 그 조직에 의존하게 만들기 때문에 재현은 중요하다.
보고서는 탐지 시점도 다뤄야 한다. 공개 거래 분석은 주요 peg-out 이전에 준비 활동이 있었음을 시사하며, 모니터링과 이상 징후 임계값에 대한 의문을 제기한다.
세 번째 신호는 Liquid의 재가동 절차다. 거래소와 사용자는 일상 활동이 재개되기 전에 예치, 인출, 준비금 검증을 위한 명확한 경로가 필요하다.
브리지 노드를 재가동하는 것은 신뢰를 복원하는 것과 동의어가 아니다. 운영자들은 부분 반환 이후 LBTC 공급량과 연합체가 보유한 bitcoin을 대조해야 한다.
남은 부족분을 어떻게 보전하는지도 설명해야 한다. 그 답은 보유자가 잔여 위험에 노출되는지, 아니면 다른 당사자가 이를 떠안는지를 결정한다.
신중한 재가동에는 기능 담당자와 브리지 노드 전반의 버전 검사가 포함될 것이다. 또한 오래된 소프트웨어가 프로덕션 네트워크에 다시 연결될 수 없다는 가시적인 확인도 제공해야 한다.
서비스가 재개된 뒤에도 더 광범위한 Liquid Bitcoin 보안 문제는 남을 것이다. 연합체는 공개된 결함과 유사한 검증 실패 모두에 대한 방어를 추가했음을 보여줘야 한다.
개발자에게 주는 교훈은 구성 요소 경계를 넘어 보안 보장을 추적해야 한다는 것이다. 잘 보호된 키도 잘못된 거래를 승인하는 시스템을 구할 수는 없다.
거래소에 주는 교훈은 담보를 독립적으로 모니터링해야 한다는 것이다. 토큰이 정상적으로 보인다고 해서 준비금과의 관계가 온전하다는 보장은 없다.
자산 보유자에게 당장의 질문은 더 간단하다. 사고가 끝났다고 판단하기 전에 공식 서비스 공지, 준비금 데이터, 거래소 인출 상태를 지켜봐야 한다.
부분 반환은 파국적 손실을 회복 가능한 위기로 바꿨다. 그러나 그것만으로 일대일 보장을 복원하지는 못했다.
Liquid Network 해킹은 남은 잔액이 해결되고, 버그가 독립적으로 이해되며, 대조된 준비금을 바탕으로 정상 인출이 재개될 때에만 통제된 것으로 볼 수 있다. 그러한 조건이 확인되기 전까지 “대부분의 자금 반환”은 업데이트일 뿐, 결말은 아니다.
