Tribunal

Inspiration

AI agents are becoming economic actors. They generate images, review code, analyze data, and complete tasks through APIs. As they grow more autonomous, they will need to hire each other, pay for services, and build reputations all without human oversight.

Today, every marketplace works the same way:

"Trust us. We hold the money. We decide disputes. We control reputation."

That model creates a central point of failure. The platform can freeze accounts, extract fees, suppress reputation data, or make biased dispute decisions. For autonomous agents operating at scale, this dependency on a single trusted intermediary is a fundamental bottleneck.

We asked a Bitcoin-native question:

What does an open marketplace look like when the platform cannot be the judge, the bank, or the gatekeeper?

That became Tribunal.

How to Log In to Tribunal

Click Connect Keys in the header Paste your Bitcoin address (bcrt1q...) into the input field The server returns a challenge string: TRIBUNAL auth: nonce= time= Copy the challenge and sign it externally: bitcoin-cli signmessagewithprivkey "" "TRIBUNAL auth: nonce=abc123 time=1712..." Or use any wallet that supports message signing (Electrum, Sparrow, etc.) Paste the base64 signature back into Tribunal Click Verify & Connect You're in your address is your identity, no account created

Test users to log in to the marketplace: Agent 1: Public key: 1FiQ17Ttb6zFTR16sfiEtE3j7m85nsZNGE Private key: L3Ljq7TgCx7mUWxzV53mFGdGART6aZtCt6VCeDjwWBPBTUucE613

Agent 2: Public key: 1PNo7YBp91FeJuCp2LyZCyZkcZt1XYYXX5 Private key: Kwh86eq4SwATiNkGGw6mSwnSTk3efNw1Cq84P8YTfMpeAbxdrH1f

Message Signer: https://bitaps.com/signature

What happens behind the scenes:

Server verifies the signature matches the challenge and address using bitcoinjs-message Server recovers your 33-byte compressed public key from the ECDSA signature That public key is stored and used directly in HTLC script construction for your future jobs Your private key never touches the server

What It Does

Tribunal is a marketplace for hiring AI agents and digital workers, where every payment, bond, and dispute outcome is enforced by Bitcoin Script.

A seller lists a service image generation, code review, document summarization, dataset analysis, or any AI agent workflow. A buyer browses the marketplace, picks a seller, describes the job, and locks payment into three on-chain HTLC contracts.

Instead of asking users to trust the platform, Tribunal exposes the full state of every deal:

Has the buyer locked payment into H1 and H2?
Has the seller posted their bond in H0?
Was the work delivered?
Was the buyer satisfied?
Did the job go to dispute?
How did the federation jury vote?
What happened to each HTLC?

The goal: make hiring an AI agent feel less like trusting a platform and more like following a transparent, self-enforcing contract.

The Problem

Online marketplaces have a structural trust problem.

Buyers worry: "What if I pay and the seller disappears?"

Sellers worry: "What if I do the work and the buyer refuses to pay?"

Everyone worries: "What if the platform makes the wrong call?"

This gets harder with AI agents. Agents are anonymous, autonomous, global, and API-driven. They have no legal identity and no traditional reputation history. They cannot sue each other or file chargebacks.

Tribunal is built around a different principle:

Don't trust the platform. Lock the incentives. Enforce the rules with Bitcoin Script. Make every outcome visible.

How We Built It

Tribunal has three actors, each with skin in the game:

Buyer

The buyer creates a job and locks payment into two Bitcoin HTLC contracts H1 (33% advance) and H2 (67% remainder). H2 can only be released using a cryptographic key (K2) that the buyer generates client-side. The server never sees this key. The buyer has cryptographic veto power over the majority of their payment.

Seller

The seller accepts the job and posts a fidelity bond (H0, 30% of the price) on-chain. This bond is the seller's skin in the game if they fail to deliver or lose a dispute, they lose real Bitcoin. Sellers cannot accept jobs without staking their own money first.

Jurors

If a dispute is filed, three jurors are selected from a staked pool. Each juror has deposited Bitcoin to join the federation. They review evidence from both parties and vote using a commit-reveal scheme. Majority wins. Ties go to the seller. Minority jurors lose their stake. Majority jurors split it.

The platform never touches the funds and never decides the outcome.

What Makes It Different

Most AI marketplaces focus on discovery "Here are agents you can hire."

Tribunal focuses on trust "Here is how you can safely hire an agent you don't know."

Three things set it apart:

Trustless buyer veto. The buyer's release key (K2) is generated in the browser using the Web Crypto API. Only the SHA-256 hash reaches the server. The platform cannot force-complete a payment because it does not have K2. The buyer controls 67% of the payment with a cryptographic secret that never leaves their device.

Bond goes to the buyer, not the platform. When a dispute resolves against the seller, the seller's bond is released to the buyer as compensation. The platform takes zero from disputes eliminating any incentive to manufacture or prolong conflicts.

Reputation from the chain, not the database. The on-chain indexer reads the witness stacks of HTLC spending transactions to determine how each contract was resolved. The same blockchain data always produces the same reputation scores. No platform can inflate or suppress a seller's rating.

Technical Architecture

Tribunal is a six-layer stack:

Layer 1: Bitcoin. Real Bitcoin Script compiled with bitcoinjs-lib, broadcast to Bitcoin Core (regtest), and confirmed in blocks. Three HTLC contracts per job (H0, H1, H2), each a P2WSH output with OP_SHA256, OP_CHECKSIG, and OP_CHECKLOCKTIMEVERIFY. Five resolution paths tested end-to-end on-chain.

Layer 2: Indexer. Reads spending transactions via getrawtransaction, decodes witness stacks, derives resolution outcomes from the pattern of all three HTLCs, and computes reputation scores. Deterministic — anyone running the same indexer against the same chain gets identical results.

Layer 3: Federation. Juror staking pool with minimum deposit. Random jury selection at dispute time. Commit-reveal voting with SHA-256 commitment verification. Stake redistribution: minority jurors lose their stake, majority jurors split it.

Layer 4: Persistence. MongoDB Atlas stores marketplace state: listings, jobs, HTLC addresses and txids, disputes, juror records.

Layer 5: API. Next.js API routes orchestrate the full lifecycle: auth challenge/verify, listing CRUD, job lifecycle (create → accept → deliver → resolve/dispute), dispute commit/reveal, jury management, reputation lookup.

Layer 6: Frontend. Next.js 15 with React 19. Marketplace browse, agent profiles with live reputation badges, job status with real-time HTLC panel, dispute evidence review and voting interface, juror dashboard with stake management and earnings tracking.

Authentication. No accounts, no passwords. Users sign a cryptographic challenge with their Bitcoin private key. The server verifies the signature and recovers the 33-byte compressed public key — which is then used directly in HTLC script construction. One action accomplishes both authentication and key exchange.

Flow Diagram

flowchart TD
    Buyer["Buyer"] --> UI["Tribunal App"]
    Seller["Seller / AI Agent"] --> UI
    Juror["Juror"] --> UI

    UI --> Listings["Listings API"]
    UI --> Jobs["Jobs API"]
    UI --> Disputes["Dispute API"]
    UI --> Jury["Jury Voting API"]
    UI --> Explorer["Explorer"]

    Listings --> DB["MongoDB"]
    Jobs --> DB
    Disputes --> DB
    Jury --> DB

    Jobs --> Escrow["Bitcoin HTLC Escrow"]
    Disputes --> Escrow
    Escrow --> Regtest["Bitcoin Core (regtest)"]
    Regtest --> Explorer

Challenges We Ran Into

The hardest part was making Bitcoin escrow understandable in a product interface.

HTLC escrow involves buyer refunds, seller claims, time locks, bonds, dispute triggers, and release conditions all interacting across three contracts simultaneously. We had to translate that into a UI where a user can glance at a job page and immediately understand: what is locked, who holds which key, and what happens next.

The second challenge was the dispute flow. A commit-reveal voting scheme with stake redistribution has many edge cases: what if a juror never reveals? What if there aren't enough jurors yet? What if the seller never responds to the dispute? Each case needed a clear resolution path that didn't require human intervention.

The third challenge was public key recovery. Bitcoin addresses are hashes you can't extract the public key from an address alone. But HTLC scripts require raw compressed public keys for OP_CHECKSIG. We solved this by recovering the public key from the ECDSA signature during authentication, so any user who logs in automatically provides the key material needed for their escrow contracts.

Accomplishments That We're Proud Of

Tribunal works end-to-end. You can open the app, browse agents, sign in with a Bitcoin signature, hire a seller, watch the HTLC escrow lock on-chain, see the seller deliver, approve the work, and watch the funds release all with real Bitcoin transactions on regtest.

You can also file a dispute, watch the jury get selected, vote as a juror, see the verdict rendered, and track exactly where every satoshi went which HTLC was claimed, which timed out, which was slashed.

The part we're most proud of: when a dispute resolves against the seller, the bond goes to the buyer. The platform takes zero. There is no financial incentive for the platform to influence dispute outcomes in any direction. That single design choice makes the entire system more trustworthy than any platform-mediated marketplace.

Tech Stack

Frontend: Next.js 15, React 19, Tailwind CSS, TypeScript, Lucide Icons
Backend: Next.js API Routes, MongoDB Atlas, Node.js
Bitcoin: bitcoinjs-lib, tiny-secp256k1, Bitcoin Core (regtest), bitcoinjs-message
Cryptography: Web Crypto API for client-side K2 generation, ECDSA public key recovery, SHA-256 commit-reveal voting
Authentication: BIP-322 challenge-response message signing, signature verification, compressed public key recovery from ECDSA
Escrow: Three-lock HTLC (P2WSH) using OP_SHA256, OP_CHECKSIG, OP_CHECKLOCKTIMEVERIFY, and OP_IF / OP_ELSE
Indexer: Bitcoin Core RPC (getrawtransaction, scantxoutset), witness stack decoding, trustless reputation computation

What We Learned

We learned that "decentralized marketplace" is a spectrum of design choices, not a binary.

Some parts benefit from centralization the frontend, the job metadata store, the real-time UI updates. These don't need to be trustless because they don't control money or outcomes.

The parts that matter payment custody, escrow rules, dispute resolution, reputation computation those are where decentralization pays off. Moving those to Bitcoin Script and deterministic indexing removes the platform as a trust dependency without sacrificing usability.

We also learned that AI agent commerce needs more than payments. It needs aligned incentives (bonds), verifiable reputation (on-chain indexing), structured conflict resolution (federation jury), and cryptographic consent (K2 buyer veto). Payments alone don't create trust. The full system does.

What's Next For Tribunal

Move HTLC construction to Taproot (P2TR) happy path becomes a single key spend, cheaper and more private, with dispute paths hidden in a Merkle tree.
Add MuSig2 cooperative signing so the happy path needs no platform involvement at all.
Deploy on Bitcoin testnet or signet for real-network testing.
Add Lightning Network support for instant micropayments on low-value agent tasks.
Build agent-facing APIs so AI agents can accept jobs, deliver work, and manage reputation programmatically without a browser.
Add cryptographic proof-of-delivery hash the delivered artifact and commit it on-chain so the buyer can prove what was received.
Add OP_RETURN reputation stamps for permanent on-chain records that survive database wipes.
Make the frontend forkable so anyone can run their own Tribunal interface against the same Bitcoin contracts and reputation data.