• ERC-3643 / ONCHAINID의 identity와 token transfer enforcement는 외부 발행자 시스템의 책임이다.
• Corner Store는 외부 판정을 임의로 완화하거나 우회하지 않는다.
• Corner Store의 DEX-level compliance 보장은 ExecutionRouter를 통한 실행 경로에 한정한다. Router 밖에서 발생하는 ERC-3643 직접 전송, 직접 venue 호출, wrapper/vault/custodian을 통한 경제적 소유권 이전은 별도 제한, token-level enforcement 위임 또는 명시적 out-of-scope 처리가 필요하다.
• tools/deploy-v3는 vendored Uniswap v3 인프라이며 제품 compliance 보장을 제공하지 않는다.

세부 제품 경계는 docs/architecture/를 기준으로 한다.

지원되는 enforcement 경로:

ExecutionRouter
  → ComplianceEngine.evaluate()
  → Adapter
  → Venue/Pool/RFQ
  → ComplianceEngine.commit()

이 경로에서는 Router가 최신 Manifest와 applicable Recipe를 평가하고, 허용된 venue/adapter에만 실행을 위임하며, 성공 후 stateful compliance commit()을 호출한다.

지원 경로 밖에서는 Corner Store의 4-Layer compliance가 자동으로 실행되지 않는다. 특히 다음 경로는 production-ready 보장으로 간주하지 않는다.

• ERC-3643 token의 직접 transfer / transferFrom
• 사용자가 AMM pool 또는 외부 venue를 직접 호출하는 swap
• Router를 거치지 않는 RFQ 또는 Order Book settlement
• wrapper, vault, custodian 또는 omnibus account를 통한 경제적 소유권 이전
• offchain ledger에서의 beneficial ownership 이전

이런 경로가 열려 있으면 다음 Corner Store 검사가 생략될 수 있다.

• investor qualification Recipe
• amount cap과 offering/fund cap
• venue allowlist와 operator pause
• nonce/replay control
• ComplianceEngine.commit() 기반 surveillance/stateful Element update
• future lockup, affiliate, jurisdiction-specific rule

현재 skeleton의 기본 보안 모델은 제한된 범위 모델이다.

Corner Store는 router-mediated trade에 대해 DEX-level compliance를 강제한다. Router 밖의 RWA 이동 또는 경제적 노출 이전은 발행자 token-level enforcement에 위임되거나, 별도 controlled venue로 제한되거나, 제품 범위 밖으로 명시되어야 한다.

더 강한 production 보장이 필요하면 다음 중 하나를 별도 설계 결정으로 확정해야 한다.

• Router-exclusive model: end user가 직접 호출할 수 없는 controlled venue/settlement만 지원한다.
• Token-level enforcement model: 핵심 제한을 ERC-3643 compliance module이 Router 밖에서도 강제한다.
• Limited-scope model: Corner Store 보장을 router-mediated trade로 한정하고, non-router path는 문서와 제품 설명에서 out-of-scope로 명시한다.

• private key, RPC credential과 API token을 코드나 문서에 커밋하지 않는다.
• 로컬 비밀값은 환경 변수로 전달한다.
• 예시가 필요하면 실제 값이 없는 .env.example만 사용한다.
• deployment state에 민감한 계정 정보가 포함되지 않는지 확인한다.

• Element/Recipe 등록, Manifest proposal/approval, venue/operator와 emergency 상태 변경은 실행 권한과 분리한다.
• privileged action은 명시적인 owner/role 검사를 가져야 한다.
• production multisig와 governance는 외부 운영 결정 전 임의로 확정하지 않는다.

• 외부 주소, amount, deadline, nonce, manifest version과 venue context를 검증한다.
• Router 실행 요청의 caller는 context.initiator와 일치해야 한다.
• 명시적 UNREGULATED public path와 ACTIVE Manifest regulated path를 명시적으로 구분한다.
• ACTIVE Manifest의 invalid Recipe/reference, unsupported engine와 version mismatch는 fail-closed로 처리한다.
• Manifest와 UNREGULATED 분류가 모두 없는 자산은 UNKNOWN으로 거부한다.
• tokenIn과 tokenOut 양쪽을 분류하며, 양쪽 모두 명시적 UNREGULATED인 경우에만 regulated evaluation을 생략한다.
• 외부 callback과 pool identity는 계산된 주소 또는 registry로 검증한다.

• Router와 Adapter는 의도하지 않은 자산을 보관하지 않는 구조를 우선한다.
• Adapter와 settlement contract는 Router-only authorization 또는 동등한 호출자 제한을 가져야 한다.
• ERC-20 상호작용은 return value를 직접 가정하지 않고 SafeERC20 또는 동등한 safe wrapper를 사용한다.
• 실패한 실행은 nonce, fill accounting과 token balance를 원자적으로 되돌려야 한다.
• ERC-3643 transfer 실패를 성공으로 취급하거나 swallow하지 않는다.

• Uniswap-style callback은 등록되었거나 계산으로 검증한 pool에서만 수락한다. callback data가 payer/token을 포함하더라도 callback origin 검증 없이 신뢰하지 않는다.
• Pool/venue 등록은 compliance 보장의 일부다. 잘못된 venue 또는 악성 adapter가 등록되면 Router를 타더라도 settlement 결과가 왜곡될 수 있으므로 governance와 preflight 검증 대상이다.
• RFQ와 Order Book signature flow는 chain id, verifying contract, maker/taker, token pair, venue, policy/manifest version, nonce와 expiry를 binding해야 한다.
• Slippage, deadline과 amount cap은 서로 다른 축이다. amountIn, RWA 수량, quote notional과 investor/fund/offering cap의 기준을 혼동하지 않는다.
• External call, callback, token transfer가 포함된 경로는 access control, reentrancy, unchecked return, signature replay와 business-logic bypass를 함께 검토한다.

• RFQ settlement는 Router-only 진입점이어야 하며 direct adapter call로 compliance evaluation을 우회할 수 없어야 한다.
• signed quote는 chainId, verifyingContract, maker, taker, tokenIn, tokenOut, amountIn, amountOut, venue, nonce와 expiry에 바인딩한다.
• quote 생성 backend는 compliance 판단을 하지 않는다. fill 시점의 최신 ComplianceEngine.evaluate()가 최종 gate다.
• JavaScript service에서 온체인 정수는 unsafe number를 거부하고 bigint 또는 decimal string을 사용한다.
• 기본 nonce 생성은 같은 millisecond 내 quote 충돌을 만들지 않는 단조 증가 fallback을 가져야 한다.
• production dealer approval, signer custody, quote cancellation, partial fill과 inventory risk는 별도 threat model과 feature spec 전까지 활성화하지 않는다.

• 민감한 identity 자료와 법률 문서를 온체인 event나 일반 로그에 기록하지 않는다.
• audit event에는 필요한 식별자와 상태 변경만 남긴다.
• 성공한 regulated evaluation은 Manifest version과 applied Recipe set을 추적할 수 있어야 한다.
• revert 시 event가 사라지는 특성을 고려한 reject logging 정책은 별도 설계 결정으로 관리한다.

• 새 의존성은 명시적인 제품 요구가 있을 때만 추가한다.
• 공식 upstream, license, pinned version과 유지보수 상태를 확인한다.
• vendored tools/deploy-v3의 upstream provenance와 독립 경계를 유지한다.

현재 기본 검증:

scripts/check.sh

현재 구현은 권한, replay/expiry, callback spoof, balance invariant, direct adapter bypass, Manifest/Recipe evaluation과 RFQ quote mismatch path를 Foundry tests로 검증한다. production 전 최소한 다음을 계속 유지·확장한다.

• 권한 경계 test
• replay와 expiry test
• callback spoof test
• balance invariant
• direct venue bypass boundary test
• Manifest lifecycle과 cumulative multi-Recipe test
• UNKNOWN, explicit UNREGULATED와 regulated path 구분 test
• unregulated-regulated와 regulated-regulated pair의 양쪽 Manifest 적용 test
• 모든 Adapter/RFQ/OrderBook settlement의 direct caller rejection test
• ERC-20 safe transfer behavior와 callback-origin validation test
• signed order/decision 도입 시 chain/domain/nonce/expiry replay test

• ERC-3643 official documentation: permissioned tokens provide identity-backed transfer checks, but Corner Store-specific venue, Recipe, amount cap와 surveillance 보장을 자동으로 대체하지 않는다.
• OpenZeppelin SafeERC20: ERC-20 operation failure, false return과 no-return token 처리를 위해 safe wrapper를 사용한다.
• Uniswap v3 integration references: pool/callback origin 검증과 audited periphery pattern을 직접 venue adapter 설계의 기준으로 삼는다.
• OWASP Smart Contract Security Top 10 / SCSVS: access control, input validation, unchecked external calls, reentrancy, signature replay와 business-logic risk를 review checklist에 포함한다.