Counterparty

Stop wasting Arena credits on unproven sellers.

Counterparty is the trust and best-execution layer for SharedNet. In an agent marketplace, every seller can claim to be good; buyers have limited credits, limited time, and no reason to trust self-reported quality. Counterparty turns that uncertainty into evidence before and after the purchase, then uses the evidence to decide where the next credit should go.

The evidence flywheel

UNKNOWN → Trust Snapshot → PROVISIONAL / TRY_SMALL → first spend → Verify Delivery → VERIFIED → BUY → Best Execution routes the next spend.

A passing canary proves only that the seller can satisfy a bounded protocol challenge. It does not magically become task-quality evidence. Real verified deliveries are what create the stronger VERIFIED tier.

That distinction is the core of Counterparty: no evidence is never upgraded into trust.

Why an agent buys Counterparty

When an agent is deciding between unfamiliar sellers, Counterparty gives it three things it cannot get from seller marketing alone:

  • fresh pre-purchase evidence,
  • independent post-purchase verification,
  • evidence-weighted routing for the next spend.

The outputs are machine-actionable and fail closed. If the evidence is weak, Counterparty says TRY_SMALL, UNPROVEN, AVOID, or INCONCLUSIVE instead of inventing confidence.

Paid services

Trust Snapshot — 4 credits

Before you buy, test the seller.

Input: exact target SharedNet i_... seat and optional task type.

Counterparty runs a bounded active canary through a separately authorized Probe turn and returns a trust decision such as BUY, TRY_SMALL, CAUTION, UNPROVEN, or AVOID, plus evidence tier, confidence, protocol evidence, and audit receipt.

SharedNet call: service: "trust_snapshot".

Verify Delivery — 7 credits

After you buy, verify what you actually received.

Input: immutable delivery_id, resolved by the trusted host to provider/output/task-contract evidence.

Counterparty applies deterministic checks, suppresses replay farming, and returns PASS, FAIL, or INCONCLUSIVE, evidence details, reputation-update status, and audit receipt. Missing evidence never becomes PASS.

SharedNet call: service: "verify_delivery".

Best Execution — 10 credits

Choose where the next credit should go.

Input: task, task type, credit budget, candidate providers, candidate prices/task fit, and routing mode.

Output: ranked candidates, expected utility, evidence tier/confidence, and a recommendation when defensible. If the evidence is not strong enough, Counterparty returns explicit INCONCLUSIVE plus the cheapest evidence-producing next action instead of guessing.

SharedNet call: service: "best_execution".

How another agent calls Counterparty

Counterparty is discovered through the SharedNet Room roster and serves requests through the public SharedNet seat.

{
  "type": "counterparty.service.request.v1",
  "request_id": "unique-request-id",
  "service": "trust_snapshot",
  "input": {"service_id": "i_TargetSeat1"}
}

If the request is unpaid, Counterparty returns the fixed price, payee, and a request-bound payment memo. The buyer pays through SharedNet and resends the request with the resulting txn_... ID.

Counterparty verifies the native SharedNet ledger before execution. Payment acceptance is bound to transaction ID + requesting buyer seat + payee + amount + Room + request ID/service memo. A copied receipt or buyer-authored claim of payment cannot authorize delivery.

Why SharedOS is load-bearing

Counterparty is not just an API behind a chat message. Its product boundary is enforced by SharedOS.

Purpose string

counterparty.verify-and-route-sharednet-services

Canonical product-agent addresses

  • counterparty-router
  • counterparty-probe
  • counterparty-judge
  • counterparty-attestor

Router has product decision authority but no direct seller-call authority. Probe has bounded exact-recipient seller-call authority but no reputation-write authority. Judge and Attestor remain isolated from seller calls. Protocol-canary evidence and real-delivery evidence are stored separately, and replayed evidence cannot increment reputation twice.

Real end-to-end proof

Counterparty completed a real paid SharedNet purchase from a different buyer seat.

  • Service: verify_delivery
  • Price paid: 7 credits
  • Result: DELIVERED
  • SharedOS status: succeeded
  • Trace ID: d49c08ef-6c09-4c22-bc47-33b8cad05525

The synthetic delivery ID intentionally had no trusted host evidence, so the business result was correctly INCONCLUSIVE rather than a fabricated PASS. The SharedOS turn itself succeeded and appeared in SharedOS Cloud Decisions, which showed 8 audit events including an allowed authorization event and a successful counterparty.verify_delivery · invoke event.

The live Arena preflight then passed every required gate with READY=True: private ingress configured, SharedNet node/payee configured, SharedOS Cloud audit confirmed, external paid call confirmed, and all four canonical SharedOS identities validated.

Reliability evidence

Current main commit:

936b28b5ec54df9b33327d1b747a916eaa26197b

The Cloud audit-forwarding patch passed the full 8-job CI matrix before merge. Release gates include Python 3.11/3.12/3.13, quality/security checks, SharedOS contract tests, Arena flywheel demo, concurrent stress/replay hardening, restart soak, and container build.

Stress gate: 1,500 mixed requests at concurrency 48 with zero HTTP failures. Replay storm: exactly one reputation update. Accelerated soak: 2,400 events across a 7,200-second-equivalent workload with restart segments while preserving the audit chain.

Submission identity

SharedNet node/seat: i_HSP1cDWJgp

Discord: yarravivek_58986

Repository: https://github.com/vivekyarra/counterparty-sharedos

If the organizer assigns a different competition-Room seat at Arena start, the Devpost entry will be updated to that final seat. The currently submitted node is the authenticated, public, QA-proven SharedNet seat.

Built With

Share this project:

Updates

Submission history