Fira
February 2026
Overview
A merged pull request says that code changed. It does not prove that a freelance milestone was delivered, that the deployed product works, or that payment should be released.
That gap became the idea behind Fira. Four of us arrived at it after workshopping several directions for HackEurope Dublin, where we entered Paid.ai’s Agentic AI track. AI verification of freelance work felt underexplored: most platforms arbitrate trust through reputation, manual disputes, and platform control. We wanted the work itself to become the evidence.
In 22 hours we built a contract platform where agents inspect GitHub and the deployed product, decide whether each deliverable is complete, and assemble their findings into a report. A second model reviews those verdicts before a separately implemented Solana payment layer can release escrow. I owned the verification agents, the review and report pipeline, the Solana backend, and the demo tooling.
The verification loop
A contract links to a GitHub repository and breaks its work into milestones, each backed by concrete deliverables. Starting verification fans those deliverables out through asyncio.gather, so every issue is checked in parallel rather than waiting for one general agent to work through the entire contract.
Each agent receives its own Patchright browser page and a focused toolset. GitHub tools let it list files and read repository contents. Browser tools let it navigate, inspect text and elements, fill forms, click controls, capture screenshots, and exercise the live Vercel deployment. The agent returns a delivered or not-delivered verdict with the evidence that led there.
For the final demonstration we triggered this loop manually. A teammate also built an ML system that estimated the probability of on-time completion from GitHub activity and could start verification automatically, but the manual path gave us a controlled baseline for judging.
Evidence, not confidence
The first model was never allowed to be the final authority. Gemini agents could read code and use the product, but a plausible verdict is still not proof. Every agent therefore produced a trace of claims, screenshots, repository evidence, and reasoning rather than returning a bare boolean.
Once the parallel checks finished, a Claude review step read all of those traces together. It could override an individual approval when the evidence did not support it, then build one structured ReportDocument from the surviving verdicts. The report was persisted to Supabase and became the boundary between verification and payment.
That separation was the part I cared about most. The system did not ask one model to be both investigator and judge. One layer gathered evidence against individual deliverables; another challenged the conclusions across the whole milestone.
Payment needs a receipt
The payment layer used a custodial escrow wallet on Solana devnet. An approved milestone produced a real transfer instruction alongside a Memo instruction containing both the milestone and report identifiers. The payment endpoint refused to release funds without a verification report and stored the resulting transaction signature to prevent a milestone being paid twice.
It was deliberately not presented as a smart contract. The server held the escrow key and submitted a normal devnet transaction. That was enough to prove the chain from evidence to an auditable payment receipt without pretending the prototype had production-grade decentralized custody.
The Solana layer worked independently, but we did not connect it to the judging demo before the deadline. The demonstrated path ended at the report.
Four systems in parallel
The team split into clear workstreams. One teammate built almost the entire Next.js interface. Another built the FastAPI CRUD and frontend-facing integration layer, including the Vercel and GitHub plumbing. A third built the original ML trigger and risk model. I built the verification pipeline and payment backend, then extended the trigger integration and pulled the demo path together.
Every stream was useful. The problem was sequencing. A few hours before the deadline, we had an agent system, an ML trigger, a UI and API, and a payment layer, but not one dependable path through all of them. Integration consumed the time we had expected to spend testing and shaping the presentation.
We narrowed the demo to the strongest complete slice: trigger verification, inspect the repository and deployment in parallel, review the evidence, and generate the report. The automatic trigger and devnet payment stayed outside the live path.
Two minutes, three times
HackEurope’s judging format made presentation time unusually tight. Company judges were assigned groups of tables and moved through them one by one. Three different companies judged Fira, each in a separate two-minute round, and there was no guarantee that the judge represented a challenge we had entered.
Each teammate presented their own subsystem with roughly equal time. I showed the verification agents through the recorded run above. A live execution would have spent most of my slot waiting for browsers and models; the video let every judge see the same evidence collection and report flow in seconds.
The judges asked questions but gave no concrete feedback, and we did not place. I cannot claim the presentation caused the result. I can say that discovering our integration problem so late left us without enough time to make a complicated system feel simple.
What I would change
I would keep the technical centre of Fira: parallel agents that inspect both code and behaviour, followed by an independent evidence review. I would change the order in which we built around it.
The first checkpoint would be a thin manual path from one deliverable to one report. Only after that worked through the real UI and API would I add automatic triggering, broader contract management, and payment. The lesson was not that any teammate’s system should not have existed. It was that independently valuable systems need an integrated baseline early enough for the product story to catch up with the engineering.
