Trust. What is in place, and what is not.

01What Predge does, and does not do

• Does: issues signed verdicts (delivered, not_delivered, inconclusive) on a paid job, with a refund recommendation. Anyone can check a signature offline against the published ed25519 key. First vertical: signed settlement-risk records for Polymarket. Also a paid whale and smart-money data API over x402.
• Does not: the API and dispute service never hold, move or refund customer funds. Every verdict carries refund.status = "recommendation_only". The merchant moves the money.

Qualification: the on-chain contracts (job escrow, validator bond, refund arbiter) can hold funds if they are used. On 20 Oct 2026 they held a zero balance on Arc, Ethereum, Arbitrum and Base, with no jobs, bonds or rulings. The other 12 chains were not checked. Whether any on-chain path counts as custody under applicable law is an open legal question (G12).

02Owner of security and compliance

Amir Latypov, founder. He is the sole operator, and nobody else has production access. That is a single point of failure and we say so. Contact: hello@predge.io.

Legal entity: none yet. Predge is not incorporated; a Delaware C-Corp via Clerky is planned with no date committed. No DPA, SLA or contract can be signed in an entity's name until then.

03Architecture and data flow

1. A caller sends POST /v1/verdicts with the job spec, the delivery evidence (HTTP status, content type, body SHA-256, body size, latency) and a payment reference.
2. Predge runs deterministic checks, stores the signed record in Postgres and returns the verdict with a refund recommendation.
3. The caller or any third party verifies the signature offline with the public key from the key registry, or calls GET /verify.
4. Paid calls settle in USDC over x402 through facilitators. The API serves the response only on a 2xx, so a refused call is not charged.
5. The web app (Vercel) serves the docs, sign-in (Privy), checkout (Paddle, NOWPayments) and Desk alert settings. Desk alerts go to customer webhooks (HMAC-signed) or Telegram.

04Sub-processors

From the code and founder notes, as of 20 Oct 2026. "Conditional" means the service is used only when its key or secret is set in production, and we have not verified that it is.

The terms page lists Anthropic as a third party; the code confirms it (optional alert commentary). Open item G15: confirm production status and disclose it on the privacy page.

05Data we store, and retention

• API keys: stored as SHA-256 hashes.
• Signups: email, company, use case, key id and a hash of the client IP.
• Desk accounts: wallet addresses, Telegram chat ids, the webhook URL and the webhook HMAC secret (currently in plaintext, because it is needed to sign; G8).
• x402 payments: payer address, route, price, network, settlement transaction, user agent, referer.
• Verdicts: the job spec including the endpoint URL as submitted, delivery status, content type, body hash and size, latency, payment reference, optional caller-supplied buyer_id and merchant_id, agent identity fields, and the signed record. The raw delivered body is not stored, only its hash.
• Web: PostHog page events and Sentry error reports (when enabled), account data via Privy.

Deletion requests: by email to hello@predge.io. They are handled manually by the owner within 30 days. There is no self-serve deletion.

Known weakness: the signup IP hash uses a fixed public prefix, not a secret salt, so it can be reversed by enumerating the IPv4 space. Fix: keyed HMAC, target 13 Nov 2026 (G7).

06Keys and custody

• Attestation signing key: one ed25519 key, kid 13fa3d18a369e6c7. The private key sits in a Railway environment variable and is loaded into the API process. No HSM, KMS, MPC or dual control. Access is limited to Railway project members. MFA status is unverified (G9). No offline sealed copy is documented (G18, target 27 Oct 2026).
• Second published key: kid a122cc095c0f7fe5, role cachet-oracle. It signs market resolutions from an operator machine, not from the API.
• Revocation: the key registry has no status or revocation field. GET /verify returns valid: true for any signature that checks against the supplied key, and reports key_published: false separately. A verifier that reads only valid would accept a compromised key's signatures. Fix: target 6 Nov 2026 (G5).
• Contract owner: one externally owned account, the deployer 0x5d016C1B4d7A42eB7c982da1Ae7fFdB958CFCAe9, is owner, validator and operator of the v1 contracts on 16 chains. Its key file sits on a founder workstation. v1 has no ownership transfer function (finding M-01). Fix: Safe multisig owner with v2, target 9 Nov 2026; interim split of the operations key, target 27 Oct 2026 (G2).
• Webhook secrets: one per Desk account, shown once, currently stored in plaintext. Encryption at rest: target 13 Nov 2026 (G8).
• Credential hygiene: a Telegram bot token and an OpenAI key were listed for rotation in the 3 Oct infra audit. Current status unverified (G9, target 24 Oct 2026).

07Contracts and audits

• Six v1 contracts (PredgeAgentValidator, AgentJob, PredgeValidatorBond, PredgeSettlement, MockRefundProtocol, PredgeRefundArbiter), same addresses on 16 EVM mainnets, deployed and Sourcify-verified (one contract per chain re-checked on 20 Oct 2026, PredgeAgentValidator, exact match). They hold no funds: balance 0 on Arc, Ethereum, Arbitrum and Base, checked 20 Oct 2026.
• Our own manual review on 20 Oct 2026 found, among others:
  • H-01 (high): a verdict recorded before submission can be reclaimed unchallenged.
  • H-02 (high): the expected output is public, so an honest score-0 verdict can be slashed, and committing it after submission makes the bond meaningless.
  • H-03 (high): after a ruling, a challenge can never succeed; evidence is not bound to the payment parties, and refunds execute before the window closes.
  • M-01 (medium): one externally owned account is owner, with no ownership transfer.
  • Plus M-02 to M-05, seven low and seven informational items. The full list will ship with v2.
• The 3 Oct internal review was reported as closed. The 20 Oct review found several of those fixes incomplete, so the earlier "all fixed" wording is superseded.
• Next: v2 with fixes and a Safe multisig owner, target 9 Nov 2026. An external scan by Olympix, funded through Circle's Arc programme, comes next. An external audit follows v2; no date committed.
• Not done: external penetration test (Vaultline decision expected 2 Nov 2026) and a bug bounty.

Sourcify (Base example) · github.com/predgeAI/predge-deploy

08Backups and recovery

• Schedule: Railway Postgres backups, daily (kept 6 days) and weekly (kept 27 days), configured 3 Oct 2026 per founder notes. Redis: weekly. Backup encryption is unverified.
• Not covered by the test: the two history tables (trades, wallet_score_history) were restored schema-only. It was not a restore of a Railway volume snapshot, so full-database restore time is not measured.
• No point-in-time recovery: no WAL archiving, no replicas. Worst-case data loss is up to 24 hours on the daily schedule.
• No off-site copy: backups are with the same provider, account and region as production. The GitHub Actions backup to Cloudflare R2 has failed since 27 Apr 2026 (missing secrets).
• Single instance, single region, no standby.
• RPO and RTO are not defined yet: target 27 Oct 2026 (G16).

09Incident response and contact

Owner: Amir Latypov. Report an issue or an incident to hello@predge.io. Public updates go to @PredgeAI. The runbook (roles, first hour, signing-key compromise, wrong verdict) is in INCIDENT-RESPONSE.md, with a desk tabletop of a signing-key leak. The tabletop was not a live drill; a live drill is planned for 15 Jan 2027.

10What we can prove today

• Public key registry: api.predge.io/.well-known/predge-keys.json
• Hosted check: api.predge.io/verify; free re-read of a verdict by id at GET /v1/verdicts/:id. Offline steps are in the docs.
• Contract source on Sourcify and in predgeAI/predge-deploy.
• Our 20 Oct 2026 contract self-review, summarised above, and the logical restore test result above.

We cannot prove today: SOC 2, ISO 27001, an external pentest, a restore from a Railway volume snapshot, point-in-time recovery, off-site backups, a signed DPA, insurance, or an uptime history.

11Current gaps, with target dates

Dates marked "target" are plans, not commitments. Anything marked "no date" has none.

12Downloads

• Trust PackFull source of this page, with evidence status per statement
• Security questionnaireLightweight vendor questionnaire, answered
• DPA template (DRAFT)Not reviewed by counsel. Not for signature.
• Service levels (draft)Targets, not commitments, until a contract is signed
• Incident response runbookRoles, first hour, signing key compromise, wrong verdict
• Tabletop: signing key leakDesk walk-through of 20 Oct 2026, not a live drill