This was the response that I got from Claude sonnet 4.6 about the SIGNUM postmortem….

This is a well-written post-mortem, and from an SSI perspective it’s directly relevant to your operational situation. A few thoughts:

The technical response was genuinely impressive. Detection-to-patch-to-chain-consensus in roughly 48 hours, with no legitimate holder balances affected, is a strong outcome for a community-run network with no corporate incident response team. The three-release cadence (containment → root fix → recovery fix) shows disciplined engineering under pressure.

The root cause is worth understanding. This wasn’t an exotic attack — it was an unchecked Java long subtraction introduced during the SMART_FEES hardfork. Integer overflow in financial arithmetic is a classic class of vulnerability that should have been caught in code review. The silver lining is that Convert.safeAdd() / Convert.safeSubtract() patterns are now explicitly in place, which raises the bar going forward.

For SSI specifically, a few things stand out:

The 3.9.9 recommendation you already received was exactly right. Your node was on the emergency patch before you were doing anything mission-critical with it, which is the ideal posture.

The three lessons they identify — faster emergency comms, formal disclosure process, automated anomaly detection — map directly onto SSI architecture concerns. Your oracle daemon polling block rewards is exactly the kind of automated monitoring they’re calling for. Worth considering whether anomalous reward detection could be a governance signal in your system.

The community narrative (“no company behind it, just people who showed up”) is authentically aligned with SSI’s founding philosophy. This incident is actually good SSI documentation material — a real-world example of decentralized resilience under pressure.

The one candid note: the detection was lucky. ANGiS happened to notice. That’s not a system — and the post acknowledges it. For a project like SSI that depends on Signum’s integrity, building that automated watchdog into your stack isn’t optional, it’s foundational.

A transparent look at the May 2026 exploit, the community response, and how the network recovered stronger.
On May 19, 2026, the Signum network faced one of the most serious security incidents in its recent history.
A crafted block exploited an integer overflow vulnerability in the Signum node’s block reward calculation. The result was extreme: approximately 140 billion SIGNA were credited to the attacker’s account in a single block — an amount far beyond the legitimate circulating supply.
At first glance, this could have been catastrophic.
But what happened next showed something far more important than the exploit itself: the strength, discipline, and speed of the Signum community.
Within the same day, the anomaly was detected, exchanges were contacted, emergency patches were released, pool operators coordinated, and a rollback process began. By the evening of May 21, the chain had reached consensus again. By May 23, exchanges had received the necessary CVE details and patch confirmation, and SIGNA trading resumed.
No legitimate Signum holder balance was affected.
This is the story of what happened, how the network recovered, and what we are improving next.



What Happened?
The exploit occurred at block 1,541,011.
An attacker crafted a malicious block that abused an integer overflow in the block reward calculation. Because the crafted block still satisfied the Proof-of-Commitment consensus rules on vulnerable nodes, it was initially accepted by parts of the network.
Shortly after the block was mined, community member ANGiS noticed an absurd account balance and detected that funds were starting to move toward exchanges. ANGiS immediately escalated the issue to frank_the_tank and ohager.
That early detection was critical.
It gave the team and the community enough time to act before the situation could spiral further.



The Root Cause
The vulnerability was introduced in the context of the SMART_FEES hardfork, which added fee cash-back and burn accounting to Signum’s block reward calculation.
In the affected versions, some arithmetic operations were performed using unchecked Java long calculations.
The vulnerable logic looked like this:
rewardFeesNqt -= block.getTotalFeeCashBackNqt();
rewardFeesNqt -= block.getTotalFeeBurntNqt();
By setting totalFeeCashBackNqt to a very large negative value, the attacker caused the reward calculation to overflow into a large positive value. That inflated reward was then credited directly to the miner account.
The issue affected Signum node versions:
signum-node >= 3.9.0 and < 3.9.8
The vulnerability was later registered as: 
CVE-2026–48486



The Immediate Response
Once the issue was confirmed, the response moved quickly.
Exchanges were contacted and asked to halt SIGNA trading and deposits while the investigation was ongoing. This prevented further damage and limited the internal accounting impact for exchanges.
On the same day, two releases were published:
v3.9.7 was an emergency containment release.
It temporarily blocked the malicious account through the configurable node.accBlocking property, preventing further exploitation.
v3.9.8 was the root-cause fix.
It replaced vulnerable fee arithmetic with overflow-safe operations and introduced explicit rejection of invalid negative fee fields.
The response was public and transparent. The malicious account, the blocking mechanism, and the code changes were visible in git history. There was no silent patching and no attempt to hide the incident.
That transparency matters.
In decentralized systems, trust is not created by pretending that incidents never happen. Trust is created by responding quickly, communicating clearly, and fixing the root cause in public.



The Rollback
Because parts of the network had accepted the malicious block, a coordinated rollback was required.
Pool operators and node operators worked together to roll the chain back to before block 1,541,010. Operators still within the 1,440-block rollback window could perform a popOff through the API. Nodes outside that window required a full resync.
During testing and recovery, another issue appeared: some nodes performing a full resync from genesis encountered a non-deterministic fork-resolution bug introduced by the v3.9.8 patch.
This led to the release of v3.9.9 on May 21.
v3.9.9 completed the fix by adding a block-version-4 requirement for burnt-fee validation and correcting the chain-restoration logic.
By the evening of May 21, the network had stabilized and reached consensus again.



Impact
The exploit credited approximately 140 billion SIGNA to the attacker’s account in a single crafted block.
However, the coordinated rollback fully invalidated the fraudulent on-chain balance.
Most importantly:
No legitimate Signum account or holder balance was affected.
There was, however, temporary disruption:
SIGNA trading and deposits were suspended from May 19 to May 23.
Some exchanges that received attacker deposits before the trading halt experienced internal ledger divergence between their own records and the rolled-back canonical chain. These cases were resolved through direct coordination between the exchanges and the Signum team.



What Was Fixed?
Three releases were part of the incident response:
v3.9.7 — Emergency containment
The malicious account was temporarily blocked through node.accBlocking to prevent further exploitation.
v3.9.8 — Root-cause fix
All vulnerable fee arithmetic was replaced with overflow-safe operations using Convert.safeAdd() and Convert.safeSubtract().
Blocks with invalid negative fee fields are now rejected during block acceptance.
Fee totals are also validated against per-transaction sums.
v3.9.9 — Complete recovery fix
A block-version-4 requirement was added for burnt-fee validation, and the non-deterministic chain-restoration bug affecting full resyncs was fixed.
All operators should now run: v3.9.9 or later



What We Learned
The response worked. The network recovered. 
The fraudulent balance was invalidated. Exchanges reopened.
But this incident also revealed areas where Signum must improve.
1. Emergency communication must be faster
Some key pool operators were difficult to reach quickly. 
In a rollback situation, time is measured in blocks.
A dedicated emergency channel for major pool operators and infrastructure providers would reduce response time significantly.
2. Vulnerability disclosure needs a formal process
This incident was handled successfully, but still too much of it was improvised under pressure.
Going forward, Signum should formalize the use of GitHub Security Advisories or a similar process for coordinated disclosure, private patch development, CVE handling, and exchange communication.
3. Anomaly detection should be automated
The incident was detected because a community member noticed something unusual.
That was fortunate.
The next step is automated monitoring for abnormal block rewards, suspicious supply changes, and other values outside expected ranges. Human vigilance is powerful, but critical alerts should not depend on someone randomly seeing the anomaly first.



A Community That Showed Up
Signum has no company behind it.
No centralized foundation with a professional incident-response department. No VC-backed security team waiting in the background.
What Signum has is something different: a community that moves when it matters.
Special thanks go to:
ANGiS for first detection and immediate escalation.
frank_the_tank for exchange coordination, pool operator outreach, and rollback orchestration.
ohager for root-cause analysis, patch development, and the rapid release of v3.9.7, v3.9.8, and v3.9.9.
pir8Radio from Nam Pool and Shadow from OG Ro-Pool for critical contributions to chain stabilization.
Balazs for post-incident analysis and ongoing hardening work.
And all pool operators, node operators, exchanges, and community members who acted quickly under pressure.
This was not just a technical recovery.
It was a community recovery.



Final Thoughts
Security incidents are never good news.
But they are also moments of truth.
They show whether a project hides, delays, blames, or acts.
In this case, Signum acted.
The vulnerability was identified.
The exploit was contained.
The chain was restored.
Legitimate balances were protected.
The root cause was fixed.
Trading resumed.
And the hardening work continues.
Signum is not stronger because the incident happened.
Signum is stronger because of how the community responded.
Transparent. Fast. Decentralized. Together.
That is what this network is built on.



Discover Signum
Signum is the world’s first truly sustainable blockchain, featuring world-class applications on a sustainable, leading-edge blockchain architecture. Unlike other cryptocurrencies, Signum powers its native cryptocurrency Signa (SIGNA), with a minor fraction of energy use and e-waste. Signum empowers users and developers worldwide with innovative blockchain solutions for everyday life.
Find out more at https://signum.network/or join a Signum channel below.
Get SIGNA : https://signum.network/exchanges
Twitter
Telegram
Discord
Reddit
Youtube
Documentation
NFT-Portal
Defi-Portal
Your
SIGNUM-NETWORK



Signum
Blockchain Security
Proof Of Capacity
Decentralization
Cryptosecurity

Some rights reserved









Follow
Published in Signum-Network
89 followers
·
Last published Apr 17, 2025
Signum is the foundation for our sustainable future. It’s easily accessible to everyone and as a customizable platform, it has the power to feature unstoppable and censorship-resistant decentralized applications.

Follow
Written by Signum
170 followers
·
12 following
Join the movement! https://signum.network

No responses yet

I might add that all the winnings that will be issued are from a collection made from the community for a listing, and we need no more listings. We just need people to on board…….

The current statistics for Nostr say there are very few users do you believe that reflects all the lurkers?

This is the reason for the sovereign stack….

US should demand Iran ‘NOT execute prisoners,’ former Iranian wrestler https://share.google/vLU483sfqaowlYjVj