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 수령 확인이 됐어요.