TxMatch

TxMatch verifies whether an AI agent’s proposed blockchain transaction actually matches what the agent said it would do—before a human approves it.

Comment

Inspiration

AI agents are becoming capable of preparing blockchain transactions for human approval. That creates a simple trust problem: the same agent that creates a transaction may also be the one explaining what that transaction is supposed to do.

This led to the core question behind TxMatch:

Does the transaction actually match what the AI agent said?

What it does

TxMatch is an independent semantic checkpoint between an AI agent and the human approving its proposed blockchain transaction.

It independently decodes the unsigned EVM transaction, builds grounded transaction facts, and compares those facts against the agent's stated natural-language intent.

The result is a clear MATCH, MISMATCH, or UNVERIFIABLE report with supporting evidence before the human approves.

For example, an agent may say: "Swap 1,000 USDC for ETH on Uniswap V3 and send the output to my designated wallet." The transaction may correctly use Uniswap and swap the correct amount, but send the output to another wallet. TxMatch would flag the destination as a semantic MISMATCH.

How we built it

For Stage 1, I designed the MVP around one principle:

Blockchain facts first → semantic reasoning second → deterministic aggregation last.

The planned pipeline is:

Agent intent + unsigned transaction → calldata decoding → grounded transaction facts → semantic comparison → MATCH / MISMATCH / UNVERIFIABLE → human approval.

The planned stack includes JavaScript, Node.js, Express, viem, Sepolia, local verified ABIs with Sourcify/4byte fallbacks, and a provider-independent LLM API.

The LLM is not treated as the source of blockchain truth. It only compares natural-language intent against facts established first.

I also used ChatGPT and Claude Code extensively for research, prior-art analysis, technical design, writing, and visual iteration. I directed the scope, evaluated the alternatives, reviewed the outputs, and take responsibility for the final project decisions.

Challenges we ran into

The biggest challenge was finding a problem that was both meaningful and sufficiently differentiated from existing Web3 tools.

I explored several directions, including payments, DAO governance verification, and AI-agent transaction safety. Some promising ideas were rejected after finding strong existing solutions or direct prior art.

Another challenge was separating transaction security from intent fidelity. A transaction can be technically valid and contain no obvious malicious indicator, yet still fail to perform what the agent told the human it would do.

That distinction became the core of TxMatch.

Accomplishments that we're proud of

I am proud that the project was narrowed down through research rather than simply choosing the first idea that sounded interesting.

For Stage 1, I completed:

  • prior-art and competitor research
  • the final product definition
  • MVP technical architecture
  • MATCH and MISMATCH demo scenarios
  • transaction approval UI mockups
  • a scoped implementation plan

The MVP is intentionally small enough to build and explain during the hackathon.

What we learned

This is my first hackathon, and I am still early in learning blockchain development.

Through TxMatch, I learned more about EVM transactions, calldata, ABI decoding, token approvals, AI-agent approval workflows, deterministic versus semantic verification, and the importance of researching existing solutions before building.

I also learned that using AI tools effectively still requires making product decisions, challenging generated answers, controlling scope, and understanding the system well enough to explain it.

What's next for TxMatch

If shortlisted, the next step is to build the functional MVP:

intent → unsigned transaction → calldata decoding → grounded facts → semantic comparison → verdict → human approval

The prototype will initially support one EVM testnet and one transaction at a time.

It will not handle private keys, custody, signing, broadcasting, or real funds.

If the core workflow is reliable, transaction simulation and real agent/wallet integrations can be explored later.

Built With

Share this project:

Updates

Submission history