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.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.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.
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
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.Transaction and contract health
Daily automated checks that confirm payment infrastructure is behaving as expected.
Failed transaction monitoring
Alerts on spikes in failed transactions or verification failures.
Unusual withdrawal/release monitoring
Alerts on release patterns that fall outside expected ranges once escrow is live.
Paymaster abuse monitoring
Alerts on sudden increases in sponsorship consumption or atypical destinations. See Gasless Transactions.
Privileged action monitoring
Every privileged operator action is logged and alertable.
Database access monitoring
Access patterns are logged and reviewed for anomalies.
Dependency alerts
Automated alerts on security advisories in application and contract dependencies.
Error reporting and incident alerts
Errors and security-relevant events are routed to on-call responders.
Status
Currently available
Server-side authentication and authorization, transaction verification against Base, replay protection, and secret management for the components deployed today.
Planned before public launch
Full contract test suite, external security review of production payment contracts, expanded monitoring for escrow and paymaster paths, and published incident response processes.
Under evaluation
Additional controls such as time-delayed privileged actions and public transparency reports.
Future
Ongoing security review cadence as the contract surface grows.