Do not open a public GitHub issue for security vulnerabilities.

Report security issues by email to: security@paystream.example

Please include:

• A clear description of the vulnerability
• Steps to reproduce
• Potential impact assessment
• Any suggested mitigations (optional)

1. Submit — Email security@paystream.example with details.
2. Acknowledgement — You will receive confirmation within 48 hours.
3. Assessment — We evaluate severity and scope within 5 business days.
4. Resolution timeline — A fix target date is communicated within 7 days of receipt.
5. Patch & disclosure — We release a fix, then coordinate public disclosure with you.
6. Credit — With your permission, we acknowledge your contribution in the Hall of Fame.

• Give us reasonable time to address the issue before public disclosure.
• Do not exploit the vulnerability beyond what is necessary to demonstrate the issue.
• Do not access, modify, or delete data that does not belong to you.
• Do not disrupt production services or degrade user experience.
• Do not use social engineering, phishing, or physical attacks.
• Act in good faith throughout the process.

We commit to:

• Respond promptly and keep you informed of progress.
• Not pursue legal action against researchers acting in good faith.
• Work with you on an appropriate disclosure timeline.

In scope:

• Smart contracts in contracts/
• Deployment and initialization scripts
• GitHub Actions workflows

Out of scope:

• Third-party dependencies (report to the respective maintainer)
• Stellar network protocol issues (report to the Stellar Development Foundation)
• Issues requiring physical access to infrastructure

We currently operate a goodwill recognition program (not a paid bug bounty).

• Critical/High severity findings: Public acknowledgement + Hall of Fame listing
• Paid bounties may be introduced in a future program — watch this file for updates

We thank the following researchers for responsibly disclosing vulnerabilities:

Please encrypt your report using our PGP key (published at https://paystream.example/.well-known/security.txt).

Include in your report:

• A clear description of the vulnerability
• Steps to reproduce or a proof-of-concept
• Affected contract(s) and function(s)
• Potential impact assessment

We follow a coordinated disclosure model. We ask that you give us the time above to resolve the issue before any public disclosure.

The following are in scope for security reports:

• contracts/stream — salary streaming and escrow logic
• contracts/token — fungible payment token

• Loss or theft of user funds (deposits, withdrawals, refunds)
• Unauthorised access to admin functions
• Reentrancy or cross-contract call vulnerabilities
• Integer overflow / underflow leading to incorrect token amounts
• Replay attacks on admin operations
• Denial-of-service attacks that permanently lock funds
• Storage manipulation or data corruption
• Logic errors in claimable amount calculation
• Bypass of require_auth() checks

The following are not eligible for bug bounty rewards:

• Issues in third-party dependencies (Soroban SDK, Stellar core) — report those upstream
• Theoretical attacks with no practical exploit path
• Issues requiring physical access to a validator node
• Social engineering or phishing attacks
• Bugs in testnet deployments that do not affect mainnet logic
• Front-end or off-chain tooling (scripts, deploy helpers)
• Gas / resource fee optimisations (not a security issue)
• Issues already reported or known (see audits/remediation.md)
• Spam or denial-of-service via normal transaction volume

PayStream operates a pre-mainnet bug bounty programme.

Severity is assessed by the PayStream security team using the CVSS v3.1 framework. Rewards are paid after a fix is deployed and verified on testnet.

Note: The bug bounty programme is active for the contracts at the commit hashes listed in the latest audit report. Rewards are at the sole discretion of the PayStream team.

All high and medium findings from the April 2026 audit have been resolved. One low-severity finding (LOW-02: re-initialisation guard) remains open and must be resolved before mainnet deployment. See audits/remediation.md for the full status breakdown.

• All state-changing functions require explicit require_auth() from the relevant party
• Employer cannot withdraw employee funds; employee cannot access unearned funds
• Claimable amount is always capped at deposit - withdrawn — no over-payment possible
• Cancel pays employee their earned share first, then refunds employer the remainder
• Paused time is excluded from accrual — last_withdraw_time is reset on resume
• All token amounts use i128 — no floating-point arithmetic
• Stop time is validated to be in the future at stream creation
• Admin operations are protected by a monotonically-increasing nonce (replay protection)
• Two-step admin transfer prevents accidental loss of admin access
• Reentrancy guard (locked flag) on withdraw as defence-in-depth

For the full threat model see docs/security/threat-model.md.