SECURITY

Security reports are taken seriously. We aim to acknowledge within 48 hours and ship a fix or mitigation within 14 days for high-severity issues. Coordinated disclosure preferred.

Report a vulnerability#

Scope#

In scope:

• Smart contracts in contracts/ and any contract this project deploys to Base.
• Edge functions in supabase/functions/.
• Postgres schema and RLS policies (migrations in supabase/migrations/).
• The web app in src/.

Out of scope:

• Findings that require a compromised admin EOA, compromised backend signer key, or physical access to a user's device.
• Social engineering of Catalysts, Vendors, or Champions.
• Denial-of-service that requires sustained, high-volume traffic.

Intentional design (not a vulnerability)#

• The Supabase anon / publishable key in the repo. It is a public token; access is gated by row-level security.
• Public SELECT access on tables that intentionally expose public data (open bounties, public donor wall, treasury totals).
• $PURPOSE balances being readable on-chain — the token is meant to be a publicly verifiable community credit.

Secrets — never commit these#

These live only in Lovable Cloud (or a fork's equivalent secret store) and must never appear in the repo, in client code, or in logs:

• BOUNTY_ADMIN_PRIVATE_KEY
• REDEMPTION_SIGNER_PRIVATE_KEY
• SUPABASE_SERVICE_ROLE_KEY
• thirdweb secret key (the publishable client ID is fine in code)
• OAuth client secrets (Google / Apple)
• Any wallet private key or mnemonic

Security controls in production#

• Role-based access via Postgres RLS and on-chain roles.
• Audit logs for bounty creation, approval, minting, and redemption.
• Contract pausability by master admin in emergencies.
• Catalyst / vendor freezing to halt malicious or negligent actors.
• Server-side redemption signer — vendor and champion devices never sign transactions.
• Allowlisted admin wallets — admin entry is restricted server-side.