The following versions of ProofOfHeart-stellar are currently receiving security updates:

We take security vulnerabilities seriously. If you discover a security issue in ProofOfHeart-stellar, please do not open a public GitHub issue.

Send a detailed report to:

Email: security@proofofheart.io (domain confirmed: proofofheart.io)

Please include the following in your report:

• A clear description of the vulnerability
• Steps to reproduce the issue
• The potential impact (e.g. fund loss, unauthorised access, overflow)
• Any proof-of-concept code or transaction examples if applicable

• Acknowledgement: We will acknowledge receipt of your report within 48 hours.
• Status updates: We will keep you informed of our progress and expected timeline.
• Resolution: We aim to resolve critical vulnerabilities within 7 days and non-critical issues within 30 days.
• Credit: With your permission, we will credit you in the release notes once the vulnerability is fixed.

We triage reports using the following severity levels:

We ask reporters to follow coordinated disclosure:

1. Report the issue privately via the email above — do not open a public issue, PR, or forum post describing the vulnerability.
2. We will work with you to validate, reproduce, and fix the issue.
3. We request 90 days from the initial report before any public disclosure, to give us time to ship and deploy a fix. This window can be shortened by mutual agreement (e.g. once a fix is live and users have had time to upgrade) or extended if the fix requires unusual coordination (e.g. a contract migration).
4. If 90 days pass without a resolution or agreed extension, the reporter may disclose publicly, but we ask that you still coordinate the exact timing and content with us where possible.

Security reports targeting core Soroban contract logic in src/ are evaluated for rewards and public accreditation:

• In-Scope Contracts & Entrypoints (public methods of ProofOfHeart in src/lib.rs):
  • contribute(), batch_contribute(), claim_refund(), withdraw_funds(), withdraw_reserve(), claim_milestone() — Campaign escrow & asset accounting
  • deposit_revenue(), claim_revenue(), claim_creator_revenue() — Revenue-share accounting
  • vote_on_campaign(), verify_campaign(), verify_campaign_with_votes() — Governance & voting invariants
  • Admin entrypoints (pause, update_platform_fee, propose_token_update / accept_token_update, initiate_admin_transfer, emergency_withdraw, …) and the storage layer in src/storage.rs
• Reward Tiers:
  • P0 Critical (Direct fund drain / auth bypass): Eligible for up to $2,500 USDC bounty + release notes credit.
  • P1 High (State corruption / fee breakdown): Eligible for up to $1,000 USDC bounty + release notes credit.
  • P2 Medium/Low: Eligible for public credit in release notes.

No formal third-party security audit has been conducted on this contract to date. Findings from internal and community review are tracked in the Security Findings & Remediation Tracking Matrix. Given the contract handles escrowed funds, we recommend treating it as unaudited and exercising appropriate caution until an audit is completed.

This policy covers the on-chain Soroban smart contract (src/) and official tooling in this repository. Frontend integrations or third-party services built on top of the contract are out of scope unless the vulnerability originates from contract logic itself.

• Vulnerabilities in dependencies outside our control (e.g. soroban-sdk)
• Issues already publicly disclosed
• Theoretical attacks without a realistic exploit path

This matrix tracks every security-relevant finding reported against this repository and how it was fixed. These are internal and community findings (GitHub issues). They are not the output of a formal third-party audit (see Audits).

Severities use the definitions above. Findings from before those definitions existed were classified afterwards. Where several issues reported the same problem, they share one row, and the first issue listed is the canonical one.

Status key: ✅ Resolved · ⚠️ Partially mitigated / mitigated · 🟡 Accepted risk · 🔴 Open

Notes

1. SEC-25 (single admin key). Mitigations in place: two-step admin transfer (initiate_admin_transfer / accept_admin_transfer), a configurable timelock on token migration (propose_token_update → accept_token_update, get_token_update_delay_secs), a 7-day timelock on emergency_withdraw, and a separate emergency-pause signer set (set_emergency_pause_signers / emergency_pause). The admin is still one address, so deployers should set it to a multisig account or a contract.
2. SEC-33 (reproducible builds). make build-docker builds inside a pinned container, but the image is stellar/rs-soroban-sdk:20.1.0 while Cargo.toml pins soroban-sdk = "=22.0.11". The image tag should be brought in line with the SDK before the build is relied on for verification. The finding stays open until then.
3. SEC-34 (accepted advisory). The CI audit job ignores RUSTSEC-2025-0001. Its justification says the vulnerable version is pinned by soroban-sdk 20.1.0. The contract now uses soroban-sdk 22.0.11, so the ignore should be re-checked and removed if it no longer applies.

1. Report it privately first, as described in How to Report. Open a public issue only after a fix ships, or once the disclosure window has passed.
2. Add a row with the next SEC-NN id, the issue number(s), a one-line description of the finding, its severity and the affected module.
3. Update Status and Fix PR(s) when the fix merges. Don't delete rows: resolved findings are the audit history.

flowchart LR
    subgraph Users
        C[Contributor]
        CR[Creator]
        V[Voter / token holder]
    end
    subgraph Privileged
        A[Admin — single address, use a multisig]
        EP[Emergency-pause signers]
    end
    subgraph Contract["ProofOfHeart contract (escrow)"]
        E[(Campaign escrow & storage)]
        G{Pause gate<br/>manual + auto-pause}
    end
    T[(SEP-41 token contract)]

    C -- "contribute / claim_refund<br/>(require_auth)" --> G
    CR -- "withdraw_funds / claim_milestone<br/>(creator auth)" --> G
    V -- "vote_on_campaign<br/>(1 address = 1 vote, min balance)" --> G
    G --> E
    E -- "transfer (after state updates)" --> T
    A -- "verify, fees, timelocked token update,<br/>timelocked emergency_withdraw" --> E
    EP -- "emergency_pause only" --> G

Checks-effects-interactions. Every payout path finishes all its state writes before the external token call. Here is claim_refund (src/contributions.rs, abridged):

contributor.require_auth();
require_not_paused(env)?;
// ... eligibility checks ...
remove_contribution(env, campaign_id, &contributor);      // effects first
remove_revenue_claimed(env, campaign_id, &contributor);
decrement_contributor_count(env, campaign_id)?;
// ... accounting updates ...
let client = campaign_token_client(env, campaign_id);
client.transfer(&env.current_contract_address(), &contributor, &amount); // interaction last

A re-entrant call from a malicious token then sees a zero contribution and fails with NoFundsToWithdraw (SEC-11).

Inspect live security state with the Stellar CLI (read-only; --source can be any funded identity):

ID=<CONTRACT_ID>; NET=testnet   # or mainnet
stellar contract invoke --id $ID --network $NET --source me -- is_paused
stellar contract invoke --id $ID --network $NET --source me -- get_admin
stellar contract invoke --id $ID --network $NET --source me -- get_pending_admin
stellar contract invoke --id $ID --network $NET --source me -- get_emergency_pause_signers
stellar contract invoke --id $ID --network $NET --source me -- get_token_update_delay_secs
stellar contract invoke --id $ID --network $NET --source me -- get_platform_fee

Compare a deployed binary with source (SEC-33; see note 2 about the image tag):

make build-docker
sha256sum $(find target -path '*release*' -name proof_of_heart.wasm)
stellar contract fetch --id $ID --network $NET --out-file deployed.wasm
sha256sum deployed.wasm

Community verification uses a token-gated, one-address-one-vote model (src/voting.rs, since #469):

• Eligibility: an address must hold at least the configured minimum balance of the platform token (get_min_voting_balance) at the time of voting, and may vote once per campaign (AlreadyVoted).
• Quorum: counts addresses that voted (approve + reject), compared against get_min_votes_quorum.
• Threshold: approval is computed from vote counts, not token balances, against get_approval_threshold_bps or the per-category override (get_category_voting_threshold). Balances are only an eligibility gate, so a flash-loaned balance cannot inflate voting weight.

Security assumptions and limitations:

• This mechanism is not sybil-resistant: anyone holding enough tokens can split them across many addresses that each meet the minimum balance, and every address gets one vote. That lets them inflate both the vote count and the approval ratio. The minimum voting balance is the main economic cost of doing this.
• The model assumes the token's distribution and issuance are outside the contract's control; if token minting is centralized or cheaply obtainable, governance can be captured.
• Admin verification (verify_campaign, verify_campaigns) is a privileged path; users should treat the stored admin as a trust assumption for campaign verification.

We follow a coordinated disclosure process. Please allow us reasonable time to investigate and patch the vulnerability before making any public disclosure.

Thank you for helping keep ProofOfHeart-stellar and its users safe.