2026-08-25 — rabbit 작업 이력
소스 문서: 없음 — jay가 "국내 가상자산 법률 현황을 PoC 항목으로 추가하라"고 직접 지시. 대상은 lib/poc-cards.ts. 전날 항목은 2026-08-24-rabbit-history.md.
PoC 카드 korea-digital-asset-act — 현황 요약이 아니라 "발표되지 않는 두 숫자"로
Cause: jay가 국내 가상자산 법률 현황을 PoC 항목으로 추가하고, done 항목들 아래에 놓으라고 지시.
Reasoning: 그대로 "현황 요약" 카드로 쓰면 이 카탈로그의 규칙을 어긴다 — 항목은 만들거나 재서 답할 수 있는 질문이어야 한다. 그래서 현황 자체를 측정 대상으로 뒤집었다. 조사해 보니 보도가 1년 넘게 같은 방식이었다: 건수("계류 법안 열 건 이상"). 그런데 건수는 쟁점 수가 아니다 — 실제로 다투는 건 원화 스테이블코인 발행 주체(한은: 은행 주도 51% 이상 / 금융위: MiCA 인가 발행자 다수가 전자화폐업자였다는 반론), 거래소 대주주 지분 한도, 발행·유통 분리 정도이고 나머지는 합의된 조문이 열 번 다시 쓰인 것일 가능성이 크다. 어느 쪽이 어느 쪽인지 아무도 발표한 적이 없다 — 이게 첫 번째 숫자다.
두 번째 숫자는 어제(2026-08-24) 한국경제 보도에서 나왔다. 금융위원장 이억원이 9월 내 목표를 밝히면서, 금융위가 정부제출이 아니라 의원입법 형태를 선호한다고 전해졌다. 두 경로는 절차가 같지 않다 — 정부입법에는 입법예고·규제영향분석·법제처 심사가 의무로 붙고 의원입법은 곧바로 상임위로 간다. 즉 경로 선택이 곧 "구속력이 생기기 전에 조문을 얼마나 공개하는가"의 선택인데, 일정 문제처럼 결정되고 있다. 이건 고발이 아니다(의원입법은 적법·일상적이다) — 요점은 산술이고, 일수로 표현 가능한데 아무도 표현하지 않는다는 것이다. 다만 의원입법이 정말 그 절차를 건너뛰는지가 하중을 받는 주장이라, howTo의 첫 작업을 "만들기"가 아니라 "국회법·행정절차법에 대고 확인"으로 두고 열린 질문에도 남겼다.
스테이블코인 조문은 cap-table-ceiling과 짝이 된다. 그 카드는 은행 둘이 각자 한도 아래에 앉아 아무도 합을 안 보는 집중을 찾았는데, 51% 요건은 같은 집중을 법정 요건으로 만든다 — 빈칸이 아니라 명문이 되는 것. 비용 쪽 대리지표도 이미 EU에 있다(MiCA 인가 발행자 중 은행 비중). 금융위는 이걸 정성적으로만 인용한다.
Change: lib/poc-cards.ts에 korea-digital-asset-act 카드 추가 — status: "soon", date 없음(신규 항목 기본값 규칙). 측정 절차는 의안정보시스템 공개 API 기반 5단계(법안 수집 → 조문 분해·정규화 → 법안 가로지른 군집화 → 합의/쟁점 표시 → 경로별 사전심사 기록), 산출물은 쟁점 조문 ÷ 법안 수와 사라진 의견수렴 일수. cap-table-ceiling 바로 뒤에 배치해 국내 규제 카드를 묶었다. pnpm docs:pocs 재생성.
Result: npx tsc --noEmit exit 0. 렌더링 카드 58 → 59, 신규 카드는 목록 22번이며 PLANNED 구간 안 — 뒤에 DONE 카드 0개(jay 요청대로 done 항목들 아래). 생성 HTML 스윕: docs/pocs.html 태그 균형 OK·깨진 로컬 링크 0, 신규 상세 페이지 docs/topics/pocs-korea-digital-asset-act.html도 균형 OK·깨진 링크 0. docs/topics/ 37개 파일이 함께 바뀐 것은 22번 삽입으로 인한 번호 재부여뿐이다. docs/index.html은 라이브 카드 6개만 싣기 때문에 변동 없음(기존 div 28/27 불균형과 file:/// 절대링크는 그대로 — 이번 변경과 무관). 남은 결정(jay): 의원입법 절차 예외의 실제 범위 확인, 그리고 "예측시장을 국내에서 운영하는 것 자체가 합법인가"는 별도 카드로 뺄지.
J2 재배열: W1을 끝으로, O1은 file: 링크로 답함 — 그리고 Phase 1이 "추가"임을 명시
Cause: 로컬 Foundry(anvil) 체인에서 구현을 시작하기로 하면서 jay가 세 가지를 물었다 — ① P0(=verex W1)를 지금 해야 하는가, ② mock UMA로 로컬 테스트해도 되는가, ③ Phase 1 이후 데모 지갑이 못 쓰게 되는가. 답을 찾는 과정에서 계획서의 세 군데가 틀렸음이 드러났다.
Reasoning: ① W1은 로컬에서 원리상 불가능하다 — 내용 자체가 "라이브 Sepolia UMA 오라클로 정산"이고, mock 경로는 uma-demo.ts에서 이미 증명돼 있다. 그런데 계획서가 W1을 "Phase 0, 맨 먼저"로 둔 근거는 스테이징 재시딩이 거래 이력을 지운다는 것뿐이었다. 그건 첫 스테이징 실행 이전을 뜻하지 모든 것 이전이 아니다. 로컬에서는 reset.sh로 언제든 지우고 다시 심고, mock은 즉시 정산되므로 redemption을 포함해 Phase 1–4 전부가 anvil에서 테스트 가능하다. jay 지적대로 테스트넷 테스트는 어차피 끝에 다시 하므로 일찍 하면 두 번 하는 것 — 그래서 W1을 Phase 6으로 옮겼다. 다만 W1은 이 계획서에서 한 번도 동작한 적 없는 유일한 항목이고 의존 대상이 verex가 쓰지 않은 컨트랙트라, 가장 위험한 미지수를 끝에 두는 함정을 피하려 W0 스모크 프로브(라이브 어댑터에 initialize 한 번, 몇 분)만 앞으로 당겼다. ② mock 사용은 정답이다 — 어댑터가 mock/실물을 구분하지 못하도록 의도적으로 설계돼 있어 로컬 경로가 곧 Sepolia 경로다. 다만 mock이 더 관대한 지점 넷(담보 화이트리스트·final fee·liveness·분쟁)을 표로 못 박았다. 특히 MockUSDC는 UMA AddressWhitelist에 없다 — 로컬에서 통과하고 Sepolia에서 revert 하는 함정이고, 어댑터 docblock에는 있는데 계획서에는 없었다. ③ 데모 지갑은 계속 쓸 수 있다. makerIndex는 nullable이 되지 제거되지 않고, V-B는 외부 maker에만 적용되며, 인덱스 0은 오퍼레이터 LMSR maker라 애초에 뺄 수 없다(외부 주문이 체결되는 상대). 그런데 Phase 1 done-when이 "거래소 어디에도 accountIndex 없음"이라고 적혀 있어 제거를 약속하는 것처럼 읽혔다 — jay가 실제로 그렇게 오해했으므로 문구 자체가 버그다.
Change: current-plan.md — Phase 0 삭제 후 W0 스모크 프로브(비-phase, #probe)로 대체, Phase 6 "go to Sepolia" 신설(7단계 표 + 함정 + "분쟁 없는 경로만"), Phase 1 done-when을 외부 maker 경로에 accountIndex 불요로 재작성 + "Phase 1은 추가적" 인용문, V-C 이후 MetaMask 서명 주문 마일스톤(O1 비의존) 추가, R-G에 "폴링하라, 인라인 await 금지"의 이유 추가, V-A에 /config가 거래소 주소를 노출해야 한다는 요구(로컬 리셋마다 주소가 바뀜) 추가, 매트릭스에서 V-A의 Depends on: P0 제거(기술적 의존이 아니라 스테이징 데이터 순서 제약이 의존의 옷을 입은 것), W0·W1 행 추가, §0 요약과 Repo status의 blocking decision 갱신, O1을 ✅ 답함으로 재작성(로컬 file: 링크 → 배포 전 퍼블리시), O8 신설(사용자 인덱스 경로 폐기는 트리거가 올 때). verex 쪽 verex 저장소의 docs/tasks/current-plan.md(W1) — W1 헤더를 J2 phase 6으로, 순서 근거를 "W6보다 먼저"에서 "첫 스테이징 실행보다 먼저"로 정정, mock 대 라이브 비교표와 undisputed-only 지침 추가. 코드 변경 없음.
Result: rabbit 계획서 +79/−28, verex 계획서 +28/−6. 내부 앵커 전수 검사 통과(끊긴 링크 0). 빌드 순서는 W0(병렬) → Phase 1–5(전부 로컬 anvil) → Phase 6(Sepolia)이 됐고, 테스트 가능한 슬라이스 {V-A, V-B, V-C, R-A, R-B, R-C}에 남은 블로커가 0개다 — O1이 답해지면서 R-B가 풀렸다. 남은 결정(jay): O2(스케줄러 호스트), O5(LLM 비용·주기), O6(스테이징 vs 전용 환경), O7(뉴스 스코프·만료), O8(트리거 대기), O3(에이전트가 건드릴 마켓).
l1-zkevm-optional-proofs → done
소스 문서: lib/poc-cards.ts — PoC 카드의 유일한 원본. 생성물은
docs/topics/pocs-<key>.html,docs/pocs.html,docs/index.html의 PoCs 구간.
Cause: jay가 네 질문(①싸다면 누가 재실행하나 ②증명 다양성이 해결하나 ③밑바닥 메커니즘 ④해시만으로 트랜잭션이 옳다는 보장이 되나)으로 정리한 요약을 상세 페이지에 넣고 카드를 done 으로 올려달라고 요청.
Reasoning: 요약을 넣기 전에 카드를 먼저 대조했더니 네 질문의 결론이 이미 Update 2026-08-25 절에 EN/KO 양쪽으로 들어가 있었다(커밋 1dda113) — 증명이 주장하는 것(공개 입력 대 증인), 블록 해시가 약점이 아닌 이유, 보장하지 않는 셋(포함·순서·데이터 가용성), 재실행 집단 넷과 거부권 비대칭, 다양성이 새는 곳 셋과 집계의 아이러니, 다양성 대 표본 재실행 표, 그리고 추가된 측정(공유 의존성 그래프)까지. 같은 내용을 다시 붙이면 상세 페이지에 같은 논증이 두 번 실린다. 그래서 본문은 그대로 두고 상태만 올렸다. 질문 ①~④ 형태의 재구성은 표현 문제라 별건으로 남긴다.
Change: lib/poc-cards.ts의 l1-zkevm-optional-proofs 카드 status: "soon" → "done". node scripts/generate-pocs-html.mjs 실행.
Result: 상세 페이지에 DONE 배지, done 그룹으로 이동. 부수 변경 둘은 번호 재배열뿐 — stake-concentration 8 → 9, erc-7683-settlement-security의 이웃 링크 갱신. 카드 총 59장.
PoC 카드 monad-last-general-purpose-l1 신설 — 통합이 닫는 것은 아무도 재지 않는다
소스 문서: Four Pillars · Validated, Monad: The Last General-Purpose L1(c4lvin, 2026, 71쪽) — jay가 PDF를 건네고 카드화를 지시. 대상은 lib/poc-cards.ts.
Cause: jay가 Monad 리포트 PDF를 읽게 하고 그 내용을 PoC 항목으로 추가하라고 요청.
Reasoning: "마지막 범용 L1"이라는 표제를 그대로 카드로 옮기면 이 카탈로그의 규칙을 어긴다 — 항목은 재서 답할 수 있는 질문이어야 한다. 그래서 리포트가 반복해서 다는 각주를 카드의 축으로 세웠다: 보고서의 강한 수치 대부분이 살아 있는 인센티브 프로그램과 겹치는데 인센티브를 보정한 값은 아무도 발표하지 않는다. 여기에 더 날카로운 두 번째 축을 붙였다 — 통합이 닫아버리는 카테고리는 아무도 채점하지 않는다. Monad에 이미 깨끗한 사례가 있다: LST 4곳이 $46M을 조달했는데 합산 TVL은 약 $12M이고, 이유는 팀의 실패가 아니라 Monad가 네이티브 스테이킹을 합의 안에 넣고 슬래싱을 구현하지 않았다는 설계 자체다. 체인이 그 앱의 존재 이유를 흡수했다. 모놀리식 체인은 통합이 만드는 프리미엄만 재고 닫는 것은 재지 않는데, 둘은 같은 선택의 결과다. 대조군도 이미 있다 — Neverland는 프로그램이 끝나 감쇠 곡선(차입 -87%, 일일 수수료 3주 만에 $18–19K → $3,700)이 실측돼 있어, 다른 프로그램을 맞춰 볼 형판이 된다.
Change: lib/poc-cards.ts에 카드 신설(EN/KO 전체) — 측정 셋(인센티브 보정 수요 · 봉쇄된 카테고리 수 · 컴포저빌리티 프리미엄), Opinion Labs가 BNB로 떠나고 HelloTrade가 들어온 양방향 사례, 그리고 예측시장 메모(Polymarket 2025-12·Kalshi 7월이 Monad를 입금 레일로 쓰는데 네이티브 승자는 없음). status: "soon" — 신규 항목은 done 으로 올리지 않는다. node scripts/generate-pocs-html.mjs 실행.
Result: 카드 총 59 → 60장. 상세 페이지 생성(21.6KB, PLANNED 배지, 표 2개, EN/KO 각 4개 절). npx tsc --noEmit 통과. 부수 변경 52개 파일은 전부 번호 재배열 — event-contract-plumbing 뒤에 끼워 넣어 이후 카드의 번호와 이웃 링크가 한 칸씩 밀렸다. 배치를 뒤로 옮기면 이 churn 은 사라진다.
J2 Phase 1 구현 + Phase 2 골격 — 그리고 계획서가 틀렸던 두 곳
Cause: jay가 로컬 Foundry 체인 위에서 Phase 1·2를 claude/j2-phase-1-2 브랜치에 구현하라고 지시. 완료 후 확인하겠다며 "무엇을 했고 어떻게 확인하는지"를 계획서에 정리해달라고 요청.
Reasoning: 코드를 읽는 과정에서 계획서의 주장 두 개가 틀렸음이 드러났다. ① "외부 주문 수용은 대체로 서명 단계를 삭제하는 것"이 아니다. 서명 시점이 둘이고, 대기 지정가 주문만 삭제로 끝난다. 정산 시점의 taker 다리는 book.ts가 체결마다 새 하위 주문을 maker의 정확한 가격과 그 체결 수량으로 서명하는데, 그 수량은 매칭 이후에야 존재하므로 클라이언트가 미리 서명할 수 없다. 해법은 이미 있었다 — matchOrders가 takerFillAmount를 주문과 별도로 받는다. 그래서 외부 클라이언트는 전체 수량에 대해 주문 하나를 서명하고 같은 서명이 각 체결을 부분 정산한다. 체결별 서명은 서버가 키를 쥐고 있어서 가능했던 것이지 거래소가 요구한 게 아니었다. ② V-D는 명세대로 만들 수 없다. POST /redeem을 주소 기반으로 바꾸라고 되어 있지만, redeemPositions는 보유자가 보내야 하고 verex는 그 키가 없다. 그래서 엔드포인트의 의미를 실행에서 기록으로 바꿨다 — 보유자가 redeem 하고 tx를 보고하면 verex가 영수증의 PayoutRedemption(redeemer + conditionId)을 검증한 뒤에야 REDEEM 행을 쓴다. 말을 믿는 게 아니라 체인이 낸 증거를 읽는 것이고, V-A의 나머지와 같은 형태다(클라이언트가 행동하고 서버가 확인한다).
O1은 file: 링크로 답했다 — 서명 대상이 12개 필드 + 도메인에 대한 EIP-712 해시라, 사본이 한 글자만 어긋나도 틀린 메시지에 대한 유효한 서명이 나오고 에러는 구조체를 언급하지 않는다. recoverOrderSigner를 SDK에 넣어 검증이 같은 ORDER_TYPES를 재사용하게 한 것도 같은 이유다.
Change: verex — verifyExternalOrder(서명 타입·maker≡signer·taker 미지정·tokenId·side·수수료·만료 + 선언된 가격·수량 대비 정확한 금액 확인 후 서명자 복원), checkExternalFunds(읽고 거절), walletSummaryByAddress/walletHistoryByAddress, faucetTo, recordExternalRedeem, /config에 exchange·ctf·usdc, makerIndex Int? 마이그레이션, SDK recoverOrderSigner + 테스트 3건. 라우트는 /wallet/:x가 isAddress로 분기한다 — :index와 :address를 따로 등록하면 라우터에겐 같은 라우트라 먼저 등록된 쪽이 둘 다 삼킨다. rabbit — @verex/sdk file: 링크, lib/agent-wallet.ts(키는 서버, 브라우저엔 주소만), lib/verex-client.ts, lib/agent-estimate.ts(뉴스 없으면 LLM을 부르지 않음), NewsItem·Mandate·AgentTick 모델, app/api/agent/{news,mandate,tick}. 계획서에 "Built so far — and how to check it" 절 신설(16단계 확인 절차 + 자동 검사 명령).
Result: verex tsc --noEmit 통과, SDK 테스트 6/6(변조된 makerAmount가 서명자로 복원되지 않는 케이스 포함), rabbit tsc --noEmit 통과. anvil이 꺼져 있어 종단 실행은 못 했고, 그래서 확인 절차를 계획서에 적어 jay가 직접 밟을 수 있게 했다. 의도적으로 남긴 빈틈: 자금을 배치 시점에만 확인하므로 외부 maker가 대기 주문을 넣고 인출할 수 있다 — verex 계획서에 W6.5로 기록(싼 해법은 매칭 시점 재확인, 철저한 해법은 W5). 이 사실이 V3.2(인덱서 드롭)의 전제 *"DB는 API만 쓴다"*도 끝내므로 두 번째 재검토 트리거로 함께 적었다. 미착수: R-A/R-E/R-I의 UI, R-F 스케줄러, R-G, R-H, V-E, W1.