The AtomicIP project handles real XLM and intellectual property assets through Soroban smart contracts. Security is critical to protect users' funds and IP rights.

We take security vulnerabilities seriously. If you discover a security vulnerability, please follow responsible disclosure practices.

DO NOT open a public GitHub issue for security vulnerabilities.

Instead, please report vulnerabilities via one of the following methods:

1. Email: Send a detailed report to security@atomicip.io
2. GitHub Security Advisories: Use the Security Advisories page

When reporting a vulnerability, please include:

• Description of the vulnerability
• Steps to reproduce the issue
• Potential impact assessment
• Suggested fix (if available)
• Any relevant logs or screenshots

• Initial Response: Within 48 hours of receipt
• Status Update: Within 7 days
• Fix Timeline: Depends on severity, typically 14-30 days

1. Acknowledgment: We will acknowledge receipt of your report within 48 hours
2. Investigation: Our team will investigate and validate the vulnerability
3. Fix Development: We will develop and test a fix
4. Disclosure: We will coordinate disclosure with you after the fix is deployed
5. Credit: We will credit you in the security advisory (unless you prefer anonymity)

• Keep your secret safe: The secret used to create your commitment hash is the only way to prove ownership. Store it securely offline.
• Verify commitment hashes: Before committing, verify your commitment hash is correctly computed: sha256(secret || blinding_factor)
• Use strong secrets: Use cryptographically secure random values for secrets and blinding factors
• Backup your keys: Maintain secure backups of your Stellar wallet keys

• Verify swap details: Always verify the IP ID, price, and counterparty before accepting a swap
• Check expiry times: Be aware of swap expiry times to avoid losing funds
• Use trusted registries: Only interact with verified IP registry contracts
• Monitor transactions: Review transaction details before signing

1. No Token Escrow: The current implementation does not escrow tokens during swaps. Payment is transferred to the contract but not held in escrow. This will be addressed in v1.1.

2. Single Network: Currently only supports Stellar testnet. Mainnet support is planned for v1.0.

3. No Partial Disclosure: The commitment scheme requires full secret revelation. Partial disclosure proofs are planned for v2.0.

4. Gas Costs: Complex operations may have higher gas costs. Optimization is ongoing.

5. Frontend Not Included: The current repository contains only smart contracts. A frontend UI is planned for v3.0.

• Users maintain secure storage of their secrets and private keys
• The Stellar network operates as expected
• Soroban runtime is secure and bug-free
• Cryptographic primitives (SHA256) are secure

• ✅ Pedersen commitment scheme for IP privacy
• ✅ Atomic swap with key verification
• ✅ Authorization checks via require_auth()
• ✅ Duplicate commitment prevention
• ✅ Expiry-based cancellation for buyers
• ✅ Monotonic ID generation (upgrade-safe)

• 🔄 Token escrow in atomic swaps
• 🔄 Multi-signature support
• 🔄 Time-locked commitments
• 🔄 Partial disclosure proofs

The API server (api-server/src/audit.rs) maintains a hash-chained (HMAC-SHA256) audit log of commitment, swap, and admin events.

• Durability: every event is appended to a durable, append-only file and fsynced before the write is acknowledged. On startup, the store replays that file to resume the existing chain (previous_signature and sequence) instead of starting a new one — a process restart does not reset or fork the chain.
• Key management: AUDIT_HMAC_KEY must be set from durable configuration/secret storage. If it is absent, the server fails to start rather than silently signing the chain with a randomly generated, unrecoverable key.
• Multi-instance safety: concurrent instances sharing the same backing store coordinate appends through an exclusive file lock and always derive the next sequence number from the store's own current tail, so replicas behind a load balancer cannot assign colliding sequence numbers.
• Independent verification: audit::verify_persisted_chain walks the persisted file and confirms every signature matches its previous_signature linkage. It only needs read access to the backing file and the HMAC key, so an outside auditor can run it without any cooperation from a live server instance.

When re-enabling a previously-disabled test module (especially those related to fund safety, upgrade safety, or security-critical operations), the following security review must be performed:

• Security impact assessment: Document why the test was originally disabled and verify the underlying issue is resolved
• Authorization checks: Verify all entry points in the test's target code call require_auth() appropriately
• Fund safety: If the test covers fund operations (escrow, transfers, swaps), ensure no edge cases allow fund loss or theft
• State invariants: Confirm that the test validates critical state invariants (e.g., token conservation, ownership verification)
• Upgrade safety: For any disabled tests related to contract upgrades, verify backwards compatibility and migration safety
• Threat model coverage: Ensure the re-enabled test covers attack scenarios documented in docs/threat-model.md
• Code review: Obtain at least one approval from a team member familiar with the affected module
• Manual testing: Perform manual testing against testnet if the test covers user-facing functionality

The following disabled test modules are security-critical and require the checklist above before re-enablement:

• upgrade_chaos_tests (#19) — covers contract upgrade safety and state consistency
• escrow_tests (#20) — covers fund safety and payment verification
• batch_swap_features_tests (#22) — covers atomic swap correctness and fund recovery

For complete threat analysis, refer to:

• docs/threat-model.md for attack scenarios
• SECURITY.md for API server audit log procedures
• The PR that re-enables the test must include security sign-off notes

Every commit is scanned automatically in CI/CD using Gitleaks to detect:

• API keys, JWT secrets, and authentication tokens
• Stellar keypairs and private keys
• Database connection strings with embedded credentials
• HMAC keys and other cryptographic material

Configuration is defined in .gitleaks.toml with patterns for:

• Stellar keypairs (S-prefixed 56-character strings)
• JWT secrets and bearer tokens
• Generic API keys (api_key, apikey patterns)
• Database passwords in connection strings
• HMAC signing keys

Scan Coverage:

• Full history: On initial CI setup or when requested, the entire git history is scanned
• PR diffs: Every pull request scans only the changed lines against baseline
• Allowlist: Common false positives (example_, test_, placeholder) are excluded

If a secret is detected in the commit history (either pre-emptively in CI or discovered post-facto):

1. Immediate Actions:

   • If the secret is a Stellar keypair or API credential: rotate the key immediately on the affected service (Stellar account, API server, database)
   • If the secret is a test/example key: verify it is only for testing; verify the file is in .gitignore and will not be committed
   • Open a private security issue (not public) to coordinate response

2. Remediation:

   • If the commit is on main or already published: use git filter-repo or BFG Repo-Cleaner to remove the secret from history
   • Re-write the git history to remove the commit containing the secret
   • Force-push the cleaned history (with security team approval)
   • Notify users and stakeholders of the exposure window

3. Audit & Documentation:

   • Log the incident in the security advisory section: who discovered it, when, what was exposed, and the remediation steps
   • Update threat model or security posture documentation if the incident reveals a new risk
   • Review .gitleaks.toml configuration to ensure the secret pattern is detected by the scanner

4. Prevention:

   • Add the secret pattern to .gitleaks.toml if it is not already covered
   • Ensure all developers run Gitleaks locally before committing (gitleaks detect --source . -v)
   • Add a pre-commit hook to reject commits with detected secrets (see Pre-Commit Hooks)

Before committing, scan your changes:

gitleaks detect --source . -v

To scan the full repository history:

gitleaks detect --source . --verbose

To ignore a specific secret (use sparingly):

echo "allowlist: [<SECRET_LINE>]" >> .gitleaks.toml

Add this to .git/hooks/pre-commit to block commits with secrets:

#!/bin/bash
gitleaks detect --staged -v --exit-code 1

Every push and pull request is scanned automatically in CI/CD:

• Security scanning — supply-chain policy (cargo-deny), secret detection (gitleaks), and static analysis. See Security Scanning.
• Dependency vulnerability scanning — cargo-audit + cargo-deny against the RustSec advisory database, plus Dependabot. See Dependency Scanning.
• Code coverage enforcement — a minimum coverage threshold is enforced in CI. See Code Coverage.
• Mutation testing — verifies the test suite catches logic errors. See Mutation Testing.

Run all gates locally with ./scripts/security-checks.sh.

• Initial Review: Internal security review completed
• External Audit: Planned for Q2 2026
• Bug Bounty: Planned for post-mainnet launch

Audit reports will be published in the security-advisories section after completion.

For security-related inquiries:

• Security Team: security@atomicip.io
• General Contact: contact@atomicip.io
• GitHub: Security Advisories

We plan to launch a bug bounty program after mainnet launch. Rewards will be based on severity:

• Critical: $5,000 - $25,000
• High: $1,000 - $5,000
• Medium: $500 - $1,000
• Low: $100 - $500

Details will be published at bugbounty.atomicip.io when the program launches.

AtomicIP is designed to comply with the General Data Protection Regulation (GDPR) requirements for user data protection.

• Data Controller: AtomicIP Foundation (contact@atomicip.io)
• Data Processor: Stellar Network (for on-chain data)
• Data Protection Officer: dpo@atomicip.io

When a user requests data deletion (POST /v1/gdpr/delete), the following actions occur:

1. Cache Invalidation: All cached IP lists, swap lists, and reputation data for the user are immediately invalidated
2. On-Chain Data: Smart contract data (IP records, swaps) cannot be deleted from the immutable ledger, but IP records can be revoked
3. Audit Log: Audit events linked to the user are anonymized
4. Webhook Events: Pending webhook deliveries for the user are cancelled
5. Confirmation Required: The request must include a confirmation: "DELETE" field to prevent accidental deletions

Data export responses (POST /v1/gdpr/export) include:

• User's Stellar address
• All IP records owned by the user
• All swap records involving the user
• All audit events linked to the user
• Export timestamp and data retention period

API responses are designed to be accessible to all clients:

• JSON Schema Consistency: All responses use snake_case field names, consistent pagination structure, and machine-readable data types
• Error Format Consistency: All errors return {"error": "message"} JSON format
• Content-Type: All responses use application/json content type
• Version Negotiation: Clients can specify API version via Accept-Version or X-API-Version headers
• Public Endpoints: Health, docs, and version endpoints require no authentication
• Minimal Payloads: All mutation endpoints accept minimal payloads with only required fields
• Machine-Readable Timestamps: All timestamps use Unix epoch (u64 seconds)
• Nullable Fields: Nullable fields use explicit null instead of field absence

While WCAG (Web Content Accessibility Guidelines) primarily applies to user interfaces, our API follows accessibility best practices:

1. Perceivable: JSON responses are machine-readable and parseable by any HTTP client
2. Operable: All endpoints are navigable via URI patterns; pagination prevents timeout
3. Understandable: Consistent error formats, snake_case naming, and semantic versioning
4. Robust: Responses include all required fields even when empty; content negotiation via Accept header

A Data Protection Impact Assessment has been conducted for the following processing activities:

• IP commitment and ownership tracking (on-chain)
• Atomic swap execution (on-chain)
• API request logging and audit trails
• Webhook event delivery

Risk Level: Medium — The system primarily processes cryptographic hashes and Stellar addresses, not personal identifiable information (PII). The immutable nature of blockchain data is mitigated by the use of commitment hashes rather than raw content.

In the event of a data breach:

1. Internal detection and verification (within 24 hours)
2. Containment measures applied
3. Supervisory authority notification (within 72 hours per GDPR Art. 33)
4. Affected users notified (without undue delay per GDPR Art. 34)
5. Post-incident review and remediation

Automated compliance tests run in CI/CD to verify:

• Error response format compliance
• Health endpoint required fields
• API versioning enforcement
• GDPR data export and deletion request validation
• Data retention policy declaration
• Cache invalidation on data deletion
• JSON schema consistency
• Webhook delivery status tracking

This security policy is subject to our Terms of Service and Privacy Policy.

Last Updated: 2026-06-24 Version: 2.0.0