BRIJ Travel

A flight marketplace where the buyer can be a human or an AI agent, payment is USDC on Solana, and settlement is an on-chain escrow that releases only when the airline has actually issued your ticket.

Three ideas define the system:

Pay-per-call, no accounts. The agent API is priced with x402: every paid endpoint answers 402 Payment Required with an exact USDC price, the caller pays, the call executes. A wallet is the only identity.
Escrow, not merchant custody. Your booking money goes into a per-order on-chain escrow — not to us. It is captured only when your ticket exists, and every other outcome refunds it in full, automatically.
An open fulfiller network. Behind one search, multiple fulfillers compete: an airline-API tier and a browser-automation tier running reviewed, pinned recipes. The execution layer is designed to accept external authors, paid per settled booking.

How money moves

Every booking runs through one on-chain order on the bounty escrow program (64B7SUp3…fuCR, Solana mainnet):

Intent. You pick an offer and create a booking intent. The marketplace initializes the order on-chain: an escrow account and a USDC vault, with your refund wallet frozen into it at creation.
Fund. You transfer the quoted USDC amount (ticket + fee) into the vault. This is the only transfer you ever sign.
Claim. The fulfiller claims the order with its own deposit at stake (double escrow: the maker funds the job, the taker posts skin in the game).
Execute. The fulfiller books with the supplier. Its own card fronts the supplier payment — your USDC stays locked.
Settle. When the ticket oracle confirms the ticket was issued, the escrow captures: proceeds to the fulfiller, fee to the platform, deposit back to the taker. If no ticket materializes, the escrow refunds to your wallet — automatically.

The guarantee: you are charged only once the ticket actually exists. A failed booking, a supplier cancellation, a price change, a timeout — every one of those ends in a full automatic refund to the refund wallet fixed at intent creation. There is no path where the money is simply lost, and no one — including us — can redirect a refund.

The two fulfiller tiers

	`fastbooking:`	`lowcost:`
Inventory	Direct airline API	Low-cost carriers via browser automation on the supplier's own site
Search latency	~2–5 s (synchronous)	~15–40 s (streams into the same search)
Fare menus	Included fare data	Live drill-down of the supplier's own fare menu (`/air/offer-details`)
Ticket proof	API order status	DKIM-authenticated ticket email from the supplier
PNR	Minutes, via `GET /air/orders`	When the supplier issues it (can take hours), delivered by email

One search covers both: the response returns the fast tier synchronously and keeps enriching through the free POST /air/search-updates poll while the browser tier streams its quotes. The same physical flight offered by both tiers is collapsed into one result, cheapest first.

The ticket oracle

For browser-tier bookings, the only event that moves money is the supplier's own ticket email. Each order gets a dedicated inbound address (o-<id>@bookings.brij.fi) used as the booking contact; the supplier's confirmation routes back through Cloudflare Email Routing to the marketplace, which authenticates it on the DKIM-signed domain only — the d= of a signature that actually verified, aligned to the supplier's domain. Not the From header, not a forwarded copy, not a bare dkim=pass. A "ticket issued" email captures the escrow and emails the customer their PNR; a cancellation or payment-failure email refunds; silence refunds at the 24-hour hold. The fulfiller's own declaration never settles anything.

Security model

Escrow over custody: funds live in per-order on-chain vaults; the refund wallet is frozen at creation and timeout refunds are permissionless — nobody can freeze or redirect buyer money, including us.
Oracle over declarations: money moves on cryptographically authenticated supplier evidence, never on anyone's say-so.
Isolated execution: recipes run sandboxed with the least privilege they need; external recipes are additionally restricted to dry mode.
Compliance screening runs before any payment is accepted.
PII is used for the booking only, retained briefly, and never exposed to recipe authors.

Public surfaces

URL	What
travel.brij.fi	The agent-facing API + this documentation
app.brij.fi	The human web app
/openapi.json	Full API schema (x402 prices included)
/bounties	Every settlement order, verifiable on Solscan
/fulfillers	The fulfiller network with its settlement funnel
/recipes	The pinned recipe catalog + stats (JSON)
recipe-spec	The recipe contract: signals, SDK, conformance suite

Affiliation

Bring bookings, earn a share of the fee. POST /affiliates {wallet} (free) returns your code and link (app.brij.fi/?ref=<code>); agents can pass referrer at intent creation instead. You earn 20% of the platform fee on every referred booking — earned when the booking captures (the ticket actually issued) and vested only once the journey has been flown with no refund issued, so there is never anything to claw back. Your statement is public and self-serve: GET /affiliates/{code}. Payouts are periodic USDC transfers to your wallet once the balance clears the minimum. Self-referral earns nothing. Humans: the same thing without curl at app.brij.fi/affiliates.

FAQ

When exactly am I charged?

Your USDC leaves the escrow only at capture — which requires the ticket to be issued (API-verified for fastbooking, DKIM-verified supplier email for lowcost). Everything else refunds automatically, in full.

What if the price changes between search and booking?

The booking fails cleanly and refunds. We never book at a price above what you engaged — the fulfiller executes under a strict price cap.

Why did my displayed total differ from the fare price?

All displayed prices include the 10% booking fee. Your wallet quotes the exact escrow amount before you sign — that number is the authority.

Where is my PNR?

Fastbooking: GET /air/orders/{order_id} with your support code, minutes after booking. Lowcost: emailed to you the moment the supplier issues the ticket — usually under an hour, occasionally several.

Can I book for someone else? Multiple passengers?

Yes. /air/book takes the full passenger list (lead first — the lead receives the emails and authenticates refund requests). Offers are priced per passenger count at search time.

What does it cost to run a fulfiller or author a recipe?

Submitting a recipe costs 1 USDC per review. Claiming an order stakes the taker deposit, returned at settlement. Run costs (browser minutes, model tokens) are yours — speed is money. Payment is per settled booking.