Implement campaign NFT receipts on completion

[ibrahimmosouf-png]

Implement campaign NFT receipts on completion

Labels: feature, enhancement, priority/low
Difficulty: High · Effort: M
Backlog slot: 59

Problem Statement

Donors have no persistent record of contribution beyond DonorRecord. A non-transferable Soulbound-style receipt NFT would improve UX.

Why it Matters

• Web3 identity benefits: verifiable donor history, weighted voting.

Expected Outcome

1. After finalise (goal reached + last milestone released) mint soulbound SAC tokens to donors.
2. Mint metadata references the donation amount.

Acceptance Criteria

• Minting happy + soulbound enforcement (transfer panics).

Files Likely Affected

• New: campaign/src/receipt.rs

Dependencies

Issue #1, #11.

---

[neromtoobad]

Hi, I'd like to work on this issue. I'm a Rust/Soroban developer with solid smart-contract and CI tooling experience. I can deliver in 12 hrs. Looking forward to contributing.

[grantfox-oss]

🦊 GrantFox — @neromtoobad has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #146)
2. Your PR will be reviewed by the OrbitChainLabs maintainers

Good luck! Track your progress on GrantFox.

[neromtoobad]

Thanks for the assignment — starting on this. Two design questions before I go far, since the spec and the current code disagree slightly and I'd rather build the thing you actually want:

1. "After finalise" — there's no finalise entrypoint today. The contract has release_milestone / release_milestone_multi_asset, but nothing named finalise/complete/close. I read the trigger as a condition rather than a function: mint when the goal is reached and the last milestone is released, detected at the end of milestone release. Is that the intent, or would you prefer an explicit finalise() entrypoint that the creator calls (and which mints)?

2. "Soulbound SAC" — a SAC can't be soulbound. The Stellar Asset Contract implements the standard token interface, so transfer is built in and can't be made to panic; the acceptance criterion "transfer panics" isn't reachable with a real SAC. I'd implement the receipt as a small custom token contract exposing the SEP-41/token interface but panicking on transfer / transfer_from / approve (mint + balance + read-only metadata still work) — i.e. soulbound semantics, SAC-shaped interface. Happy to do it another way if you had something specific in mind.

Unless you say otherwise I'll proceed with: condition-triggered minting at last-milestone release + a custom non-transferable receipt token referencing each donor's total_donated, with tests covering the mint happy path and transfer-panics enforcement.