We take security seriously. If you discover a vulnerability in sorokit-contracts, please report it responsibly to help us protect our users.

Please do not open a public GitHub issue for security vulnerabilities.

Instead, report security issues via email:

📧 security@sorokit.org

Include in your report:

• Description of the vulnerability
• Steps to reproduce
• Potential impact
• Suggested fix (if any)

We will:

• Acknowledge receipt within 24 hours
• Provide an initial assessment within 48 hours
• Release a fix within 7 days (for critical issues)
• Coordinate with you on disclosure timing

Security updates are provided for:

• Current version (v0.1.0) — Full support
• Patches applied to latest release branch

When deploying sorokit contracts:

1. Testnet Testing First

   • Deploy to testnet and test thoroughly
   • Verify all edge cases work as expected

2. Code Audit

   • Have smart contracts audited by security professionals
   • Use the provided test suite as a baseline

3. Key Management

   • Secure your deployment keys
   • Use hardware wallets for mainnet deployments
   • Never share private keys or seed phrases

4. Network Configuration

   • Verify network passphrases before deployment
   • Use official Stellar network endpoints
   • Validate contract addresses before interaction

Security best practices:

• Arbitrators: Choose trusted, independent arbitrators
• Amounts: Start with small amounts in production
• Verification: Users should verify counterparty addresses before depositing
• Disputes: The arbitrator has significant power; choose carefully

Security best practices:

• Admin Transfer: Transfer admin role only to trusted accounts
• Split Validation: Verify splits sum to 10000 before distribution
• Recipient Verification: Ensure all recipients are legitimate addresses
• Token Safety: Only use contracts with known, audited tokens

Security best practices:

• Whitelist Management: Audit reader whitelist regularly
• Data Sensitivity: Do not store sensitive data even with access control
• TTL Usage: Use TTL for temporary data; don't rely on expiry for secrets
• Version Tracking: Monitor version counter for unauthorized writes

1. State Transition Errors

   • User error (sending to wrong address)
   • Frontrunning attacks on Soroban RPC
   • Network latency causing transaction races

2. Token-Specific Risks

   • Non-standard token implementations
   • Wrapped token liquidity issues
   • Token pause/freeze mechanics

3. Oracle-Free Design

   • No price feeds or external data
   • Relies entirely on user input and contracts
   • No dispute mechanism for price disagreement

1. Private Key Exposure

   • Compromised deployment keys allow admin override
   • Lost keys make contract immutable

2. Network Selection

   • Mainnet vs testnet mistakes
   • Using wrong network passphrase

3. Contract Upgrades

   • No built-in upgrade mechanism
   • New deployments required for bug fixes
   • Data migration needed if state structure changes

✅ Do:

• Test thoroughly on testnet first
• Use well-known Stellar tokens (USDC, native XLM)
• Document contract configuration
• Monitor on-chain events
• Keep audit trail of admin actions

❌ Don't:

• Deploy untested code to mainnet
• Use beta or experimental tokens
• Disable access controls
• Mix mainnet and testnet addresses
• Give admin access to unknown parties

✅ Do:

• Verify contract addresses independently
• Start with small amounts
• Understand contract terms before sending funds
• Keep private keys secure
• Report suspicious activity

❌ Don't:

• Send funds to unverified addresses
• Use contracts you haven't read the code for
• Share transaction details with strangers
• Assume funds are recoverable if lost
• Use contracts during network instability

We practice coordinated responsible disclosure:

1. Discovery — Researcher finds vulnerability
2. Report — Report to security@sorokit.org with details
3. Triage — We assess severity and impact
4. Fix — We develop and test a patch
5. Disclosure — We release patch and credit researcher (if desired)
6. Public — Vulnerability details published after fix is live

We request a 60-90 day embargo period before public disclosure to allow time for deployment and user updates.

We thank the following researchers for responsibly disclosing vulnerabilities:

To be updated as security researchers responsibly disclose issues

• OWASP Smart Contract Top 10
• CWE/SANS Top 25
• Solana Security Guide

• cargo-audit — Vulnerability scanning
• cargo-tarpaulin — Code coverage

• Stellar Discord — #soroban-developers
• Sorokit GitHub Discussions

This security policy is published under the MIT License. It may be updated at any time without notice.

Last Updated: July 4, 2026

Questions? Contact: security@sorokit.org