enhancement: Add contributor CSV export for campaign creators

[dotunv]

Description

Campaign creators have no way to export a list of their contributors for fulfilment, reward shipping, or thank-you communications. This is a standard feature on Kickstarter, Indiegogo, and every major crowdfunding platform.

Proposed Solution

Backend

• Add GET /api/campaigns/:id/contributions/export — returns CSV with columns: contributor_name, display_name, amount_usd, amount_xlm, tier, contributed_at, wallet_address (if provided)
• Only accessible to campaign owner and admin
• Respect contributor privacy preferences (exclude wallet address if contributor opted out of public listing)

Frontend

• Add "Export CSV" button on the campaign creator's management view
• Show download progress for large exports

Acceptance Criteria

• CSV includes all contribution data relevant for fulfilment
• Contributor privacy preferences respected in export
• Only campaign creator and admin can download export
• Export works correctly for campaigns with > 1000 contributors (streaming response)

[BigJohn-dev]

@BigJohn-dev has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Pls i would like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @BigJohn-dev to this issue.

[AlphaMaleBaDI]

@AlphaMaleBaDI has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hi Maintainer, I will solve this by introducing a contributor CSV export feature for campaign creators to enable smooth reward fulfillment and communication tracking.

To deliver a pristine, 100% compliant data export layer matching all stated acceptance criteria, I plan to:

• Implement a dedicated, securely guarded GET /api/campaigns/:id/contributions/export endpoint within the backend architecture.
• Enforce strict role-based access controls ensuring the route is explicitly restricted to verified campaign owners and system administrators.
• Construct a robust, streaming CSV generator capable of safely parsing and processing datasets exceeding 1,000 contributors without introducing memory overhead or connection timeouts.
• Embed structural checks to meticulously respect individual contributor privacy preferences, automatically omitting wallet address fields if a user opted out of public listings.
• Structure the CSV payload with precise, standardized columns: contributor_name, display_name, amount_usd, amount_xlm, tier, contributed_at, and wallet_address.
• Integrate an intuitive "Export CSV" trigger directly into the frontend campaign creator's management view, complete with real-time download progress tracking for high-volume campaigns.

I will solve this by building a stream-based CSV export mechanism that scales beautifully for large campaigns, keeping strict validation on owner authentication and user privacy settings. Ready to lock it in!

ℹ️ Repo Maintainers: To accept this application, review their application or assign @AlphaMaleBaDI to this issue.

[gloskull]

Hi, I’d love to work on this issue. I have 4 years of experience across backend, frontend, full-stack, and smart contract development. I understand the task clearly and can deliver a clean, efficient, well-tested solution on time, with strong focus on code quality and maintainability. My PR will be submitted in under 10 hours.

[deralph]

@deralph has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hi maintainer,

I'll add contributor CSV export for campaign creators. Quick, privacy-aware, and scalable.

My Approach:

Backend: Streaming CSV endpoint at /api/campaigns/:id/contributions/export using json2csv streams to handle 1000+ contributors without memory issues
Authorization: Campaign owner + admin only (middleware check)
Privacy: Exclude wallet_address if contributor opted out of public listing
Columns: contributor_name, display_name, amount_usd, amount_xlm, tier, contributed_at, wallet_address (conditional)
Frontend: "Export CSV" button on campaign management view with loading spinner for large exports

ℹ️ Repo Maintainers: To accept this application, review their application or assign @deralph to this issue.

[DevSolex]

Hi Maintainer,

I’m a smart contract and full-stack developer and would love to contribute to this issue. I’m an experienced contributor with hands-on expertise in Rust, Soroban, Cairo, and TypeScript.

I’m passionate about building secure, scalable blockchain solutions, with a strong emphasis on writing clean and maintainable code. Based on the scope of this issue, I’m confident I can deliver a complete solution within 24 hours of assignment.

I’d greatly appreciate the opportunity to contribute and help move this forward.

[dadichaoren]

Implemented this in PR #414: #414

[drips-wave]

Congratulations, @deralph! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 30, 2026.

🧑‍💻 @deralph: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[dadichaoren]

Hi maintainers / Wave team,

I would like to clarify reward/points eligibility for this issue.

I implemented the contributor CSV export in PR #414, and that PR was merged into main on 2026-06-28:
#414

I also linked the implementation here before the later Wave assignment comment:
#408 (comment)

After that, the Wave bot accepted another contributor on this same issue. Could you please clarify whether the merged contribution in #414 is eligible for any Wave points/reward/payment, or whether eligibility requires being accepted/assigned before submitting the implementation?

If #414 is not eligible, a clear confirmation of that rule would also help me avoid misunderstanding future Wave/Crowdpay tasks.

Thanks.