Status and evidence

Pactwright runs on Stellar testnet. It is not audited, not on npm, and not on mainnet. Everything below links to something you can check.

What works

Piece	Status
pact contract	On testnet. Reproducible build: the release asset, the deployment and a local build are the same bytes
Hashing, Rust and TypeScript	Byte-identical, tested against shared vectors
Verifier: rules, signing, receipt checks	Working; the contract accepts its signatures on testnet
Verifier: model reading	Real model, 29 of 29 on the labelled translation set (gemini-3.5-flash-lite, 29 October 2026)
Hosted verifier	On testnet; one of its verdicts was accepted by the contract and settled (below)
Seller middleware	On testnet: a valid 402, payments verified and settled by the facilitator before serving, signed delivery receipts
Agent purchases over x402	On testnet, with both exact and pact schemes
Facilitator pact scheme	Merged in Accensa’s facilitator and hosted on testnet
Refunds signed in a KMS	A RefundVault refund signed by a HashiCorp Vault transit key, on testnet
Studio	On testnet: indexes pacts, anchors receipts hourly, shows timelines and checks certificates

Not yet

What	Why
Mainnet	Waits for an audit
npm packages	The first release is pending
Partner integrations (Vespi approvals, Pollar wallets)	The adapters exist and fail safely; they need partner API access
Real data on Studio’s seller and budget pages	They show sample data until sellers and budgets are registered

The hosted verifier

On 29 October 2026, an escrow pact was opened with fresh accounts, the delivery was committed to the evidence store, and the hosted verifier judged it with its real model. The contract accepted the verifier’s attestation, and the pact settled.

Step	Ledger	Transaction
open (1 USDC locked)	5453755	b0103116…
Verdict: ALLOW 1 USDC	issued at 5453756
record_verdict	5453761	0225f78b…
settle	5453762	1f4ab38c…

The pact in Studio: 40725564…5c55.

Every scenario, end to end

The Kit’s testnet suite runs every scenario as real transactions against the deployed contract, with real testnet USDC. It runs nightly in CI; these are from its run on 29 October 2026. In this suite the model’s reading is a fixture, so the outcomes test the rules, the contract and the payment flow.

Scenario	Outcome	Step	Transaction
M0 allow	ALLOW, seller keeps 1	x402 exact payment	38509ae3…
M0 deny	DENY, 1 refunded	x402 exact payment	1b639eab…
		RefundVault.refund	2bc4f53d…
M0 non-delivery	DENY, 0.5 refunded	x402 exact payment	b3b37888…
		RefundVault.refund	d9b68052…
M2 allow, partial	ALLOW 0.75 of 1, settled	open	a774fa79…
		record_verdict	15263e7c…
		settle (0.75 to seller, 0.25 back)	18ea30d9…
M2 deny	DENY, full refund	open	9a49c8fa…
		record_verdict	d53cc633…
		release	eae7c711…
M2 silence	No verdict; refunded	open	105581ce…
		release after the verdict deadline	2a4c579d…
Dispute	2 of 4 pages, 0.5 refunded	RefundVault.refund	79d22019…
x402 escrow	ALLOW 1, settled; every fee paid by the facilitator	pact.open via x402	a33591a1…
		record_verdict via /pact/submit	9d63a621…
		settle via /pact/submit	51d659e4…

Progress

Every task and its state is tracked in each repository’s ROADMAP.md, and every pull request updates it: contracts, Kit, Studio.

The master roadmap holds every task across all of them and is the count of record — this page deliberately does not repeat a percentage, because a second copy of a number is a second place for it to be wrong. A CI job (roadmap-sync) fails if the master and a repository disagree.