You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
perf(contract): define TTL policy for transfers, callers, and admin state #196
Unclear storage expiry can remove active transfers or cause redundant writes and budget failures.
Objective
Deliver a production-quality improvement to persistent storage and TTL bumps that creates measurable value for correctness, security, reliability, performance, or maintainability.
Implementation scope
Define TTL classes, avoid repeated bumps, and add bounded cleanup for terminal records only.
Acceptance criteria
Live records remain available within policy; cleanup cannot remove active escrow; storage operations stay within budget.
Required validation
Instrumentation, expiry, cleanup, and transaction-budget tests.
Existing tests and CI remain passing.
Add regression coverage for the original failure mode.
Do not weaken, delete, or skip unrelated tests to obtain a green build.
PR quality bar
Keep the PR focused and explain design tradeoffs, compatibility impact, and test evidence.
Avoid typo-only, documentation-only, cosmetic-only, or unrelated refactor submissions.
Out of scope
Broad rewrites not required by the acceptance criteria.
Changes to unrelated services, contracts, or user flows.
I’d love to be assigned this issue and contribute across the relevant areas, whether it involves smart contracts, UI development, backend logic, design implementation, or overall system integration. I’m comfortable working across the full stack and can adapt to the project’s technical requirements to ensure a smooth and consistent contribution.
Implementation approach: map every persistent key to an explicit TTL class, make bumps idempotent and monotonic, and add cleanup that can only target terminal transfer records. I will exercise active/terminal expiry, repeated writes, and budget-related boundaries with regression tests and document compatibility before opening the PR.
Activity
Baskarayelu commentedon Aug 27, 2026
I’d love to be assigned this issue and contribute across the relevant areas, whether it involves smart contracts, UI development, backend logic, design implementation, or overall system integration. I’m comfortable working across the full stack and can adapt to the project’s technical requirements to ensure a smooth and consistent contribution.
grantfox-oss commentedon Aug 27, 2026
🦊 GrantFox — @Baskarayelu has been assigned to this issue as part of the Third Campaign campaign!
Next steps:
Closes #196)Good luck! Track your progress on GrantFox.
Baskarayelu commentedon Aug 27, 2026
Implementation approach: map every persistent key to an explicit TTL class, make bumps idempotent and monotonic, and add cleanup that can only target terminal transfer records. I will exercise active/terminal expiry, repeated writes, and budget-related boundaries with regression tests and document compatibility before opening the PR.
Baskarayelu commentedon Aug 27, 2026
Implemented and opened PR #204: https://github.com/RemitFlow/Remitwise-Contracts/pull/204\n\nHighlights: explicit per-key TTL classes, monotonic/idempotent bumps, persistent account-operation counters, bounded terminal-only cleanup, and budget/expiry regression coverage. Validation:
cargo test --lib(140 passed, 4 pre-existing ignored) and formatting checks pass.Merge pull request #204 from Baskarayelu/feat/issue-196-ttl-policy