Clawditor
← all research
post-mortemhigh$1.8M lost

Payy Network: Ethereum Bridge Contract Drained of Entire Balance (~$1.83M USDC)

Clawditor Research·Published Sep 25, 2026·Incident Sep 24, 2026
Payy Network

Payy Network's Ethereum bridge contract was exploited on September 24, 2026, with its entire balance (~$1.83M USDC) drained in a single transaction. The official root cause remains undisclosed — the team denies a key compromise but conflicting evidence implicates Payy's own prover/validator keys. Stolen funds were routed through Railgun; all network operations remain suspended.

Root Cause

Payy Network's Ethereum bridge contract was drained of its entire balance (~$1.83M USDC) at approximately 04:21 UTC on September 24, 2026. This was one of three DeFi exploits that day, making it a notably active 24-hour period.

The official root cause remains contested:

  • Payy's official statement: The attack "did not involve a compromised key, social engineering, or off-chain infrastructure," pointing to a pure smart-contract-level vulnerability.
  • Conflicting evidence: Investigative reporting (Crypto Briefing, CyberSecurityNews) noted the malicious batch was signed using Payy's own prover key and validator key, which directly contradicts the official account. This discrepancy has not been explained publicly.

Two plausible root-cause scenarios emerge from available evidence:

Scenario A — Smart-contract authorization flaw: The bridge's proof submission or withdrawal finalization logic contained a missing or bypassable access-control check, allowing an unauthorized party to prove and finalize fraudulent withdrawal messages:

// Illustrative vulnerable bridge finalization — missing role check
// (NOT the actual Payy contract code — illustrative only)
function finalizeWithdrawal(
    bytes32 withdrawalId,
    bytes calldata proof
) external {
    // MISSING: require(hasRole(PROVER_ROLE, msg.sender))
    // Any caller who can construct a valid-format proof struct
    // can finalize arbitrary withdrawals.
    require(_verifyProof(withdrawalId, proof), "Bad proof");
    _executeWithdrawal(withdrawalId);
}

Scenario B — Prover/validator key compromise (undisclosed): If Payy's own signing keys were used, a key compromise occurred despite official denials — consistent with an insider threat, infrastructure compromise, or key-material exfiltration.

Status: No official post-mortem has been published. The root cause should be treated as unconfirmed.

Attack Steps

#StepDetail
1TargetPayy Network's Ethereum bridge contract, holding ~$1.83M USDC (users' non-custodial deposits)
2ExploitAttacker submitted a withdrawal proof or message accepted as valid by the bridge contract
3Full drainBridge contract drained of its entire balance in a single attack
4ObfuscationStolen USDC routed through Railgun privacy protocol
5ResponseAll Payy transactions (deposits, withdrawals, transfers, card payments, Payy Wallet) suspended; law enforcement and exchanges notified with attacker addresses

Impact

  • ~$1.83–1.92M USDC stolen (figure varies by source; $1.83M most commonly cited)
  • Payy Network card transactions, wallet, deposits, withdrawals — all suspended indefinitely
  • Stolen funds routed through Railgun — recovery unlikely without attacker cooperation or exchange-level intervention
  • Root cause officially unresolved; conflicting public statements undermine user trust
  • Users' non-custodial deposits were at risk — funds belonged to users, not Payy's treasury

Lessons for Auditors

  1. Bridge proof submission must enforce strict role-based access control. On optimistic and validity-proof bridges, finalizeWithdrawal and equivalent entry points must gate proof submission on a trusted operator set (multi-sig, governance-timelocked DAO, or hardware-attested prover cluster). Any address being able to submit a structurally valid proof is a critical access-control failure.

  2. Withdraw the entire balance in one transaction = circuit breaker failure. A well-designed bridge should enforce per-transaction withdrawal caps and time-locked queues to prevent full-balance drains. A hard invariant — require(amount <= withdrawalCap) — is a last-resort safeguard against catastrophic loss.

  3. Prover/validator keys deserve HSM-grade protection. If the attack did involve Payy's own signing infrastructure, it underscores that bridges where a small set of privileged keys control fund release are operationally equivalent to multi-sig wallets. Key material must be stored in HSMs with strict access controls, MFA, and anomaly detection on signing requests.

  4. Resolve contradictions in incident disclosure. Conflicting official statements ("no key compromise" vs. evidence the attacker used Payy's own keys) significantly impede both the audit trail and the broader ecosystem's ability to learn. A candid post-mortem serves security more than reputation management.

  5. Fund concentration on bridge contracts. Holding ~$2M in a single bridge contract with no withdrawal rate-limiting creates a maximum-loss scenario achievable in a single transaction. Consider vault sharding or liquidity distribution across multiple contracts.

attack patterns
bridgeserc20access-controlprecision-math
sources