What we defend, what we cannot defend, and how to tell us when we are wrong.
ShyPay is a self-custody wallet in development. This page describes the model we are building to, in plain words, including the parts where the honest answer is that the risk sits with you.
A payment request must pass every check before it is shown to you.
Verification runs on your phone, before the request is rendered. A request that fails any check is refused outright, and there is no override, no "proceed anyway", and no way for a merchant to talk your wallet past it.
-
The signature is valid and the issuer is current
Ed25519 signatures are checked against published issuer keys. A key that has been revoked fails even when the signature over the payload is mathematically valid.
-
The request is fresh
Requests carry a validity window. Anything expired, or not yet valid, is rejected rather than shown with a warning.
-
The request has not been seen before
A request ID, reference, or nonce that your wallet has already processed is refused. A screenshot of yesterday's code is worth nothing.
-
The asset is exactly the asset
The USDC mint address, its decimals, the network, and the recipient must match what ShyPay is configured for. Lookalike tokens with similar names do not pass.
-
The amount you see is the amount you sign
The figure on screen is taken from the same verified payload your device signs. There is no second, quieter number underneath it.
-
Approval is a separate, deliberate act
Opening the app, scanning a code, funding your wallet, or verifying a request never moves money. Only your explicit approval does.
Nobody can sign for you. Not us, not the wallet provider.
ShyPay is a self-custody wallet: ShyPay never holds your keys or your funds and cannot move, freeze, or sign for your money. Signing uses a split key — one part stays on your device and one part is held by the wallet provider, Dynamic, in secure hardware. Neither part can sign alone, so no one, including ShyPay and Dynamic, can move your money without you. That removes an entire category of risk: there is no ShyPay vault to be drained and no ShyPay employee who can sign on your behalf. It also means the responsibility for your recovery method is genuinely yours.
ShyPay cannot move your funds
ShyPay holds no key share at all, so no transfer can be authorised without you approving it on your device.
ShyPay cannot reverse a transfer
A settled Solana transfer is final. There is no chargeback and no clawback. Check the recipient before you approve.
A split key, and neither half is ours
One key share sits on your device; the other is held by the wallet provider in secure hardware. Both are required for every signature. ShyPay holds neither. ShyPay is being built to use Dynamic for wallet key management and Ramp Network for buying and selling USDC; these integrations are in development and are subject to those providers’ approval and terms.
Nobody here will ever ask for your key
Not support, not an email, not a phone call. Any request for a seed phrase, private key, or recovery material is fraud, without exception.
Who we are defending you against, stated plainly.
A security page that only lists strengths is marketing. This is the shape of the problem as we understand it, including the attackers we do not claim to stop.
A hostile or tampered register
Defended. A register that alters the amount, substitutes the recipient, replays an old code, or presents an unsigned request fails verification on your device before you see anything.
ShyPay building a record of your purchases
Defended. ShyPay does not collect what you buy. No line items, receipts, category codes, or loyalty identifiers reach us, because nothing in the flow sends them.
Commercial profiling by card networks
Defended. Payments are not routed through card networks, so no card network receives a purchase-by-purchase feed from ShyPay.
Chain analysis of a public ledger
Not defended, and we will not claim otherwise. Solana is public. An observer can see the flow between addresses and may be able to correlate an address with a person using information from outside ShyPay, such as an exchange or a counterparty.
A compromised phone
Partly defended. Your key share is protected by your device's secure storage and its lock screen, and it cannot sign on its own: the second share, held by the wallet provider in secure hardware, is required too. A device with malware at the operating-system level, or one left unlocked in the wrong hands, is a genuine risk we cannot engineer away.
Someone talking you into sending money
Not defended by cryptography. If you are persuaded to approve a transfer, the transfer is valid and final. This is why approval is deliberate, and why the recipient is shown before you sign.
The wallet provider going away
Mitigated, not eliminated. Because signing needs both shares, the wallet provider is a dependency. This is why export exists: you can take your private key out and run the wallet elsewhere. Do it before you need it.
Lawful process
Not defended, by design. ShyPay is a privacy product, not an evasion product. All cash-in and cash-out goes through a regulated provider that verifies identity and applies the law, and we respond to valid legal process with the limited data we actually hold.
Losing your recovery method
Your responsibility. Self-custody means there is no one to phone who can let you back in. Set up recovery before you hold a balance you would miss.
Found something? Tell us before you tell the internet.
We would much rather hear about a flaw from you than read about it later. Report it to security@shypayments.com. Machine-readable contact details are published at /.well-known/security.txt.
Read the disclosure policySecurity you can argue with beats security you have to take on faith.
ShyPay is in development. If something on this page does not hold up, we want the argument before launch, not after.