The Williams team takes the security of our smart contracts and protocol infrastructure seriously. As a protocol managing trustless inheritance and user funds on Stellar Soroban, we encourage responsible disclosure of any security vulnerabilities.

Only the latest code on the main branch and currently active deployments are actively supported for security updates:

Do not report security vulnerabilities via public GitHub issues, discussions, or pull requests.

If you discover a security vulnerability, please report it privately using one of the following methods:

1. GitHub Private Vulnerability Reporting (Preferred):

   • Navigate to the Security Advisories tab of the repository.
   • Click "Report a vulnerability" to submit a confidential report directly to the maintainers.

2. Email Disclosure:

   • If Private Vulnerability Reporting is unavailable, send your findings to security@williams.org.
   • Include a detailed description of the vulnerability, steps or proof-of-concept (PoC) code to reproduce it, and the potential impact on user funds or contract execution.

• Initial Acknowledgment: Within 48 hours of receiving your report.
• Triage & Assessment: Within 5 business days, detailing validity, severity classification, and expected remediation timeline.
• Fix & Public Disclosure: Fixes will be coordinated and deployed prior to any public advisory release.

If you conduct security research in good faith and follow these guidelines, we will:

• Consider your research to be authorized and refrain from taking legal action against you.
• Work with you to understand and remediate the issue promptly.
• Recognize your contribution in our security advisories and reward pool (where applicable).

• Do not compromise user funds: Test vulnerabilities against local Soroban test environments or mock data on Testnet. Do not attempt to drain live contract instances.
• Maintain confidentiality: Keep information about discovered vulnerabilities private until a fix has been released and coordinated disclosure is agreed upon.
• Avoid disruptive testing: Do not perform Denial of Service (DoS) attacks, spam transactions, or social engineering against maintainers.

• Smart contract source code under contracts/will/
• Storage layouts, authorization logic, and state transitions
• Inherited token handling and balance calculation logic

• Third-party protocols and external RPC providers
• Social engineering, phishing, or physical attacks
• Issues in un-deployed or experimental code branches

A hashed beneficiary claims by revealing a pre-image of the commitment stored on the will. That pre-image is public once the claim transaction is submitted, so without extra checks an observer could replay it or front-run it. The contract mitigates this as follows:

• One claim per slot. Each hashed slot has a claimed flag, which is set and persisted in the same invocation that pays out, before the token transfer. Any later call for that slot fails with AlreadyClaimed.
• Pre-image bound to the recipient. The pre-image must be claimant.to_xdr() || salt. The contract checks the prefix against the claimant argument, and claimant must authorize the call. Someone who copies the pre-image cannot redirect the payout to their own address.
• Signed invocations cannot be replayed. Soroban authorization entries carry a nonce and an expiration ledger.

Integrators must build commitments as sha256(beneficiary_address.to_xdr() || salt) with a random salt of at least 16 bytes. A commitment built any other way can never be claimed.

Williams assumes that all deposited tokens adhere to standard SEP-41 semantics without deduction on transfer (balance_transferred == amount).

• Threat Model: If a deflationary or fee-on-transfer token is deposited via create_will or top_up, the actual tokens received by the contract will be strictly less than the nominal amount recorded in the will's internal balance. When distribute() attempts to pay out beneficiaries or cancel_will() refunds the owner, the contract will attempt to transfer more tokens than it holds, causing the transaction to revert and trapping the remaining funds.
• Mitigation: Users and integrators must only deposit standard 1:1 SEP-41 tokens without transfer fees. Tokens with burn-on-transfer, fee-on-transfer, reflection, or rebasing mechanisms are unsupported.

Resolutions for verified security vulnerabilities reported under this policy are eligible for recognition and reward distribution through the Stellar Wave Program on Drips. Point allocations are determined based on severity classification (Critical, High, Medium, Low).