The problem Only Trust solves

The problem

Freelancers and clients in the gig economy have no shared trust layer:

• Fake portfolios — clients can't verify whether a GitHub repo, CV, or
  LinkedIn profile actually reflects the freelancer's real work, especially
  now that AI makes fabricated portfolios trivial to produce.
• Payment risk on both sides — freelancers fear finishing work and never
  getting paid; clients fear paying upfront and getting nothing back. Neither
  side wants to go first.
• Fragmented reputation — a freelancer's track record is scattered
  across GitHub, LinkedIn, Behance, and past clients' memory, with no single
  verifiable source of truth a new client can check.

How Only Trust solves it

Only Trust is an AI-powered trust protocol for the gig economy — it verifies
who you are, holds payment safely, and records your track record on-chain.

• AI-verified profiles — cross-checks GitHub activity, CVs, and other
  submitted evidence for consistency and produces a Truth Score, instead of
  taking a resume at face value.
• Escrow-based payment — a client funds a job upfront into a smart
  contract. Funds release automatically once milestones are confirmed, so
  neither party has to trust the other directly — the contract enforces it.
• On-chain, non-transferable reputation — every completed job updates a
  worker's on-chain record (completion rate, skills, trust score), giving
  clients a single, tamper-proof profile to check instead of five scattered
  ones.
• AI dispute assistant — if something goes wrong, both sides submit
  evidence and an AI assistant gives a neutral read of the situation to help
  resolve it faster, without replacing human judgment.

Who can use it

• Freelancers / gig workers who want proof of their real track record
  and a guarantee they'll get paid for completed work.
• Clients / SMEs who want to hire with confidence without personally
  vetting every applicant's history.
• Other freelance platforms — Only Trust is built as an open protocol,
  so existing marketplaces can plug into its escrow and reputation layer
  instead of building their own trust infrastructure from scratch.

Challenges we ran into

Learning Sui's object-ownership model under time pressure

Neither of us had written Move before. The hardest part wasn't syntax — it was
Sui's object model (owned vs shared objects, who can mutate what), which is a
different mental model from typical account-based chains. Letting AI generate
the full escrow contract on day one would have produced code we couldn't debug
when it broke. We got over this by writing a plain "Hello World" Move contract
by hand first, deploying it to testnet, and only bringing AI assistance in
once we understood object ownership well enough to read and reason about the
generated job_escrow.move and reputation.move ourselves.

No documented way to retrieve a Gonka request ID

The AI for Society track requires showing a Gonka request ID as part of the
verification trail, but the official Gonka Router workshop material never
actually documents a field with that name — it only covers a third-party
SaaS wrapper's own debug trace ID, which is a different thing entirely. We
resolved this by testing empirically: logging the full response headers from
a real Gonka API call and confirming which header actually carries a usable
request/trace identifier, rather than continuing to search documentation that
didn't have the answer.

Catching scope drift before submission

Running a full pre-submission audit of the README against the actual codebase
surfaced two problems that would have been caught immediately by a judge: the
tech stack section listed the wrong AI provider (an earlier draft, not the
model we actually integrated), and zkLogin was mentioned in three places
despite never being implemented. We fixed this by rewriting those sections to
match the real feature set exactly, and moving anything unbuilt into an
explicit "Future work" section instead of implying it already existed.