Smart Contract — New Feature
Summary
A recurring schedule must be persisted and kept alive in storage. This adds a persistent storage key and read/write helpers for schedules, mirroring how proposals are stored.
Background
Proposals are persisted through read_proposal and write_proposal in contracts/accord/src/lib.rs, stored under a persistent key by id and kept alive with a TTL bump via the existing bump_persistent helper. Recurring schedules need the same treatment under their own key.
What Needs to Be Done
- Add a persistent storage key for recurring schedules (for example a
RECUR key), keyed by schedule id.
- Add
read_recurring_payment and write_recurring_payment helpers mirroring read_proposal and write_proposal.
- Bump the persistent entry's TTL on write using the existing bump helper, matching the proposal pattern.
Acceptance Criteria
Files to Look At
contracts/accord/src/lib.rs — add helpers near read_proposal/write_proposal and the storage key definitions
Difficulty: Medium
Smart Contract — New Feature
Summary
A recurring schedule must be persisted and kept alive in storage. This adds a persistent storage key and read/write helpers for schedules, mirroring how proposals are stored.
Background
Proposals are persisted through
read_proposalandwrite_proposalincontracts/accord/src/lib.rs, stored under a persistent key by id and kept alive with a TTL bump via the existingbump_persistenthelper. Recurring schedules need the same treatment under their own key.What Needs to Be Done
RECURkey), keyed by schedule id.read_recurring_paymentandwrite_recurring_paymenthelpers mirroringread_proposalandwrite_proposal.Acceptance Criteria
Files to Look At
contracts/accord/src/lib.rs— add helpers nearread_proposal/write_proposaland the storage key definitionsDifficulty: Medium