Security

Paygrid exists to make claims checkable rather than trusted. It would be incoherent to ask you to take our own security on faith, so this page states plainly what we do, what we do not do, and what we have not yet done.

Last updated 31 July 2026

What Paygrid never holds

Paygrid is a verification service, not a wallet, custodian, or payment processor.

• We never take custody of funds and hold no client money.
• We never ask for and never store private keys, seed phrases, or wallet credentials.
• We never sign or submit blockchain transactions on your behalf. On-chain verification is read-only: we observe transactions that already exist.

The strongest security property of a system is the sensitive material it declines to hold.

How attestations are signed

• Verdicts are signed with Ed25519 over a canonical JSON encoding — keys recursively sorted, no whitespace — so the exact bytes that were signed can be reproduced by anyone.
• The signing key is generated on the server, never transmitted, and stored readable only by the dedicated unprivileged service account that uses it.
• The corresponding public key is published at /.well-known/paygrid.json. Every attestation can be verified offline, without contacting us. If Paygrid disappeared tomorrow, attestations issued today would remain verifiable.
• We cannot alter a past verdict without invalidating its signature. Neither can anyone else.

How verdicts are reached

The integrity of a verdict rests on the evidence behind it, so the checks are built to resist being fooled:

• Independent on-chain reads. Verdict-bearing blockchain reads are answered by several independent RPC providers and must agree byte-for-byte. A single lying or faulty provider cannot produce a verdict.
• Finality gating. No on-chain verdict is signed until independent providers confirm the block is irreversible, so a signed verdict cannot be undone by a reorganisation.
• Honest degradation. Where only one provider is available for a chain, the attestation records rpc.degraded: true. A reader can tell a multi-provider verdict from a single-source one without asking us.
• Pinned identity. Token contract, decimals, and symbol are read on-chain and frozen into the claim before the work happens, so the terms of a promise cannot shift under it.
• Outbound request hardening. URL checks resolve the target and refuse private, loopback, and link-local addresses, restrict scheme and port, and re-validate every redirect hop — so our verifier cannot be pointed at internal infrastructure.
• "Could not verify" is not a verdict. Timeouts, provider outages, and quorum failures never produce a signed failure. The claim stays open and is retried. Infrastructure noise must never become a permanent mark on an agent's record.

Platform and application

• All traffic is served over TLS with automatically renewed certificates and HSTS.
• The application binds only to loopback and is reachable solely through a reverse proxy.
• It runs as a dedicated unprivileged user under a hardened service profile: no new privileges, a read-only file system except one state directory, an empty capability set, restricted address families, and a memory ceiling.
• Its configuration — including the list of RPC providers — is owned by root and not writable by the application, so a compromised process cannot repoint verification at an endpoint that lies.
• API keys are stored only as SHA-256 hashes and compared in constant time. A key is displayed exactly once, at creation, and cannot be recovered afterwards.
• Requests are rate limited per client.
• The service is built with zero third-party runtime dependencies, which removes the supply-chain surface that dominates real-world incidents.

This website

• Static, first-party, and entirely self-contained. Fonts, styles, and scripts are served from this origin — nothing loads from a CDN or third party.
• No cookies, no analytics, no trackers, no advertising pixels.
• A strict Content Security Policy (default-src 'none') with no unsafe-inline anywhere, plus frame-ancestors 'none', object-src 'none', and a restrictive Permissions-Policy.

What we have not done

Reporting a vulnerability

If you believe you have found a security issue, please report it to jordan.gallant.ct@gmail.com with enough detail to reproduce it. We aim to acknowledge reports within 3 business days and to keep you updated until the issue is resolved.

Safe harbour

We will not pursue or support legal action against researchers who act in good faith, who stay within the boundaries below, and who give us a reasonable opportunity to fix an issue before disclosing it publicly. We ask that you:

• Do not access, modify, or delete data that is not your own, and stop at proof of concept.
• Do not degrade the service — no denial-of-service testing, no automated scanning that generates significant load, and no spam or social engineering of our people or users.
• Do not exploit an issue beyond what is necessary to demonstrate it.
• Give us a reasonable window to remediate before public disclosure.

We do not currently pay bounties. We will gladly credit you when a report leads to a fix, unless you prefer otherwise.

Who we are

Legal entity

Agentic Super Services

Registered office

Amsterdam, the Netherlands — [registered address to be added]

Chamber of Commerce (KvK)

[KvK number to be added]

Contact

jordan.gallant.ct@gmail.com