How discovery connects to a Bulla transaction

Agent A does not query Bulla for the world's agents. It queries one or more discovery sources. Bulla treats the returned listings as advertisements, binds the selected offer to exact terms, and checks the evidence delivered afterward.

Discovery flow

1. Agent A searches one or more catalogs.
2. The catalogs return candidate cards or listings.
3. Agent A fixes the job, price ceiling, and evidence requirements.
4. Providers return signed offers or existing signed listings.
5. Agent A applies its own policy to the supplied candidates.
6. The selected provider accepts exact transaction terms.
7. Delivery and evidence arrive.
8. Bulla retains and checks the resulting transaction.

Transaction stages

1. The buyer signs one closed request before discovery.
2. Provider-signed listings arrive through replaceable index snapshots.
3. The buyer issues a request-bound nonce; each provider signs a response with its listing key.
4. The buyer policy recomputes route eligibility over the normalized union.
5. The selected provider accepts a term root that commits the exact request and selected listing.
6. Delivered evidence is verified through the existing inference-clearing profile.
7. The retained bundle is checked offline after every market process exits.

Qualification rule

A candidate is eligible to route only when its signature, service, schemas, checkpoint freshness, price, promised evidence class, listing-key challenge, transport, and buyer context pass. The buyer's fixed rule selects the lowest price among eligible candidates, with the canonical listing commitment as the tie-breaker. Index order is ignored.

Route eligibility permits an attempt only. It is not reliance, payment eligibility, settlement authorization, or settlement execution.

Layer boundary

Replaceable discovery sources

A buyer could obtain candidates from A2A Agent Cards, the MCP Registry, x402 Bazaar, ERC-8004 registries, or a private enterprise catalog. These systems can provide discovery, naming, identity, reputation, validation, or paid-service metadata. They do not replace the buyer's acceptance rule for one transaction.

This demonstration uses two synthetic catalogs and fixed-price listings. It does not query a live registry, run an auction, or implement an MCP, A2A, x402, or ERC-8004 adapter. Request-for-quote and dynamic bidding are possible future market patterns, not features of this profile.

Reproduce

python3 -m venv .inference-market-venv
.inference-market-venv/bin/python -m pip install './bulla[identity]'
PYTHONPATH=bulla/src .inference-market-venv/bin/python bulla/examples/inference-market/run_demo.py --story --out market-run
.inference-market-venv/bin/python -I bulla/spec/inference-market/check.py market-run/transaction --context market-run/context.json
node bulla/spec/inference-market/check.mjs market-run/transaction --context market-run/context.json

The runtime accepts one fixed synthetic task, starts separately keyed loopback processes, binds their signed artifact commitments to the retained bundle, terminates them, and blocks Python socket creation during the final check. OS-level network isolation and real payment are not established.

Evidence

• Human-visible checked projection
• Python/Node expected report
• Project-authored process-exit and offline-run report
• Public byte manifest
• Transaction core
• Separately supplied buyer context

Return to the demonstration.