Pattern A: The Self-Transfer No-Op

From a P2P lending contract — every outbound transfer was broken:

;; ❌ BROKEN (Clarity 3): transfers from contract → contract (no-op)
(as-contract (stx-transfer? amount tx-sender tx-sender))

;; ✅ Clarity 4 fix: explicit allowances prevent this confusion
(let ((caller tx-sender))
  (as-contract? (with-stx)
    (stx-transfer? amount tx-sender caller)))

The developer intended tx-sender to mean "the user who called this function." But inside as-contract, both the sender and recipient resolve to the contract itself. Every withdrawal, loan disbursement, collateral return, and liquidation payout was silently doing nothing. Five critical functions — all dead:

• withdraw-funds — lenders could never withdraw deposits
• borrow — borrowers posted collateral but never received loans
• repay — borrowers repaid debt but collateral was never returned
• liquidate — liquidators paid debt but got no collateral
• withdraw-collateral — collateral permanently locked

Pattern B: The Wrong-Sender Transfer

From a multisig wallet — deposits went to the owner, not the contract:

;; ❌ BROKEN (Clarity 3): deposits go to CONTRACT-OWNER's personal address
(try! (stx-transfer? amount tx-sender CONTRACT-OWNER))

;; ❌ BROKEN (Clarity 3): execution pulls from the executor's own balance
(try! (stx-transfer? (get amount tx) tx-sender (get to tx)))

;; ✅ Clarity 4 fix: contract executes with explicit STX allowance
(as-contract? (with-stx)
  (try! (stx-transfer? (get amount tx) tx-sender (get to tx))))

The contract never held any funds. The entire multisig approval process was theater — the owner personally funded every transfer at execution time.

Pattern C: The Stake-to-Owner Funnel

From a bug bounty platform:

;; Nominally "burns" forfeited stakes, actually sends to owner
(define-private (burn-stake (amount uint))
    (as-contract (stx-transfer? amount tx-sender CONTRACT-OWNER))
)

;; ✅ Clarity 4 fix: burn to a real burn address with explicit allowance
(define-private (burn-stake (amount uint))
    (as-contract? (with-stx)
        (stx-transfer? amount tx-sender BURN-ADDRESS))
)

Inside as-contract, tx-sender correctly refers to the contract (the holder of the stakes). But the "burn" function sends to the contract owner, creating a perverse incentive: the owner profits from rejected reports.

Bounties Calculated, Never Paid

From a bug bounty platform:

;; Bounty is computed and recorded...
(var-set total-bounties-paid (+ (var-get total-bounties-paid) final-bounty))

;; Stakes are returned (this works)...
(try! (return-stake reporter staked))

;; But where's the stx-transfer? for the bounty itself?
;; Nowhere. It doesn't exist.

The contract tracked total-bounties-paid in a data variable. The number went up. But no STX ever moved. The entire economic incentive of the platform was cosmetic.

Bridge Records Transfers, Never Executes Them

From a cross-chain bridge contract:

;; initiate-transfer records the request in a map...
(map-set transfer-requests request-id { 
  sender: tx-sender, amount: amount, status: STATUS-PENDING })

;; AI risk assessment approves it...
(map-set transfer-requests request-id 
  (merge request { status: STATUS-APPROVED }))

;; But there's no function that actually calls stx-transfer?
;; Approved transfers have no on-chain effect.

The bridge had risk scoring, multi-agent validation, daily volume limits — an entire security apparatus protecting transfers that never happen.

NFT Sale Completes Without NFT Transfer

From a social platform with NFT marketplace features:

;; buy-nft records the sale in history, marks listing inactive
;; buyer's STX is transferred to seller ✓
;; but the NFT itself? Never transferred.
;; The buyer pays and receives nothing.

Underflow Wrapping: Signer Count Goes to Max-Uint

From a multisig wallet:

;; ❌ No check if signer actually exists before decrementing
(var-set signer-count (- (var-get signer-count) u1))

If remove-signer is called for a non-existent signer, the count underflows. In Clarity, u0 - u1 causes a runtime abort (not a wrap to max-uint), which would revert the transaction. But the deeper issue is: there's no check that the signer exists at all, so the intent was clearly wrong.

Refund Underflow Blocks All Refunds

From an AMM prediction market:

;; Refund calculates: user's original shares minus shares they traded
;; But after swaps, traded shares can exceed original deposit
;; Result: underflow → transaction aborts → no refund possible

Users who traded in the AMM could never get refunds if the market was cancelled, because the refund calculation assumed shares only decreased — ignoring that AMM swaps could redistribute shares.

Multiplication Overflow in AMM Math

From the same prediction market:

;; mul-down: fixed-point multiplication
;; If a * b overflows u128, the function returns max-uint
;; instead of aborting — silently corrupting all AMM pricing

The mul-down helper was designed to handle overflow "gracefully" by returning u340282366920938463463374607431768211455 (max uint128). But this doesn't fail — it returns a garbage value that propagates through every subsequent calculation, making trades execute at wildly wrong prices.

Anyone Can Call Admin Functions

From a prediction market — the most dangerous instance:

;; ❌ mock-resolve-market: no authorization check at all
;; Anyone can call this to resolve any market in their favor
;; and drain the entire vault

A market resolution function with no access control. Any user could declare themselves the winner and claim all funds.

Anyone Can Cancel

From a jackpot contract:

(define-public (cancel-pot (pot-contract <stackspot-trait>))
  ;; No check on tx-sender at all
  ;; Anyone can cancel any active pot
  ...
)

Tokens That Can Never Exist

From a yield staking platform:

;; ❌ Max supply = 0. ft-mint? will ALWAYS fail.
(define-fungible-token YIELD-ANALYTICS-TOKEN u0)

The second argument to define-fungible-token is the maximum supply. Setting it to u0 means zero tokens can ever be minted. The entire reward system — staking, yield calculation, tier multipliers, lock durations — all of it feeds into a mint that always fails.

The contract had 300+ lines of staking logic, yield multipliers up to 90,000x, governance power calculations — all computing rewards for a token that cannot exist.

Infinite Recursion by Accident

From a DAO's voting escrow contract:

(define-private (to-int (value uint))
  (if (< value u9223372036854775807)
    (to-int value)   ;; ← calls ITSELF, not the built-in to-int
    0))

The developer defined a helper called to-int — the same name as the Clarity built-in that converts uint to int. In Clarity, user-defined functions shadow builtins. So the recursive call to to-int calls the user's function, not the builtin, creating infinite recursion.

Every function that called checkpoint (which called to-int) would hit the runtime recursion limit and abort. This meant: no locks could be created, no amounts could be increased, no unlock times could be extended. The entire voting escrow — the centerpiece of the DAO — was dead on arrival.