Redeemify
Retired (built 2023 · ran until early 2026)- Role
- Sole backend developer
- Timeline
- Built 2023 · retired early 2026
- Chain
- Algorand
- Scale
- 52 commits · 6 models · 26 endpoints
- Stack
- Node · Express · MongoDB · Algorand SDK · Nodemailer · Swagger UI
Redeemify was a marketplace for NFTs with real, physical items attached. Any creator could list a collection where each NFT is tied to a physical good — art prints, merch — and holders could order and redeem the physical item; redeeming marks the NFT as redeemed so its status reflects that the physical good has been claimed. Holders pay in any of several assets. Two properties had to hold or the whole premise breaks: an item can't be redeemed twice, and a redeemed NFT must clearly read as redeemed. I built it in 2023; it ran in production until it was retired in early 2026.
The problem
The model is a two-sided marketplace: creators list collections-with-physical-items and get approved; holders browse, pay, and redeem; the platform coordinates fulfilment (shipping) and keeps the on-chain side honest. The dangerous part is the moment money and state move together — redemption is paid for, it changes the NFT's status, and it can never happen twice for the same asset. A retry, a double-submit, or a race must not redeem the same item twice or charge a holder twice.
Architecture
The API handles creator-collection approval, verifies a multi-asset payment (ALGO, USDC, or project tokens — each verified on-chain on its own terms), records the redemption and order lifecycle in MongoDB, updates the NFT so it reads as redeemed, manages shipping details, and sends automated email confirmations. The whole REST surface is Swagger-documented.
The hardest decision: an idempotent, globally-unique redemption guard
The core risk for anything that moves state and money is the double-redeem. I made redemption idempotent: the database records the redemption transition and the payment, and the state change is gated on that transition, so replaying a request can't produce a second redemption or a second charge.
The key design choice was making the guard global across every collection on the platform, not per-collection. A unique-asaId index enforces that any given on-chain asset can be redeemed once, ever, anywhere in the system — closing the cross-collection replay hole where the same asset might otherwise be redeemed under two different listings. Supporting multiple payment assets (ALGO, USDC mainnet ASA 31566704, project tokens) added a verification branch per asset, in exchange for letting holders pay however they liked.
Results
- 52 commits, sole author, delivered end-to-end — built 2023, ran in production until retired early 2026.
- A two-sided redemption marketplace (creator listings + approval, holder orders, shipping), multi-asset on-chain payment verification (ALGO + USDC ASA
31566704+ tokens), a global cross-collection double-redeem guard, automated order/shipping email, and a fully Swagger-documented API.
What this demonstrates
Clean, complete delivery of a payment-plus-state-change product: idempotency where money and state move together, a globally-unique guard against replay/double-spend, multi-asset settlement, marketplace/order/fulfilment modelling, and the documentation discipline (Swagger) that makes a backend handoff-ready.