Files
pezkuwi-sdk/tools
Satoshi Qazi Muhammed cc246664ee fix(usdt-bridge): replay protection, real recipients, working withdraw path, reserve check
The withdrawal direction (burn wUSDT -> release real USDT) had no
listener at all - nothing watched Pezkuwi for redemption deposits, and
the manual ProcessWithdrawals command was an empty stub. The deposit
listener also had two real bugs: it minted to the bridge's own address
instead of the sender's (a leftover "for demo" placeholder), and it
never checked whether a deposit had already been processed before
minting again.

- Add is_deposit_processed/is_withdrawal_processed idempotency checks,
  enforced before every mint/burn/release, not just recorded after.
- Fix listen_deposits() to mint to the sender's actual Pezkuwi address
  (same AccountId32, re-encoded under Pezkuwi's SS58 prefix - both
  chains share one derivation, so no memo/registration is needed) and
  to persist processed deposits to the database, which it never did.
- Add listen_withdrawals(), mirroring the deposit listener: detects
  wUSDT sent to bridge custody, burns it, verifies the Polkadot
  custody wallet actually holds enough real USDT before releasing
  (circuit breaker - an under-collateralized peg must halt loudly,
  not silently short-pay), then releases to the sender's Polkadot
  address.
- Add max_single_tx cap so one bad/anomalous event can't move an
  unbounded amount automatically.
- Add a Reserves command reporting real custody balance vs circulating
  wUSDT supply - the exact invariant that, when broken, is what the
  wallet's "waiting for liquidity" banner was masking.
- load_keypair() now prefers BRIDGE_SEED_MNEMONIC (meant to be
  Vault-injected, matching how the exchange's hot wallets are already
  provisioned) over the plaintext seed_path file, which remains only
  as a local/dev fallback with a loud warning.

Flagged, not fixed here: the event-matching in both listeners
(Debug-formatted Value string containing a slice of the bridge's SS58
text) is unverified against a live node in this environment and should
be replaced with subxt's typed/codegen API before this handles real
value. Custody is still single-keypair (no multisig/MPC threshold
signing) - that is an infrastructure/key-ceremony decision, not a code
change, and is the highest-priority follow-up.
2026-07-13 13:03:16 -07:00
..