Sovereignty Mechanics
Advanced Guides > Gameplay Specifics > Sovereignty Mechanics
Last revision 100 months ago

English version

Note: This guide has no intention to be an approximation or be quick to read. I am here to give you a precise view of the new system which should answer every possible situation you might encounter.

Note 2: Please do not hesitate to report any English mistake, as it is not my native language.


Short Introduction to the concept of Sovereignty:

In Eve Online, there are four types of security level categories for solar systems: High-sec, Low-sec, Null-sec, and Wormhole-space. However, Null-sec is itself divided into two subcategories, not to be confused as they are very different: Sov Null, and NPC Null.

NPC Null is controlled by NPC factions (often pirate ones) allowing every player to dock inside their stations. This enables everyone to live at the same place, regardless of you being friends with your neighbors or not. It is also in NPC null that you can run missions for Pirate NPC Factions, to be able to buy pirate ships only sold by them.

Sov Null however, is a section of Null-sec that is not, by default, controlled by anyone. Players can claim these systems as their own, or more precisely, alliances (player corporations banding together) can. It is a structural pre-requisite: May your group be 1 or 10 000, you need to be in an alliance to own a solar system.

This includes stations that might be in there, which enables you to set who can or cannot dock, which in turn allows you to dictate who gets to live in your system.

Presentation of the different structures:

Infrastructure Hub (IHub): The IHub is a structure containing the ‘Sov Upgrades’ of the system. These are upgrades which, once put inside the IHub, improve the system permanently as long as certain conditions are met. Among the benefits of sov upgrades, there are instant-respawn mining anomalies, instant-respawn NPC farming anomalies, cynosural jammer deployment authorization, etc… Note that the IHub must be anchored near a planet, this is relevant for what’s next.

Territorial Claim Unit (TCU): The TCU is a structure controlling the discount in the hourly Fuel Blocs consumption for POSes owned by the same alliance as the TCU’s. As opposed to the IHub, the TCU could be placed near a moon (only before the new sov). POSes are also placed near moons, meaning that it can (and often will) be at range of being defended by POS turrets (‘POS guns’).

Sovereignty Blocade Unit (SBU): Now obsolete, this structure allowed to initiate a system capture under the old system.

Command Node: This new temporary ‘structure’ is tied to the new sovereignty system. Command Nodes allow to finalize the capture or defense of structures inside a solar system.

Summary of the old Sovereignty System:

To be able to fully understand the impotance of the new sov system, and for your personal knowledge, it is important to understand how the old model worked.

In the old model, sov structures were invulnerables by default. SBUs had to be onlined on a system’s Stargates in order to initiate a capture. Without giving too many details, lets just mention that the defender could also put his own SBUs on stargates to ‘occupy the slot’, leaving no choice for the attacker but to first blow up the defensive SBUs before onlining his owns.

Once SBUs were online, the TCU was becoming vulnerable. Its destruction meant the loss of sovereignty in the system, returning it to an unclaimed state. SBUs, TCUs, IHUBs, and Stations each possessed tens of millions of hitpoints, making big guns mandatory to be able to ‘bash’ motionless structures in a decent timeframe.

Due to the relative easiness of taking down a TCU, but also to enjoy system upgrades, most alliances added an extra layer of protection for the TCU in the form of the IHub. Any active IHub or Station inside the solar system meant that the TCU remained invulnerable even with SBUs online. Forcing the attacker to capture the Station and destroy the IHub before being able to capture the system. Stations and IHubs had to be captured / destroyed three times: Once for the shield layer, then for the armor layer, and then for the hull one. Each step being separated by 24-48h or 48-72h of waiting (respectively for the IHub or Station) which the structure is invulnerable.

The station was captured by the corporation landing the final blow (Does anybody knows what used to happen when the final blow was made by a character belonging to an NPC corp?) on the hull layer. This allowed a lucky defender to try and recapture his own station right below the nose of a winning attacker. Ex-F did it twice (once in a cruiser and once in a frigate), facing Pandemic Legion’s Supercarriers and Titans. Which was both hilarious (for everyone), and unfair (for PL).

Hence, the procedure to capture a system could at the time very well look like this (in the event of an IHub and Station being present)

  1. System held by the enemy.
  2. Onlining of the attacker’s SBUs (3 hours)
  3. Blow up the IHub’s shields.
  4. Blow up the Station’s shields.
  5. Wait (24h-48h)
  6. Blow up the IHub’s armor.
  7. Wait (0h-24h)
  8. Blow up the Station’s armor.
  9. Wait (0h-24h)
  10. Blow up the IHub for good.
  11. Wait (0h-48h)
  12. Capturer the station
  13. Blow up the enemy’s TCU
  14. System now unclaimed
  15. Onlining of the attacker’s TCU (8 hours)
  16. System now claimed by the attacker.

Conclusions from the old model:

The capture of ONE system could require bashing of hundreds of millions of hitpoints, require to win 5 to 6 consecutive battles, and to mobilize a sizeable strike force. This led to a substantial stagnation of null-sec’s sovereignty even if undefended space, especially given the amont of work required to capture even one single system. Not to mention the extremely high barrier of entry, because of the necessity to have a sizeable strike force even if the system wasn’t actively defended. (And I haven’t even talked about supercaps. But this is not the place.)


The new Sovereignty model

The new sovereignty model completely eliminates bashing from the procedure: It is no longer necessary to damage the structure to capture or defend it. The new system also deletes one step of invulnerability, to accelerate the process.

The capture of sovereignty is now done with a module: the Entosis Link.

The Entosis link

The Entosis Link is a high-slot module available in the base T1 version, plus four variations, plus a T2 version. Once activated (cycling), the Entosis:

  • Stops you from receiving positive remote effects from other players (with the exception of gang links). Thus, it is impossible for your fleet to rep you.
  • Disables warping, jumping, docking, and cloaking (MJD still ok)
  • Increases your mass a bit, which slows you down. Substantially so if you are in a fast frigate.
  • The only way to interrupt an ongoing entosis cycle is to destroy the ship. Cycles lasts for minutes.
  • The Entosis Link consumes one unit of Strontium Clathrates (said ‘Strontium’ or ‘Strong’) per cycle. This is often overlooked when undocking!
  • Capital ships have a cycle time multiplied by 5.

Note : The MJD (Micro Jump Drive) is a module enabling you, once activated, to teleport yourself forward 100km. In EVE’s vocabulary, a MJD activation isn’t a ‘jump’ at all.

Basic Capture Principles:

The capture of a structure stats once a single or multiple Entosis Link belonging to the same ‘side’ are ‘active’ on a structure. A side is sometimes composed of the defender’s alliance versus every other alliances, or sometimes one side is one alliance. Keep in mind that:

  • Multiple active entosis links do not accelerate the capture. There is no benefit to have multiple active entosis links on the same structure, it can only be useful to add a level of redundancy in case one active entosis ship dies.
  • One active entosis belonging to a different camp is enough to completely halt the capture / the defense that another camp is conducting.
  • An entosis link is only considered active once it has completed a full ‘warm up’ cycle.
  • If a ship with an active entosis link loses the lock for whatever reason, the current cycle continues until the end, but the module stops having any impact on the capture process. You have to wait for the end of the ongoing cycle, then go through a full warm-up cycle, before being counted as active again.
  • A mail notification is sent to every member of the alliance once an active hostile entosis is detected on a fully defended structure. Since the entosis must already be active, it means that you can try to conceal the warm-up cycle, but nothing more.

The Defense Multiplier

The Defense Multiplier is a value reflecting (in theory) the activity of a system’s inhabitants. It is the sum of the three sov indexes. Sov indexes are visible to all, and increases relatively to the system’s activity:

The Strategic Index increases passively over time. It represents the duration during which the system stayed within the Defender’s grasp without interruption.

The Military Index increases by killing NPCs in the system.

The Industry Index increases by mining m3 of minerals in the system.

The Military and Industry Indexes decays over time, which means that a suddenly lower activity in a system will translate into a slow decrease in indexes, and as a consequence, a decay of the Defense Multiplier.

The role of the Defense Multiplier is to multiply the capture duration for the attackers, to make their task more complicated and to increase the reaction margin that defenders enjoy in case of attack, as long as the defender is active in his system.

Note: The Defense Multiplier only penalizes attackers. Defensive capture speed for defenders behaves like if the multiplier was x1 (or inexistent).

Even though the announced goal of the Defense Multiplier is to reflect the occupancy level of defenders in a system, the fact that Military and Industry Indexes are not reset once the system changes hands, alters from my point of view the final result. As a matter of fact, successfully capturing a very active system gives the attacker (now a defender) a maximum value of Defense Multiplier, even though he did absolutely no effort toward that goal. The activity of the previous Defender (now attacker) turns against him if he wishes to retake his old system.

The value of the Defense Multiplier is 6 at maximum. This value is the total of 1 plus the three indexes, following this spreadsheet: (This guide is now a True Eve guide since it has a spreadsheet)

Index type Level 0 Level 1 Level 2 Level 3 Level 4 Level 5
Military 0 0.6 1.2 1.7 2.1 2.5
Industry 0 0.6 1.2 1.7 2.1 2.5
Strategic 0 0.4 0.6 0.8 0.9 1


Thus, the formula is:

Defense Multiplier = 1 + Military + Industry + Strategic

With Defense Multiplier = 6 maximum.

As you can see, you don’t need to have all indexes at maximum to reach the maximum Defense Multiplier.

The Capital System

Each alliance can name a solar system as being its Capital, which gives the system +2 Defense Multiplier, allowing it to reach the maximum of 6 without having the required Indexes for that. This particular rule is in place to allow for the HQ of some alliances to be defendable, even though they are too busy to allow for defenders to rat and mine effectively.

Vulnerability Window

However, sov structures aren’t vulnerables at all times. Each alliance picks a center point of vulnerability (example: 18 00 EVE TIME). The server then assignes a vulnerability window expanding equally to each side of the center point. For instance, a 4 hour vulnerability centered around 18ET will last every day from 16h to 20h.

Outside of this vulnerability window, sov structures aren’t capturables. The duration of this window is of 18h divded by the Defense Multiplier.

Defense Multiplier x1.0 x2.0 x3.0 x4.0 x5.0 x6.0
Vulnerability window 18h00 9h00 6h00 4h30 3h36 3h00

It is planned that alliances will also be able to customize the center point for each structure, but this feature is not yet available.

Note: All structure partially captured at the end of a vulnerability window *remains vulnerable as long as there is no resolution* (either the defender ‘uncaptures’ it, or either the attacker manages to complete the capture). This means that a bad defense of your structures, or a hotly contested structure, can potentially make the fight last way beyond the expected vulnerability window.

Note 2: A sudden change in the Defense Multiplier doesn’t translate in an immediate change of the Vulnerability Window. To avoid surprising anyone, the server will look at the old Defense Multiplier of the day before, and the current Defense Multiplier. The Vulnerability Window will end up being an average of the two.

In the old system, the three main sov structures (TCU, IHub, Stations) were all linked together and had to belong to the same owner. With the new system, it is entirely possible to split the ownership of these three structures between different alliances. However, in practice I expect in most cases one of the alliance to own the three structures of a solar system.


Capture process

Lets talk about the capture process of the different structures. If you want a reminder about the use of a certain structure, please go read their definition again, at the beggining of this guide.

TCU and IHub

The capture of a TCU and of an IHub follow exactly the same rules:

During the Vulnerability Window, the attackers can capture the structure. The base capture duration is 10 minutes, multiplied by the Defense Multiplier, which equals to a capture time of 60 minutes at x6.

The only difference between the TCU and the IHub is during the initial phase. The IHub will be anchored near a planet and will therefore be ‘alone’, while the TCU might be anchored near a moon. Since POSes can also be anchored near moons, the defender will usually place a ‘deathstar’ POS near the TCU to protect it. A Deathstar is a POS with lots of turrets (also called ‘POS Guns’). This makes capturing the TCU harder even if the defender does not intervene, since the POS will pose a constant threat.

TCUs now follow the same placement rules as IHubs (near planets only), but old TCUs have been grandfathered-in into the new system. Therefore, TCUs in place before Fozziesov can still be found near moons with an active Deathstar protecting them.

If the initial capture is completed, the structure enters an invulnerability period, also called ‘reinforced’, for about 48 hours, in a way that the period ends somewhere inside the Vulnerability Wndow.

At the end of the reinforced period, a capture event starts:

Command Nodes starts randomly appearing in solar systems of the constellation in which the contested structure is. Each solar system belongs to a region AND a constellation, the later being a small group of 4-6 systems on average. It now plays a tactical role in the new sov, because that’s the area where Command Nodes for your system can spawn. Command Nodes have an equal chance to spawn in every system of the constellation.

5 Command Nodes appear at the beginning of the capture, and respawn (in the same or a different system) each time one of them is captured. As time goes on, the number of simultaneous active command nodes starts increasing, to accelerate the end of the battle. Obiously, the capture event stops once a resolution is found. Beware, the capture event WILL ignore the end of your Vulnerability window and can potentially continue for hours, it can even pause for downtime and resume immediately afterwards.

Command Nodes take 4 minutes to capture, but they are also affected by the Defense Multiplier and can therefore reach 24 minutes of base uncontested capture time (for the attacker only, as always).

Note: The capture duration of a Command Node is determined by the Defense Multiplier of the solar system of the structure that you want to capture or defend (TCU, IHub, Station). Therefore, it is not necessarily the Defense Multiplier of the system in which the command node is currently in!

A Command Node is visible on D-scan, on the Anomaly Scanner, and on the overview. You can warp to it, and capture the Command Node with an Entosis Link, as you would for the rest.

Each successfully captured Command Node gives 5% to the side who completed the capture. If another side captures a command node, the opposite side loses 5%. The first side to reach 100% wins the capture.

Note: As from the Galatea release, the defender starts with 60% control. Nodes now passively regenerate in favor of the defender (passive regeneration takes about 90 minutes)

Here, there are only two ‘sides’: The alliance of the Defender, versus every other alliance. If an alliance wishes to help the Defender, destroying the Defender’s enemies is an option, but it is impossible to use an Entosis defensively if you do not directly belong to the Defender’s alliance. Both sides start at 50%.

At the end of the ‘Capture’ of a TCU or IHub (therefore if the attacker won), the structure explodes, leaving any alliance free to drop and protect their own replacement TCU or replacement IHub. It then needs to be defended during the whole anchoring / onlining process.

At maximum, there can be 10 simultaneous Command Nodes per capture event.