01 / Executive summary
Payment does not prove delivery.
PactVerity is an operational off-chain evidence-verification release and a proposed assurance and settlement protocol for software agents and online service providers.
An agent can increasingly discover a service and initiate a payment without human involvement. Payment alone, however, does not prove that the requested service was delivered correctly. The operating release evaluates machine-readable terms against caller-supplied evidence. A future Solana protocol would add stablecoin payment escrow, a separate provider stablecoin performance bond, challenges and settlement if it passes its launch gates.
The first version is intended for services that can be measured objectively: API availability, response time, data freshness, file integrity and deterministic compute. It is not intended to determine whether subjective work is “good” or whether complex information is universally true.
02 / Operating stack and metrics
Three inspectable off-chain surfaces are operational.
Proof Engine v1 is a public browser interface. The stateless Receipt API beta at /api/v1 exposes bounded receipt creation and verification requests, a known-answer health check and an OpenAPI 3.1 document. The technology page also runs a deterministic synthetic scenario simulator in the browser. None of these components requires or submits a blockchain transaction.
The engine and API accept explicit service thresholds and caller-supplied evidence, then evaluate maximum latency, minimum uptime, maximum data freshness and an optional SHA-256 output commitment. Every result is represented as a versioned, portable JSON receipt.
The engine normalises percentage values into integer basis points, applies deterministic comparisons, records each check and creates a domain-separated SHA-256 payload digest. An imported receipt is strict-parsed, its checks are rerun and its digest is recomputed. A compatible Solana wallet may optionally sign the digest off-chain with Ed25519; this requires no SOL and submits no blockchain transaction.
A self-consistent receipt proves that the recorded inputs reproduce the recorded result and digest. A valid wallet signature additionally proves that the corresponding key signed that exact digest. Neither proves that the underlying measurements were honestly or completely collected. The MVP does not independently monitor services, establish trusted time, move funds, provide escrow, execute settlement or publish receipts on-chain.
Metrics taxonomy
- Simulated nominal protected volume: the sum of synthetic agreement notionals supplied to the deterministic model. The default scenario is 250,000 synthetic agreements × $100 = $25,000,000 simulated nominal.
- Synthetic checks: generated rule evaluations, not customer transactions. The default scenario runs four checks per agreement, or 1,000,000 checks.
- Service and escrow volume: assets transferred, custodied or settled by deployed PactVerity service systems. The current value is $0.
- Health self-test: a current known-answer execution check. It is not an uptime history, security audit, usage measure or adoption claim.
The $25,000,000 synthetic total is not TVL, revenue, customer funds, assets secured, adoption or historical transaction volume. The model exists to make performance and reproducibility testable without presenting fictional activity as fact.
03 / Problem
Autonomous payments create autonomous disputes.
Software agents can discover APIs, data and compute, then pay programmatically. They still face practical trust failures: a provider may not deliver, a service may arrive outside the agreed specification, evidence may be incomplete, and a new provider may have no portable reputation.
- Traditional disputes are too slow for machine-speed transactions.
- Escrow can hold money, but escrow alone cannot decide if work succeeded.
- One central marketplace can become the only source of identity and reputation.
- A volatile network token is a poor unit for customer refunds.
04 / Planned protocol model
Define → Bond → Fund → Verify → Settle.
This lifecycle is a target design, not a deployed value system. If the Solana programs are implemented, tested and launched, a buyer and provider would agree measurable conditions; the provider would post a stablecoin performance bond and, only after that utility exists, a separate PVTY eligibility stake. The buyer would fund stablecoin escrow. Independent verifiers would submit attestations, and program rules would release payment, apply the recorded refund path or open a challenge process.
Target transaction lifecycle
- Terms: service, price, deadline, evidence rules, refund conditions and collateral would be recorded.
- Acceptance: the provider would accept and post the required stablecoin performance bond.
- Funding: the buyer would place stablecoin payment into escrow.
- Delivery: the provider would perform the work and commit the evidence.
- Attestation: selected verifiers would independently assess the agreed signals.
- Settlement: a defined threshold would release payment or apply the recorded refund path.
- Challenge: conflicting evidence would enter a time-bound dispute process.
Under the proposed failure path, unused buyer payment escrow would return first. Agreed compensation could then be paid from the provider's stablecoin bond, up to the stated cap. Any future network-token slashing would be an additional participation consequence; it would not guarantee customer repayment.
PactVerity does not remove trust entirely. It makes responsibilities, evidence and financial consequences explicit.
05 / Architecture
Compact on-chain state. Purpose-built off-chain checks.
Operational off-chain
Proof Engine v1, the stateless Receipt API beta and the deterministic scenario simulator create reproducible evidence computations. They provide no custody, persistence, independent monitoring or on-chain settlement.
Planned on Solana
Job and terms registry, stablecoin escrow accounts, provider bonds, verifier stake, attestations, settlement and refund logic, challenge state and fee accounting. None is deployed.
Additional planned services
A developer SDK, independent monitoring workers, evidence adapters, encrypted evidence storage, indexing and operational dashboards would support the future network. No SDK package is represented as available today.
Sensitive or heavy data should remain off-chain. A future Solana implementation would record transaction state, signatures and cryptographic commitments where appropriate. A blockchain cannot independently understand arbitrary work; it can execute published rules only using supplied evidence and attestations.
Identity and reputation
A proposed reputation layer would reference public keys and finalised outcomes rather than publish raw private evidence. Records remain provisional during the challenge window. Appeals and corrections would be appended so integrators can see the full history. Key compromise, Sybil identities, linkability and privacy remain material design risks.
Why Solana
Automated services may produce frequent, low-value transactions. Solana offers fast settlement, generally low fees, stablecoin support, token tooling and a broad wallet ecosystem. This choice does not eliminate network interruption, congestion, program or wallet risk.
06 / Planned token and fee design
Economic collateral, not default payment.
PVTY has a finalized fixed supply and is intended for possible future provider bonding, verifier staking, penalties and later governance. None of those utilities is active. Buyers would settle protocol services in stablecoins rather than accepting network-token volatility.
- Provider eligibility: participants could be required to lock network tokens before accepting protected work, separately from the stablecoin performance bond.
- Verifier staking: verifiers could be required to stake before submitting outcome attestations.
- Slashing: voluntarily deposited stake could be lost for provable dishonest behaviour under published rules.
- Active rewards: a future network could reward completed verification work—not passive holding.
- Governance: selected parameter voting would be considered only after operational utility exists.
Slashing destinations are not final. The approved specification must disclose whether stake is retired, assigned to a successful challenger or placed in a security reserve, plus the evidence threshold and appeal window. Slashing is not a promise of customer compensation.
PVTY would not represent equity, ownership, guaranteed income, redemption, a price floor or an automatic right to protocol revenue.
Finalized issuance record
Exactly 50,000,000 PVTY were finalized on Solana mainnet on 4 August 2026 using the original SPL Token Program and 9 decimals. The full supply is held in the associated token account controlled by the published owner wallet. Mint and freeze authorities are removed; the metadata update authority remains the published owner wallet for disclosed corrections. Official mint: 8a9P2My6dUhKYJacztYv6bSjKJ1XZwTYY3qz5VwgcGML.
Proposed distribution
The working model assigns 45% (22.5 million) to network work rewards, 20% (10 million) to integrations and ecosystem, 15% (7.5 million) to contributors, 10% (5 million) to treasury, 5% (2.5 million) to security and 5% (2.5 million) to community and liquidity. These transfers, vesting contracts and wallets are not yet implemented. They must be published on-chain before a sale. Allocations confer no equity, revenue entitlement, redemption or guaranteed value.
Planned SOL purchase
If an authorised sale is later launched, the intended primary purchase would be atomic: a buyer would sign one Solana transaction that transfers the quoted PVTY from a sale vault and routes the agreed SOL to a disclosed treasury. The sale program, inventory and operator terms are not final or live. The proposed starting reference of $0.01 means only that a PVTY-per-SOL quote could be calculated from a public SOL/USD snapshot immediately before a transaction. It would not guarantee a resale price, liquidity or value.
Illustrative fee path
Rates are not set. A job's stablecoin-denominated service price, assurance fee, verifier compensation, dispute fee and refund treatment would need to be visible in its terms before funding. One design scenario allocates collected assurance fees 60% to active verifiers and monitors, 20% to a segregated safety reserve and 20% to protocol operations. This split is illustrative, can change and is not a token-holder distribution. A failed job may still incur a pre-disclosed evidence or dispute cost; unused amounts follow the recorded refund rules.
07 / Governance
Decentralise only what the network can operate safely.
Early upgrade and emergency permissions may require a disclosed multisignature arrangement. Later governance could cover fee ranges, verifier eligibility, collateral requirements, evidence adapters, treasury grants and program upgrades.
Material changes should use public proposals, voting thresholds and time delays. Governance should not rewrite active job terms or arbitrarily remove user assets. Authorities, signers and emergency powers must be disclosed before mainnet.
08 / Security
Limits first. Audits before meaningful value.
The planned approach includes independent program audits, adversarial testing, early transaction limits, multisignature permissions, upgrade delays, continuous monitoring, multiple independent verifiers, challenge and appeal windows, and responsible disclosure.
No audit or security status should be assumed until a completed report is published. Audits reduce risk; they cannot guarantee that software is free from vulnerabilities.
09 / Risks and limitations
Assurance is not certainty.
PactVerity may face smart-contract vulnerabilities, compromised admin keys, incorrect or manipulated evidence, verifier collusion, false slashing, ambiguous terms, data-source and licensing failures, Solana interruption, stablecoin depeg or issuer freezing, insufficient collateral, identity and reputation errors, public-chain privacy loss, governance capture, token volatility and legal uncertainty.
It should not initially be used for subjective creative work, medical decisions, legal conclusions, physical delivery or other high-stakes services where correctness cannot be measured reliably. PactVerity is not a bank, insurer or guarantee of performance.
10 / Roadmap
Utility and safeguards before any public market.
2026: Proof Engine v1, the Receipt API beta, health and OpenAPI surfaces, deterministic simulator and verified fixed-supply PVTY mint launched. Selected Solana sale and escrow source files, threat model, reserved program identities, artifact hashes and local-check summary are published. Next, publish a reproducible runtime bundle; deploy the frozen programs to devnet for full multi-wallet lifecycle testing; complete legal and independent security review; and keep public purchase disabled.
2027: devnet program testing, independent audits, controlled pilots, multiple-verifier support, challenge workflows, published pilot evidence and a restricted mainnet decision only if the launch gates pass.
2028: verifier expansion, additional evidence adapters, improved agent-payment integrations, staged governance, and any broader token distribution or secondary-market liquidity only after genuine utility, security evidence and legal readiness.
11 / Version history
A technical record with visible changes.
| Version 0.5 | 4 August 2026 · Published the finalized 50,000,000 PVTY mainnet mint, treasury token account and permanent removal of mint and freeze authorities. Public sale remains disabled. |
|---|---|
| Version 0.4 | 4 August 2026 · Added the operational Receipt API beta, public health and OpenAPI surfaces, simulator, deployment boundary and metrics taxonomy. |
| Version 0.3 | 4 August 2026 · Added Proof Engine v1, deterministic receipt design, optional wallet-signature verification and exact limitations. |
| Version 0.2 | 4 August 2026 · Selected PVTY name, 50 million fixed-supply configuration and planned SOL purchase model. |
| Version 0.1 | 3 August 2026 · Initial public design: protocol model, two-asset collateral concept, illustrative token and fee scenarios, security gates, risks and roadmap. |
Disclaimer
Information, not financial advice.
This paper describes an operational off-chain evidence beta and a broader proposed technology project. It is provided for general information only and is not financial, investment, legal or tax advice, nor an offer or solicitation to purchase any token, security or financial product.
The fixed PVTY mint is live, but the Solana settlement layer, sale and broader PactVerity network remain undeployed. Future features, architecture, roadmap and commercial model may change or may not be completed. Digital assets, smart contracts, stablecoins and blockchain networks involve substantial risk, including possible total loss.