Create and recheck
pactverity.assurance-receipt.v1 records normalized terms, supplied evidence, four checks, outcome and a domain-separated SHA-256 digest.
06 / Developers
Proof Engine v1, the public stateless Receipt API beta and the deterministic scenario simulator are operational. The API evaluates caller-supplied evidence; it does not monitor services, store customer records or move funds.
01 / Operating stack
The browser engine and API use the same published receipt rules. The simulator is a separate deterministic synthetic workload and never submits a transaction.
pactverity.assurance-receipt.v1 records normalized terms, supplied evidence, four checks, outcome and a domain-separated SHA-256 digest.
POST strict JSON to create a receipt or independently verify an exported one. Public health and OpenAPI documents expose the service boundary.
The default run models 250,000 synthetic agreements at $100 each and executes 1,000,000 checks: $25,000,000 simulated nominal, while service and escrow volume remains $0.
02 / Receipt API
These calls use the operational public beta. The first command requires jq only to extract the receipt object from the response envelope into a file for the second command.
curl -sS -X POST https://pactverity.com/api/v1/receipts \
-H 'Content-Type: application/json' \
--data-binary '{
"agreementId": "demo-2026-08-04",
"serviceName": "Example API availability",
"providerReference": "provider-demo",
"buyerReference": "buyer-demo",
"issuedAt": "2026-08-04T12:05:00.000Z",
"criteria": {
"maxLatencyMs": 900,
"minUptimeBps": 9950,
"maxFreshnessSeconds": 120,
"expectedOutputSha256": ""
},
"evidence": {
"measuredLatencyMs": 642,
"uptimeBps": 9988,
"freshnessSeconds": 42,
"observedOutputSha256": "",
"observedAt": "2026-08-04T12:04:30.000Z"
}
}' | jq '.receipt' > pactverity-receipt.jsoncurl -sS -X POST https://pactverity.com/api/v1/receipts/verify \
-H 'Content-Type: application/json' \
--data-binary @pactverity-receipt.jsonA valid response proves deterministic consistency of the submitted data and receipt. It does not prove that the measurements were independently observed, historically complete or true.
03 / Deployment boundary
Status is stated per component so an API response cannot be mistaken for custody, settlement or network adoption.
| Component | Status | Responsibility |
|---|---|---|
| Proof Engine v1 | Operational | Browser-based receipt creation, export, import, deterministic rechecking and optional off-chain wallet signature verification. |
| Receipt API beta | Operational | Bounded, stateless receipt creation and verification plus a public known-answer health check. |
| Scenario simulator | Operational | Runs reproducible synthetic workloads. Its nominal value is neither TVL nor customer or historical transaction volume. |
| Solana programs | Not deployed | Planned job registry, escrow, provider bonds, verifier stake, challenges, settlement, refunds and fees. |
| PVTY mint | Live on mainnet | 50,000,000 fixed supply; mint and freeze authorities removed; full supply held by the published treasury token account. |
| PVTY sale | Not deployed | No funded sale inventory, purchase program or live purchase route exists. |
| SDK, workers and indexer | Planned | Future transaction helpers, independent observations, evidence adapters and searchable on-chain views. |
04 / Planned architecture
If deployed after testing and audit, Solana programs would hold compact job state and assets while purpose-built workers would collect or attest service evidence.
Would provide stablecoin escrow, disclosed collateral, challenge state and deterministic settlement instructions. None of those capabilities is live today.
Applies measurable terms to supplied evidence now. Independent monitoring and trusted data collection remain separate future responsibilities.
05 / Primary references
Build status