Security updates are applied to the default branch and the latest released contract version.

Please report suspected vulnerabilities privately through GitHub Security Advisories for this repository. Do not open a public issue or pull request that includes exploit details, private keys, account data, or reproduction steps that could put users at risk.

When possible, include:

• A clear description of the vulnerability and affected code path.
• Minimal reproduction steps or a proof of concept.
• Potential impact, including affected assets or permissions.
• Suggested remediation, if you already have one.

If GitHub Security Advisories are unavailable, open a GitHub Discussion or issue that asks for a private security contact without including sensitive details.

The maintainers aim to:

1. Acknowledge valid reports within 3 business days.
2. Triage severity and affected versions within 7 business days.
3. Prepare and test a fix before public disclosure.
4. Credit reporters in release notes when requested and appropriate.

Public disclosure should wait until a fix is available or the maintainers agree on a coordinated disclosure date.

Reports are in scope when they affect the StellarTip contract, deployment scripts, CI, or repository configuration in a way that could compromise contract funds, admin controls, user balances, privacy, or release integrity.

Out-of-scope reports include spam, social engineering, denial-of-service against third-party services, and vulnerabilities that require already-compromised maintainer credentials.

This section documents a STRIDE threat model for the current contract (CONTRACT_VERSION = 3, the init() signature that includes min_tip_amount). Each mitigation links to the issue(s) that introduced it; protections that predate issue tracking are labelled "initial design (v0.1.0)".

Assets

• Creator internal balances (Balance(creator, token) persistent entries) and the tokens the contract holds in custody on their behalf.
• The admin role (pause control, fee configuration, caps, admin rotation).
• The profile and username registry (Profile, UsernameToAddress).
• Tip history (Tip, TipCount persistent entries) as an auditable record.

Actors

• Supporter — any wallet calling tip().
• Creator — a registered profile owner who can withdraw(), update_profile(), and unregister().
• Admin — the address set at init() (or via set_admin()); controls pause, fees, and caps.
• Deployer — uploads the WASM and is expected to call init() immediately.
• Anonymous caller — anyone invoking view functions; reads are unauthenticated by design.

Trust boundaries

• Wallet authorization: every state-changing function calls require_auth() on the acting address; the contract performs no signature verification of its own.
• External calls: token movements go through Stellar Asset Contract (SAC) token::Client transfers — the token contracts are outside this contract's trust domain, and the contract assumes only that a transfer of amount moves amount; it does not verify this and does not reconcile its internal ledger against token balances (see Residual Risks).
• Storage tiers: instance storage (shared config) vs. persistent storage (per-creator data) have independent TTL lifecycles.

• Init front-running. The first caller of init() after deployment becomes admin. Mitigation is procedural — deploy and initialize atomically (see scripts/deploy.sh). No in-contract protection; no tracked issue.

• Single admin key. There is no multisig or timelock. A compromised admin key enables pause abuse and fee redirection. Fee redirection is bounded: fee_bps is capped at 10,000 (100%) and applies only to future tips — existing creator balances can only ever be withdrawn by the creator.

• Unbounded limit in get_tips(). Documented as M-2 in docs/static-analysis-findings.md. Impact is limited to instruction-budget exhaustion of the caller's own read; no state risk.

• DEFAULT_MIN_TIP_AMOUNT = 1 provides no real dust protection. It is equivalent to the amount > 0 guard. Admins must raise it via set_min_tip_amount post-deploy for meaningful protection.

• The custody invariant is implicit and unenforced. The contract relies on sum(internal balances for token T) == T.balance(contract) but never checks it: tip() credits the amount argument and withdraw() debits it, and neither reads token.balance(). Any token that moves holder balances outside a transfer breaks the invariant — rebasing tokens (stETH, aTokens), fee-on-transfer tokens (the contract receives less than amount but credits the full amount), and tokens with clawback enabled. All three are legal SEP-41 tokens.

  Consequences are bounded to the offending token and are published behaviour, not latent bugs. An upward rebase strands surplus in the contract permanently — there is no sweep function. A downward rebase leaves the contract under-collateralised: withdrawals revert inside the token contract rather than with a TipError, and the last creators to withdraw absorb the shortfall. A wipeout leaves unregister() blocked by BalanceNotEmpty, since internal credit survives a token balance going to zero.

  Choosing which tokens to accept is the supporter's and the creator's responsibility. The rebasing case is characterised by the fixture in src/fixtures.rs and the tests in src/test.rs; a fee-on-transfer fixture is worth a follow-up issue.

This threat model describes CONTRACT_VERSION = 3. Because deployed Soroban WASM is immutable, any change to the contract surface (new functions, storage keys, or an init() signature change) ships as a redeployment — and must be accompanied by a review of this section in the same pull request. Reviewers should treat a CONTRACT_VERSION bump without a threat-model update as a blocking omission.