You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each campaign is currently tied to a single token at creation time. There is no option to accept contributions in secondary tokens, limiting the flexibility of crowdfunding campaigns on Stellar.
6
+
7
+
## Proposed Solutions
8
+
9
+
### Option 1: Extend Campaign Model to Support Multiple Accepted Tokens
10
+
11
+
**Implementation Approach:**
12
+
- Modify the `Campaign` struct in the Soroban contract to include `accepted_tokens: Vec<Address>` instead of a single `token: Address`
13
+
- Update `create_campaign` to accept a list of accepted tokens
14
+
- Modify `contribute` to accept a `token: Address` parameter and validate it against `accepted_tokens`
15
+
- Track pledged amounts per token separately
16
+
- Define how the target amount is evaluated (sum of all contributions? conversion to base value?)
17
+
18
+
**Challenges:**
19
+
1.**Valuation Complexity**: How to determine if the campaign target is met when contributions are in different tokens?
20
+
- Option A: Sum all contributions in their native tokens (requires target to be per-token)
21
+
- Option B: Convert all contributions to a base value using price feeds (requires oracle integration)
2.**Contract Complexity**: Need to track contributions per token, modify storage keys, update invariants
25
+
26
+
3.**Claim Logic**: How to transfer funds when claiming? Transfer all tokens to creator?
27
+
28
+
4.**Refund Logic**: Refunds need to return the correct token
29
+
30
+
5.**UI Complexity**: Contributors need to choose which token to contribute with
31
+
32
+
### Option 2: Single Token Per Campaign (Current Approach)
33
+
34
+
**Pros:**
35
+
- Simple contract logic
36
+
- Clear valuation (all amounts in same token)
37
+
- Straightforward claiming and refunding
38
+
- Easy to understand for users
39
+
40
+
**Cons:**
41
+
- Limited flexibility for creators
42
+
- Contributors must hold the specific token
43
+
- May reduce participation if token is illiquid
44
+
45
+
### Option 3: Token Conversion at Contribution Time
46
+
47
+
**Implementation:**
48
+
- Campaign specifies primary token and accepted secondary tokens
49
+
- At contribution time, automatically convert secondary token contributions to primary token using an oracle
50
+
- All accounting in primary token
51
+
52
+
**Challenges:**
53
+
- Requires reliable price feeds/oracles
54
+
- Introduces slippage and conversion fees
55
+
- Additional complexity in contribution flow
56
+
- Oracle dependency for core functionality
57
+
58
+
## Final Decision: Implement Option 1 (Multi-Token Support)
59
+
60
+
**Rationale:**
61
+
1.**Flexibility**: Allowing multiple tokens increases the potential for campaign success by letting contributors use their preferred assets.
62
+
2.**Standardization**: Implementing this at the contract level ensures consistent behavior across different frontends.
63
+
3.**Future-Proofing**: While simple now, this architecture allows for future integration with price oracles for more complex valuation.
64
+
65
+
## Implementation Details
66
+
67
+
### Contract Architecture
68
+
-**Storage Keys**:
69
+
-`Contribution(u64, Address, Address)`: Tracks contributions per campaign, contributor, and token.
70
+
-`CampaignTokenBalance(u64, Address)`: Tracks total pledged amount for each token in a campaign.
71
+
-**Valuation Strategy**:
72
+
-`pledged_amount` in the `Campaign` struct is a raw sum of all token amounts.
73
+
-**Tradeoff**: This assumes a 1:1 value ratio for all accepted tokens in terms of meeting the `target_amount`. Creators should only accept tokens of similar value (e.g., various USD stablecoins) or understand that the target is a sum of units.
74
+
-**Claim Flow**: The `claim` function iterates over all `accepted_tokens` and transfers the full balance of each token to the creator.
75
+
-**Refund Flow**: The `refund` function iterates over all `accepted_tokens` and returns the specific tokens contributed by the user.
76
+
77
+
### API for Integrators
78
+
79
+
#### Campaign Creation
80
+
```json
81
+
{
82
+
"creator": "G...",
83
+
"accepted_tokens": ["USDC:GA...", "PYUSD:GA..."],
84
+
"target_amount": 1000,
85
+
"deadline": 1234567890,
86
+
"metadata": "..."
87
+
}
88
+
```
89
+
90
+
#### Contribution
91
+
```json
92
+
{
93
+
"campaign_id": 1,
94
+
"contributor": "G...",
95
+
"token": "USDC:GA...",
96
+
"amount": 100
97
+
}
98
+
```
99
+
100
+
#### Querying
101
+
-`get_contribution(campaign_id, contributor, token)`: Returns the amount of a specific token pledged by a contributor.
102
+
-`get_campaign_token_balance(campaign_id, token)`: Returns the total amount of a specific token pledged to the campaign.
103
+
104
+
## Conclusion
105
+
106
+
Multi-token support has been implemented to provide maximum flexibility for crowdfunding on Stellar. The current valuation strategy is simple (1:1 unit sum), which is suitable for campaigns using similar-value assets. For campaigns requiring diverse assets (e.g., XLM and USDC), integrators should be aware that the `target_amount` is calculated as a raw sum of units.
0 commit comments