# Security PepFund's security model is built around a non-custodial architecture. The platform is designed so that no single party, including PepFund itself, can unilaterally move campaign funds. This page documents the design principles, current audit status, known limitations, and the process for reporting vulnerabilities. *** ## Non-Custodial Design Campaign funds are held in program-derived addresses (PDAs) owned exclusively by the PepFund Solana program. No human wallet holds private key authority over any escrow account. The only ways funds can move are: | Action | Authorisation Required | | ---------------------------------------- | ----------------------------------------------------------------------- | | Contribution (backer to escrow) | Backer wallet signature | | Milestone release (escrow to researcher) | Program logic validation (window closed, no quorum of flags) | | Refund (escrow to backer) | Backer wallet signature; requires campaign in Failed or Cancelled state | | Cancellation (researcher initiates) | Researcher wallet signature; only valid before goal is reached | PepFund operations team members do not have admin keys, multisig override authority, or any privileged instruction in the current program. There is no "admin withdraw" or "emergency drain" function. *** ## Audit Status {% hint style="warning" %} **Beta Disclosure:** The PepFund Solana program has not yet completed a formal third-party security audit. The program is operating on Mainnet during the beta period. This means real USDC is at risk. Contribute only what you are prepared to lose in the event of an undiscovered vulnerability. {% endhint %} An audit by an independent Solana security firm is scheduled for completion before the V1 general release. The audit will cover: * All program instructions and account validation logic * PDA ownership and signer validation * Arithmetic overflow and precision handling in fund calculations * Token-2022 extension interactions * Cross-program invocation (CPI) privilege escalation risks The audit report will be published in full here upon completion. *** ## Bug Bounty PepFund operates a bug bounty programme. If you discover a vulnerability in the Solana program or the web application that could result in loss of user funds or compromise of user accounts, please report it responsibly. **Contact:** **Scope:** | Severity | Description | Reward | | -------- | ------------------------------------------------------------ | ------------------ | | Critical | Direct theft or permanent freezing of user funds | Up to $50,000 USDC | | High | Privilege escalation, unauthorised state transitions | Up to $10,000 USDC | | Medium | Denial of service, milestone manipulation without fund theft | Up to $2,500 USDC | | Low | UI/UX vulnerabilities, informational disclosures | Up to $500 USDC | **Out of scope:** * Theoretical attacks without a proof of concept * Issues already known and documented in this page * Social engineering attacks against PepFund staff * Issues in third-party dependencies outside PepFund's control Responsible disclosure means giving PepFund a minimum of 7 days to patch a critical vulnerability before public disclosure. We commit to responding to all valid reports within 24 hours. *** ## Known Limitations ### Beta Dispute Resolution Is Centralised During the beta period, disputed milestones are resolved by the PepFund team rather than by a fully onchain governance mechanism. This introduces a degree of centralisation in dispute resolution. The decision by the PepFund team is final during beta. Fully onchain dispute resolution via a governance programme and escalation oracle is planned for V2. ### Researcher Token Vesting Is Program-Enforced, Not Timelock-Enforced Researcher token vesting is enforced by program logic that gates token releases to milestone completions. It is not enforced by a time-lock with an independent onchain authority. This is equivalent in practice but should be understood as a design characteristic. ### Arweave Permanence Is Probabilistic Arweave is designed for permanent storage, but its guarantee is probabilistic, not absolute. PepFund stores milestone evidence on Arweave because it is the most resilient available option. In the unlikely event that Arweave data becomes inaccessible, the Solana state still contains the content hash of the evidence, which can be used to verify evidence if it is republished elsewhere. ### Solana Network Risks PepFund depends on the Solana network. Solana has historically experienced network instability including brief halts. PepFund's frontend degrades gracefully during network issues (read-only mode from Supabase index), but transactions cannot be submitted during a Solana outage. Campaign deadlines still advance in real time during outages. *** ## Smart Contract Risk Smart contracts can contain bugs. Even audited programs have had vulnerabilities discovered post-audit. Users should: * Contribute only amounts they can afford to lose * Verify the program ID before signing transactions * Be sceptical of any third-party website or integration that asks for wallet signatures against PepFund campaign accounts **PepFund Program ID (Mainnet):** Published at [pepfund.xyz/program](https://pepfund.xyz/program) and verifiable on Solana Explorer. *** ## Wallet Security PepFund never asks for your seed phrase or private key. If any website, application, or person asks for your seed phrase claiming to be PepFund, it is a scam. PepFund transactions are initiated from the official web application at [pepfund.xyz](https://pepfund.xyz) only. Verify the URL in your browser before signing any transaction. Recommended wallet practices: * Use a hardware wallet (Ledger, Trezor via Phantom) for large positions * Keep your seed phrase offline, in multiple secure locations * Use a dedicated wallet for DeFi and DeSci activity, separate from your primary holdings --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.pepfund.xyz/reference/security.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.