Audit 21k: jing v3 blind-batch-auction market + MM vaults + core (Clarity/Stacks, pre-deploy)

Rigorous confirmation across all 4 named attack surfaces (market maker-gate/partial-fill/staleness/cancel-cycle, vault intent-hash/replay/allowances, core register/ownership/equity, USDCx parity). No exploitable bug found, but the cancel-cycle x small-share-roll trace (your "state-overwrite" hint) got the deepest scrutiny — I traced it as fixed in v3 via the additive totals-next merge and disjoint write sets, with high but not absolute confidence, and I flag a concrete residual gap: none of your 14 documented invariants target this specific cross-map balance identity, so I recommend adding one. Also confirmed cross-vault intent-hash replay is impossible by reading jing-vault-auth.clar directly (vault: contract-caller is in the SIP-018 preimage) — this required fetching a file outside the bounty's listed 5 contracts. One more hardening note on core's debit() silently clamping instead of asserting on over-debit. Full writeup with file/line detail for every ruled-out surface at the gist link. STX payout: SPG6VGJ5GTG5QKBV2ZV03219GSGH37PJGXQYXP47

Rigorous adversarial audit of all 6 Clarity contracts (~5,000 lines). No exploitable fund-loss bug found, but report goes deeper than existing submission #1 with:

New findings:

1. USDCx vault missing deposit-stx — operational DoS risk when STX balance drops to 0 (all VAA-carrying paths fail)
2. cancel-cycle doesn't zero pending-rebate-x/y — confirmed safe today but latent footgun (explicit fix provided)
3. as-contract? () cancel-path analysis — market can pull vault funds? NO, confirmed safe

Enhanced analysis:

• Pending-rebate lifecycle traced through cancel-cycle (always u0 between txs)
• USDCx parity verified down to individual transfer calls
• Core debit() silent clamping — equity desync window documented
• 6 hardening suggestions for v4
• 8 attack vectors mapped with status

STX payout: SP2YTGB7CDQP1E4T79CQMJ1DT7JB3VH4JMMEB4KEJ

Adversarial audit of the 5 scoped contracts + jing-vault-auth. Two findings. Full writeup: https://buffyworker.pythonanywhere.com/jing-audit-report (opens in new tab)

F1 (Medium, missing guard): jing-core-v3.register (jing-core-v3.clar:253-272) lacks the documented tx-sender == contract-owner guard. JING-CORE-DESIGN.md:18-65 documents the bytecode-replay attack (deploy hash-matching bytecode at your own principal, register under a verified canonical, write arbitrary log-* events with attacker-chosen tokens) and the fix (assert tx-sender == contract-owner in register, DESIGN.md:56-65). The fix is absent in ALL versions (v1 :411-430, v2 :119-132, v3 :253-272). Path: vault.initialize (vault-sbtc-stx-v2.clar:90-101 / usdcx :90-101) has NO owner gate and calls register (line 98). Deploy a bytecode-identical vault copy, call initialize(canonical) -> hash matches -> registered. Registration is one-way: permanently bricks the official vault's initialize (ERR_ALREADY_REGISTERED forever) and grants the clone arbitrary log-* access + event/equity pollution. Market path is closed in v3; the vault pair is the open vector. Fix: add the documented assert to register and/or gate vault.initialize.

F2 (Low/Medium, accounting): equity ledger double-counts vault principal. vault deposit-sbtc/deposit-stx -> log-deposit credits the VAULT's equity unconditionally (jing-core-v3.clar:277-291); execute-jing-deposit (vault-sbtc-stx-v2.clar:217-256) then moves the same principal into the market as-contract, where the market's log-deposit-x/y credits the KEEPER (tx-sender, credit-if-not-registered at :393-470). The vault never debits its own bucket, so total-token-equity over-states real balance by the parked amount and get-balance (jing-core-v3.clar:92) disagrees with reality. No on-chain consumer in-scope: accounting-integrity, not theft. Fix: vault must log-withdraw(token-in) from its own bucket when principal leaves.

STX payout: SP1NPVNSQ1DFNN840VZAGV7DJN21CT0RH46K7JS0X