Skip to main content
• 5 min read

SQ Token Staking Drain: $346K Lost
via Hardcoded Owner Backdoor and Fake Renounce

SQ Token's BNB Chain staking contract was drained for about $346,137 after a hardcoded owner backdoor bypassed a visible renounce-to-dead-address setup. The attacker forged staking records, disabled the lock period, and converted staking inventory and AMM liquidity into USDT.

AUTOSEC.DEVAUTOSEC.DEV
SQ Token Staking Drain: $346K Lost via Hardcoded Owner Backdoor and Fake Renounce
  • Incident Date: May 12, 2026
  • Target: SQ Token staking contract on BNB Chain
  • Target Overview: SQ Token operated a staking flow tied to SQi inventory and PancakeSwap liquidity. The affected verified Staking contract appeared to have renounced ownership to a dead address, but its custom owner check still allowed a hardcoded address to call privileged functions.
  • Total Loss: ~$346,137 USDT
  • Attack Vector: Hardcoded Owner Backdoor / Fake Ownership Renounce / Staking Record Forgery / EIP-7702 Batched Execution

Incident Review & Technical Details​

1. Attack Path​

  1. Renounced Contract Still Had a Hidden Owner: The vulnerable staking contract at 0x404404a845fff0201f3a4d419b4839fc419c99f7 used a modified owner check that allowed the hardcoded address 0xE746c9043Aa0106853c5e4380A9A307Fe385378e to pass onlyOwner, even after the visible owner had been set to a dead address.
  2. Backdoor Restored Administrative Control: The attacker used the embedded exception to call transferOwnership() and make the attacker address the stored owner again. This proved the public renounce signal was not a real loss of privilege.
  3. Staking Lock Was Set to Zero: The attacker called setUintArray(1, [0]), setting the relevant staking lock duration to zero and making newly created positions immediately redeemable.
  4. Fake Stakes Were Minted Without USDT Deposits: The privileged stakeOwner() path let the attacker create synthetic staking records for themselves without a corresponding user deposit.
  5. Forged Positions Were Redeemed Through unstake(): The attacker then redeemed forged positions for USDT. Public analysis attributed 296,500 USDT to repeated unstake() redemptions.
  6. Remaining SQi Inventory Was Swept and Sold: The attacker used a privileged token withdrawal path to sweep roughly 2,000,039 SQi from the staking contract and sell it through the PancakeSwap SQi/USDT pair for another 49,637.034345 USDT.
  7. EIP-7702 Bundled the Exploit: The transaction used a type-0x04 EIP-7702 authorization so the attacker EOA could execute helper code while preserving EOA-style semantics. This helped batch the exploit and satisfy onlyEOA-style checks, but the root cause remained the owner backdoor.

2. Impact Scope​

  • Direct Realized Proceeds: Public technical analysis calculated total attacker proceeds of approximately 346,137.034345 USDT.
  • Affected Contract: The Staking contract at 0x404404a845fff0201f3a4d419b4839fc419c99f7 on BNB Chain.
  • Affected Liquidity: The drain hit the PancakeSwap V2 SQi/USDT pair at 0x56b681876b7a6df313e34ad4efc74146a75ea51e.
  • Related Token: SQi at 0xc7d2fab3e1f81f3c8fb1669a2f9dff647eaea3e9.
  • Attack Transaction: The focal transaction was reported as 0x1bae633eda9b3d98999ea116bc403712eaa07093ec32bd6d559085cc4607f5b8 in block 97836948.
  • Residual Synthetic Balance: DARKNAVY reported that the attacker retained 90,100 synthetic SQ Token claims that were not counted in the realized USD loss figure.

3. Root Cause Assessment​

The incident is best classified as a deliberately embedded access-control backdoor rather than an accidental staking math bug:

  • Custom Ownable Broke Trust Assumptions: The contract looked like it had renounced ownership, but _checkOwner() still accepted a hardcoded privileged address.
  • Privileged Bookkeeping Minted Real Claims: stakeOwner() created staking records that downstream redemption logic treated as valid, even without a matching USDT deposit.
  • Owner-Tunable Lock Durations Removed Time Protection: By setting the staking duration to zero, the attacker eliminated the normal delay between position creation and redemption.
  • AMM Recycle Mechanics Amplified the Drain: Redemption and token recycling logic let synthetic positions convert contract-held SQi and pool liquidity into USDT.
  • EOA-Only Checks Were Not a Security Boundary: The EIP-7702 wrapper preserved enough EOA behavior to pass onlyEOA checks while still executing a multi-step script.

The key security failure was simple and severe: a contract cannot be considered renounced or trust-minimized if any hidden address can still pass owner checks and reach fund-moving functions.

4. Mitigation and Response​

Recommended actions for staking and token projects:

  • Use unmodified, well-reviewed ownership libraries and verify deployed bytecode against expected source.
  • Treat any hardcoded bypass in _checkOwner(), role checks, or privileged modifiers as a critical backdoor.
  • Do not rely on renounce-to-dead-address optics; verify that no alternate role, hardcoded address, proxy admin, or hidden owner path remains.
  • Require real asset inflow before minting staking claims that can later be redeemed for principal or rewards.
  • Put owner-controlled staking parameters such as lock periods, reward rates, and withdrawal routes behind timelocks and public change windows.
  • Monitor EIP-7702 type-0x04 transactions that touch privileged functions, staking redemptions, or large token sweeps.
  • Treat onlyEOA checks as weak friction, not a meaningful defense against modern account-delegation and batching patterns.

AUTOSEC.DEV Solution: Building a 360-Degree Defense​

The SQ Token drain shows why verified source and renounced ownership are not enough. The real question is whether deployed authorization logic contains hidden privilege, and whether privileged paths can manufacture redeemable value.

  1. Smart Contract Access Control Audit: AUTOSEC.DEV reviews custom ownership logic, role checks, modifier overrides, hardcoded addresses, proxy admins, and hidden privilege paths.
  2. Staking Logic Security Review: We test staking record creation, redemption, reward settlement, lock-period updates, token recycling, and AMM interaction paths for synthetic-claim and liquidity-drain risks.
  3. Rug Pull & Backdoor Assessment: We compare deployed bytecode, verified source, owner state, renounce claims, and privileged function reachability to identify deceptive control retention.
  4. Incident Response (IR): AUTOSEC.DEV supports rapid transaction tracing, liquidity impact analysis, exchange and bridge monitoring, attacker-wallet tracking, and post-incident technical reporting.

Service Content​

Reference​