Search projects, hackathons, sponsors and tech

    ← All projects

    Reclaim

    Executable receipts that let buyers cancel, refund, transfer, or dispute onchain purchases.

    Demo

    About

    Reclaim turns payment receipts into executable interfaces for onchain purchases. Instead of a receipt being a passive record, each purchase creates a portable receipt that exposes the rights attached to that transaction, such as cancelling an eligible purchase, requesting a refund, transferring the claim, or opening a dispute. Arc is the canonical settlement layer, where USDC is held and purchase state is enforced by the escrow contract. ENSv2 gives each receipt a portable identity such as order-1.reclaimprotocol.eth, together with records describing its status, amount, merchant, claim owner, deadlines, and available actions. The result is a receipt that acts like a remote control for the purchase while keeping financial authority onchain.

    How it's made

    Reclaim uses a Solidity escrow contract deployed on Arc Testnet with USDC for settlement. The contract manages purchase lifecycle states including PAID, REFUND_REQUESTED, CANCELLED, REFUNDED, FINALIZED, and DISPUTED, and exposes the actions currently available to each user. We built and tested the contract with Foundry and verified a real 49 USDC lifecycle on Arc: approve → purchase → PAID → cancel → CANCELLED → funds returned. The application is built with TanStack Start, React, TypeScript, Vite, and viem. The frontend independently reads canonical order state from Arc instead of trusting browser state. For ENS, Reclaim uses ENSv2 Beta on Ethereum Sepolia. reclaimprotocol.eth acts as the parent namespace, with a Permissioned Registry creating receipt subnames such as order-1.reclaimprotocol.eth. A Permissioned Resolver stores receipt metadata including status, amount, Arc chain ID, escrow contract, order ID, merchant, claim owner, deadlines, transferability, and available actions. A dedicated server-side synchronizer reads the canonical Arc order and updates ENS only after verifying the real onchain state. ENS never authorizes or moves funds. We also use ENSv2 Enhanced Access Control so authoritative receipt fields remain controlled by the synchronizer while the current claim owner can receive narrowly scoped permissions such as editing a customer note. GitHub Actions is used for contract deployment and real lifecycle verification, and the application is being packaged as a single Vercel deployment with a same-origin /api/receipt-sync server endpoint.