Decide what a share-token freeze blocks #171

Research question

Should a freeze on the share token stop a frozen investor from receiving shares and from leaving in cash, and if so, where should that check live?

Time-box

1 day

Background / What we already know

With stellar-tokens 0.7.2 and our contracts as they are today:

• transfer refuses a frozen sender or receiver. That check is in the token itself, not in a compliance hook.
• mint checks only verify_identity and can_create, so a frozen investor on the allowlist is minted on claim_deposit.
• request_redeem escrows with forced_transfer, which checks neither freezes nor the allowlist, and releases as much of a partial freeze as it needs. A frozen holder can then collect cash through claim_redeem.
• The compliance contract registers no modules, so can_create and can_transfer always allow.
• The design document (§8.1) keeps a frozen investor outside the payable-claims guarantee but does not say whether a freeze should block the exit.

Tests in contracts/async-vault/src/test/compliance.rs record this behaviour: a_frozen_investor_on_the_allowlist_is_still_minted, a_frozen_holder_can_still_queue_an_exit, queueing_an_exit_releases_a_partial_freeze.

Investigation approach

• Decide what a freeze must mean for the kit: no new shares, no exit, or both, and how a partial freeze should behave.
• Compare where the check could live: a compliance module on can_create, an override on the share token's mint, or a check in the vault's claim_deposit and request_redeem.
• Check each option against the payable-claims guarantee and the exit-only cash path for de-listed investors.

Expected output

A recommendation recorded here, a design document amendment if the answer changes §8.1, and follow-up issues for the chosen implementation.

Next steps

Update docs/COMPLIANCE_MATRIX.md and the tests above once the decision lands.