The Avalanche community faces an important decision with ACP-247, a proposed upgrade that would fundamentally restructure how validators can accumulate weight through delegations. The proposal aims to improve staking economics by increasing the delegation multiplier from 4x to 24x - essentially allowing validators to accept more delegations relative to their self-stake. This sounds like a reasonable efficiency improvement on its surface, but any change to consensus-critical mechanisms warrants deep scrutiny.
The most critical issue surfaced is whether this upgrade creates new pathways for Sybil attacks - coordinated efforts where a single entity controls many validators to capture network consensus. To answer this, we need to think carefully about what it actually takes to attack Avalanche, what changes with ACP-247, and crucially, what practical barriers would stand in the way of a determined attacker.
This article walks through five different attack scenarios, comparing the current system with the world ACP-247 would create. The analysis reveals something counterintuitive: while ACP-247 does enable some new attack vectors, the practical barriers to executing them are substantially higher than superficial capital cost analysis would suggest. The real vulnerability is not capital availability but operational feasibility.
Editor’s note: whenever dollar prices are mentioned, a 20$/AVAX price is implied, unless otherwise specified.
Before we can meaningfully evaluate ACP-247's impact, we need to understand how Avalanche's current staking system works and why it already resists Sybil attacks quite effectively.
Today, Avalanche operates with a 4x delegation multiplier and a 3,000,000 AVAX weight cap per validator. The network currently has roughly 800 active validators collectively holding 210 million AVAX in stake, with about 42 million of that in delegations.
To control the network (specifically, to achieve BFT control, which means preventing consensus by controlling >33% of stake), an attacker would need to accumulate more than 69.9 million AVAX in weight. Let's consider how an attacker might try to do this under the current rules.
The first strategy that comes to mind is straightforward: maximize leverage by deploying as few validators as possible, each at the 3 million AVAX weight limit. This requires 600,000 AVAX in self-stake plus 2.4 million AVAX in delegations per validator. To achieve BFT control, an attacker would need just 24 such mega-validators.
The capital cost is significant: 72 million AVAX, or roughly $1.44 billion at current prices, of which 288M USD of stake capital. But here's where we encounter the first major practical barrier: 24 mega-validators worth 3 million AVAX each are spectacularly obvious. Each is worth 57 times the network average. When these validators appear on Avascan or other validator tracking tools, they would immediately rank among the top validators. The community would notice them within hours, if not minutes. Governance could coordinate a response within 24 hours. This attack path is essentially impossible because it trades operational simplicity for visibility - and visibility is fatal when the community is paying attention.
The alternative is to distribute validators across thousands of small identities, each with minimal self-stake. If an attacker deployed 6,994 validators with 2,000 AVAX self-stake each, each receiving 8,000 AVAX in delegations (the 4x multiplier), they'd reach roughly the same 69.9 million AVAX total while looking far less obviously coordinated. The capital cost is virtually identical - 69.9 million AVAX, or about $1.4 billion, of which 280M USD of stake capital.
But this approach trades visibility for operational burden. Managing 6,994 separate validator identities over the course of a year is an extreme operational undertaking. The attacker would need to maintain distinct keys for each, coordinate infrastructure across multiple hosting providers to avoid clustering, ensure none fail or get slashed, and most crucially, maintain operational security such that no employee ever reveals the coordination. In practice, this is where many sophisticated attacks fail - not because the math doesn't work, but because maintaining such an operation for 12+ months without someone talking, without infrastructure patterns becoming visible, without some leak occurring, is genuinely difficult at scale.
Moreover, an attacker attempting this would face a timeline problem. To avoid being obviously noticeable, they'd need to spread the deployment over many months - perhaps 100 new validators per month over 5-6 years. But that timeline gives the community years of lead time to notice the pattern, analyze it, and implement fixes. By year 6, when the attack might theoretically be complete, the community would have had 5 years to cap entity weight or implement other defenses.
So under the current system, attackers face a brutal choice: deploy obviously (24 mega-validators, detected in hours) or deploy subtly (6,994 small validators, operationally nearly impossible and giving the community months to respond).