• 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는 외부 운영 결정 전 임의로 확정하지 않는다.
• 위험 중단(global/asset/venue pause, Manifest suspend)은 operator가 즉시 수행한다. unpause, Manifest resume와 semantic update는 owner 예약과 timelock을 거친다.
• 배포 후 TokenPolicyRegistry.owner()가 Factory인 구조에서는 governance가 Factory forwarding API를 사용한다. registry를 EOA가 직접 소유한다고 가정하지 않는다.

• 외부 주소, 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 검증 없이 신뢰하지 않는다. positive delta, pool의 canonical token0/token1과 요청 token 방향도 서로 일치해야 하며 다른 token을 transferFrom하도록 바꾼 callback은 거부한다.
• 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을 가져야 한다.
• maker(dealer) approval과 quote cancellation은 operator-curated allowlist와 nonce-scoped cancel로 활성화되었다. 위협 모델, actor/asset/trust boundary와 threat table은 docs/rfq-threat-model.md를 기준으로 한다.
• production RFQ는 ADR-009와 docs/product-specs/production-rfq-policy.md를 따른다. services/rfq-host는 demo backend와 분리된 host hardening boundary를 제공하지만 production activation에는 operator-owned HA store, signer custody, shared limiter, WORM audit, TLS/proxy와 live pricing/risk freshness integration이 필요하다.
• partial fill은 새 quote/adapter version과 별도 accounting/replay 검증 전까지 활성화하지 않는다.

• production-onboarding-plan은 unsigned calldata/Safe draft export 전용이다. private key, Safe owner signature, broadcast, token transfer 또는 ERC-20 approval을 생성하지 않는다.
• onboarding config는 exact schema를 사용하고 unknown field, signer-secret shaped key/value, raw contact PII와 중복 address/key를 fail-closed한다. Governance Safe, bounded required approvals, explicit operator executor, canonical recipe alias/key commitments, immutable Element default actions, bounded strengthen-only overrides, at least one active venue and at least one inventory requirement are mandatory for production v2. Active RFQ venues additionally require approved maker, signer delegate and approved-maker inventory evidence. Legal/TA evidence는 PII-free hash로만 참조한다.
• production-onboarding-verify는 ERC-3643 token→IdentityRegistry→Compliance wiring, Identity Registry dependencies, Element/Recipe registry state, recipe alias/key mapping, Element default actions/version hashes, exact Manifest hash/fields/bindings, compiled plan hash/rules, global/asset/venue pause gates, maker approval, governance Safe ownership of safe-owner targets, active signer delegate, operator executor authorization on TokenPolicyRegistry and RFQAdapter, and inventory balance/allowance minimum을 read-only로 확인한다. Unavailable RPC/read mismatch, safe-owner target owner mismatch, pending signer authorization, paused global/asset/venue state or missing inventory evidence is not production-ready.
• Inventory mutation은 maker/operator custody process의 책임이다. Corner Store tooling은 inventory-before-service-open 조건을 plan dependency와 verifier evidence로 표현할 뿐 transfer/approval/custody transaction을 합성하지 않는다.

• RFQ host audit events must hash principals, request bodies and idempotency keys; they must not store raw bearer tokens, raw idempotency keys, signer refs, raw request bodies, PII or stack traces. Metrics labels must stay bounded and must not contain principals or addresses.
• 민감한 identity 자료와 법률 문서를 온체인 event나 일반 로그에 기록하지 않는다.
• audit event에는 필요한 식별자와 상태 변경만 남긴다.
• 성공한 regulated evaluation은 Manifest version과 applied Recipe set을 추적할 수 있어야 한다.
• revert 시 event가 사라지는 특성을 고려한 reject logging 정책은 별도 설계 결정(ADR-008)에 따라 off-chain hash-chain audit에 기록한다. local hash-chain은 tamper evidence일 뿐 production WORM/retention을 대체하지 않는다.
• acquisition 원본 lot, identity와 provider payload는 온체인에 기록하지 않는다. AttestedAcquisitionSource에는 PII-free source hash, conservative clock, freshness와 status만 기록하고 stale/missing/broken lineage를 fail-closed한다.

• 새 의존성은 명시적인 제품 요구가 있을 때만 추가한다.
• 공식 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에 포함한다.