상황을 상상해보자. Polymarket에 USDC가 있고 조용하고 프라이빗한 보관을 위해 XMR을 원한다고 하자. rabbit.io에 가서 Polygon의 USDC를 XMR로 스왑하도록 주문을 설정하고, 입금 주소를 받아 토큰을 보냈는데 - 아무 일도 일어나지 않는다.
Polymarket에서 사용하는 지갑이 트랜잭션에 서명했다. Polygonscan에는 초록색 체크표시, 올바른 주소, 정확한 금액이 표시된다. 하지만 스왑 서비스는 입금을 인식하지 못한다.
언뜻 보기에 이는 이상하게 보인다. 블록체인은 모두가 공유하는 것이다. 익스플로러에 유입 전송이 표시된다면, 서비스가 버튼 하나만 누르면 토큰을 적립해주지 않을까?
그러나 이것은 어떤 암호화폐 거래소나 스왑 서비스에서도 마주칠 수 있는 문제다. 이유는 거래소와 스왑 서비스가 여러분처럼 블록 익스플로러를 읽지 않기 때문이다. 그들은 자동화된 입금 회계 시스템을 사용한다. 그리고 그 시스템은 체인에서 무언가가 어디론가 이동했다는 사실뿐 아니라, 그 이동이 진짜이고 최종적이며 지원되는 안전한 입금인지를 이해해야 한다.
바로 오늘 내가 이야기하고자 하는 문제는 여기서 시작된다.
비슷해 보이는 두 종류의 주소
EVM 네트워크에는 두 가지 유형의 주소가 있다.
- 사용자 주소. 공식적으로는 EOA(Externally Owned Account)라고 하며—가상 머신 밖 어딘가에서 트랜잭션에 서명되는 주소다. 이를 제어하려면 개인 키가 필요하다.
- 스마트 계약 주소. 이 주소에서의 전송은 온체인에서 실행되는 코드에 의해 생성된다. 즉, 해당 주소는 스마트 계약에 작성된 알고리즘에 의해 관리된다.
두 유형 모두 코인과 토큰을 수신하고 보유하며 보낼 수 있다. 일반 사용자에게는 둘 다 거의 동일하게 보인다: 0x로 시작하는 긴 문자열일 뿐이다. 그러나 트랜잭션 내부에서 일어나는 일을 회계해야 하는 어떤 시스템에게는 이 차이가 매우 중요하다.
이것을 이더리움으로 예를 들어 설명하겠다.
일반 지갑에서 ETH를 보내면, 그것은 단순한 전송이다: 주소 A가 주소 B로 자금을 보냈다. 이 작업은 메인 Transactions 탭에서 쉽게 찾을 수 있다.
그러나 ETH가 스마트 계약에서 도착하면, 그것은 Internal Transaction으로 나타날 수 있다. 수신자의 잔액은 실제로 증가하지만, 그 전송은 계약에 작성된 규칙에 따라 계약 실행 로직의 일부로 발생한 것이다.
이러한 트랜잭션을 통해 도착한 자금을 자동으로 적립해주는 것이 항상 옳은 결정은 아니다. 자금이 나온 계약이 어떤 종류인지, 그리고 트랜잭션 내부에서 정확히 무슨 일이 일어났는지를 먼저 확인하는 것이 합리적이다.
하지만 USDC는 항상 계약을 통해 전송되지 않나?
그렇다 — 그리고 이 점은 중요하다.
모든 ERC-20 토큰 — USDT, USDC, WBTC, LINK 등 — 은 그것을 정의한 스마트 계약의 규칙에 따라 주소 간에 이동한다. USDC를 전송할 때, 여러분은 그 토큰의 계약을 호출한다. 계약은 내부 잔액 테이블을 업데이트하고 블록체인에 Transfer 이벤트를 기록한다.
토큰의 경우, 이것은 정상적인 메커니즘이다. 입금 시스템은 이러한 전송을 처리하도록 구축되어 있다. 그렇다면 보통 문제없이 진행되는 이러한 토큰 전송과 자동으로 처리되지 않는 다른 전송 사이의 근본적인 차이는 무엇일까?
답은 토큰 전송 이벤트에 발신자로 누구(주소)가 기재되어 있는지에 있다.
USDC가 여러분의 일반 EOA 주소에서 차감되어 거래소나 스왑 서비스의 주소로 전송되었다면, 모든 것이 순조롭게 진행될 가능성이 크다. 문제가 발생할 수 있는 경우는 토큰이 브리지, 볼트(vault), 라우터, 스마트 월렛, 멀티시그, 또는 트레이딩 플랫폼 계약의 주소에서 차감될 때다.
왜 문제가 "발생할 수 있다"고 말하느냐고? 스마트 계약 기반 입금 처리 규칙은 서비스마다 다르기 때문이다.
Coinbase는 예를 들어 스마트 계약을 통한 ETH 및 ERC-20 입금은 지원하지만, Solana의 SOL 및 SPL 토큰에 대한 동등한 입금은 지원하지 않는다고 한다. Bybit는 FAQ에서 ETH를 제외한 모든 코인에 대한 스마트 계약 입금은 지원되지 않는다고 명시한다. Crypto.com은 대부분의 네이티브 EVM 체인 토큰에 관해 스마트 계약에서 온 입금은 자동으로 적립되지 않는다고 경고한다.
다시 말해, 업계에는 아직 어떤 계약 기반 전송을 정상적인 입금으로 간주할지, 어떤 것은 수동 처리가 필요할지, 어떤 것은 전혀 허용하지 않을지에 대한 단일 규칙이 없다.
문제를 더 심각하게 만드는 점은 사용자가 자신의 토큰이 EOA가 아닌 다른 무언가에서 전송되고 있다는 사실조차 모를 수 있다는 것이다.
보통 사용자는 어디에서 스마트 계약을 받게 되는가?
만약 내가 누구와도 어떤 계약을 체결하지 않았다면, 스마트 계약이 내 트랜잭션과 무슨 관련이 있겠는가?
불행히도 스마트 계약은 여러분의 직접적인 행동 없이도 체인에 나타날 수 있다. 예고 없이 나타나는 세 가지 일반적인 시나리오는 다음과 같다.
첫 번째 시나리오는 예측 시장, DEX 애그리게이터, 대출 프로토콜 또는 다른 dApp에서 자금을 출금할 때다. 이러한 앱들은 종종 자산을 여러분의 일반 주소가 아닌 계약 내부에 보관한다 — 여러분의 Web3 지갑이 이를 분명히 드러내지 않아 자산이 늘 여러분과 함께한 것처럼 생각할 수 있다.
정확히 말하면, 자산은 잔액으로 표시될 수 있지만 완전히 직접적인 통제 하에 있지는 않다. 해당 토큰을 이동시키는 것은 스마트 계약의 조건에 의해서만 가능하다.
그래서 여러분이 Withdraw(출금)를 클릭하면, 앱은 자금을 올바른 주소로 보낸다 — 그러나 온체인에서 발신자는 여러분의 EOA가 아니라 플랫폼의 계약인 것으로 드러난다.
두 번째 시나리오는 브리지와 관련된다.
하이퍼리퀴드(Hyperliquid), dYdX, Paradex, Payy Network 등 자체 내부 블록체인을 운영하는 거래소나 결제 서비스에서 출금할 때 브리지가 종종 작동한다. 그 내부 체인의 데이터베이스에서는 토큰이 여러분의 주소에 있었을 수 있으므로 여러분은 그것들이 그 주소에서 보내진다고 생각한다 — 스마트 계약에서 보내지는 것이 아니라.
그러나 그것들을 Arbitrum, Polygon, Ethereum 같은 다른 블록체인으로 옮기면, 수신자는 완전히 다른 주소로부터 토큰을 받게 될 수 있다. 목적지 네트워크에서의 여러분의 주소는 그 토큰을 보유한 적이 없었다. 토큰은 브리지 계약 또는 브리지 관련 인프라에 의해 보관되었고, 내부 체인은 다른 쪽의 잔액을 나타냈을 뿐이다.
이 모든 것이 이런 전송들이 반드시 모두 사라진다는 것을 의미하지는 않는다. 다만 수신 거래소나 스왑 서비스의 자동화 시스템에는 단순 전송처럼 보이지 않을 수 있다는 뜻이다.
세 번째 시나리오는 계정 추상화(wallets with account abstraction) 지갑과 관련된다.
이들은 실제로 유용하다: 결제 묶음(배치), 스테이블코인으로 가스비 지불, 제3자가 가스비를 대신 내주기, 맞춤형 지갑 복구 조건 설정 등 편의 기능을 제공한다. 그러나 이러한 편의는 종종 여러분의 지갑을 스마트 계약으로 바꾸는 방식으로 달성된다.
주목할 점: 이 유형의 가장 인기 있는 지갑 중 하나인 OKX Wallet의 개발자들은 그러한 지갑이 스마트 계약이며 시드 문구나 개인 키로 다른 앱에 가져올 수 없다는 점을 명확히 지적한다.
사용자에게는 개인 지갑처럼 보이지만, 수신 서비스에는 발신자가 스마트 계약일 수 있다.
거래소와 스왑 서비스가 이러한 전송을 경계하는 이유
가장 단순한 이유는 기술적이다. 자동화된 입금 스캐너는 비표준 블록체인 이벤트를 추적하지 못할 수 있다.
이 제한은 고쳐질 수 있다. 그러나 그것이 우연히 발생한 것은 아니다. 그 이면에는 더 깊은 보안 문제가 있다.
익스플로러에서 보기 좋다고 해서 모든 Transfer 이벤트를 신뢰할 수는 없다. 암호화폐 역사에는 이미 입금처럼 보이게 만들어 수신자가 실수로 이를 실제 입금으로 처리하도록 유도하는 가짜 입금 공격 사례가 있다.
6년 전 발표된 DEPOSafe 연구는 그러한 공격에 취약할 가능성이 있는 7,000개 이상의 계약을 발견했다. 그 계약들은 사라지지 않았다. 이더리움에 아직도 배포되어 있다. 그리고 지난 6년간, 다른 네트워크를 포함해 새로운 취약 계약들이 추가됐을 가능성이 매우 높다.
이 공격들의 핵심은 잘못된 신호를 신뢰하는 것이다.
수신자는 토큰이 도착한 것처럼 보이는 이벤트를 보고 자금이 그들의 것이라고 가정한다. 하지만 계약 로직은 실제 결과를 매우 다르게 만들 수 있다: 자금은 반환되거나 소각되거나 다른 곳으로 리디렉션되거나, 입금 시스템이 기대한 방식으로 수신자의 통제 하에 실제로 놓이지 않을 수 있다.
따라서 거래소와 스왑 서비스가 보이는 주의는 관료주의가 아니며, 다루기 까다로운 트랜잭션을 처리하기 싫어서 벌어지는 나태함도 아니다. 스마트 계약은 복잡하고, 신뢰할 수 있는 입금을 가짜 입금 공격과 구분하는 일은 항상 간단하지 않다.
내가 스마트 계약에서 보내는지 어떻게 알 수 있나?
여러분이 보내는 앱의 인터페이스는 자금이 실제로 어떤 유형의 주소에서 떠날지 전혀 알려주지 않을 때가 있다. 종종 이것은 사후에 익스플로러에서 무슨 일이 일어났는지를 확인한 후에야 평가할 수 있다.
ETH, AVAX, BNB 또는 HYPE와 같은 네이티브 자산을 보내는 경우, 들어오는 전송이 어디에 표시되는지 확인하라. Transactions에 표시된다면 아마 괜찮을 것이다. 그러나 이동이 Internal Transactions 또는 Internal Transfers 탭에 있다면, 이미 계약 기반 시나리오다.
ERC-20 토큰을 보내는 경우에는 Token Transfers를 열어 From 필드를 보라. 거기에 기재된 주소를 방문하라. Etherscan 및 유사한 익스플로러에서 스마트 계약은 보통 Contract 탭, 검증된 코드, 계약명 또는 라벨을 가지고 있다. 주소는 또한 Contract, Bridge, Router, Proxy, Safe, Vault, EntryPoint, Settlement 등으로 태그되어 있을 수 있다.
이 모든 것은 트랜잭션이 이미 존재할 때만 볼 수 있다. 따라서 새로운 플랫폼에서 의미 있는 금액을 보내기 전에, 자신에게 소액 테스트 전송을 해보고 그것이 스마트 계약 주소에서 왔는지 확인하라. 그렇지 않았다면, 이후에 그 플랫폼에서 보내는 전송은 대부분 일반 트랜잭션이나 토큰 전송으로 정상 처리될 가능성이 크다.
사전에 스마트 계약 발신을 알아차릴 수 있는 경우도 있다. 가장 명확한 것은 지갑이 가스비를 스테이블코인으로 지불하도록 허용할 때다. 스마트 계약 로직 없이는 그게 불가능하다.
또 다른 유용한 경고 신호: 앱을 통해 브리지를 통해 출금한 경우, 목적지 네트워크의 발신자는 여러분 자신의 EOA가 아니라 브리지 계약 또는 브리지 관련 인프라일 수 있다.
스마트 계약에서 전송하면 무슨 일이 일어날 수 있나?
첫 번째 가능성: 전송이 자동으로 처리된다. 스마트 계약에서 온 전송이 그 자체로 문제가 될 필요는 없다. 많은 잘 알려지고 신뢰할 수 있는 계약들이 거래소와 스왑 서비스에 의해 화이트리스트에 올라 있으며, 자동 입금 스캐너는 이러한 전송을 올바르게 처리할 수 있다.
두 번째 가능성: 입금이 자동으로 처리되지 않지만, 수동으로 찾아서 처리할 수 있다. 다만, 안전한 수동 처리는 스마트 계약과 트랜잭션 내부 구조를 신중히 검토해야 하므로 적립이 원하는 만큼 빠르게 이뤄지지 않을 수 있다.
Bitcointalk의 한 사용자는 최근 Polymarket에서 보낸 15,759 USDT를 HTX가 수동 적립을 위해 40영업일의 일정으로 처리한다고 공유했다.
세 번째 가능성: 트랜잭션을 검토한 후 수신자가 위험이 너무 높다고 판단해 토큰 적립을 거부할 수 있다. 그런 경우, 그들은 자금을 여러분에게 반환할 수도 있다.
마지막으로 네 번째 가능성: 자금이 수신자에게 도달했지만, 스마트 계약 때문에 수신자가 토큰을 기대한 방식으로 사용하거나 이동하지 못하게 될 수 있다. 그 경우, 환불조차 불가능할 수 있는데—이는 수신자가 부정직해서가 아니라 발신자의 스마트 계약 구조 때문일 수 있다.
바로 그렇기 때문에 거래소나 스왑 서비스로의 첫 전송 전에 실제 온체인 발신자가 누구인지 잠시 확인할 가치가 있다.
여러분의 주소에서 평범한 전송이 나갈지 확신이 서지 않는다면, 이전의 아웃고잉 트랜잭션을 찾아 블록 익스플로러에서 그것이 스마트 계약에서 시작되지 않았는지 확인하라. 확인할 트랜잭션 기록이 없다면, 먼저 소액을 테스트로 보내 모든 것이 원활히 진행되는지 확인하라.
rabbit.io에서는 실수로 스마트 계약에서 암호화 자산을 보냈더라도, 우리는 가능한 한 빨리 전송을 처리하거나 최악의 경우 자금을 반환하기 위해 우리가 할 수 있는 모든 조치를 취할 것임을 약속한다.
