One obligation. One payment. Human-approved invoice settlement shared by independent executors, with verified Arbitrum-chain testnet payment and duplicate rejection.
Problem and motivation
A finance operator approves an invoice. An automation worker later receives another copy of the same bill. Both payment routes can be within budget, yet together they can pay twice. The missing boundary is the business obligation, not simply the transaction nonce.
Existing solutions and remaining gap
Request Finance already detects duplicate bills and protects payments inside its own suite. Its documentation excludes outside payments from that protection. Wallet limits and transaction policies are also mature. InvoiceFence explores a shared settlement boundary for independent clients that agree to use the same vault and obligation identifier.
Working prototype
This is our running prototype with fictional invoices and mock funds. Review the invoice against the registered supplier and purchase order. A human explicitly confirms the amount, payee, and business obligation. The demo signer then creates a fixed authorization. Payment settles 100 Mock USDG. Next, an independent worker tries the same obligation through another route. Contract preflight rejects the duplicate. The interface keeps that rejection distinct from the mined payment transaction. The guarantee applies to this vault and a shared obligation identifier; it cannot stop transfers made outside that boundary.
Technical approach
The signed authorization binds the obligation, recipient, token, amount, chain, and expiry. The contract checks approval and payment state together. Document analysis assists review; it never grants payment authority. Multiple clients consult one settlement record instead of relying on unrelated local histories.
Results and limitations
The public lab demonstrates an approved 100 Mock USDG payment and rejects a duplicate. A separate experiment on Robinhood Chain Testnet (Arbitrum chain 46630) deployed InvoiceFence, settled 1.000000 official test USDG, and rejected another executor with a fresh approval nonce for the same obligation. The vendor balance increased exactly once; the rejected approval nonce stayed unused. These are valueless test assets, not production savings or customer adoption. Public receipts: https://hackathon.pocketplay.win/proofs/invoicefence/ .
AI and dependency disclosure
OpenAI Codex assisted research, code, tests, interface and documentation. Remotion composes actual screen recordings with synthetic narration. No customer traction, revenue, production security audit or unmeasured business impact is claimed. Third-party libraries retain their licenses.
Sources
- https://help.request.finance/en/articles/11665474-how-does-the-double-payment-prevention-work
- https://docs.safe.global/home/ai-agent-quickstarts/agent-with-spending-limit
<p>Built in September 2026 during the hackathon: Solidity EIP-712 settlement contract, invoice and supplier review, explicit human approval, web and independent worker flows, tests, live isolated demo, public source, and narrated walkthrough. On September 21 we deployed InvoiceFence to Robinhood Chain Testnet (chain 46630), paid 1.000000 official test USDG to a synthetic vendor, and verified a mined rejected duplicate from another executor using a fresh owner-approved nonce. The vendor received exactly one payment; the second nonce remained unused. Evidence: <a href="https://hackathon.pocketplay.win/proofs/invoicefence/">https://hackathon.pocketplay.win/proofs/invoicefence/</a> . OpenAI Codex assisted research, implementation, tests, interface and documentation; Remotion composes real recordings and synthetic narration. No production savings or external customer validation is claimed.</p>
<p>Independently built hackathon prototype. No external funding, investment, revenue or customer traction is claimed in this submission.</p>
