agents-marketplace/prompts/marketplace-buyer-pair.md

Marketplace Buyer Pair — Two-Agent Exercise

A paired prompt for running the agents-marketplace from the buyer side on Vector L2 testnet. Hand each section below to a separate agent run.

• Agent A — Successful User completes the happy-path lifecycle (PostEscrow → Accept) cleanly.
• Agent B — Adversary Buyer probes defenses across four attack styles (within-protocol cheating, protocol-fuzzing, liveness/DoS, social/spec).

Each agent's prompt below is self-contained — copy from the ═══ BEGIN AGENT … PROMPT ═══ line through ═══ END AGENT … PROMPT ═══ and paste. The two prompts share a header (Marketplace primer, target config, hard caps); if you edit the target advert ref or endpoint, update both sections.

Operator note: testnet AP3X only. Never reuse mainnet keys. Both agents must log every tx hash, escrow ref, HTTP status, and response body — that's the evidence trail.

---

Agent A — Successful User

═══ BEGIN AGENT A PROMPT ═══

You are a buyer using the agents-marketplace on Vector L2 testnet. Your job: get a useful LLM completion from a supplier and pay them for it correctly. Demonstrate that the marketplace works end-to-end.

Marketplace primer (read first)

Buyers post on-chain escrow against a supplier's on-chain advert; the supplier claims the escrow, runs inference locally, submits a signed receipt on chain, and the buyer accepts. Symmetric 1 AP3X bonds plus on-chain deadlines keep both sides honest.

Lifecycle (escrow state machine): Open → Claimed → Submitted → {Accepted | Released} | Reclaimed.

The seven lifecycle tx names — all defined in packages/shared/src/tx/:

• PostAdvert, Retire (supplier-side, advert lifecycle)
• PostEscrow, Claim, Submit, Accept, Reclaim, Release (escrow lifecycle)

Key invariants:

• advert_ref in the escrow datum spec-locks the escrow to a specific advert UTxO (price, capability, model can't be swapped mid-flight).
• deliver_by = posted_at + advert.max_processing_ms + NETWORK_BUFFER_MS(30_000).
• ACCEPT_WINDOW_MS = 600_000 (10 min). After submitted_at + ACCEPT_WINDOW the supplier can Release and take both bonds + payment.
• prompt_hash = sha256(canonical(messages)); request_spec_hash = sha256(canonical(envelope)). Supplier recomputes both and rejects mismatches at supplier/src/routes/chat.ts.
• Receipt is Ed25519-signed by supplier's pkh.

Target supplier (testnet)

Primary:

• Endpoint: https://supplier.summitstak.ing
• Supplier pkh: 8e93e53214eb778fa71beadc4914ad1961ece1d71710f5e597e9494a
• Active advert ref: 386d30fdc3e69c5a7063b9bb99a6ea3e2bee79498c16a22cf3a9c74a4a004040#0
• Capability: llm.text.generate.v1, model qwen3.6:35b, price 2 AP3X, max_output_tokens 2048, max_processing_ms 60000

Backup (run by the Vector / Apex Fusion team — not the operator of this exercise):

• mp-suppliers.vector.testnet.apexfusion.org

Indexer (read-only chain view):

• GET /suppliers, GET /capabilities, GET /escrows/{ref}, GET /events?stream=1 (SSE)

Buyer surface

Pick whichever fits the tools you have. The SDK is the easy path; CLI plus raw HTTP works if you want lower-level control.

• Buyer SDK in buyer/src/sdk/Marketplace.ts:
  • Marketplace.discoverSuppliers(opts?)
  • Marketplace.submitPrompt({advertRef, messages, …}) — runs the full lifecycle except Accept
  • Marketplace.acceptResult({escrowRef}) — builds & submits Accept
• CLI:
  • pnpm --filter @marketplace/buyer tx:accept --escrow-ref <txHash>#<ix>
• Direct HTTP to supplier:
  • POST https://supplier.summitstak.ing/v1/chat/completions with header X-Escrow-Ref: <txHash>#<ix> and OpenAI-compatible JSON body.

Hard caps (must respect)

• Testnet AP3X only.
• Maximum 5 escrows posted across this whole run.
• Maximum 2 AP3X locked per escrow (the advertised price). Never inflate.
• Always log: every tx hash, every escrow ref, every HTTP response code and body.
• If the supplier endpoint returns 5xx three times in a row, pause 60s and try once more before reporting failure.

Steps

1. Discover the supplier: GET <indexer>/suppliers, or use the target advert ref directly. Confirm advert.status == "Active" and advert.price_lovelace matches the 2 AP3X you expect.
2. Compose a small prompt — e.g. [{role: "user", content: "Summarize the Cardano EUTxO model in 3 bullets."}]. Compute prompt_hash over the canonicalized messages.
3. PostEscrow referencing advert_ref, locking price + 1 AP3X buyer bond. Capture the result as escrow_ref = txHash#ix. Wait for chain confirmation (poll indexer GET /escrows/{ref} or subscribe to /events?stream=1).
4. POST <supplier>/v1/chat/completions with header X-Escrow-Ref: <escrow_ref> and the OpenAI-compatible body matching the prompt you committed to.
5. Wait for the supplier to Claim then Submit on chain. Save both tx hashes from the indexer.
6. Verify the response payload: check that receipt.prompt_hash matches what you computed, that receipt.response_hash matches sha256(canonical(choices)), and that receipt_signature verifies against the supplier's pkh.
7. Accept: call Marketplace.acceptResult({escrowRef}) or run pnpm --filter @marketplace/buyer tx:accept --escrow-ref <ref>. Capture the Accept tx hash.
8. Confirm settlement: payment + supplier bond went to supplier, your buyer bond returned. Your wallet's net delta should be exactly -price (≈ -2 AP3X plus fees).
9. Repeat steps 2-8 two more times with slightly different prompts to demonstrate stability.

Failure handling

• If the supplier hasn't Submitted by deliver_by (advert.max_processing_ms + 30s buffer + posted_at), run Reclaim. The buyer recovers payment + both bonds.
• Do not retry blindly. If a step fails, report which step, which tx/HTTP call, and the full error.

Report (final output)

Produce a markdown table with one row per cycle:

| Cycle | Prompt summary | PostEscrow tx | Claim tx | Submit tx | Accept tx | Wall-clock latency | Supplier wallclock_ms | Net wallet delta |

Then a short paragraph: anything surprising, any retries, any mismatch between expected and observed behavior.

═══ END AGENT A PROMPT ═══

---

Agent B — Adversary Buyer

═══ BEGIN AGENT B PROMPT ═══

You are a buyer running an adversarial assessment of the agents-marketplace on Vector L2 testnet. Your job: probe defenses across four attack styles and report concrete evidence — every tx hash, every HTTP response code and body, every log line. Finding one real gap is more valuable than completing the whole matrix; stop and report immediately when a defense fails.

Marketplace primer (read first)

Buyers post on-chain escrow against a supplier's on-chain advert; the supplier claims, runs inference, submits a signed receipt, the buyer accepts. Symmetric 1 AP3X bonds plus on-chain deadlines keep both sides honest.

Lifecycle (escrow state machine): Open → Claimed → Submitted → {Accepted | Released} | Reclaimed.

The seven lifecycle tx names — all defined in packages/shared/src/tx/:

• PostAdvert, Retire (supplier-side, advert lifecycle)
• PostEscrow, Claim, Submit, Accept, Reclaim, Release (escrow lifecycle)

Key invariants and defenses you will be probing:

• advert_ref in the escrow datum spec-locks the escrow (price/capability/model frozen at advert UTxO).
• deliver_by = posted_at + advert.max_processing_ms + NETWORK_BUFFER_MS(30_000).
• ACCEPT_WINDOW_MS = 600_000 (10 min). Buyer who skips Accept after Submit forfeits both bonds + payment via supplier-side Release.
• prompt_hash, request_spec_hash canonical-hashed at supplier/src/routes/chat.ts; mismatch → 4xx.
• All escrow datum integer fields are CBOR major type 0/1 (BigInt). Any FLOAT64 leak → script crash. (Prior history: AdvertDatum had this bug; EscrowDatum may or may not.)

Target supplier (testnet)

Primary:

• Endpoint: https://supplier.summitstak.ing
• Supplier pkh: 8e93e53214eb778fa71beadc4914ad1961ece1d71710f5e597e9494a
• Active advert ref: 386d30fdc3e69c5a7063b9bb99a6ea3e2bee79498c16a22cf3a9c74a4a004040#0
• Capability: llm.text.generate.v1, model qwen3.6:35b, price 2 AP3X, max_output_tokens 2048, max_processing_ms 60000

Backup (run by the Vector / Apex Fusion team — not the operator of this exercise):

• mp-suppliers.vector.testnet.apexfusion.org

Indexer (read-only chain view):

• GET /suppliers, GET /capabilities, GET /escrows/{ref}, GET /events?stream=1 (SSE)

Buyer surface

• Buyer SDK in buyer/src/sdk/Marketplace.ts: discoverSuppliers, submitPrompt, acceptResult.
• CLI: pnpm --filter @marketplace/buyer tx:accept --escrow-ref <…>.
• Direct HTTP: POST <supplier>/v1/chat/completions with header X-Escrow-Ref: <txHash>#<ix>.
• Raw tx-building: buildPostEscrowTx, buildReclaimTx, buildReleaseTx, etc., exported from @marketplace/shared/tx.

Hard caps (must respect — this is a safety-bounded probe, not a real attack)

• Testnet AP3X only.
• Maximum 10 escrows posted total. Maximum 2 AP3X locked per escrow.
• Total burn ceiling: 5 AP3X across failed-tx fees + forfeited bonds. If you would exceed this, stop and report.
• Rate cap: ≤ 2 requests per second to the supplier endpoint, ≤ 100 requests total.
• Single slow-loris socket attempt only — do not hold many sockets open.
• If the supplier endpoint returns 5xx three times in a row, pause 60s and drop your rate by half before continuing.
• Always log: tx hashes, HTTP method+URL+status+body excerpt (first 1KB), timestamps.
• Stop the moment any defense fails and report the gap — finding one real issue beats finishing the matrix.

Attack matrix

For each attempt, record:

• What you tried (concrete payload / tx / sequence)
• Expected defense (what should fire)
• What happened (response code, validator error, on-chain state, timing)
• Verdict — one of: BLOCKED (defense held), GAP (defense failed), UNCLEAR (need follow-up)
• Evidence — tx hash, response body excerpt, timestamp

A. Within-protocol cheating (buyer-side, syntactically valid)

• A1. Post an escrow, accept the supplier's receipt off-line, then never submit Accept. Wait ACCEPT_WINDOW_MS (10 min) past submitted_at. Expected: supplier calls Release and takes payment + both bonds. GAP = you recover any funds.
• A2. Build a Release tx yourself (as buyer) before submitted_at + ACCEPT_WINDOW. Expected: on-chain validator rejects (validity-lower-bound check, escrow.ak).
• A3. Post an escrow with deliver_by already in the past. Expected: build-time validator in buildPostEscrowTx rejects, or supplier refuses to Claim.
• A4. Post an escrow then immediately try Reclaim before deliver_by. Expected: validator rejects (state=Open but now < deliver_by).

B. Protocol-fuzzing (malformed datums, replay, double-spend)

• B1. Build a PostEscrow tx whose datum has capability_id not matching the advert (e.g. llm.text.generate.v2). Expected: supplier's chat.ts rejects with 4xx (capability mismatch).
• B2. PostEscrow with prompt_hash set to a value ≠ sha256(canonical(messages)) that you'll send. Expected: supplier rejects 400 with prompt_hash mismatch.
• B3. POST /v1/chat/completions with X-Escrow-Ref pointing at an escrow ref that doesn't exist on chain (random txHash#ix). Expected: 404 or 400.
• B4. Replay a previously-Accepted escrow ref in X-Escrow-Ref. Expected: supplier rejects (UTxO spent / state terminal).
• B5. PostEscrow paying strictly less than advert.price_lovelace. Expected: build-time price-equality check in postEscrow.ts rejects.
• B6. Construct a PostEscrow datum where one of the integer fields (deliver_by, posted_at, max_output_tokens) is encoded as CBOR FLOAT64 instead of major-type 0/1. (Use a hand-rolled CBOR encoder or patch cbor-x's number coercion.) Expected: Plutus validator rejects with unreachable / script crash. This mirrors the AdvertDatum bug pattern — verify whether EscrowDatum has the same defense.

C. Liveness / DoS (within hard caps)

• C1. Send a request body with messages totalling >100KB. Expected: 413 or 400 before LLM invocation.
• C2. Send max_output_tokens: 999999 in the request body. Expected: supplier clamps to advert.max_output_tokens=2048 or rejects 400.
• C3. Open one TCP connection and dribble bytes (slow-loris). Single attempt only. Expected: server timeout, connection closed.
• C4. Burst 50 requests at 2 rps with bogus X-Escrow-Ref headers. Expected: all 4xx; supplier stays responsive. Verify liveness mid-burst by issuing one valid happy-path probe (small honest escrow) in parallel; confirm it completes successfully.
• C5. Spam the indexer (GET /suppliers, GET /escrows/{ref}) at 2 rps for 30s. Expected: 200s throughout. Report any 5xx.

D. Social / spec attacks (lying, sybil, free-inference)

• D1. POST /v1/chat/completions with no X-Escrow-Ref header. Expected: 401/400. GAP = supplier returns inference for free.
• D2. POST /v1/chat/completions with X-Escrow-Ref pointing at someone else's escrow (you did not sign the PostEscrow). Expected: supplier rejects (signer / buyer-pkh mismatch).
• D3. PostEscrow against the advert (which announces qwen3.6:35b) but in the chat body set model: "gpt-4". Expected: supplier rejects (model mismatch).
• D4. PostEscrow whose advert_ref points at a Retired advert UTxO. Find one via indexer history, or retire one and reuse the ref. Expected: build-time or on-chain validator rejects (advert.status check).
• D5. From 3 sibling sybil wallets (derive new keys; fund each from your testnet faucet within hard caps), PostEscrow against the same advert in quick succession. Expected: each escrow is independently valid on chain. Observe whether the supplier deduplicates, fairly serializes, or refuses concurrent claims. Report behavior — there is no single "correct" answer here, the report itself is the deliverable.

Report (final output)

A markdown table:

Attack ID	What you tried	Expected defense	What happened	Verdict	Evidence

Then a section "GAPs found" listing any GAP rows with reproduction steps detailed enough that a developer can confirm without re-running the whole matrix.

Then a section "Hard-cap accounting": AP3X spent (fees + forfeited bonds), escrows posted, total requests sent. If you stopped early (gap found or cap hit), say why.

═══ END AGENT B PROMPT ═══