Please DO NOT open public GitHub issues for security vulnerabilities.

Report vulnerabilities privately through GitHub's built-in private vulnerability reporting, which does not depend on any external mail server:

1. Open the Security Advisories page for this repository.
2. Click Report a vulnerability.
3. Fill in the advisory form and Include:
   • Detailed description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested fix (if any)

This opens a private thread visible only to you and the maintainers; no special repository permissions are required to submit a report.

If you cannot use GitHub's private reporting, open a public issue titled [SECURITY] Private contact request that contains no vulnerability details and a maintainer will follow up with a private channel.

• Initial Response: Within 48 hours
• Status Update: Within 7 days
• Fix Timeline: Depends on severity
  • Critical: 1-3 days
  • High: 1-2 weeks
  • Medium: 2-4 weeks
  • Low: Next release cycle

• We practice coordinated disclosure
• We will work with you to understand and fix the issue
• Public disclosure after fix is deployed (typically 90 days)
• You will be credited in our security advisories (if desired)

• All production smart contracts on Mainnet
• Testnet contracts for design flaws only

• Critical: $10,000 - $50,000 (funds at risk)
• High: $5,000 - $10,000 (significant impact)
• Medium: $1,000 - $5,000 (moderate impact)
• Low: $100 - $1,000 (minimal impact)

• Issues in third-party dependencies
• Known issues already reported
• Theoretical vulnerabilities without proof of concept
• Social engineering attacks
• DoS attacks on public endpoints

• Be respectful and professional
• Do not publicly disclose before fix
• Do not exploit vulnerabilities
• Provide clear reproduction steps
• One bounty per unique vulnerability

1. Never share your private keys
2. Verify contract addresses before interacting
3. Use hardware wallets for large amounts
4. Monitor your transactions
5. Report suspicious activity

1. Read our Security Audit Checklist
2. Follow Stellar security guidelines
3. Review all PRs for security implications
4. Keep dependencies updated
5. Use static analysis tools

• Two-step admin transfer
• Per-function authorization checks
• No hidden backdoors
• All privileged operations emit events

• Checks-effects-interactions pattern
• Balance verification before transfers
• Saturating math to prevent overflow
• Escrow isolation

• Comprehensive state transition validation
• TTL management for all storage
• No orphaned state possible
• Atomic operations

• Least-privilege CI. All four GitHub Actions workflows declare explicit permissions blocks: the release job gets contents: write (the minimum softprops/action-gh-release needs to create a release and upload assets), every other job gets contents: read. This keeps releases working under a read-only default token and bounds what a compromised third-party action can reach.
• Locked dependency resolution. Every cargo invocation across CI, release, and testnet deploy uses --locked, so published WASM artifacts and their recorded SHA256 checksums are built from exactly the dependency set the test suite validated, and rebuilding a tag is reproducible.
• Version-consistency guard. release.yml refuses to build or publish when the pushed vX.Y.Z tag disagrees with the version declared by the workspace crates (or when the crates disagree with each other).

The project uses three distinct version numbers; they are intentionally not the same thing:

• Private vulnerability reporting: GitHub Security Advisories
• Discord: FaniLab Official Server

• Security Audit Checklist
• Deployment Guide
• Testing Guide
• Stellar Security Best Practices

Last Updated: August 2026