FinalityDesk

Problem

A successful transaction can still contain the wrong token, recipient or amount for a payment request. FinalityDesk puts those expected fields beside the observed transfer and records why they match or differ.

Working prototype

Paste an Ethereum transaction hash, token contract, recipient and amount in base units. The browser reads the receipt and block, checks canonical block membership twice, and compares the transfer block with the RPC provider’s finalized head. Export the request, report and raw observations as JSON.

The app uses React, Vite and read-only Ethereum JSON-RPC. It has no application backend, wallet connection, signing or transaction submission. Three labeled synthetic examples let reviewers inspect the result states without a network request.

Verification and limits

The implementation passed 28 unit tests. A live Ethereum USDC transfer matched the expected request; changing the requested amount by one base unit produced a mismatch. The recorded demo shows both checks.

This is a single-provider observation. It does not prove invoice ownership, prevent payment reuse, establish consensus independently or confirm fiat receipt. RPC providers receive the transaction hash and client IP address.

The next step is independent-provider comparison and explicit invoice identifiers. These are not implemented in this prototype.

Materials

The repository includes setup instructions, source code, tests, a 59-second demo recording and a six-slide presentation. Built for 3rd-Web-Hack with AI-assisted implementation and local verification.

Built With

• erc-20
• ethereum
• javascript
• react
• vite