Security
What we protect, and what we simply never have.
The strongest control in the design is an absence: ProxyPay has no customer signer, no merchant signer, and no account that merchant funds pass through.
Boundaries
- No funds
- ProxyPay software does not hold, receive or transmit funds. There is no ProxyPay balance, float or settlement account in the flow.
- No keys
- No customer signer, no merchant signer, no vault seat, no recovery share. Approval keys are held by customers and by merchant-named people on their own hardware.
- No silent execution
- Every money-moving action is a proposal that a merchant-controlled key authorises. A mismatch between the displayed proposal and the decoded action is a denial and an incident.
- Tenant isolation
- Every call is bound to one tenant. Authorisation is checked before lookup, so an inaccessible record and an absent record are indistinguishable from outside.
Request integrity
- Requests are signed with Ed25519 over canonical JSON bytes. The raw wire is authoritative; re-canonicalisation must reproduce it exactly.
- Issuer keys are published before use, have explicit validity windows, and are rejected the moment they are revoked — even if the signature still verifies mathematically.
- Request identifiers, payment references and nonces are reserved atomically for the life of the request, so a replayed request fails closed.
- An invalid request never consumes a replay reservation, so a rejected forgery cannot burn a legitimate identifier.
- The issuing path verifies its own output: ProxyPay recomputes the hash over the returned bytes and compares every claim with the request it intended to make before anything is displayed.
Data
- The request format prohibits customer identity, contact details, loyalty identifiers, item or basket data, memos and receipt identifiers. These are rejected fields, not conventions.
- Support diagnostics are shown to the person submitting them, field by field, before anything is sent, with an explicit purpose and a deletion date.
- Access to a support record is logged as who, when, which scope and which opaque case — never the contents.
- Any information passed to another company is limited to a public display reference and, where needed, a public transaction signature, for a named purpose and a fixed deletion date.
The ledger is public
Stablecoin payments settle on a public blockchain. Amounts, addresses and timestamps are visible to anyone, permanently, and ProxyPay cannot make them private. Treat receiving-address reuse as a business-information decision.
ProxyPay will screen merchants and merchant addresses against applicable sanctions lists, and merchants must remain in good standing under their own exchange or off-ramp provider’s rules. See acceptable use.
Open items
Pilot stage means some assurances do not exist yet. Listing them is part of the product.
| Item | Status |
|---|---|
| Independent security review | Not yet performed. Required before a production candidate. |
| Production key ceremony and issuer key hosting | Designed, not yet operated. |
| Vault vendor and exchange agreements | Commercial and technical gates still open. |
| Physical device testing in a live store | Pending the first pilot. |
| Production database, access management and backup qualification | Open. |
| Counsel review of terms, privacy and acceptable use | Open. The documents on this site are pilot-stage drafts. |
Found a problem? See responsible disclosure or write to security@proxypay.app.