Location: complete-deposit-wrapper — missing validation

Description: The contract accepts any amount ≥ 546 (dust limit) but has no concept of fees or minimum net amount. In the sBTC protocol, Bitcoin deposits include a max_fee parameter set by the user. If max_fee >= amount, the sBTC signers will skip the deposit because there would be zero or negative sBTC to mint after fees. However, nothing in the contract or the Bitcoin-side deposit script prevents a user from setting max_fee >= amount.

This results in permanently stuck BTC: the Bitcoin is sent to the peg address, but signers will never call complete-deposit-wrapper for it because the economics don't work. The BTC cannot be recovered.

Impact: Users lose funds. We personally experienced this: 5,000 sats stuck in a deposit where maxFee ≥ amount. The signers simply never process it. There is no reclaim mechanism.

Recommendation:

1. The deposit request script on Bitcoin should enforce max_fee < amount - dust_limit at the script level
2. Alternatively, signers should process these deposits by minting amount - max_fee (even if tiny) rather than silently skipping them
3. A reclaim/refund mechanism should exist for deposits that signers cannot or will not process
4. At minimum, front-end UIs should validate max_fee < amount before broadcasting

Note: This is partially an off-chain/signer issue, but the lack of any on-chain reclaim path makes it a High severity finding for the protocol as a whole.

Location: complete-individual-deposits-helper

Description: The complete-deposits-wrapper uses fold with complete-individual-deposits-helper. If any individual deposit fails (e.g., replay, bad burn hash), the error is propagated and all subsequent deposits in the batch are skipped. The fold returns the error and stops processing.

(match helper-response
  index
    (begin
      (unwrap!
        (complete-deposit-wrapper ...)
      (err (+ ERR_DEPOSIT_INDEX_PREFIX (+ u10 index))))
      (ok (+ index u1))
    )
  err-response
    (err err-response)
)

The err-response match arm short-circuits — once one deposit fails, all remaining deposits in the list are never processed.

Impact: A single invalid deposit in a batch of 500 blocks all deposits after it. Signers must carefully order/filter deposits, or retry with the failing deposit removed. This is a DoS vector on deposit throughput.

Recommendation: Use a "skip on error" pattern instead of aborting. Return an (ok) with an error log for failed individual deposits, allowing the fold to continue processing remaining deposits.

Location: complete-deposit-wrapper — amount validation

Description: The contract only enforces amount >= dust-limit (546 sats) with no upper bound. A compromised or buggy signer could mint an arbitrary amount of sBTC in a single transaction.

Impact: If the signer key is compromised, an attacker can mint unlimited sBTC. While this is inherent to the trust model (signers are trusted), a sanity cap (e.g., no single deposit > 21M BTC worth of sats) would limit blast radius.

Recommendation: Add a reasonable per-deposit cap as a safety rail, even if set very high (e.g., 2,100,000,000,000,000 sats = 21M BTC). This limits damage from key compromise or bugs.

Location: complete-individual-deposits-helper

Description: The error encoding is ERR_DEPOSIT_INDEX_PREFIX + 10 + index. ERR_DEPOSIT_INDEX_PREFIX is u303. So errors are u313, u314, etc. For large batches (index > ~696), these could theoretically collide with other protocol error codes, though in practice the list is capped at 500 items (max error = u813).

Impact: Low — error codes could be confusing but functional impact is minimal.

Recommendation: Use a dedicated error range (e.g., u10000 + index) to avoid any possible collision.

Location: complete-deposit-wrapper

Description: The deposit contract itself emits no print events. Events are only emitted by sbtc-registry.complete-deposit. If the registry call fails after minting, the mint event exists but no deposit-completion event is emitted, making it harder to track partial failures.

Impact: Low — observability gap. The registry does emit events, but a failed registry call after successful mint would leave an inconsistent state with no deposit event.

Recommendation: Emit a print event in the deposit contract itself for better observability.

Description: The contract uses .sbtc-registry and .sbtc-token relative references and does not use Clarity 4's as-contract? with explicit asset allowances. While this contract doesn't use as-contract at all (minting is done via contract-call? to the token), future upgrades should adopt Clarity 4 patterns.

Recommendation: When upgrading, migrate to Clarity 4 for as-contract? with explicit asset allowances and contract-hash? for verifying contract integrity.

Description: The current-signer-principal is a single address checked via is-eq tx-sender. This represents the multisig output of the signer set, but on-chain it appears as a single principal. Key rotation is handled by sbtc-registry.rotate-keys (governance-only).

Impact: Standard for the sBTC design. The signer set is the root of trust. If compromised, unlimited minting is possible.

Recommendation: Informational — this is the intended design. Consider time-locked minting caps as defense-in-depth.

Description: The recipient parameter is an unchecked principal. Signers could (accidentally or maliciously) mint sBTC to any address, including the contract itself or burn addresses.

Impact: Low likelihood given trusted signers, but no guardrails exist.

Recommendation: Consider basic validation (e.g., recipient is a standard principal, not a contract principal) if the protocol intends deposits only for user wallets.