// security

Non-custodial.
By design.

Your customers pay you on-chain, directly to a wallet you control. We never hold the funds, never see the keys, and can't freeze the flow. The rest of this page shows exactly how that's enforced — in code, in architecture, and in operations.

0
// private keys held
100%
// on-chain settlement
always
// public audit trail
// how money moves

The payment never touches us

A crypt.pe payment is a regular on-chain transfer with one difference: we present the QR code, your customer scans it, their wallet broadcasts the transaction. The destination address on that transaction is yours, not ours. We don't sit in the middle.

customer wallet  →  on-chain (ETH / SOL / BTC / TRON / ...)  →  YOUR wallet
                  ↑
                  crypt.pe shows the QR; we never sign, never relay.
// what we don't touch

No keys. No seeds. No funds.

  • private keysnever stored, never transmitted, never generated by us.
  • seed phraseswe don't ask. we don't have a field for them. there is no endpoint that accepts one.
  • custodial balancesthere is no internal ledger of "your funds at crypt.pe". the only on-chain balance for your money is the one your own wallet shows.
  • signing authoritywe cannot move, pause, or claw back any payment. once it's broadcast it belongs to your wallet.
// provability

Every payment is public, forever

Because settlement is on-chain, you can verify any payment independently of us — paste the tx hash into Etherscan, Solscan, Blockstream, Tronscan, and you'll see the exact same record we used to credit your dashboard.

If crypt.pe goes offline tomorrow, your historical payments stay verifiable. Your customers can still pay you (your QR code is just a string), and you can still spend the funds — they were never gated by us.

// infrastructure

What we actually run

The boring half (so you know what's actually live):

  • APIFastAPI behind a TLS-only ingress; bcrypt-hashed passwords; JWT auth with rotation; rate limiting on every auth surface.
  • databaseMongoDB Atlas (managed, encrypted at rest); TTL indexes on every token collection; no PII beyond email + display name.
  • webhooksAlchemy Notify for EVM/Solana; signature verification on every inbound webhook; replay-protection via nonce store.
  • emailsResend with DKIM + SPF; recovery / verification links scoped to 24h.
  • 2FATOTP available on every account; recovery codes generated client-side and shown only once.
// legal entity

Who you're trusting (and with what)

crypt.pe is operated by HACKASTRA INFOSEC L.L.C-FZ, a UAE-registered Free Zone company. You're trusting that entity with:

  • uptimeavailability of the dashboard, QR pages, and webhook routing.
  • UXthe buttons, the links, the analytics, the receipts.
  • privacyhandling your email + your display name responsibly per our privacy policy.

You are not trusting us with your money. That's the whole point.

// responsible disclosure

Found a bug? Tell us first.

If you've found a security issue in crypt.pe, please email us before publishing details. We'll respond within 72 hours, work with you on a fix timeline, and credit you on our changelog if you'd like.

security@crypt.pe

// pgp key available on request — we'll send fingerprint in the ack reply.

// last reviewed: feb 2026 — this page is updated whenever the architecture changes. for the full technical changelog see /changelog.