Add multi-token support for groups

[big14way]

Allow groups to accept contributions in multiple tokens (e.g., USDC and XLM).

Acceptance Criteria:

• Add accepted_tokens: Vec<Address> to group config
• Modify contribute function to accept token parameter
• Validate token is in accepted list

Files: contracts/sorosave/src/types.rs, contracts/sorosave/src/contribution.rs

[WuXieSec]

/apply

I’m taking this bounty and will submit a PR shortly.

Plan:

1. Add accepted_tokens: Vec to group config types
2. Update contribution flow to accept a token parameter
3. Enforce allowlist validation against accepted_tokens
4. Add/adjust tests for accepted vs rejected token paths

I’ll keep the change minimal and backwards-safe.

[WuXieSec]

Update: implemented and submitted PR for multi-token support.

PR: #82

Delivered in this PR:

• Added accepted_tokens: Vec<Address> to group config
• Updated contribution API to accept token parameter
• Added token allowlist validation in contribution flow
• Updated tests for new signatures

Validation:

• cargo test --package sorosave => 9 passed / 0 failed (run in ephemeral Rust env, then removed)

[TUPM96]

/attempt #4

Plan: add accepted_tokens to group config, keep existing single-token groups backward-compatible, add multi-token group creation plus contribute_with_token, validate token allowlist, track per-token round totals, and distribute each token pot during payout. Payout details can be provided privately if accepted.

[TUPM96]

/claim #4

PR opened: #155

Implemented accepted token allowlists, multi-token group creation, token-specific contribution validation, per-token round accounting, and per-token payout distribution with tests. Payout details can be provided privately on acceptance.

[Hobie1Kenobi]

Approach

1. Update types.rs: Add accepted_tokens: Vec<Address> field to the GroupConfig struct, with helper methods for token validation.
2. Update contribution.rs: Modify the contribute function to accept a token: Address parameter, validate it against the group's accepted_tokens list, and pass it through to the token transfer logic.
3. Add validation: Implement an is_token_accepted helper that iterates accepted_tokens and panics with a clear error if the token is not in the list.
4. Update initialization: Ensure create_group accepts and stores the accepted_tokens vector.

Deliverables

• accepted_tokens field added to GroupConfig in types.rs
• is_token_accepted validation helper in types.rs
• contribute function signature updated with token param in contribution.rs
• Token validation enforced before any transfer in contribute
• create_group updated to accept accepted_tokens input
• All existing call-sites and tests updated to pass token parameter

ETA

3 days from assignment

Payout Address

0x408f39B19266022FeC03076091e59D1f4f163658

[Hobie1Kenobi]

Approach

1. Update types.rs — Add accepted_tokens: Vec<Address> field to the group config struct and update any related initialization/storage logic.
2. Update contribution.rs — Modify the contribute function to accept a token: Address parameter, then add a validation check that the provided token exists in the group's accepted_tokens list before processing the contribution. Return a clear error (e.g., TokenNotAccepted) if validation fails.
3. Testing — Add unit tests covering: contribution with an accepted token (success), contribution with a non-accepted token (failure), and groups with multiple accepted tokens.

Deliverables

• accepted_tokens field added to group config in types.rs
• contribute function updated with token parameter + validation in contribution.rs
• Custom error variant for invalid token
• Unit tests for the above scenarios

ETA

2–3 days from assignment

Payout Address (Base)

0x408f39B19266022FeC03076091e59D1f4f163658