제가 겨울에 발리 갔다가 다계폰 6개를 도둑맞았어요..
그 중 하나가 솔라나 시커폰이었어서 다들 $SKR 에드 받고 신나할 때 손가락만 빨고 있었습니다..
이 얘기는 예전에 채널에도 올렸었습니다.
프라이빗키 백업은 했었는데,
시커폰 내 시드볼트 앱에서 말곤 클레임 할 수 있는 곳도 없더라구요.
팀한테 연락도 해봤는데 시드볼트 앱에서밖에 클레임 못한다고,
받고 싶으면 솔라나폰 하나 더 사라고 엿같은 소리 하더라구요
그래서 포기하고 있었는데 돌찬님의 졷대는 경험 공유 가 생각나
카톡 대란때 산 chatGPT pro 가지고 이리저리 해봤습니다.
우선 컨트랙트 주소도 공개 안돼있어서 클레임 오픈 시간 이후 skr 토큰 트잭 많이 찍은 컨트랙트 찾아오라고 시켰고
이 주소에서 돈 찾아오는 계획은 chatGPT Pro 한테 시켰고, 이 계획대로 codex 5.3한테 이거 나한테 상당히 중요한 돈이니 꼭 내 돈 찾아달라고 했더니 찾아줬어요
알아서 지갑으로 샥 들어와 있었습니다.
에드 만개밖에 못받은건 아쉽네요.
자세한 과정은 밑에 적어둘게요
1. 처음에는 “Seeker 앱 화면 없이도 직접 클레임할 수 있는지”부터 확인했어요.
핵심은 두 가지였어요.
2. 찾아낸 클레임 컨트랙트인 mERK...가 진짜 클레임에 쓰이는지, 그리고 공식 흐름을 그대로 재현할 수 있는지.
초반에는 온체인 데이터부터 역으로 파봤어요.
SKR 민트와 관련된 큰 토큰 계정, 최근 트랜잭션 패턴, 반복되는 프로그램 호출을 모아서 봤고, 이 과정에서 mERK...가 후보가 아니라 실제로 쓰이는 축에 가깝다는 확신이 생겼어요.
3. 여기서 첫 번째 벽을 만났어요.
온체인 정보만으로는 “정확히 어떤 입력 형식으로 클레임을 만들어야 안전한지”가 100% 확정되지 않았어요.
즉, 억지로 직접 호출 코드를 짜는 건 가능해도 리스크가 컸어요.
4. 그래서 전략을 바꿔서, 사용자님이 말한 3번 경로(공식 웹/API 추적)로 전환했어요.
공식 웹이 실제로 어떤 순서로 호출하는지 따라가면, 불필요한 추측 없이 같은 결과를 낼 수 있으니까요.
5. publish 쪽 번들과 호출 흐름을 분석해서, 실제 SKR 클레임에 쓰이는 API 묶음을 찾아냈어요.
중요한 건 getClaimTx였고, 이 API가 “서명할 트랜잭션” 자체를 내려준다는 점이었어요.
이걸 확인한 순간부터 방향이 아주 명확해졌어요.
6. 두 번째 벽은 인증 상태였어요.
처음엔 어떤 요청이 JSON이 아니라 웹페이지(HTML)로 떨어져서 분석이 끊겼어요.
원인을 보니 계정 상태가 이메일 인증 단계에 걸려 있으면 그런 현상이 생기더라고요.
7. 이메일 인증이 끝난 상태로 다시 시도하니까, 같은 요청이 정상 JSON으로 돌아오기 시작했어요.
여기서부터는 클레임 관련 응답을 안정적으로 받을 수 있었고, 진행이 빨라졌어요.
8. 그다음 제 주소로 실제 클레임 트랜잭션을 받아서 디코드했어요.
안에 들어있는 프로그램 목록을 확인했더니, mERK...가 정확히 포함돼 있었어요.
즉, “우리가 보는 tx가 진짜 그 컨트랙트로 가는 tx”라는 걸 확인한 거예요.
9. 세 번째 벽은 데이터 충돌처럼 보이는 부분이었어요.
checkWalletEligibility는 부정적으로 나오는데, getClaimTx는 유효한 tx를 주는 상황이 있었어요.
처음 보면 모순처럼 보이죠.
10. 그래서 판단 기준을 바꿨어요.
단일 eligibility 숫자보다,
실제 getClaimTx 발급 여부
시뮬레이션 성공 여부
무관한 지갑으로는 실패하는지(대조군)
이 3개를 함께 보기로 했어요.
11. 대조군 테스트를 해보니, 랜덤 지갑은 wallet ineligible로 바로 막혔어요.
반면 사용자님 지갑은 시뮬레이션에서 Created new claim ... unlocked 10000000000 로그가 떴어요.
이걸로 “실행 가능 상태”를 확정했어요.
12. 이후에는 반복 실행 실수를 줄이기 위해 클레임 툴을 정리했어요.
기본은 dry-run, 전송 전 시뮬레이션, 예상치 못한 프로그램이 끼면 중단, mERK... 없으면 중단 같은 안전장치를 넣었어요.
13. 중간에 작은 장애물도 있었어요.
한 번은 JWT 전달이 비어서 인증 에러가 났고,
또 한 번은 사용자 정보 응답 형식 차이 때문에 상태 로그가 undefined로 찍혔어요.
둘 다 파싱/실행 쪽을 손봐서 안정화했어요.
14. 안정화 후 다시 사용자님 지갑 기준으로 dry-run을 돌렸고, 다시 성공했어요.
여기서 “실전 전송해도 된다”는 최종 판단을 했어요.
15. 실제 전송을 실행했고, 트랜잭션이 확인됐어요.
16. 마지막으로 온체인 잔고를 다시 읽어서 결과를 닫았어요.
SKR 잔고가 0 -> 10000000000(raw)로 바뀌었고, UI 단위로는 10,000 SKR 수령 확인이 됐어요.