Specify optional delayed first-use recipients with routed-transfer coverage #7

Open
opened 2026-10-31 02:07:41 +00:00 by PlasticDigits · 0 comments
Owner

Research follow-up from code/cw20-mintable #8. Existing portal #2 already owns readable security-setting previews; this issue owns an additional opt-in recipient maturity policy, not a duplicate dashboard.

Acceptance:

  • Publish a threat model and exact enforcement location for delayed new recipients and delayed disabling/replacement, with independent old-channel notices and cancel-safe changes.
  • Distinguish UI address book from enforceable authorization. If enforcement is only UI, explicitly disclose direct-contract bypass; do not claim protected transfers.
  • Bind chain/token/recipient and actual final beneficiary for CW20 Send hooks, routers, bridges, contract recipients and delegated debits; unknown destination semantics refuse protected execution or require a documented reviewed route.
  • Preview exact amount, recipient, approvals, message/call scope and protection coverage using exact units; independent recipient check guidance and clear-signing support matrix. Never collect seed/private keys or imply Ledger defect.
  • Concrete compatibility examples for ordinary transfer, router and bridge; boundary/change/cancel checks scoped to implementation selected. No mandatory KYC for ordinary transfers.

Deliver design/acceptance first, coordinate any future contract ABI change with #5/#7; no unreviewed token changes or live deployment under this issue's research parent.

Research follow-up from code/cw20-mintable #8. Existing portal #2 already owns readable security-setting previews; this issue owns an additional opt-in recipient maturity policy, not a duplicate dashboard. Acceptance: - Publish a threat model and exact enforcement location for delayed new recipients and delayed disabling/replacement, with independent old-channel notices and cancel-safe changes. - Distinguish UI address book from enforceable authorization. If enforcement is only UI, explicitly disclose direct-contract bypass; do not claim protected transfers. - Bind chain/token/recipient and actual final beneficiary for CW20 Send hooks, routers, bridges, contract recipients and delegated debits; unknown destination semantics refuse protected execution or require a documented reviewed route. - Preview exact amount, recipient, approvals, message/call scope and protection coverage using exact units; independent recipient check guidance and clear-signing support matrix. Never collect seed/private keys or imply Ledger defect. - Concrete compatibility examples for ordinary transfer, router and bridge; boundary/change/cancel checks scoped to implementation selected. No mandatory KYC for ordinary transfers. Deliver design/acceptance first, coordinate any future contract ABI change with #5/#7; no unreviewed token changes or live deployment under this issue's research parent.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
code/cl8y-wallet-security#7
No description provided.