Skip to content

Implement canonical asset whitelist with allow-list verification #106

Description

@ibrahimmosouf-png

Implement canonical asset whitelist with allow-list verification

Labels: security, feature, priority/medium
Difficulty: Medium · Effort: M
Backlog slot: 19

Problem Statement

accepted_assets is just a list at initialization; the contract trusts that every issuer is correct. There's no deep verification: confirm the token contract address is a real SEP-41 token, not a malicious address that simulates a token interface.

Why it Matters

  • An attacker could deploy a malicious mock token, register it as accepted, and trick users into "donating" to the attacker.

Expected Outcome

  1. Implement verify_token_contract(env, address) — calls token::Client::newforname, symbol, decimals` and asserts they exist.
  2. Optionally require an allow-list of pre-approved issuers at platform level.

Acceptance Criteria

  • Initialization panics on a non-Soroban-token address.
  • Verified address stored alongside accepted_assets to avoid re-checking at every donate.

Files Likely Affected

  • campaign/src/lib.rs, campaign/src/storage.rs

Dependencies

None.


Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardOfficial Campaign | FWC26Campaign: Official Campaign | FWC26featureImported from .github/ISSUES_TO_CREATE.mdpriority/mediumImported from .github/ISSUES_TO_CREATE.mdsecurityImported from .github/ISSUES_TO_CREATE.md

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions