Security

Security & vulnerability disclosure

PENGY is a non-custodial wallet. Its security model is enforced on-chain, and we treat vulnerability reports as a first priority. If you've found an issue, here's how to reach us and what you can expect.

Reporting a vulnerability

Email us with as much of the following as you can:

  • A description of the issue and its potential impact.
  • Steps to reproduce — a proof-of-concept transaction, program logs, or a code reference is ideal.
  • The affected component: on-chain program, mobile application, native cryptographic layer, or server-side service.
  • How you'd like to be credited, if at all.
founder@pengywallet.com

What we commit to

72 hoursAcknowledgement of your report.
7 daysInitial assessment — our severity judgement and whether we accept the finding.
OngoingRegular updates while we work on a fix, and notice before any public disclosure.
On publishCredit for your finding, unless you prefer to remain anonymous.

Ground rules

Please do

  • Report privately and give us reasonable time to fix before public disclosure.
  • Test against devnet wherever possible.
  • Limit testing to accounts and funds you control.

Please don't

  • Access, modify, or exfiltrate data belonging to other users.
  • Run denial-of-service, spam, or social-engineering attacks against our users or infrastructure.
  • Disclose publicly before we've had a chance to remediate.

Scope

In scope: the PENGY on-chain program, the mobile application, the native cryptographic layer, and the server-side components that support them.

Out of scope: third-party dependencies (please report those upstream), and issues requiring physical access to an unlocked device where PENGY claims no protection.

Explicitly in scope, despite involving device access

PENGY is designed to resist coercion — an attacker holding both the device and the user. Findings in that surface are the ones we most want to hear about, and the exclusion above does not apply to them:

  • Any way to distinguish a duress authorisation from a normal one — on-chain, in the application, in network traffic, or by timing.
  • Any way to determine whether a duress password exists, or whether one has ever been used.
  • Any bypass of velocity limits, withdrawal timelocks, or the new-device delay.
  • Any way for an attacker holding the seed phrase alone, or the seed and password without a registered device, to move funds out of a vault.
  • Any way to enumerate or read a vault's emergency contacts from on-chain data or from a restored device.

What the model protects, and what it doesn't

Stating the boundary is more useful to a researcher than restating the claims. PENGY splits a wallet into two tiers with deliberately different properties.

The vault

A Program Derived Address — an account with no private key at all. Funds move only through the PENGY program, which evaluates policy before permitting a transfer. Withdrawal requires three independent factors: a key derived from the seed phrase, a key derived from a password via Argon2id, and a hardware-bound device key held in the platform keystore and gated by biometrics. None is computable from another. On top of that the program enforces per-period velocity limits, timelocks on large movements, a delay on registering a new device, and duress authorisation.

The spending wallet

A conventional Solana keypair. It signs in one step, connects to applications, and has the same exposure as any other wallet — a compromised seed drains it. That is the cost of it being fast, and it is why value is intended to sit in the vault.

Known limits

  • Loss of all three factors is unrecoverable. There is no recovery mechanism, because a recovery mechanism is an attack surface. This is deliberate.
  • The factors are independent in kind, not in location. All three can be present on a single device. A multi-signature arrangement with keys on separate machines has a higher compromise threshold; PENGY has a substantially better loss profile once compromise occurs, because limits and timelocks bound the rate.
  • The program upgrade authority is currently a conventional key. Placing it behind an immutable policy gate is a prerequisite to mainnet.
  • Post-quantum work is architecture, not an active protection. The vault authorises by policy rather than by one signature scheme, so a hash-based factor can be added without changing a user's seed phrase or address. It is not active on any network and we do not describe PENGY as quantum-resistant.

On-chain reference

The security model is enforced by a program on Solana. Its behaviour is verifiable independently of anything stated here.

Program ID 2ckQ7mp3QEoY6j8GmE6AEfPRnXPg4bHMZpmnYioSt93k
Network Solana devnet — view on explorer
security.txt Published on-chain in the program binary and surfaced by explorers. This page is the policy it points to.
Disclosure contact founder@pengywallet.com

Six re-runnable on-chain proofs demonstrate the core properties against the live program: that a vault is created with the exact factors recorded on-chain, that a three-factor withdrawal succeeds, that a seed-only attacker is rejected, that a valid seed and password with an unregistered device is rejected, that an over-limit spend is refused even with every factor present, and that a duress withdrawal completes indistinguishably. They can be executed by anyone against the deployed program.

Bug bounty

We don't currently run a formal paid bounty programme. We credit reporters publicly, and we intend to establish a bounty programme at mainnet launch.

Audit status

0 / 0critical & high — initial third-party review (Bevor)

An initial third-party security review by Bevor is complete, with 0 critical and 0 high findings. PENGY will not launch on mainnet without clean results from at least two independent, top-tier security audit firms. Our on-chain program's verifiable state is public on Solana devnet.

Last updated: 18 August 2026