MCP Management

한 문장 요약

1~8차 에어드랍에서 받기로 약속됐던 사람들이 실제로 MPC 토큰을 받았는지 회차별로 한 줄씩 확인합니다. "약속(CSV) vs 현실(블록체인)"의 대조표입니다.

무엇과 무엇을 비교하는가

• 계획(planned) — Archive/<회차>/ 폴더에 들어있는 회차별 송금 CSV. "이 지갑에 이 토큰 얼마를 보내야 한다"는 작업 명세입니다. 헤더는 to;transferCoin;transferAmount 형식.
• 실제(onchain) — Polygonscan에서 동기화해온 실제 MPC 토큰 전송 기록. 이게 "정말 일어난 일"입니다.

매칭 방법 — 행 하나하나가 아니라 지갑 단위로

planned CSV에는 같은 지갑이 여러 줄에 나뉘어 있을 수 있고, onchain도 한 명에게 여러 번 나눠 보냈을 수 있습니다. 그래서 행 1대1로 비교하지 않고, 지갑 주소 단위로 합쳐서 "이 지갑이 받기로 한 합계" vs "이 지갑이 실제 받은 합계"를 맞춥니다.

• CSV에 거래 해시(source_tx_hash)가 적혀 있으면 그 해시로 직접 짚어서 확인 (Tier A).
• 없으면 (받는 지갑 + 수량) 조합으로 후보 거래를 찾습니다.

표의 두 가지 비율 — 하나는 신뢰, 하나는 참고만

• 수신자 매칭율 = (MPC를 한 번이라도 받은 planned 지갑) ÷ (planned 지갑 총 수). 가장 신뢰할 수 있는 숫자. 100% 면 그 회차에 누락된 사람이 없다는 뜻.
• 금액 매칭율 = (onchain MPC 합계) ÷ (planned MPC 합계). ⚠ 보조 지표. 같은 지갑이 여러 회차에 걸쳐 등장하면, 그 지갑이 받은 onchain 합이 등장한 회차마다 똑같이 잡혀서 100%를 훌쩍 넘기도 합니다 (중복 카운팅). 단독 진단용으로 쓰지 말고, 수신자 매칭율과 함께 보세요.

오른쪽 컬럼 의미

• 미수령 — planned에는 있는데 MPC를 단 한 번도 못 받은 지갑 수.
• 점검대상 — 미수령 중 시스템적으로 액션 가능한 건 (송금 누락 + audit hash 불일치). 나머지(community 미등록 사용자)는 시스템 측에서 확정 불가능.
• 금액불일치 — 받긴 받았는데 합계가 다른 지갑 수 (오차 0.001 MPC 이상).
• Tier A hash — CSV에 source_tx_hash가 적힌 행 중 그 해시가 실제 onchain에서 발견된 비율.

미수령자 분류 카테고리

• 송금 누락 (다른 회차에도 미수령) — 같은 지갑이 여러 회차 planned에 있는데 전 회차에서 한 번도 못 받음. 즉시 점검 필요.
• audit hash가 polygon에 없음 — audit CSV에 송금 완료된 것으로 기록(PolygonScanTx)되었지만 실제 polygon MPC 컨트랙트 sync에는 그 트랜잭션이 없음. audit 데이터 신뢰성 또는 송금 실패.
• 송금 누락 (단일 회차, community 등록자) — 한 회차에만 등장하지만 8차 community에 wallet이 등록된 사용자. 진짜 누락 가능성.
• 사용자 미참여 (community 미등록) — 단일 회차 + 8차 community에 wallet 등록 안 함. 사용자 이탈/포기 추정, 시스템적으로 확정 어려움.

왜 페이지 진입에 시간이 걸리나

검증 결과를 미리 저장해두는 테이블이 없습니다 (CLAUDE.md 정책: 사전계산 캐시 금지). 매 진입마다 8개 회차 × 수천 지갑을 SQLite에서 GROUP BY/JOIN으로 다시 돌리기 때문에 페이지가 뜨기까지 몇 초~수십 초 걸립니다. 클릭하면 어두운 화면에 스피너가 뜨니 그동안 기다려 주세요. 정상 동작입니다.