Wallet rate limits, delayed security changes and opt-in transfer locks

PlasticDigits commented

2026-10-31 01:57:06 +00:00

Owner

Implement wallet-level security enforced in every ordinary debit path (transfer/send/burn and all From variants), attributed to balance owner, plus actor/recipient checks and allowance-increase rules where needed. Default protection applies lazily to existing wallets after migration. Initial design target: 10% of protected opening balance per rolling 24h, 24h settings relaxation/opt-out delay, 48h opt-in lock unlock delay. Evaluate documented DEX/bridge/treasury compatibility before finalizing defaults; avoid prices/oracles and decimals-dependent fixed-unit defaults. Exact bounded rolling accounting or equivalent conservative algorithm must prevent split transactions, boundary bursts, inbound-top-up resets and settings reset bypasses. Same-block allowance reuse must not bypass limits. No broad implicit exemption for all contracts/minters.

Tightening/locking may be immediate; weakening/opt-out/delay shortening requires OLD configured delay, minimum 24h for protection relaxation. A pending request snapshots exact payload, nonce, initiator, proposed/executable timestamps; replacing it restarts timer. Cancellation cannot weaken settings. User may increase delay immediately; shortening uses previous delay. Lock opt-in only, cancellation/relock safe, unlock expiry visible. Reject lock enrollment that strands protocol accounts without explicit reviewed compatibility. Consider new wallets with zero opening balance and inbound funds safely.

Default/read-only effective state, schedule/execute/cancel APIs and timer-start events.
Focused clock-boundary, delegated bypass, mutation-reset, replay and accounting tests.
Upper/lower bounds and policy documented; legacy CW20 message casing retained.
Integrate controller query guard without duplicated query fanout; decreases/cancellation remain available during containment as safe.
Dependency: controller interface for global guard; wallet state work parallel.

Working rules

User authorizes implementation and worker coordination. Trusted CL8Y governance is an explicit trust assumption; separate containment, unpause, recovery authorization, execution and key rotation. No social account alone establishes asset ownership. Never publish PII, secrets or private incident operations. Work in small reviewable increments, with bounded focused security tests; no broad soak runs or very long scripts. Publish commits/PRs and factual evidence. Keep acceptance open until actually met; source success does not establish live deployment. No automatic closing keywords in PR descriptions before full acceptance.

Implement wallet-level security enforced in every ordinary debit path (transfer/send/burn and all From variants), attributed to balance owner, plus actor/recipient checks and allowance-increase rules where needed. Default protection applies lazily to existing wallets after migration. Initial design target: 10% of protected opening balance per rolling 24h, 24h settings relaxation/opt-out delay, 48h opt-in lock unlock delay. Evaluate documented DEX/bridge/treasury compatibility before finalizing defaults; avoid prices/oracles and decimals-dependent fixed-unit defaults. Exact bounded rolling accounting or equivalent conservative algorithm must prevent split transactions, boundary bursts, inbound-top-up resets and settings reset bypasses. Same-block allowance reuse must not bypass limits. No broad implicit exemption for all contracts/minters. Tightening/locking may be immediate; weakening/opt-out/delay shortening requires OLD configured delay, minimum 24h for protection relaxation. A pending request snapshots exact payload, nonce, initiator, proposed/executable timestamps; replacing it restarts timer. Cancellation cannot weaken settings. User may increase delay immediately; shortening uses previous delay. Lock opt-in only, cancellation/relock safe, unlock expiry visible. Reject lock enrollment that strands protocol accounts without explicit reviewed compatibility. Consider new wallets with zero opening balance and inbound funds safely. - [ ] Default/read-only effective state, schedule/execute/cancel APIs and timer-start events. - [ ] Focused clock-boundary, delegated bypass, mutation-reset, replay and accounting tests. - [ ] Upper/lower bounds and policy documented; legacy CW20 message casing retained. - [ ] Integrate controller query guard without duplicated query fanout; decreases/cancellation remain available during containment as safe. Dependency: controller interface for global guard; wallet state work parallel. ## Working rules User authorizes implementation and worker coordination. Trusted CL8Y governance is an explicit trust assumption; separate containment, unpause, recovery authorization, execution and key rotation. No social account alone establishes asset ownership. Never publish PII, secrets or private incident operations. Work in small reviewable increments, with bounded focused security tests; no broad soak runs or very long scripts. Publish commits/PRs and factual evidence. Keep acceptance open until actually met; source success does not establish live deployment. No automatic closing keywords in PR descriptions before full acceptance.

PlasticDigits referenced this issue

2026-10-31 01:59:42 +00:00

Security upgrade: incident-driven CW20 protections and wallet security portal #3

PlasticDigits commented

2026-10-31 01:59:44 +00:00

Author

Owner

Implementation assigned to BB worker thr_n4vtxxfcb7, coordinated by thr_4rw76j9ker in security epic.

Dependency/order: Controller ABI before global guard integration; local wallet state may proceed independently.

Worker is active in an isolated worktree. It owns implementation and truthful acceptance evidence, with independent review before production completion. Initial orchestration does not establish code/deployment acceptance.

Implementation assigned to BB worker `thr_n4vtxxfcb7`, coordinated by `thr_4rw76j9ker` in [security epic](https://git.cl8y.com/code/cw20-mintable/issues/3). Dependency/order: Controller ABI before global guard integration; local wallet state may proceed independently. Worker is active in an isolated worktree. It owns implementation and truthful acceptance evidence, with independent review before production completion. Initial orchestration does not establish code/deployment acceptance.

PlasticDigits referenced this issue

2026-10-31 02:07:43 +00:00

Inventory expiring allowances and add scoped approval/revocation guidance #9

PlasticDigits commented

2026-10-31 02:28:45 +00:00

Author

Owner

Implemented owner-attributed guards for all6 debit variants, mint/allowance containment, conservative bounded25-bucket rolling10% default, dust-safe first-positive-debit basis, no topup/settings accounting reset, delayed old-policy weakening/rebase, opt-in48h unlock, exact pending nonce/cancel/replay and reviewed delayed protocol assignments.21 meaningful cross-contract tests plus56existing and14controller tests pass; strict workspace clippy and schema reproducibility pass. WalletResponse.initialized exposes lazy versus persisted basis. Token source/schema2d70d43 independently reviewed: #7 (comment) . Compatibility policy and explicit remaining DEX/pool/bridge/treasury enrollment gates are documented; no production exemptions invented.

Implementation PR: #14 . Reviewed exact-byte local candidate (draft, not deployed): https://git.cl8y.com/code/cw20-mintable/releases/tag/security-v1-review-2d70d43 . Rollout receipts: docs/rollout/{README.md,artifact-provenance.json,columbus-5-inventory.json,selected-integration-balances.json}. Contract lead thr_n4vtxxfcb7 retains issue/rollout ownership; parent coordinator thr_4rw76j9ker. No closing keywords or live coverage claim; this issue remains open for unverified production acceptance.

Implemented owner-attributed guards for all6 debit variants, mint/allowance containment, conservative bounded25-bucket rolling10% default, dust-safe first-positive-debit basis, no topup/settings accounting reset, delayed old-policy weakening/rebase, opt-in48h unlock, exact pending nonce/cancel/replay and reviewed delayed protocol assignments.21 meaningful cross-contract tests plus56existing and14controller tests pass; strict workspace clippy and schema reproducibility pass. WalletResponse.initialized exposes lazy versus persisted basis. Token source/schema2d70d43 independently reviewed: https://git.cl8y.com/code/cw20-mintable/issues/7#issuecomment-65389 . Compatibility policy and explicit remaining DEX/pool/bridge/treasury enrollment gates are documented; no production exemptions invented. Implementation PR: https://git.cl8y.com/code/cw20-mintable/pulls/14 . Reviewed exact-byte local candidate (draft, not deployed): https://git.cl8y.com/code/cw20-mintable/releases/tag/security-v1-review-2d70d43 . Rollout receipts: docs/rollout/{README.md,artifact-provenance.json,columbus-5-inventory.json,selected-integration-balances.json}. Contract lead thr_n4vtxxfcb7 retains issue/rollout ownership; parent coordinator thr_4rw76j9ker. No closing keywords or live coverage claim; this issue remains open for unverified production acceptance.

Rows
Columns

Wallet rate limits, delayed security changes and opt-in transfer locks #5

Working rules