> ## Documentation Index > Fetch the complete documentation index at: https://docs.fundwork.app/llms.txt > Use this file to discover all available pages before exploring further. # Fundwork Security Model > Fundwork's security principles, current practices, and planned pre-launch work across the application, smart contracts, and operations. Security is not a single feature; it is the sum of a set of principles applied consistently across the application, the smart contracts, and the operational practices that keep them running. This page separates what Fundwork does today from what is planned before public launch. Fundwork is in **alpha**. Where a control is planned but not yet in place, that is labeled explicitly. Where a control is currently in effect, that is stated in the present tense. ## Security Principles The following principles guide every part of the Fundwork architecture. ### Minimize custody The less user money the platform holds directly, the smaller the impact of any single failure. The current alpha uses direct settlement precisely to keep custody minimal while marketplace behavior is validated. See [Payment Architecture](/technical/payment-architecture). ### Minimize privileged admin controls Admin capabilities create blast radius. Every privileged action increases the impact of a compromised operator account. Fundwork aims to keep the set of privileged actions small and well-audited. ### Verify authentication server-side The backend does not rely on the frontend to enforce authentication. Every mutating request is authenticated and authorized on the server against the Privy session and the target record. ### Never trust frontend payment state A UI showing a green checkmark is not evidence that a payment occurred. Payment state is confirmed by verifying transactions against Base, as described in [Payment Architecture](/technical/payment-architecture). ### Least privilege Every component, service credential, and human role has the smallest set of permissions needed to do its job. ### Explicit authorization Access to a record is granted by an explicit rule tied to the requesting user's identity, not by obscurity or by the frontend not linking to it. ### Defense in depth Security does not rely on any single control. Authentication, authorization, database-level access rules, monitoring, and rate limiting each catch different failure modes. ### Secure secret management Secrets are stored in a dedicated secret manager and injected at runtime. They are not committed to source, embedded in the frontend, or shared across environments. ### Database row-level security Authorization rules are enforced at the database access layer, so that even a bug in application code cannot expose records to users who should not see them. ### Safe storage access Access to file storage is scoped to the requesting user's records. Storage URLs are not treated as capabilities. ### Transaction replay protection Every confirmed payment transaction hash is recorded and cannot be reused to satisfy another payment record. ## Smart Contract Security Fundwork does not yet operate production payment contracts. Direct settlement in the current alpha means the contract surface is limited to Base Account and USDC on Base, both of which are widely deployed and used. Before production payment contracts are launched, Fundwork intends to perform, at minimum, the following classes of work. ### Testing scope * Unit testing of every public and external function. * Integration testing of interactions between contracts. * Fork testing against Base state where appropriate. * Invariant testing of the properties that must always hold. * Fuzz testing of amounts, addresses, and call sequences. * Adversarial test cases against known attack patterns. * Emergency-state testing of any pause or recovery paths. See [Smart Contract Testing](/technical/smart-contract-testing) for the detailed testing philosophy. ### Review scope * Access-control review of every privileged path. * Reentrancy review of every path that transfers tokens or makes external calls. * Token-transfer edge-case review for USDC and any other ERC-20 involved. * Upgradeability review if any upgrade pattern is used. * Economic attack analysis of release, refund, and fee paths. ### External audit Fundwork has not been audited. No production payment contract has been reviewed by an external security firm at this time. Before production escrow contracts are entrusted with meaningful user funds, Fundwork intends to obtain an independent smart contract security review or audit. When an audit is scheduled or completed, this documentation will be updated with the specifics. Until then, Fundwork will not describe any contract as "audited." ## Ongoing Monitoring Operational security is what makes a secure design stay secure. The following monitoring controls are planned production capabilities. Some are in place today for the components that exist; others will come online alongside the contracts they monitor. Daily automated checks that confirm payment infrastructure is behaving as expected. Alerts on spikes in failed transactions or verification failures. Alerts on release patterns that fall outside expected ranges once escrow is live. Alerts on sudden increases in sponsorship consumption or atypical destinations. See [Gasless Transactions](/technical/gasless-transactions). Every privileged operator action is logged and alertable. Access patterns are logged and reviewed for anomalies. Automated alerts on security advisories in application and contract dependencies. Errors and security-relevant events are routed to on-call responders. ## Status Server-side authentication and authorization, transaction verification against Base, replay protection, and secret management for the components deployed today. Full contract test suite, external security review of production payment contracts, expanded monitoring for escrow and paymaster paths, and published incident response processes. Additional controls such as time-delayed privileged actions and public transparency reports. Ongoing security review cadence as the contract surface grows.