User Story:
As a developer, I want the campaign contract's storage keys and core data struct defined together so that storage access is consistent, typed, and gas-efficient.
Acceptance Criteria:
DataKey enum: CampaignData, MilestoneData(u32), DonorData(Address), TotalRaised, ContractStatus (plus keys needed by later issues: RaisedPerAsset, Locked, Admin, Frozen)
CampaignData struct: creator: Address, goal_amount: i128, raised_amount: i128, end_time: u64, status: CampaignStatus, accepted_assets: Vec<AssetInfo>, milestone_count: u32; derives contracttype, stored under DataKey::CampaignData
- Storage access extracted into a dedicated storage module rather than scattered
env.storage() calls throughout the contract
- Document, with brief cost reasoning, which keys are temporary vs. persistent storage
User Story:
As a developer, I want the campaign contract's storage keys and core data struct defined together so that storage access is consistent, typed, and gas-efficient.
Acceptance Criteria:
DataKeyenum:CampaignData,MilestoneData(u32),DonorData(Address),TotalRaised,ContractStatus(plus keys needed by later issues:RaisedPerAsset,Locked,Admin,Frozen)CampaignDatastruct:creator: Address,goal_amount: i128,raised_amount: i128,end_time: u64,status: CampaignStatus,accepted_assets: Vec<AssetInfo>,milestone_count: u32; derivescontracttype, stored underDataKey::CampaignDataenv.storage()calls throughout the contract