07 / Security

Trust requires evidence here too.

Proof Engine v1, a public stateless Receipt API beta and a deterministic scenario simulator are operational but unaudited. PactVerity will not call a Solana protocol audited, decentralised or production-ready until it is deployed and those claims can be linked to public evidence.

AuditNo completed auditBug bountyNot openMainnet protocolNot deployed
Current status:The fixed 50 million PVTY supply is finalized with mint and freeze authorities removed. The browser engine, API beta and simulator move no service funds. Unaudited sale and escrow candidates passed isolated local execution but are not deployed to devnet or mainnet.

00 / Live off-chain boundary

Receipt integrity is not evidence truth.

The browser engine and Receipt API beta strict-parse receipt data, re-run the checks, recompute the digest and validate an optional wallet signature. The API processes submitted JSON through hosting infrastructure; it does not turn supplied evidence into an independent measurement.

Off-chain

No funds or transaction

Browser receipt work stays local unless a user chooses the API. API evaluation and optional wallet message signing are also off-chain and do not spend SOL or settle value.

IntegritySHA-256

Recomputable receipt

The digest protects the recorded payload from undetected change under the published engine version. Receipts contain user-supplied data.

Limit!

No trusted oracle yet

The engine cannot prove honest collection, completeness, trusted time or real-world delivery. Independent evidence collection is a future layer.

01 / Simulation boundary

Scale tests are not financial history.

The deterministic simulator's default $25,000,000 is synthetic nominal volume from 250,000 model agreements at $100 and 1,000,000 checks. Service and escrow volume is $0.

No TVL, customer volume or assets secured.

The model stress-tests deterministic computation. Its output does not establish revenue, adoption, settlement capacity, audited performance or protection of real funds.

02 / Threat model

Assume every layer can fail.

Security work must cover smart contracts, economic incentives, evidence systems, wallets, infrastructure and governance.

Programs

Code and authority risk

Any future Solana programs could expose assets to logic flaws, unsafe upgrades, account validation errors, authority misuse and integration bugs.

Evidence

Verifier and oracle risk

Any future verifier layer could produce incorrect outcomes through bad data, collusion, bribery, Sybil identities or unavailable workers.

Economics!

Collateral and market risk

If deployed, volatile stake value, insufficient stablecoin bonds or concentrated holdings could weaken the intended incentives.

03 / Before value

Required before meaningful funds are accepted.

  • Independent program audits with published reports and remediation status.
  • Unit, integration, simulation and adversarial testing for normal and failure paths.
  • Transaction, provider and collateral caps during controlled releases.
  • Disclosed multisignature signers, upgrade authority and emergency powers.
  • Multiple independent verifiers plus challenge and appeal windows.
  • Monitoring, incident response and responsible disclosure procedures.
  • Publish the full verified PVTY mint address, metadata authority, owner wallet and treasury token account alongside every Solana program ID and release history.

04 / Token authorities

No hidden supply switches.

PVTY has a finalized fixed supply. Mint and freeze authorities are removed; the retained metadata update authority and any future protocol or sale-program authorities are separate disclosures.

Selected disclosure and control of PactVerity token authorities
Mint authorityPermanently removed after exactly 50,000,000 PVTY were minted to the published treasury token account.
Freeze authorityNone. Token accounts cannot be frozen by a PVTY freeze authority.
Metadata authorityThe selected specification would leave the published owner wallet as update authority for disclosed metadata corrections. That authority would not change a finalised fixed supply or freeze holder accounts.
SlashingAny future slashing must apply only to tokens voluntarily deposited into PactVerity collateral accounts—not to ordinary holder wallets.
Upgrade authorityAny future PactVerity protocol or sale-program upgrade authority must be disclosed, protected by appropriate controls and constrained by published delays.

Public candidate source; reporting channel pending.

The sale and escrow audit-candidate source and local validation manifest are public for review. An authenticated vulnerability-reporting channel, response target and disclosure policy must still be published before any buyer funds or protocol value go live. Never include private keys or seed phrases in a report.

Security principle

Audits reduce risk. They never create certainty.

Pre-audit