mirror of
https://gitlab.com/pezkuwichain/pezkuwi-sdk.git
synced 2026-10-20 18:56:23 +00:00
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.