Shibarium update

Kaal Dhairya

• 7 min read
Shibarium update
Photo by Tommy Liu / Unsplash

Date: 10/02/2025
Status: Containment holding • Integrity restored

TL;DR

  • Round‑the‑clock response: For the last 10+ days, the core team and partners worked non‑stop (nights, weekends, holidays) to isolate risk, restore integrity, and harden Shibarium end‑to‑end.
  • Foundation hardening: Ownership of 100+ critical contracts migrated to hardware custody, all validator signer keys rotated, and blacklisting added to staking flows.
  • 4.6M BONE rescue: We neutralized the 4.6M BONE delegation from the attacker via controlled contract upgrades and state cleanup—tested on Devnet Puppynet, and reviewed by Hexens.
  • Checkpoint fix: A malicious three‑checkpoint injection caused Heimdall to halt (by design). We corrected the on‑chain pointer (nextHeaderId) using a protocol housekeeping function after a 3‑stage test process (Devnet → Puppynet → Mainnet). Checkpointing has resumed normally.
  • Why we didn’t deploy a bounty contract: No response from the attacker + visible on‑chain movement of stolen assets = no credible negotiation; deploying a contract would have added risk without benefit.
  • Near‑term focus: Blacklisting for Plasma Bridge to prevent future problems, re‑initiate Plasma Bridge, making whole plan + PoS Bridge restart (with careful gating).
  • Infra momentum: New partnership with dRPC.org; consolidating the official RPC to http://rpc.shibarium.shib.io/; major docs overhaul to simplify node setup.
  • Support:  security@shib.io • Telegram help: https://t.me/+ENbsmVntoyNhOTA1

1) What Happened (High‑Level)

  • A malicious actor submitted three fake checkpoints to Shibarium’s Ethereum mainnet contracts, breaking continuity between Heimdall’s local state and on‑chain state. Heimdall halted (intentionally conservative behavior), pausing legitimate checkpoint submissions.
  • In parallel, the attacker used short‑lived stake amplification (via a 4.6M BONE delegation) to cross thresholds and attempt malicious control.
  • Our job: isolate risk, verify every layer, recover assets where possible, correct the contract ledger state, and re‑start secure checkpointing—without exposing new attack surface.

2) How We Worked (The Last 10+ Days)

We organized the response into overlapping workstreams, running 24/7 with Hexens.io as an independent, parallel reviewer:

  • Overnights/Weekends/Holidays: Pager rotations, daily standups, 2–3 syncs per day, and continuous review of diffs and logs.
  • Separation of duties: Distinct owners for infra, contracts, validator ops, testnets, and monitoring; Hexens mirrored testing and signed off on changes.
  • No single points of failure: Hardware custody for keys; multi‑party review on sensitive ops; every critical change rehearsed off‑chain or on testnets first.

3) Foundation Hardening & Key Security

(a) Contract Control Migration

  • Ownership of 100+ mission‑critical contracts—spanning Shibarium, ShibaSwap, Metaverse, and more—migrated to new secured wallets with multi‑party procedures.

(b) Validator Key Rotation

  • All validator signer keys rotated to isolate the network from prior state exposure and enforce new custody discipline.

(c) Staking Blacklisting (New Control)

  • Added an update‑blacklist capability to the StakeManager and related staking paths:
    • If a delegator/validator address is flagged as malicious, every staking action is blocked (stake, unstake, withdraw rewards, claim).
    • This defensive layer neutralizes attacker attempts to move or re‑bond funds post‑incident.
All changes above were reviewed by Hexens and rehearsed in Devnet/Puppynet before touching Mainnet.

4) Protocol Security & Asset Recovery

4.1 The 4.6M BONE Rescue (Attacker Delegation)

  • We identified a 4.6M BONE delegation staked via the attacker’s contract (not EOA):
    • Attacker contract: 0xe9B854365FF0F4Ce7a155f177f528cb37A737Ab7
    • State visible in ValidatorShare unbond data for the affected validator.

What we did (sequence):

  1. Introduced a rescue method in StakeManager to recover at‑risk BONE.
  2. Executed AdminConsumeLegacyBound to clean legacy unbond state tied to the attacker contract.
  3. Verified the staking ledger updates and confirmed 4.6M BONE was rescued and the malicious delegation removed.

Additional safeguards shipped at the same time:

  • Blacklisting (described above).
  • Withdrawal delay: Increased from 1 checkpoint to ~30 checkpoints (~24h) so operations have time to detect anomalies and act before withdrawals finalize.

All of the above was simulated in Devnet with multiple scenarios, validated on Puppynet, reviewed by Hexens, and only then applied to Mainnet.

5) Checkpoint Integrity: From Divergence to Recovery

5.1 The Problem (Heimdall Divergence)

  • Shibarium posts checkpoints (state snapshots) to Ethereum L1 contracts to secure the bridge.
  • The attacker injected three fake checkpoints into the Root Chain Manager:
    • Root Chain Manager reference: 0xd46042f503B8Ec0A166af8C0BFbB0a3C562353F9
  • Heimdall compared its local view against the on‑chain ledger, saw a mismatch, and halted with continuity errors (by design).
  • Key symptom in logs:Checkpoint not in continuity: currentToolTip and endBlock
  • Result: Heimdall stopped queueing and submitting new valid checkpoints until the ledger inconsistency was fixed.

5.2 The Fix (Protocol Housekeeping)

  • We used an existing protocol maintenance function—a housekeeping tool—to adjust the on‑chain checkpoint ledger pointer.
  • Specifically, we set nextHeaderId back to the last known good checkpoint (effectively rolling back by three) so Heimdall and the contract agreed again.
  • This ignored the fake checkpoints, restored the secure last‑good state, and allowed Heimdall to resume normal checkpoint generation/submission.

5.3 Three‑Stage Validation (Before Mainnet)

  1. Devnet Replication
    • Built a controlled network with 3 validators; injected fake checkpoints using test signer keys.
    • Observed endpoints:
      • …/checkpoints/latest (last successful submission in memory)
      • …/checkpoints/buffer (next checkpoint queued to submit)
    • After injection, buffer stalled while latest stayed constant—matching Mainnet symptoms.
    • Exercised recovery:
      • Rotated validator signer keys (test only).
      • Used the housekeeping function to revert nextHeaderId on the root chain.
      • Heimdall immediately resumed normal operations.
  2. Puppynet (Public Testnet) Validation
    • Repeated the nextHeaderId correction and key rotation tests under compromised conditions.
    • Heimdall resumed posting valid checkpoints, confirming the fix works in a near‑live environment.
  3. Mainnet Implementation
    • Executed the same procedure:
      • Updated nextHeaderId to remove the effect of the three fake checkpoints.
      • Mandatory rotation of all validator signer keys.
    • Outcome: Heimdall immediately resumed secure, valid checkpoint submission to the Ethereum root chain.

Key takeaways:

  • Monitoring both latest and buffer endpoints detects divergence early.
  • On‑chain pointer reconciliation (with strict controls) is a surgical, auditable way to restore continuity.
  • Key rotations must be followed by validator‑set verification to avoid mismatches.

6) Why We Did Not Deploy a Bounty Contract

  • We extended a public offer to the attacker to discuss returning funds for a bounty.
  • The attacker never responded and, in parallel, began moving/selling stolen assets.
  • With no credible negotiation path and active movement on‑chain, deploying a bounty contract would have:
    • Added operational complexity,
    • Created a new surface to monitor,
    • Distracted from the core mission: securing the protocol and restoring integrity.

Decision: No bounty contract. All focus remained on defense, recovery, and restoration.

7) Monitoring, Playbooks, and Observability (Improvements)

From the Devnet exercise and incident learnings, we:

  • Documented a checkpoint mismatch playbook (detect → validate → reconcile).
  • Added alerts for continuity errors and buffer stalls (where buffer stops changing while latest remains static).
  • Established a key‑rotation checklist with validator‑set verification.
  • Planned on‑chain sanity checks to streamline audited rollbacks in controlled scenarios (without expanding attack surface).
  • Expanded test coverage with scenarios for: signer rotation, malformed checkpoints, and forced state divergence.

8) Near‑Future Updates (What’s Next)

  • Blacklisting in Plasma Bridge
    Proactive deny‑list controls to block malicious actors from initiating or completing bridge flows.
  • Re‑initiate Plasma Bridge
    Restore full bridge functionality once the above controls are landed and verified.
  • Plan to make users whole + PoS Bridge Restart
    We’re designing a plan to make users whole and restart mechanics to allow users to bridge/withdraw safely. This includes careful gating, phased limits, and partner coordination. (We’ll communicate specifics only when it’s safe.)
Note: We’re evaluating user‑friendly mechanisms to represent any remaining obligations transparently over time without over‑promising or leaking sensitive timelines.

9) New RPC Nodes

Technical Momentum

  • New RPC Partnership: dRPC.org for improved access and reliability.
  • Official RPC Consolidation:
    • http://rpc.shibarium.shib.io/ will be the definitive entry point.
Always verify URLs via our official channels before use.

Your Support Network

10) Appendix A — Checkpoint Recovery

Purpose: Reproduce Mainnet mismatch, validate behavior, and harden recovery.

Environment:

  • Devnet with 3 validators (to simulate majority behavior).

Steps:

  1. Bootstrap Devnet and verify normal checkpointing.
  2. Submit fake checkpoints (test keys) to create a mismatch.
  3. Observe:
    • latest remains the last good checkpoint.
    • buffer stalls, no new checkpoints queued.
    • Heimdall logs: Checkpoint not in continuity: currentToolTip and endBlock.
  4. Rotate validator signer keys (test). Verify staking/validator‑set reflects changes.
  5. Use housekeeping to revert nextHeaderId (roll back by three) to the last good state.
  6. Result: Heimdall resumes generating and submitting checkpoints normally.

Takeaways:

  • Divergence is detectable by buffer stalls vs. steady latest.
  • On‑chain pointer reconciliation is safe when audited and rehearsed.
  • Post‑rotation validator‑set verification prevents silent mismatches.

Post‑Test Actions:

  • Wrote the operational playbook.
  • Added monitoring/alerting.
  • Expanded test coverage for future drills.

11) Appendix B — 4.6M BONE Rescue

  • Discovered attacker’s 4.6M BONE stake in ValidatorShare unbond data (via attacker contract).
  • Added rescue and AdminConsumeLegacyBound routines to StakeManager.
  • Removed malicious unbond state and rescued tokens.
  • Added blacklisting (delegator/validator), increased withdrawal delay to ~30 checkpoints.
  • All changes co‑developed with Hexens, tested on Devnet and Puppynet, then applied to Mainnet.

12) Appendix C — Frequently Asked (Security‑Focused)

Q: Are the new controls permanent?
A: Yes—blacklisting, key‑rotation discipline, and monitoring remain part of the standard stack. Withdrawal delays can be tuned based on observed risk.

Q: What data won’t you publish?
A: We won’t disclose sensitive thresholds, internal addresses, or exact rollback parameters while an adversary could still benefit.

Q: How will repayment work?
A: We’ll share specifics when it’s safe. The design principle: fair, transparent, and auditable—with careful gating and no over‑promises.

13) Final Note

The last ten days have been hard, focused, and productive. The team and partners have worked through nights, weekends, and holidays to secure, validate, and restore Shibarium. Integrity is back, defenses are stronger, and the path forward is get system back on track asap.

Sign up for more like this.

Enter your email
Subscribe