security: review compliance bypass paths outside `ExecutionRouter`

[0xMuang]

security: review compliance bypass paths outside ExecutionRouter

Summary

Corner Store currently enforces DEX-level compliance only on the router-mediated path:

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

This protects trades that enter through Corner Store, but it does not automatically protect RWA movements or RWA exposure transfers that happen outside ExecutionRouter.

We need to define and document the security boundary for non-router paths before treating the system as production-ready.

Why this matters

The recent skeleton PR hardened the internal Corner Store path:

• both ACTIVE token sides are evaluated for regulated-regulated pairs
• missing recipe references fail closed
• AMM adapter execution is router-only
• router caller is bound to context.initiator

Those fixes protect the Corner Store execution path. They do not, by themselves, prevent a user from bypassing Corner Store and interacting directly with the underlying ERC-3643 token, pool, RFQ settlement, wrapper, or custodian.

If a non-router path remains open, the following Corner Store checks may be skipped:

• investor qualification recipes
• amount caps
• venue restrictions
• nonce/replay controls
• stateful commit() / surveillance updates
• future lockup, affiliate, or jurisdiction-specific rules

Threat cases to review

1. Direct ERC-3643 token transfer

A holder may call the RWA token directly:

User A → RWA.transfer(User B)

If the ERC-3643 token allows the transfer, Corner Store does not run evaluate() or commit().

We need to decide whether direct transfers are blocked by token-level policy, explicitly allowed, or out of Corner Store scope.

2. Direct AMM pool or venue call

A user may call an underlying pool directly:

User → Pool.swap(...)

If the pool is a verified ERC-3643 holder, it may become a bypass path. The token may only check holder eligibility, while Corner Store-specific venue, recipe, cap, and surveillance rules are skipped.

3. Direct RFQ / order book settlement

Future settlement contracts may be callable directly:

Maker/Taker → RFQSettlement.fill(...)

If settlement is not router-only, trades can bypass compliance evaluation and post-trade commit. Future RFQ/order book work should define router-only settlement or an equivalent authorization model before merge.

4. Wrapper, vault, or custodian bypass

RWA economic exposure may move without direct RWA token transfers:

RWA → Vault/Custodian → users trade shares or beneficial ownership

We need to decide whether wrappers, vaults, omnibus accounts, and offchain beneficial ownership transfers are in scope for Corner Store compliance guarantees.

Design decision needed

Choose and document the intended model:

Option A — Router-exclusive model

Corner Store only supports venues and settlement contracts that cannot be used directly by end users.

This likely requires router-only adapters, router-only settlement, and possibly wrapped/controlled venues instead of arbitrary third-party pools.

Option B — Token-level enforcement model

Critical restrictions are enforced by the ERC-3643 token/compliance module even outside Corner Store.

Corner Store remains an additional DEX-level compliance layer, but direct transfers and direct venue calls rely on token-level policy.

Option C — Limited-scope model

Corner Store guarantees DEX-level compliance only for router-mediated trades.

Direct token transfers, direct venue calls, wrappers, custodians, and other non-router paths are explicitly documented as out-of-scope unless separately restricted.

Recommended immediate action

Do not attempt a broad code patch before choosing the security boundary.

First, document the current boundary clearly:

Corner Store enforces DEX-level compliance only on router-mediated execution paths.
Underlying ERC-3643 transfers, direct venue calls, wrappers, custodians, and other non-router settlement paths must be separately restricted, delegated to token-level compliance, or explicitly treated as out-of-scope.

Acceptance criteria

• docs/security.md defines the current compliance enforcement boundary.
• ARCHITECTURE.md explains which execution paths are protected by Corner Store and which are not.
• The project chooses one of: router-exclusive, token-level enforcement, or limited-scope model.
• Future RFQ/order book settlement work requires router-only settlement or an equivalent authorization model.
• Product-facing language does not imply that Corner Store globally enforces compliance for every possible RWA movement.