CrownyDoc 문서함 견적서 제안서 도면 + 새 문서 문서편집기 프로젝트문서 기술백서
← 목록
기타 2026-07-29 48KB 읽기 46분

크라우니 디지털화폐·블록체인 자산 감사 + DEX 접속 준비 계획

개요

크라우니DEX(dex.crowny.org:9402, 1단계 라이브)가 자체 인메모리 원장으로만 돌고 있다. DEX를 실제 화폐 인프라에 붙이려면 그 뒤의 블록체인(crowny-chain)·지갑(wallet/pay/paygate)·토큰 페그가 먼저 정확해야 한다. 이 문서는 세 자산의 실측 감사 결과와, DEX 접속을 위한 보완 계획이다.

범위 구분: crowny-dex 2단계(에이전트6561·배포·딥링크)는 다른 세션이 진행 중(LIVE_STATUS 3세션). 이 트랙은 그 아래층 = 체인·지갑·토큰 정합/보안/효율 및 접속 계약만 다룬다. 파일 충돌 없음.

1. 자산 실측 현황

1-1. 블록체인 — /Users/ef/crowny-chain (전량 한선씨)

항목실측
라이브코인체인 9729 crownyc run /tmp/crowny-chain.toau LISTEN. 스테이킹서버 별도 가동
혼재9730/9731/9732/9733/9740은 node 프로세스가 리슨 — 시작.sh의 순한선씨 7서버 구성과 실운영이 다름
블록높이:이전해시:TX:채굴자 SHA256, WAL /Users/ef/crowny-data/chain/coin-wal.log (B|/T|)
복원2026-07-16 수정 완료(블록·잔고·발행량·TX수 전체 복원, 파이프 오른쪽 기준 파싱). 백업 .bak 보존
합의없음 — /api/mine 호출자가 miner 자유 지정(사실상 중앙 coinbase)
토큰CRN 단일(보상27, 729블록 반감기 ÷3, 최대 27,000,000). 뱅크서버는 CRN/FNC/CRM 3종, 고정환율 하드코딩

1-2. 지갑·결제

리포포트상태
crowny-wallet (지갑서버.한선)9410LaunchAgent 로드·가동
crowny-pay (server.한선+server.js)9866plist.disabled, 포트 dead
crowny-paygate9954가동 중, HMAC 웹훅
  • 원장은 JSON 파일 기반(JsonStore, tmp→rename). SQLite/WAL 없음.
  • crowny-pay/paygate 어디도 crowny-chain에 기록하지 않음 — 완전 독립 폐쇄 원장.

1-3. 토큰 페그 (SSOT = /Users/ef/crowny-pay/페그.한선)

1 CRD = 1,000원        (내부전용·공개 페깅표현 금지)
1 CRN = 25,500원 = 10 포네 = 1,000 맘 = 25.5 CRD
소수 회피를 위해 ×2 정수연산(CRN을CRD로x2), 원화→CRD는 안전몫(내림), 정합판정은 곱셈만 — 설계 견고. CRNY 구명칭은 화폐게이트.sh 금칙어 린트로 회귀 차단 중(실질 잔재 없음, market 2파일만 텍스트 언급).

1-3b. 스테이킹·마켓 (별도 리포 아님 — 위치 정정)

  • /Users/ef/crowny-stake는 존재하지 않는다. 실체는 /Users/ef/crowny-chain/서버/스테이킹서버.한선(1,247줄), 포트 9603 라이브(/api/health 200). gateway.yaml에 stake.crowny.org → 9603 등록됨.
  • 언본딩 3에포크(10,800초), APR 900bp, 4상 슬래싱(정상 티/1~2에폭 옴 경고/3에폭↑ 타 젤드+5%bp).
  • 비례슬래시 잔여는 07-16 완료 — 자기지분만이 아니라 전 위임자 활성분 비례 차감(1020→969 격리 검증).
  • 원장 = append-only PSV /Users/ef/crowny-chain/데이터/스테이킹.psv, 재기동 시 로그 재스캔 복원. 밸리데이터 잔고는 9729에 curl 검증(다운 시 자체 폴백).
  • crowny-market: 결제토큰 CRN/FNC/MOM 다통화 에스크로, CRD는 결제수단이 아님(CRD=DEX 대출 전용 발행). CRNY 잔재는 .bak-crn 백업 2건뿐, 라이브 코드 0. 별도 P2P 셀러노드 체인(9750/9751) 보유 — chain과 다른 계통.

    • 1-3c. 재사용 가능 자산

    자산경로수준
    체인 코어(운영중 9729)crowny-chain/서버/크라우니코인.한선, CrownyOS/crownyc/블록체인서버.한선(888줄, 4상3진 셀)높음
    스테이킹(운영중 9603)crowny-chain/서버/스테이킹서버.한선높음
    DEX v2(라이브 9402)crowny-dex/DEX서버.한선(1,296줄)높음
    구 오더북 DEX(백업)crowny-dex-backup-20260728/crowny-dex/참고 — 매칭엔진(가격-시간 우선순위·체결·1h 만료) 로직 보유. 신 DEX는 오더 등록만 되고 체결 미구현이라 이식 후보
    AMM 거래소(구 토크노믹스)CrownyOS/crownyc/크라우니거래소서버.한선(677줄, x*y=k+주문장 3페어)중간, 골격 참고
    컨트랙트 VMCrownyOS/crownyc/컨트랙트.한선(99줄)낮음, 개념증명
    게이트웨이 등록 현황: dex(9402, health /api/dex/prices)·chain·chain-node·chain-v2·amena-chain·stake(9603). coin 단독 도메인 없음(chain에 통합). 과거 장애: 2026-06-23 DEX가 9729 하드코딩으로 chain과 bind 충돌 → busy-wait CPU 100% 스핀. 정본 포트 9402 확정으로 수리됨. bind 실패 시 종료(busy-spin 금지) 원칙 재확인 필요.

    1-4. 정합 불일치 (핵심 문제)

    페그가 3중으로 따로 존재한다:
    위치값
    crowny-pay/페그.한선 (SSOT 선언)CRN 25,500원 / CRD 1,000원
    crowny-chain 뱅크서버.한선CRN대FNC=10, CRN대CRM=1000 하드코딩, 원화가 미참조
    crowny-dex/DEX서버.한선CRN=25.5CRD, FNC=2.55, CRM=0.0255 자체 상수
    crowny-marketEXCHANGE_RATES {CRN:25500, FNC:2550, MOM:25.5}
    값은 현재 우연히 일치하지만 참조 관계가 없어 한 곳만 바뀌면 조용히 어긋난다. 백서의 "회기(매년 9/30) 연 ~7% 상향"이 실행되는 순간 즉시 4중 분기된다.

    1-5. ★정정 — 체인 서버군 실제 가동 범위 (2026-07-29 13:5x 실측)

    앞선 1-1의 "9730/9733 등은 node 래퍼로 운영 중"은 오판이었다. 실측 결과:

    포트실제 점유 프로세스포트 레지스트리 정당 소유자체인 서버 상태
    9729crownyc run /tmp/crowny-chain.toau (PID 62884, 13:03:45 기동)chain.crowny.org (crowny-chain)코인체인 라이브
    9730node /Users/ef/crowny-project/server.jsproject.crowny.org (crowny-project)게이트웨이서버 미가동
    9733node /Users/ef/crowny-market/server.jsmarket.crowny.org (crowny-market)뱅크서버 미가동
    • 즉 crowny-chain에서 실제로 도는 것은 코인체인(9729)뿐이다. 뱅크서버·게이트웨이서버·연동은 소스만 있고 가동되지 않는 죽은 코드다.
    • libs/체인공통.한선의 포트 상수 체인_게이트웨이포트=9730, 체인_뱅크포트=9733은 다른 서비스가 정당하게 점유한 포트를 가리킨다(레지스트리 충돌). 기동을 시도하면 bind 실패한다.
    • 보안 영향: 뱅크 /api/transfer·/api/credit/grant 무인증 취약점은 현재 노출되어 있지 않다(서버가 안 뜸). 다만 소스 취약점이므로 기동 시 즉시 노출된다 — 배선은 여전히 필요하고, 실효 검증은 포트 재배정 후에만 가능하다.

    2. 보안 감사 (우선순위순)

    #심각도위치내용
    S1P0crowny-chain 코인 /api/mine, 뱅크 /api/transfer·/api/credit/grant인증·서명 전무. 요청자가 miner/from/id 자유 지정 → 임의 발행·임의 송금. 과거 "PUT 무인증 민팅"과 동일 계열이 POST로 잔존. X-Chain-Token은 CORS 허용목록에만 있고 검증 코드 없음
    S2P0crowny-chain 게이트웨이서버 /proxy/<서비스>/<경로>, 연동.한선 기여기록클라이언트 경로/payload를 체계()의 curl 문자열에 그대로 결합. ..만 차단, 백틱/$()/; 무필터 → 명령 인젝션. (crowny-services 3회 반복된 동일 패턴)
    S3P1crowny-dex /api/_seed, /api/_settimeQA 백도어 — 시간·잔액 임의 조작 가능. 실배포 전 가드/제거 필요(1단계 문서에도 기재)
    S4P1crowny-paygate웹훅 HMAC 시크릿 = merchant.apiKey 재사용. 키 유출 시 웹훅 위조까지 연쇄
    S5P2crowny-pay관리자 시크릿 하드코드 폴백(crowny-pay-2026-...) — env 미설정 시 그대로 노출
    S6P2뱅크서버지갑ID 문자열 매칭만, 서명 검증 없음. 거래해시는 인증이 아님

    3. 코드·통신 효율

    #위치내용
    E1crowny-chain 전 서버TCP수락→읽기→처리→쓰기→닫기 단일 blocking loop — 동시성 0, 연결 순차 처리. DEX가 체인을 동기 호출하면 DEX 응답이 체인 처리량에 직결
    E2crowny-chain 코인블록해시목록 트리밍 없음(이벤트는 1000 제한 有) → 배열4095 상한 충돌 + 이후 조회 O(n) 저하
    E3WALappend만, 스냅샷·압축·로테이션 없음 → 기동 재생 시간이 무한 증가
    E4crowny-payrequireMerchant()가 매 요청 전체 선형 스캔. paygate는 Map 인덱스로 이미 해결 — pay만 미해결
    E5crowny-dex프로세스 재시작 시 인메모리 잔액 미복원(TSV append만) — 재기동=잔고 소실
    E6crowny-pay트랜잭션당 개별 JSON 파일 → 결제량 증가 시 inode·I/O 팽창
    E7전반서비스 간 통신이 체계()+curl 셸 경유 — 프로세스 fork 비용 + S2 인젝션 표면의 근원

    4. DEX 접속 관점 갭

    • crowny-chain/연동.한선의 DEX주소 = http://localhost:9729는 코인서버 자기 자신을 가리킨다. 실제 DEX(9402)와 무연결이며 /api/ticker/<토큰>이 코인서버에 없어 이 경로는 항상 실패.
    • 체인 게이트웨이 라우팅에 DEX·연동(9735)이 없음 → 외부에서 DEX 관련 체인 엔드포인트 진입 경로 자체가 없음.
    • DEX의 스왑/대출/기부는 체인에 한 줄도 기록되지 않는다. 감사 가능성(백서 §5 "기부 공개 장부")이 성립하지 않음.
    • 지갑 단일화 부재: DEX 잔고 · 뱅크 지갑(9733) · wallet(9410) · pay(9866, dead)가 각각 다른 사용자 잔고를 가진다.

    5. 보완 계획 (단계·의존순)

    P0 — 즉시 (보안, 다른 작업과 무관하게 선행)

    1. S1 인증 게이트: 체인 쓰기 API(/api/mine,/transfer,/credit/grant)에 서명/토큰 검증 도입. 한선씨 체인인증.한선 신설 — HMAC(공유키) 1차 → 키쌍 서명 2차. 무인증 요청 401.
    2. S2 인젝션 차단: 체계() 결합 지점 전수(게이트웨이서버·연동)에 화이트리스트 새니타이저 셸안전.한선 적용. 중기적으로 curl 경유를 TCP 직호출로 교체(E7 동시 해소).
    3. S3 백도어 가드: DEX _seed/_settime을 DEX_QA=1 env + 로컬 바인드에서만 활성.

    P1 — 페그 단일화 (DEX 접속의 전제)

    1. crowny-pay/페그.한선을 유일 SSOT로 승격, chain 뱅크서버·DEX·market이 하드코딩 대신 이를 가져오기하도록 전환. 값 변경 1곳 원칙.
    2. 회기 상향 엔진: 연 ~7% CRN 상향을 페그.한선에 회기 테이블로 구현(매년 9/30 마감). 하드코딩 25500 제거.
    3. 페그정합 게이트: 화폐게이트.sh를 확장해 4개 리포의 환율 상수를 스캔·불일치 시 exit 1 (결정형·토큰0).

    P2 — 체인 접속 계약

    1. 체인 기록 계약 정의: DEX 확정거래(스왑·대출·상환·기부)를 체인 TX로 앵커링하는 최소 스키마 확정(DEX|swap|user|from|to|amt|donation|note_hash). 개인정보 아닌 해시만.
    2. 연동.한선 실주소 교정: DEX주소를 9402로, 게이트웨이 라우팅 테이블에 dex·연동 등록.
    3. 비동기 앵커링: DEX는 로컬 확정 후 큐에 넣고 체인 기록은 배치(E1 단일 blocking loop를 우회 — 동기 호출 금지).
    4. 기부 공개 장부: donation_ledger를 체인 앵커 해시와 대조 가능한 공개 조회 API로.

    P3 — 효율·내구성

    1. 코인서버 블록해시목록 상한+로테이션(E2), WAL 스냅샷 압축(E3).
    2. DEX 상태 복원 로직(E5) — TSV 재생으로 잔액 재구성. 재기동 후 잔고 일치를 수용기준으로.
    3. crowny-pay 가맹점 Map 인덱스(E4), pay 서버 재활성화 여부 결정(paygate 통합 vs 부활).
    4. 지갑 단일화 로드맵: wallet(9410)/뱅크(9733)/DEX 잔고의 소유 관계 확정.
    5. 오더북 체결엔진 이식: 신 DEX는 주문 등록만 되고 체결이 없다. 백업본(crowny-dex-backup-20260728)의 가격-시간 우선순위 매칭엔진을 신 토크노믹스(가치노트·쿨다운·기부)에 맞춰 이식.
    6. bind 실패 = 즉시 종료 가드를 체인·DEX·스테이킹 전 서버에 확인(06-23 CPU 100% 스핀 재발 방지).
    7. 스테이킹(9603)의 잔고 검증이 9729 curl 동기 호출 — E1·E7과 같은 경로, 앵커링 큐로 통합 대상.

    5-1. 집행 결과 (2026-07-29 실측)

    완료 — P0 라이브러리 (한선씨 신규 2본, 셀프테스트 14/14 PASS)

    • libs/체인인증.한선(84줄) — SHA256 내장 서명검증. 4상 반환. 실측: 키미설정→옴(0) / 서명불일치→타(-1) / 시각만료600초→타 / 헤더누락→타 / 올바른서명→티(1)
    • libs/셸안전.한선(105줄) — 화이트리스트. 실측: api/status→티 / `x/id →타 / ../etc/passwd→타 / abc;rm -rf /`→타
    • libs/보안셀프테스트.한선(67줄) — 검증 엔트리. 컴파일 14,602 큐브
    • 재사용: 체인공통.한선(CORS응답·헤더값), 문자열.한선(공백제거). SHA256은 VM 내장

    완료 — P0 배선 + 라이브 실측 (코인체인 9729)

    백업 4본 .bak-보안배선전-20260729 생성 확인(크라우니코인·뱅크서버·게이트웨이서버·연동). 코인서버 13:03:45 재기동 후 실측:

    검사실측 결과
    무인증 POST /api/mineHTTP 401 {"error":"unauthorized","reason":"invalid or missing X-Chain-Sign/X-Chain-Time"}
    읽기 GET /api/statusHTTP 200, 165바이트 JSON이 }까지 온전 — CORS응답 Content-Length 수정(E) 정상
    게이트웨이 인젝션 ` /proxy/coin/api/statustouch /tmp/injected_pwn | /tmp/injected_pwn` 미생성(차단). 단 응답 200은 9730 점유 서비스(crowny-project)가 낸 것 — 체인 게이트웨이 검증 아님
    • 키 미설정(옴) 정책 적용 확인: 인증키 파일이 아직 없는 상태에서 쓰기 API가 401로 거부됨 = 의도대로 "열어두지 않음".
    • 미검증 항목(정직 기록): 뱅크 /api/transfer·/api/credit/grant 인증 배선은 서버 미가동으로 라이브 검증 불가(9733은 market이 점유). 체인 게이트웨이 인젝션 차단도 동일 사유로 소스 배선만 완료, 라이브 미검증. 올바른 서명으로의 성공 경로도 키 미배치라 미검증.

    완료 — P1 페그 정합 게이트

    • crowny-pay/페그정합.한선(122줄, 판정코어) + 화폐게이트.sh 페그 서브커맨드(81줄, 얇은 래퍼)
    • 추출 실측: 뱅크 CRN대FNC=10·CRN대CRM=1000 / DEX CRN 25.5·FNC 2.55·CRM 0.0255 / market CRN25500·FNC2550·MOM25.5 / SSOT CRD원화1000·CRN원화25500
    • 검증 3종 실측: 현상태 exit 0(티) / 뱅크값 10→11 조작 exit 1(타) + crowny-chain|서버/뱅크서버.한선|CRN대FNC|10|11 / market 키 파손 exit 3(옴) + (미검출)
    • 실제 불일치 0건 — 4개 리포 값은 현재 SSOT와 정합
    • 개발 중 자체 결함 1건 실측 수리: bash 추출 정규식이 EXCHANGE_RATES 선언이 아닌 빈 지갑 오브젝트({CRN:0,FNC:0,MOM:0} 5곳)를 먼저 매칭 → 옴을 거짓 티로 통과시킬 뻔함. 선언 라인 단독 추출로 수리

    사고 1건 — 셀프테스트가 운영 인증키를 파괴 (발견·수리 완료)

    • libs/보안셀프테스트.한선이 운영 키 경로에 테스트키를 덮어쓰고, 끝에 체계("rm -f " + 인증_키경로)로 삭제했다. 배선 중 실제로 운영키가 지워지는 사고 발생(에이전트가 재생성해 복구).
    • 수리: 테스트 시작 전 운영키를 .운영대피로 mv → 종료 시 원복. 실측 재검증 14/14 PASS + 운영키 md5 동일 + 대피본 잔류 0.
    • 교훈: 셀프테스트가 운영 자원 경로를 공유하면 테스트 자체가 장애 원인이 된다. 파괴적 정리(rm) 앞에는 대피/원복이 짝으로 있어야 한다.

    신규 발견 (다음 작업 대상)

    • 포트 충돌: 체인공통.한선의 게이트웨이 9730·뱅크 9733이 crowny-project·crowny-market이 정당 점유한 포트. 재배정 필요(crowny-ports.sh free로 빈 포트 확보 후 set).
    • 한글 파일명 NFD: find . -name "*.한선"이 0건 반환(패턴 NFC vs 파일명 NFD). 진행 확인에 find -name 한글 패턴 사용 금지 — 셸 글로브나 경로찾기.sh 사용.

    5-2. ★중대 발견 — 진짜 뱅크는 crowny-bank:9400이다 (2026-07-30 실측)

    포트 재배정을 하려다 발견. 체인의 뱅크서버.한선은 살려서는 안 되는 중복 사산 코드다.

    항목체인 뱅크서버.한선crowny-bank (정본)
    상태미가동(9733은 market 점유)라이브 crownyc PID 53169, :9400
    언어한선씨한선씨 (src/ 13모듈)
    인증없음(이번에 배선했으나 미가동)이미 있음 — /api/wallet 무인증 → 401 {"error":"인증 필요. Authorization: Bearer <token>"}
    게이트웨이미등록gateway.yaml:625 등록 + web static 서빙
    토크노믹스환율 상수만DEX 백서와 1:1 — CRN 234억/FNC 777억/CRM 777억, 1CRN=10FNC=1000CRM, 상향 0%·하향 7%→재단 귀속, 회기 매년 9/30, 2038-09-30 면책
    엔진없음전환엔진.한선(상·하향 스왑+7% 수수료), 원장.한선, 계좌.한선, 귀속.한선, 갱신.한선, 리딤.한선
    체인 API—/api/chain/status·/api/chain/block·/api/chain/account 보유
    • crowny-chain/연동.한선의 뱅크주소=9400은 오류가 아니라 정답이었다 — 진짜 뱅크를 가리키고 있었다.
    • DEX는 crowny-bank를 전혀 참조하지 않는다(DEX서버.한선에 9400·bank·뱅크 문자열 0건). DEX가 자체 인메모리 잔고를 따로 들고 있는 이유가 여기 있다.
    • 결론: 체인 뱅크서버를 새 포트로 기동하지 마라. 두 번째 경쟁 원장이 생겨 잔고가 갈라진다. 체인 뱅크서버는 폐기 대상으로 표시하고, DEX의 연동 대상은 crowny-bank:9400으로 확정한다.
    • DEX의 하향 스왑 7% 기부와 뱅크의 하향 7% 재단 귀속은 같은 규칙의 중복 구현이다. 어느 쪽이 SSOT인지 확정해야 한다(권고: 잔고·전환은 뱅크가 SSOT, DEX는 호출자).

    포트 재배정 판단 (변경)

    • 뱅크: 재배정 불필요(폐기 대상). 게이트웨이: 필요성 재검토 — crowny-gateway가 이미 리버스 프록시 정본이므로 체인 자체 게이트웨이(9730)도 중복 가능성 높음.
    • 참고: 레지스트리가 "빈 포트"로 보고한 9743은 실제로는 crownyc가 점유 중(미등록 스쿼터). free 결과를 믿지 말고 lsof로 재확인할 것.

    5-3. 집행 — 뱅크 SSOT 확정 + 체인 정리 + DEX 어댑터 (2026-07-30, 오너 승인 "권고대로")

    결정 (확정)

    잔고·전환·송금 SSOT = crowny-bank(:9400). DEX는 호출자. DEX 고유(가치노트·쿨다운·RWA대출·희년·주문)는 DEX가 유지.

    완료 — 체인 중복 서버 폐기 처리

  • 서버/뱅크서버.한선 헤더에 폐기 선언(정본=crowny-bank:9400, 기동 시 경쟁 원장 발생, 9733은 market 정당 점유). 컴파일 통과 유지.
  • 서버/게이트웨이서버.한선 폐기 검토 표시(정본=crowny-gateway).
  • 시작.sh 재작성 — 코인체인(9729) 단독 기동으로 축소. 근거: 9729 외 6포트가 전부 타 서비스 정당 소유(9730 project·9731 stock·9732 patent·9733 market·9734 artist·9740 network)로 bind 실패 확정. 2026-06-23 bind 실패 busy-spin CPU 100% 장애 재발 차단.
  • 안전장치 3종 추가: ①9729 이미 리슨 시 중복 기동 없이 종료 ②컴파일 산출물 비면 기동 중단(exit 1) ③인증키 없으면 경고 + 생성법 출력.
  • 포트별 정당 소유자 표를 주석으로 보존(되살릴 때 판단 근거).

    • 완료 — DEX↔뱅크 어댑터 (한선씨 신규, DEX서버.한선 무수정)

  • crowny-dex/libs/뱅크연동.한선(~90줄) + libs/뱅크연동셀프테스트.한선(~40줄) + 뱅크연동-인수인계.md
  • 컴파일 3,656 / 3,759 큐브 exit 0. 셀프테스트 4/4 PASS (라이브 :9400 상대 실측):
  • 헬스 → 티 {"status":"T","server":"CrownyBank/4.0-account",...}
  • 무효토큰 잔고조회 → 타 / 토큰없음 → 옴 / 죽은포트 → 옴(응답길이 0, 폴백값 미생성 확인)
  • 확인된 실제 계약(근거=crowny-bank 소스): 인증 Authorization: Bearer <token>(_토큰검증() 657행), GET /api/wallet/balance → {"crn","fnc","crm"}, POST /api/convert/upgrade|downgrade
  • ★문서-코드 불일치: API.md는 바디를 {from,amount}로 적었으나 실제 코드는 {"direction","amount"}를 읽는다(전환엔진.한선 8~67행). 어댑터는 소스 기준으로 작성. API.md 정정 필요.
  • 원칙 준수: 7% 하향 수수료를 어댑터에서 재계산하지 않고 뱅크 응답을 그대로 전달. 연결실패 시 로컬 폴백 잔고 생성 안 함(허위배선 차단).

    • ★신규 P1 보안 발견 — 뱅크 무효 토큰이 401이 아니라 404로 샌다

    • 실측: GET /api/wallet/balance 헤더 없음 → 401 {"error":"인증 필요..."} (정상)
    • 그런데 무효 토큰을 넣으면 → 404 {"error":"지갑 없음"} — 즉 토큰 검증을 통과해 세션 매핑 단계까지 진입한다.
    • 위험: 인증 경계가 토큰 유효성으로 끊기지 않고 "지갑 존재 여부"로 끊긴다. 유효 토큰 형식만 맞추면 계정 열거(enumeration) 가 가능한 형태이며, 다른 라우트에서는 더 깊은 단계까지 진입할 소지가 있다.
    • 조치: 어댑터는 인증 필요와 지갑 없음을 둘 다 타로 판정해 방어(완료). 단 근본 수리는 뱅크 쪽 _토큰검증() 감사 필요 — 미착수(crowny-bank는 이번에 읽기 전용으로만 다뤘다).

    미검증 (정직 분리 — 통과로 적지 않는다)

    • 뱅크전환() 정상 성공 경로(유효 토큰 상·하향 전환) — 실계정 오염 방지로 쓰기 미실행
    • 뱅크 토큰 실제 발급·배치 — 미실행(인수인계 문서에 절차만)
    • /api/wallet/deposit·/withdraw·/api/transfer 어댑터 — 범위 밖 미구현
    • DEX서버.한선 실배선 미실행 — 교체 지점만 행번호로 인계: 잔고엔진 365·375행, 스왑 7% 계산 495~538행

    5-4. 집행 — 뱅크 인증 가드 수리 + 기부원장 역할분리 (2026-07-30, 오너 승인 "권고대로")

    ★P1 수리 완료 — 뱅크 인증 가드가 VM 함정으로 우회되던 문제

    원인 규명(앞선 "계정 열거 가능" 표현은 과장이었음 — 정정):
    • _토큰검증()(657행)은 세션맵 조회 후 없으면 빈 문자열 반환. 로직 자체는 정상.
    • 인증 관문은 크라우니뱅크.한선 1025행(전체 인증 라우트 중앙 게이트)과 875행. 둘 다 만약 (uid == "").
    • 이것이 문서화된 VM 함정에 정면으로 걸린다: 내부에 다른 함수 호출이 있는 함수가 반환한 빈 문자열은 호출부 == "" 비교에 매치되지 않는다.
    • 경로별 차이가 관측 결과를 설명한다: 헤더 없음 → 글자수(인증헤더) < 8 조기 분기의 리터럴 반환 "" → 비교 성공 → 401. 무효 토큰 → _DB읽기(_세션맵,토큰)의 함수 반환 빈값 → 비교 실패 → 게이트 통과 → 지갑조회 404.
    • 데이터 유출은 없었다(빈 uid는 실제 지갑에 매칭 안 됨). 그러나 인증 경계가 의도한 지점이 아닌 "지갑 존재 여부"에서 우연히 막히던 상태.
    수리: 875·1025행을 글자수(uid) == 0으로 교체. 백업 src/크라우니뱅크.한선.bak-토큰가드수리전-20260730 + /tmp/crowny-bank.toau.bak-토큰가드수리전. 컴파일 23,055 토큰 / 102,685 큐브, 경고 0.

    라이브 실측 (수리 전 → 후):

    요청수리 전수리 후
    /api/wallet/balance 헤더 없음401401 (유지)
    /api/wallet/balance 무효 토큰404 {"error":"지갑 없음"}401 {"error":"인증 필요..."}
    /api/account/info 무효 토큰(동일 누수 계열)401
    /api/account/charset (공개)200200 (유지)
    /api/health200200
    - WAL 239건 리플레이 정상, 제네시스 14코드 복원 확인(데이터 손실 0).

    사고 1건 — 중복 기동 CPU 스핀 재현(즉시 수습). 뱅크 감독자는 crowny-gateway/scripts/재기동.psv:17(9400|crowny-bank|/|crownyc run /tmp/crowny-bank.toau). 교체 후 수동 기동했는데 감독자와 레이스가 나 2 인스턴스가 됐고, bind 실패한 쪽이 CPU 80.5%로 스핀했다(2026-06-23 장애와 동일 기전). kill -9로 정리, 리슨 1개·헬스 200 확인. → 교훈: 감독 대상 서비스는 수동 기동하지 말고 감독자에게 맡겨라. 재기동.psv에 등재된 서비스는 kill만 하고 대기(감독 주기 확인 후). 이 항목을 운영 규칙으로 승격 권고.

    기부원장 — 결정: 역할 분리 (제 초기 권고 철회)

    초기 권고("뱅크 재단 귀속을 정본, DEX 원장은 미러로 격하")는 감사성을 잃는 오판이었다. 실측 근거:

    뱅크 (전환엔진.한선 75~101행)DEX (donation_ledger.tsv)
    기록 형태_재단CRN += 수수료 — 재단 지갑 잔고 누적만건별 명세 행
    건별 추적불가가능 — D-1 / AGENT-99 / CRN->FNC / 17.85 / ts
    현재 규모상태값(재단지갑 ID=FOUNDATION, 크라우니뱅크.한선 105행)2,916행 / 합계 78,075.90
    백서 "기부 공개 장부" 충족✗○
    • 중복이 아니라 보완이다. 뱅크=돈의 상태 정본, DEX=거래 명세 정본.
    • 그 2,916행은 전부 AGENT- 계정(6,561 러너 생성분), 실사용자 거래 0건. 원장을 격하하면 살아 있는 생성 경로를 끊는다.
    • 확정: 잔고·전환 SSOT=뱅크 / 기부 명세 원장 정본=DEX / 뱅크 재단 잔고는 대조 검증값.
    • 후속: 두 기록이 어긋나는 것을 잡는 기부 대조 게이트(crowny-dex/기부대조.한선 + .sh, 페그 게이트와 동일 4상·exit 규약) 구축 진행 중. 재단 잔고는 /api/admin/stats가 401이라 WAL(crowny-bank/data/wal.log, FOUNDATION 13건) 결정형 추출으로 1차 구현.

    5-5. 기부 대조 게이트 — 구축 완료, 첫 대조에서 실제 어긋남 검출 (2026-07-30)

    산출: crowny-dex/기부대조.한선(102줄 판정코어) + 기부대조.sh(81줄 래퍼). 컴파일 396토큰/1,828큐브. 페그 게이트와 동일 4상·exit 규약(티0/타1/옴3/음4).

    재단 귀속액 추출 근거(뱅크 자체 로직과 1:1): WAL 라인 형식 W|FOUNDATION|{"wallet_id":"FOUNDATION","user_type":"FOUNDATION","crn_balance":"0","fnc_balance":"0",...} 크라우니뱅크.한선 481행이 리플레이 시 _재단CRN = 숫자변환(JSON값(지갑값,"crn_balance"))로 마지막 W|FOUNDATION 스냅샷을 재단액으로 삼는다 → 래퍼도 grep -E '^W\|FOUNDATION\|' | tail -1로 동일 추출.

    ★검출 결과 — 두 정본이 실제로 어긋나 있다 (본인 재현 확인)

    [기부대조] 원장 CRN->FNC 합계(×100)=7810754 / FNC->CRM=미검출
[기부대조] WAL 재단귀속 crn(×100)=0 / fnc(×100)=0
CRN->FNC(원장합계 대 재단CRN누적)|7810754|0|7810754
기부대조판정=-1 (타)     실제 EXIT=1
    • DEX 원장: 2,918행 / 합계 78,102.67 (계속 증가 중 — 6,561 러너 가동)
    • 뱅크 재단 지갑: WAL 13건 전부 crn_balance:"0" fnc_balance:"0" → 재단 귀속 0
    • 해석: DEX가 하향 스왑 7%를 자체 원장에만 쌓고 뱅크 전환엔진을 한 번도 호출하지 않았다. 즉 "기부는 기록됐지만 재단에 실제로 귀속된 돈은 없다." 어댑터 배선(§5-3)이 반드시 완료돼야 해소된다.
    • 이 게이트의 존재 이유가 첫 실행에서 증명됐다. 티가 나오도록 맞추지 않고 타를 그대로 보고한다.

    검증 4종 실측

    케이스실측
    현상태EXIT=1(타), 차액 7,810,754(×100)
    티 통제(원장합계 0 사본)EXIT=0
    음성(금액 조작 사본)EXIT=1, CRN->FNC(...)|103372976|0|103372976
    옴(WAL FOUNDATION 제거)EXIT=3 (WAL 재단귀속 미검출)
    음(원장 경로 없음)EXIT=4 음: DEX 원장 파일 없음·손상

    미확정 (정직 분리)

    • 단위·개념 동치 미확정: 원장 amount(하향 스왑 기부액)와 뱅크 crn_balance(수수료 누적)가 완전 동치인지 확정 안 됨. 환산계수가 정해지면 _대조(...) 호출부만 교체하도록 주석 처리됨. 다만 뱅크 측이 0이라는 사실은 단위와 무관하게 유효하다.
    • FNC->CRM 방향은 원장 0건이라 코드만 있고 대조 미수행.
    • WAL 경로 동일성(crowny-bank/data/wal.log vs 소스 설정 crowny-data/bank/wal.log)은 라인 수 일치로 판단, inode 미비교.
    • 게이트 실행 시 $?를 파이프라인 뒤에서 읽으면 tail의 코드가 잡힌다 — exit 판정은 리다이렉트 후 읽어라(본인 1차 측정 오류, 재측정으로 EXIT=1 확정).

    5-6. 배선 시도 → ★뱅크↔DEX 연동이 경로 불일치로 처음부터 死 (2026-07-30)

    오너 결정 "뱅크가 잔고 주인"에 따라 배선하려다, 뱅크의 DEX 연동 자체가 호출 경로 불일치로 작동한 적이 없다는 것을 발견.

    실측 (본인 재현)

    GET  http://127.0.0.1:9402/api/dex/prices  → 404 "not found"
POST http://127.0.0.1:9402/api/dex/swap    → 404 "not found"
    • 뱅크 연동.한선은 _내부GET(9402,"/api/dex/prices")·_내부POST(9402,"/api/dex/swap")를 부른다(66·116·282·611행). DEX에 그 라우트가 없다.
    • DEX 실제 라우트: /api/swap·/api/markets·/api/orderbook·/api/loan·/api/repay·/api/agents/*… (/api/dex/* 아님). 스키마도 다름 — 뱅크는 {pair,direction,amount,user}를 보내지만 DEX /api/swap은 {from,to,userId,amount,value_note,토큰}.
    • 게이트웨이 헬스는 무관: gateway.yaml:697 healthCheck=http://127.0.0.1:9402/health(§1-3c의 /api/dex/prices는 부정확). DEX 헬스는 정상. /api/markets·/api/stats는 200.

    이번 배선의 실제 상태

    • 연동.한선 API_DEX스왑에 재단 7% 귀속 로직은 코드로 추가 완료(전환엔진 패턴 그대로, donation 파싱→출금자산 기준 _재단* 누적→_재단지갑생성(), 감사기록). 백업 .bak-재단귀속배선전-20260730. 컴파일 103,420큐브 경고0. 감독자 경유 재기동(PID 80554), 인스턴스 1개·헬스 200 확인.
    • 그러나 앞단(뱅크→DEX 경로)이 死라 이 로직은 실행될 일이 없다 — 방어적으로 짜여(필드 부재 시 스킵) 안전하지만 미검증.
    • DEX donation 단위도 미확정: DEX 스왑실행() 779~862행에서 기부액 = 가치입력 × 수수료율이며 가치입력 = 금액 × 토큰율 → CRD 환산가치로 읽힘(원자산 수량 아님). 경로가 살아나야 실증 가능.

    정리 — 뱅크↔DEX 통합의 진짜 갭 (3중)

    1. 경로/스키마 불일치: 뱅크 /api/dex/* 호출 ↔ DEX /api/swap. 뱅크 연동.한선을 DEX 실제 API에 맞춰야 함. + DEX /api/swap은 가치노트·토큰 필수 → 뱅크가 사용자 대신 어떻게 전달할지 설계 필요.
    2. 러너 우회: 6,561 러너는 DEX /api/swap 직접 호출(뱅크 계정 없음) → donation_ledger 2,918행. 경로 1을 고쳐도 러너는 여전히 우회. 러너를 뱅크 경유로 돌릴지 = 6,561 러너 세션 결정.
    3. 소급 불가: 과거 러너 기부는 재단에 소급 안 됨(대조 게이트 계속 타). 컷오버 기준일 정책 필요.
    기부 대조 게이트 재실행: 여전히 EXIT=1(타) — 위 3중 갭이 안 풀렸으니 정상. 게이트는 이 미해결을 계속 정직하게 드러낸다.

    5-7. 재단 지급 설계 확정 — 방식 A(집계 이체), 오너 결정 반영 (2026-07-30)

    오너 결정: 러너 기부(2,918행, AGENT-*)는 개발비로 기록만 — 재단 소급·컷오버 불필요. 실사용자 스왑만 재단 대조.

    미확인 2건 해소 (코드 실측)

    • /api/transfer(원장.한선:120): 목적지 제약 없음 — to가 존재 지갑이면 FOUNDATION으로 이체 가능. WAL에 FOUNDATION 지갑 존재. → 방식 A 재단 지급 경로 성립.
    • /api/account/register(계좌.한선:140): 제네시스 없이 일반계좌+토큰 발급(216행 _세션쓰기(토큰,계좌번호), 반환 {token,customer_id,account_number}). → DEX 서비스 계정을 제네시스 14슬롯 소모 없이 발급 가능. 재발급은 API_계좌로그인.

    6,561 러너 뱅크 직접 = 금지 (3대 이유)

    ① 계정 폭발(제네시스 14 한정, 일반계좌 6,561 발급은 관리·세션맵 폭증) ② 성능(뱅크 단일 blocking 루프에 tick 부하 집중=병목) ③ 실원장 오염(시뮬 거래가 실통화 유통량에 영향). → 러너는 DEX 시뮬 잔고 유지, 기록만.

    확정 구조

    러너(6,561)  → DEX /api/swap 직접 → DEX 시뮬 잔고 + donation_ledger
                                      └ AGENT-* = 개발비 (재단 대조 제외)
실사용자     → 뱅크 /api/dex/swap → [뱅크: 잔고 SSOT] → DEX 계산 → 7%→FOUNDATION (방식 B, 트래픽 시)
재단 창구    ← DEX-재단수금 계정 → transfer(to:FOUNDATION)  (방식 A 배치, 지금 가능)

    착수 순서

    1. 대조 게이트에 AGENT- 개발비 필터 — 재단 대조는 실사용자 기부만. 러너 기록은 개발비 장부로 별도 집계·보존.
    2. DEX 서비스 계정 발급(/api/account/register) → 토큰 crowny-data/dex/뱅크토큰.txt 배치.
    3. 배치 이체 도구(집계→transfer to:FOUNDATION) — ★실자금 이동이므로 dry-run까지만, 실이체는 오너 확인 후.
    4. (트래픽 발생 시) 방식 B: 뱅크 연동.한선 경로/스키마 교정(/api/dex/prices→/api/markets, /api/dex/swap→/api/swap, {pair,direction}→{from,to,userId,value_note,토큰}).

    5-8. 방식 A 배선 완료 + 게이트가 테스트 오염 검출 (2026-07-30)

    완료

    • 개발비 분리: 기부대조.sh가 AGENT-*를 개발비로 걷어냄 — 2,916건 / 7,808,076(×100), 재단 대조 제외·보고 전용.
    • DEX 서비스 계정 발급: /api/account/register HTTP 200, 토큰 유효성 실측 확인, crowny-data/dex/에 chmod 600 저장(민감값 미기록). 재실행 멱등(기존 토큰 유효 시 스킵).
    • 배치 이체 dry-run: 재단이체.한선+.sh, --실행 없이 계획만 출력. 실이체 미실행.
    • 신규 한선씨 코어 2개(재단수금계정판정·재단이체판정), 컴파일 통과, learn 2건.

    ★게이트 검출 — "실사용자" 2건이 실은 테스트 오염

    개발비를 걷어내도 게이트는 여전히 타(exit 1). 이유가 유의미하다: 
    실사용자 CRN->FNC 합계(×100)=2678   (2건)
  D-1  alice            CRN->FNC  17.85
  D-1  qa_1785398024    CRN->FNC  8.925
WAL FOUNDATION crn_balance = 0
    • 두 건 다 명백한 테스트 데이터(alice=예시 계정, qa_=QA 타임스탬프 계정, id D-1 중복). 실사용자 거래가 아니다.
    • 이는 §5-2에서 P1로 지적한 _seed/_settime QA 백도어가 실제 원장을 오염시킨 증거다. QA가 만든 기부가 append-only 원장에 실기록으로 남았다.
    • 게이트의 가치: "실사용자 기부가 재단에 안 들어갔다"가 아니라 "재단 대조 대상에 테스트가 섞여 있다"를 드러냈다. 이걸 못 걸렀으면 테스트 26.78 CRN이 실이체될 뻔했다(dry-run이 이체계획|crn|2678 출력).

    판단 필요 (오너)

    1. 테스트 2건(alice·qa_) 처리: (가)원장 정리 (나)게이트가 테스트계정도 제외 (다)그대로 실사용자 간주. 권고=(가)+백도어 차단 — QA 백도어(_seed/_settime)를 막지 않으면 재오염된다.
    2. 실이체(--실행) 시점: 실사용자 진짜 기부가 생긴 뒤. 지금은 이체 대상 0(테스트 제외 시).

    5-9. QA 백도어 차단 + 원장 정리 완료 (2026-07-31, 본인 실측)

    ★함정 — DEX 진짜 감독자는 재기동.psv가 아니라 LaunchAgent였다

    • 작업지시가 준 감독자(재기동.psv:19 → /tmp/dex.toau)는 실 라이브와 달랐다. 실제 supervisor = LaunchAgent ~/Library/LaunchAgents/org.crowny.dex.plist(KeepAlive), 실행 대상 = /Users/ef/crowny-dex/build.toau.
    • /tmp/dex.toau만 갱신하고 kill했더니 구 코드(백도어 무가드)로 재기동되는 것을 실측 → build.toau도 컴파일 교체해야 반영됨. 교훈: 재기동.psv와 LaunchAgent가 같은 서비스에 이중 등록될 수 있다 — kill 후 어느 바이너리로 살아나는지 실측 확인 필수.

    완료 (전후 실측)

    • 백도어 3개 env 가드(DEX서버.한선, QA플래그 부팅 캐시 + 진입부 인라인 403). 컴파일 55,810큐브. LaunchAgent 재기동 PID 단일, markets/stats 200, agents total 6,561 유지.
    | 라우트 | 전 | 후 | |---|---|---| | _seed(임의 잔액 주입) | 200 | 403 | | _settime | 200 | 403 | | _debugmod | 200 | 403 |
    • 제거가 아닌 가드 — DEX_QA=1이면 복원(테스트 편의 유지). DEX_QA=1 정상동작은 미검증(기본 차단만 실측).
    • 원장 정리: 2,918→2,916행. alice·qa_1785398024 제거, AGENT-* 2,916건 보존. mv 전후 행수 동일(레이스 유실 0). 백업 .bak-테스트오염정리전-20260731 + data/원장정리기록.txt.

    게이트: 타 → 옴 (버그 아님, 올바른 전환)

    • 정리 전 EXIT=1(타, 테스트 오염이 실제 감사 실패 유발) → 정리 후 EXIT=3(옴, 실사용자 데이터 0건).
    • 기대했던 티(0)가 아니라 옴(3)인 이유: 실사용자 기부가 아직 0건이라 게이트가 "일치"를 허위 단정하지 않고 "대조할 실데이터 없음"을 정직하게 옴으로 보고. 이게 설계 의도(옴과 티를 구분). 실사용자 거래가 생기고 방식 A 이체가 돌면 티로 간다.
    • 즉 현재 상태: 재단 대조에서 오염 제거됨, 실데이터 대기. P1 QA 백도어 잔여(§5-2)도 이로써 닫힘.

    5-10. 방식 B 설계 확정 — DEX 견적 분리로 순환·이중잔고 해소 (2026-07-31)

    문제

    DEX 스왑실행()(831행)은 잔액변경(유저)로 자체 잔고를 SSOT로 변경한다. 방식 B(뱅크가 잔고 주인)를 그대로 하면 뱅크·DEX가 잔고를 이중 변경한다.

    해법 — 견적/실행 분리

    DEX 스왑의 계산부(가치입력=금액×토큰율, 수수료율(하향 0.07), 기부액, 가치출력, 출력량=가치출력/토큰율)는 순수 함수다. 이를 떼어 /api/quote 견적 전용 라우트 신설: 잔고·인증·쿨다운·노트·기록 없이 {출력량, 기부액, 수수료율, 가치입력}만 반환.

    실사용자 → 뱅크 /api/dex/swap {pair,direction,amount,value_note}
   ├ 뱅크: 잔고 확인 (SSOT)
   ├ 뱅크 → DEX /api/quote {from,to,amount}  (계산만, 상태 무변경)
   ├ 뱅크: 잔고 차감/증가 (출력량)
   ├ 뱅크: 기부액 → FOUNDATION 재단 적립 (방식 B 실시간, 기존 배선 재활용)
   └ 뱅크: value_note를 거래기록에 저장 (백서 확정 규칙)
러너 → DEX /api/swap 기존대로 (자체 시뮬 잔고 + donation_ledger)
    • 순환 없음(뱅크→DEX 단방향, quote는 계산만 되돌림). 이중 잔고 없음(quote는 잔고 무관). 러너 경로 불변.
    • 뱅크 연동.한선 교정: /api/dex/swap→/api/quote(9402), pair/direction→from/to 변환. 잔고 반영·재단 적립 로직은 §5-3/5-6에서 이미 배선됨(필드명만 quote 응답에 맞춤).

    배선 범위·검증 한계

    • 수정: DEX서버.한선(quote 추가, 기존 영향 0), 뱅크 연동.한선(경로/스키마).
    • 검증: quote 단독 실측(하향 7% 계산 정확), 뱅크 컴파일·재기동, 무효토큰 401 유지.
    • 통합 실잔고 흐름(뱅크 계정→스왑→재단 실적립)은 테스트 계정·잔고 세팅이 필요 — 이번엔 미검증으로 남긴다(실계정 쓰기 회피). quote가 정확하면 나머지는 이미 배선된 잔고/재단 로직이 처리.

    5-11. 방식 B 배선 완료 (2026-07-31, 본인 실측)

    완료

    • DEX /api/quote 견적 라우트 신설(DEX서버.한선 2041행). 계산부를 공통 헬퍼 스왑견적계산()(749행, 토큰율/토큰랭크 뒤·스왑실행 앞=전방참조 안전)으로 추출해 스왑실행()과 공유(계산 중복 제거). 컴파일 58,485큐브, build.toau 교체·감독자 재기동·단일 인스턴스.
    • 뱅크 연동.한선 경로 교정: /api/dex/prices(3곳)→/api/markets, /api/dex/swap(404)→/api/quote, {pair,direction}→{from,to} 매핑, 응답 received→출력량·donation→기부액, value_note 422 게이트 + 거래기록 부기. 컴파일 104,279큐브.

    quote 실측 (본인 재현, 페그 정합 확인)

    입력출력
    CRN→FNC 100 (하향)수수료율:0.07, 기부액:178.5, 출력량:930, 가치입력:2550 — 178.5 = 100×25.5×0.07 ✓ CLAUDE.md 일치
    CRM→CRN 100 (상향)수수료율:0, 기부액:0, 출력량:0.1 ✓
    CRN→CRN422 동일토큰
    XXX→CRN422 대상 아님
    - 스왑실행과 동일 헬퍼라 러너 경로와 값 일치 보장. 백도어 _seed 여전히 403, 뱅크 health 200·단일 인스턴스, 게이트 옴(실데이터 0) 유지.

    미검증 (정직)

    • 뱅크 실계정 통합 흐름(잔고 차감→입금→재단 실적립)은 테스트 계정 세팅 회피로 미검증. quote 정확성 + 경로 교정 + 기동까지가 이번 범위. 실사용자 트래픽 발생 시 이 경로가 자동 발동.
    • 뱅크 재기동을 에이전트가 수동 기동(전담 launchd 미발견) — 현재 단일 인스턴스지만, 재기동.psv:17 감독자가 별도로 또 띄우면 중복 위험. 다음 세션에서 뱅크 감독 경로 일원화 확인 권고.

    6. 최종 상태 요약 (2026-07-31)

    이 트랙("블록체인/지갑/토큰 확인 + 효율·보안 + DEX 접속 준비") 도달점:

    자산 지도 — 잔고 SSOT=crowny-bank(:9400 라이브), 코인체인(:9729), 스테이킹(:9603), DEX(:9402), 페그 SSOT=crowny-pay/페그.한선. 체인 중복 뱅크·게이트웨이=폐기 표시. crowny-pay(:9866)=미가동.

    보안(완료·실측) — 코인 무인증 발행 401 / 뱅크 인증가드 VM함정 수리 401 / DEX QA백도어 3종 403 / 셸인젝션 화이트리스트 라이브러리. 셸안전·체인인증 셀프테스트 14/14.

    정합(게이트 2종, 음성테스트 통과) — 페그 정합(불일치 0) / 기부 대조(테스트 오염 검출→정리). 둘 다 결정형·토큰0.

    DEX 접속(배선 완료, 통합 실잔고만 미검증) — 견적/실행 분리로 순환·이중잔고 해소. 재단 지급 방식 A(집계 이체 dry-run) + 방식 B(실시간 경로) 둘 다 배선. 러너=DEX 시뮬(개발비), 실사용자=뱅크 경유.

    남은 것(트래픽 의존) — 방식 A 실이체·방식 B 통합 실잔고는 실사용자 거래 발생 후. 뱅크 감독 경로 일원화. 테스트 계정 E2E.

    사고·교훈 기록 — 셀프테스트 운영키 파괴, 뱅크 중복기동 CPU스핀, DEX 감독자 이중등록(재기동.psv vs LaunchAgent), 게이트 exit 파이프라인 오독. 전부 §5-x에 재발방지와 함께.

    5-12. 벡터형 동적 정족수 + 10기 노드 테스트 (2026-08-01)

    오너 방향: 화폐 생태계 정족수는 ERP 전결(고정 테이블)과 달리 규모·거래량에 따라 벡터형 유동. 과거 구현 없음(탐색 확인) — 신규 구축.

    코어 crowny-chain/체인/정족수.한선 (셀프테스트 15/15)

    • 동적기준 B=거래 중앙값, ρ=금액/B, Q=clamp(1,N,round(N×S(ρ))), S(ρ)=ρ²/(ρ²+k).
    • 소액 하한(오너 확정): ρ<0.5 → Q=1 절대고정(N 무관). "최소 노드만 동의=즉시 실행+전파". 실측 ρ0.3에서 N=10·100·1000 모두 Q=1.
    • 오버플로 수리(에이전트 잔여 P0): 1000×ρ² 곱셈이 VM 정수범위(ρ>11.8) 초과 → 분자·분모 동시축소로 ρ<375 안전 + ρ≥50 조기반환. 실측 ρ=100·1000에서 Q=N 정상.
    • 곡률 k·소액임계는 런타임 조정 가능 상수.

    노드 서버 + 10기 하네스 (재현 실측)

    • 정족수노드.한선(473줄, 8207큐브) + 10기하네스.sh(임시포트 9470~9479, 라이브 9400·9402·9603·9729 무침범 확인, 종료 후 잔존 0).
    시나리오실측
    1 정족수 스케일소액→Q1·보통→Q5·고액→Q10·초고액→Q10 = 공식 일치 ✓
    2 소액 즉시확정+전파Q=1 자기표만으로 즉시 티, ~5s 내 10/10 전파, 홉수 1 ✓
    3 고액 미확정즉시 티 안 됨 확인. 단 옴 대기 정확 포착은 부분적(REJECT 노드 섞여 타로 감 — 순수동의+중간시점 옴 시나리오 미완)
    4 동적성(벡터형)같은 금액1000: B=1000→Q5, B=20000→Q1 = 거래량↑→Q↓ ✓
    5 거부 정족수거부6>한계5 → 타 확정 ✓

    ★VM 함정 신규 2건 (CrownyDoc 기록)

    1. 싱글스레드 노드끼리 동기 curl 전파 = 순환 데드락: 각 노드가 blocking accept-loop인데 서로 동기 broadcast하면 서로 응답 대기로 accept 불가 → propose 20s+ 무응답. 해법 = (curl … &) </dev/null fire-and-forget. (기존 "데몬 서브셸+stdin분리" 함정이 노드간 RPC에도 필수임을 확인)
    2. 한글 URL 경로 = curl 자동 percent-encoding으로 라우팅 실패: HTTP 경로는 ASCII로, 내부 함수/JSON 필드명만 한글 유지.

    보안성능 정량화 관점 도달점

    • 처음 질문("블록체인 보안성능 정량 확인")에 대해: 금액별 합의 강도가 공식대로 작동함을 10노드에서 숫자로 실증. 소액=약한 합의(빠름)·고액=강한 합의(전 노드)의 트레이드오프가 벡터형으로 연속 조정됨을 확인.
    • 미완: (a)옴 대기 상태의 정확한 실증(순수동의 노드+중간시점), (b)부하/DoS 지표(처리량·p99·느린노드 영향)는 이 하네스에 얹을 수 있으나 미실행, (c)N>10에서 /투표회신 전체동보 O(N²) 트래픽.

    부록. 초기 수용 기준 (측정 가능)

    • 무인증 curl -X POST .../api/mine → 401 (현재 성공)
    • /proxy/x/\id\`` 형태 인젝션 페이로드가 셸에서 실행되지 않음
    • 4개 리포 환율 상수 스캔 게이트 통과(불일치 0)
    • 페그.한선 CRN 값 1곳 수정 → chain·dex·market 응답이 동시에 변함
    • DEX 스왑 1건 → 체인 TX 앵커 조회 가능, donation 합계 일치
    • DEX 재기동 후 잔고·대출·락 상태 복원 일치
    • 체인 블록 10만 초과 시뮬에서 배열 상한 미충돌·조회 지연 선형 아님

    관련 파일

    • 체인: /Users/ef/crowny-chain/ (크라우니코인.한선·뱅크서버.한선·게이트웨이서버.한선·연동.한선)
    • 페그 SSOT: /Users/ef/crowny-pay/페그.한선 · 린트 화폐게이트.sh
    • 지갑: /Users/ef/crowny-wallet/지갑서버.한선(9410), /Users/ef/crowny-paygate/(9954)
    • DEX: /Users/ef/crowny-dex/DEX서버.한선(9402), web/index.html
    • 핸드오프: /Users/ef/Downloads/crowny-dex-handoff/
    • 선행문서: 2026-07-28-crowny-dex-재구축.md, 2026-07-29-요청-crowny-dex-2단계.md

    잔여 이슈

    • crowny-chain 9730~9740이 node 래퍼로 운영 중인 경위 미확인 — 순한선씨 복귀 여부 결정 필요(헌법상 한선씨 우선)
    • 합의 알고리즘 부재는 이번 범위 밖(중앙 coinbase 전제 유지 여부 = 사장님 결정)
    • crowny-pay 부활 vs paygate 통합 = 오너 결정 필요
    ← 이전크라우니 오피스 → 크라우니클라우드(9611) 선택적 미러 (P2-⑩)2026-07-29-크라우니오피스-클라우드미러-P2-10다음 →DEX(:9402) 크라우니 통합인증 IdP 연동2026-07-30-DEX-IdP연동

    관련 문서

    Phase 2 연동 스펙 — Tradovate · NinjaTrader · TradingView 챌린지 룰 설계 (온체인 고정) 포네 결제 모듈 스펙 교육 커리큘럼 초안 crowny-sweep — Crowny 데이터 관리 도구2026-04-14
    1 / 1