Smart Contract — New Feature
Summary
Recurring schedules need their own independent id sequence. This adds a RECUR_NEXT counter with helpers to read and advance it, kept separate from the proposal id counter.
Background
The contract already maintains a next_id counter for proposals, stored under an instance key and read/written through read_next_id/write_next_id in contracts/accord/src/lib.rs. Recurring schedules must have their own id sequence so the two types do not collide.
What Needs to Be Done
- Add an instance storage key for the next recurring schedule id (for example
RECUR_NEXT), independent of the proposal id counter.
- Add
read_next_recurring_id and write_next_recurring_id helpers mirroring the proposal id helpers.
- Keep the recurring id counter's initialization and progression separate from the existing proposal sequence.
Acceptance Criteria
Files to Look At
contracts/accord/src/lib.rs — add the helpers near the existing read_next_id/write_next_id
Difficulty: Medium
Smart Contract — New Feature
Summary
Recurring schedules need their own independent id sequence. This adds a
RECUR_NEXTcounter with helpers to read and advance it, kept separate from the proposal id counter.Background
The contract already maintains a
next_idcounter for proposals, stored under an instance key and read/written throughread_next_id/write_next_idincontracts/accord/src/lib.rs. Recurring schedules must have their own id sequence so the two types do not collide.What Needs to Be Done
RECUR_NEXT), independent of the proposal id counter.read_next_recurring_idandwrite_next_recurring_idhelpers mirroring the proposal id helpers.Acceptance Criteria
Files to Look At
contracts/accord/src/lib.rs— add the helpers near the existingread_next_id/write_next_idDifficulty: Medium