Security

Last updated: September 18, 2026

We have not commissioned a third-party security audit, so we do not publish an "Audit Reports" page claiming one. What follows is what is actually implemented, and how you can check it for yourself.

What we do not claim

  • ●No third-party audit has been performed on this codebase, and we have no SOC 2, ISO 27001, or equivalent certification.
  • ●We do not describe addresses as "military grade" or "institutional grade" — those phrases have no defined meaning.
  • ●We do not hold customer funds, so we make no claim about insuring them.

Keys are generated on your device

When you mint an address yourself, the private key is produced by your browser using cryptographically secure randomness. For EVM and TRON addresses it is a secp256k1 key; for Solana it is an ed25519 key. The correct curve matters: the same 32 bytes produce a completely different address on each family, so the key is generated natively for the family you selected rather than converted.

The private key stays in your browser unless you explicitly list the address for sale on the marketplace.

Held keys are encrypted, not merely stored

  • ●Keys that must be held for later delivery are encrypted with AES-256-GCM under a per-key data key, which is itself wrapped by a master key held outside the database.
  • ●The encryption is bound to the address it belongs to, so a ciphertext cannot be silently moved to a different address.
  • ●A keyed hash of each private key is stored to detect duplicates. It is a keyed hash, not a plain hash, so the stored value cannot be used to test guesses offline.
  • ●Listing APIs never return key material. Public address queries use an explicit field allow-list rather than selecting all columns.

Delivery happens once

A purchased private key is delivered through a single-use link that only the buyer of that order can open. The link is claimed with a single atomic operation, so two simultaneous requests cannot both receive the key. If the link is lost before it is opened, contact support to have it re-issued; the key itself remains encrypted and is never deleted.

Payments are verified on-chain

  • ●We verify the transaction succeeded on-chain — not merely that a hash was submitted.
  • ●The transfer must go to our payment address for that network.
  • ●The token contract is checked, not just the token symbol, so a look-alike token is rejected.
  • ●The amount received must cover the order total, and the required number of confirmations must be reached before an order counts as paid.
  • ●If a payment cannot be checked because a node is unreachable, the order is neither completed nor rejected — it stays pending, and you can retry.
  • ●Each transaction hash can only be used for one order.

How to verify

  • ●Compare the addresses you receive with what an independent wallet derives from the private key. That is the check that actually matters, and you can do it offline with any standard wallet.
  • ●Check that a public address query never exposes key material.
  • ●Report anything that looks wrong to dcsoceo@gmail.com — we would rather hear it from you than find out later.