Robinhood - CashCat 온체인 분석 시리즈 목차

1. Cashcat은 어떻게 200M을 갔나?
- 자금 유입 phase 1, 2
- 세력의 존재 근거들. 재단 or 자금세탁?

2. Dev cluster 분석
- 총 얼마 벌었나?
- 보유량/매매 패턴

3. 천상계 플레이 다시보기
- 빛
- 패턴분석

4. 블록타임/시기별 유입과 수익률 분석
- private 런칭시기 / Noxa,CC배포 전후 / public 후

5. 밈코에 대한 접근
- 반면교사

6. KOL 클러스터 조사

7. 마무리
- 툴 링크
- why?

헐 르브론 필라델피아 행;

처음으로 프로젝트 매니저(PM)라는 맥용 데스크톱 앱을 만들어봤습니다.

개발할때 로컬에 여러 포트 띄우고 백그라운드에 뭐 돌고 있는지 명령어로 확인하고 리소스 관리하기 귀찮아서 하나 만들어서 쓰니까 나름 편리하더라구요. 써보시고 피드백 좀 부탁드립니다...

https://github.com/heun630/pm

[x402 암호화폐 결제망에서 31개 취약점 발견..거래 99% 노출 위험]
크립토슬레이트에 따르면 HTTP 기반 암호화폐 결제 표준인 'x402'를 지원하는 주요 서비스 제공 업체들에서 31개의 신종 취약점이 발견됐다. 이번 조사는 전체 거래의 99%를 차지하는 15개 업체를 대상으로 진행되었으며, 모든 업체에서 결제 검증 및 정산 규정 위반이 확인됐다. 발견된 취약점은 무단 이용, 자산 도난, 서비스 거부, 가스비 남용 등 4가지 유형이다. 특히 정산이 완료되기 전 서비스를 제공하는 허점을 노린 '무단 이용(Free shopping)' 사례 2건이 검증됐다. 코인베이스, PayAI 등 주요 업체들은 관련 취약점을 인정하고 보완 작업에 나섰다. 연구진은 가맹점들에게 사전 검증에만 의존하지 말고, 최종 정산 확인 후 서비스를 제공하거나 명시적인 롤백 로직을 도입할 것을 당부했다.
https://coinness.com/news/1163979

Five Attacks on x402 Agentic Payment Protocol [출처]

x402의 공격 벡터를 다룬 논문이 arxiv에 8시간 전에 공개되었네요, 재미있게 한번 읽어보겠습니다

1/ 예전에 공유해 드린 논문인데, 아마도 이러한 공격 벡터들을 기반으로 조사가 진행되지 않았을까 추측해 봅니다.

사실 공식 문서에 나와 있는 결제 플로우만 보더라도 쉽게 예상할 수 있는 공격 방식들(예: 비동기식 블록체인 정산)이 존재합니다. 바로 이런 취약점들 때문에, 실제로는 기존 결제 플로우를 그대로 쓰기보다 약간 변형해서 사용하는 경우가 대부분입니다. (예: 클라우드플레어의 Monetization Workflow)

2/ https://arxiv.org/html/2607.19545

새로운 논문이 나왔군요 한번 뜯어보죠

이건 오히려 훨씬 잘썼다 싶었는데 시스템보안 학계 최고권위자가 교신저자로 들어가있네요. 논문 하나하나가 주옥같다

https://scholar.google.com/citations?user=9cFCY5wAAAAJ&hl=ko&oi=ao

https://www.youtube.com/watch?v=IH7LtXoC6CA&t=17s

요거 온체인버전이네요

3/ 결국 논문으로 돌아가면, 이 공격 벡터들이 나오는 근본 원인은 세 가지 설계 결정으로 나온다고 생각하는데:

첫째, verify가 nonce 소비나 자금 예약 없는 stateless 검사, 사실상 prediction에 그친다는 점
- 카드 결제의 authorization이 자금을 실제로 묶는 상태 변경인 반면, x402의 verify는 "settle 시점에도 유효할 것"이라는 예측일 뿐 보증이 아니므로 취약점 생길 가능성 농후

둘째, 소비자와 머천트를 동시에 보호하려다 보니 verify - execute - settle이라는 분리 구조가 나옴.
- 온체인 정산은 되돌릴 수 없으므로 business logic이 성공한 뒤에만 정산해야 하는데, 이 순서가 verify와 settle 사이에 어느 당사자도 책임지지 않는 상태 구간을 만든다.

셋째, gas와 rent 부담을 facilitator에게 이전함.
- 지갑에 native token이 없는 에이전트도 결제하게 하려는 선택인데, 그 순간 공격자 통제 입력이 facilitator 비용으로 직결

낙관적으로 보면, Cloudflare Monetization Gateway처럼 검증된 빅테크의 수직 통합 모델에서는 이 문제들이 그렇게 큰 문제를 야기하지는 않는데:
- 게이트웨이가 reverse proxy로 앉아 있어 origin이 리소스를 만들어놓아도 정산이 확정될 때까지 응답을 반출하지 않으면 되고(release를 settle 뒤로 미루는 것)
- gas와 rent도 자신이 fee payer라 통제 가능

다만 이건 취약점을 제거한 것이 아니라 다수의 분산된 구현 버그를 소수의 집중된 신뢰 가정으로 치환한 것에 가깝기 때문에...

4/ 결국 여기서 또 블록체인/탈중앙화의 아이러니가 나온거 같네요.

x402가 겨냥하는 시장은 원래 누구나 API를 팔 수 있는 개인과 소규모 공급자들의 마이크로페이먼트 시장인데, 완벽한 패널티 매커니즘(카드의 차지백같은)을 구현하지 않는 이상 컨슈머와 머천트를 동시에 보호하려는 탈중앙 설계는 필연적으로 실패할수 밖에 없다고 생각이 드네요

5/ 결국 그러한 시장이 온다고 하더라도, 지금 당장 드는 생각은 어그리게이터도 어느정도 인증된 기관이나 프로젝트들이 해야하지 않나 싶고(ex) Coinbase)

이러한 점에서 orthogonal(https://x.com/orthogonal_sh)과 같은 프로젝트들이 더욱 주목받지 않을까 하네요

6/ 이상, 퇴근길에 'x402 망했다' 뉴스 보고 밥 먹자마자 달려와서 부랴부랴 읽고 남겨보는 의견입니다 식겁했네요