diff --git a/docs/protocol-design/attack-vectors.md b/docs/protocol-design/attack-vectors.md
index 0237f62d2..e4cb026ec 100644
--- a/docs/protocol-design/attack-vectors.md
+++ b/docs/protocol-design/attack-vectors.md
@@ -40,14 +40,14 @@ description: Understand the different attack vectors on the nano network and the
 |**Description** | A penny-spend attack is where an attacker spends infinitesimal quantities to a large number of accounts in order to waste the storage resources of nodes.    
 |**Defense** | Blocks publishing is rate-limited by work so this limits accounts to a certain extent.  Nodes that are not full historical nodes can prune accounts below a statistical metric where the account is probably not a valid account.  Finally, Nano is tuned to use minimal permanent storage space so space required to store one additional account is proportional to the size of one block + indexing ~ 96b + 32b ~ 128b.  This equates to 1GB being able to store 8 million penny-spend account.  If nodes want to be aggressive, they can calculate a distribution based on access frequency and delegate infrequently used accounts to slower storage.  
 
-## >50% attack
+## >33% attack
 
 | | |
 |----------------|-------------
 |**Risk** | Low
 |**Impacts** | Completely destructive
-|**Description** | The metric of consensus for Nano is a balance weighted voting system.  If an attacker is able to gain over 50% of the voting strength, they can cause the network to oscillate their decisions rendering the system useless.  An attacker must have at least some value tied up in the network as a balance which they're willing to forfeit as an expense to performing this type of attack since this attack ruins the integrity of the system.  An attacker is able to lower the amount of balance they must forfeit by preventing good nodes from voting through a network DDOS.  
-|**Defense** | There are multiple levels of defense against this type of attack:</br><ul><li>*Primary defense*: voting weight being tied to investment in the system; attempting to flip the ledger would be destructive to the system as a whole which would destroy their investment.</li><li>*Secondary defense*: cost of this attack is proportional to the market cap of all of Nano.  In proof of work systems, technology can be invented that gives disproportionate control compared to monetary investment and if the attack is successful, this technology could be repurposed after the attack is complete.  With Nano the cost of attacking the system scales with the system and if an attack were to be successful the cost of the attack can't be recovered.</li><li>*Tertiary defense*: In order to maintain the maximum quorum of voters, the next line of defense is representative voting.  Account holders who are unable to reliably participate in voting for connectivity reasons can name a representative who can vote with the weight of their balance.</li><li>Forks in Nano are never accidental so nodes can make policy decisions on how to interact with forked blocks.  The only time non-attacker accounts are vulnerable to block forks is if they receive a balance from an attacking account.  Accounts wanting to be secure from block forks can wait a little or a lot longer before receiving from an account who generated forks or opt to never receive at all.  Receivers could also generate separate accounts for receiving from dubious accounts in order to protect the rest of their balance.</li><li>A final line of defense is block cementing.  As blocks are confirmed in V19.0+, the node marks the height of the last block confirmed for every account and will refuse the replacement of an already confirmed block. Attempts to fork after previous confirmation of a block will immediately fail.</li><br />The most sophisticated version of a >50% attack is detailed in the diagram below.  "Offline" is the percentage of representatives who have been named but are not online to vote.  "Stake" is the amount of investment the attacker is voting with and will be lost if they successfully attack the system.  "Active" are representatives that are online and voting according to the protocol.  An attacker can offset the amount of stake they must forfeit by knocking other voters offline via a network denial of service attack.  If this attack can be sustained, the representatives being attacked will become unsynchronized and this is demonstrated by "Unsynced".  Finally, an attacker can gain a short burst in relative voting strength by switching their denial of service attack to a new set of representatives while the old set is resynchronizing their ledger, this is demonstrated by "Attacked".<br /><br />![Voting attack](https://raw.githubusercontent.com/nanocurrency/nano-node/master/images/attack.png)<br /><br />If an attacker is able to cause Stake > Active by a combination of these circumstances, they would be able to successfully flip votes on the ledger at the expense of their stake.  We can estimate how much this type of attack could cost by examining the market cap of other systems.  If we estimate 33% of representatives are offline or attacked via denial of service, an attacker would need to purchase 33% of the market cap in order to attack the system via voting.<br />Voting attack cost:<br /><ul><li>Euro - M1 in 2014 \~6 trillion, attack amount 2 trillion</li><li>USD - M0 in 2014 \~4 trillion, attack amount 1.2 trillion</li><li>UK pound sterling - M0 in 2007 \~1.5 trillion, attack amount 500 billion</li><li>Bitcoin - Market cap 2014 \~3 billion, attack amount 1 billion</li>
+|**Description** | The metric of consensus for Nano is a balance weighted voting system.  If an attacker is able to gain over 33% of the voting strength, they can cause the network to oscillate their decisions rendering the system useless.  Unless the attacker managed to obtain its voting power by being elected as representative by accounts with balances summing up to the required 33%, the attacker must have at least some value tied up in the network as a balance which they're willing to forfeit as an expense to performing this type of attack, since this attack ruins the integrity of the system.  An attacker is able to lower the amount of balance they must forfeit by preventing good nodes from voting through a network DDOS.  
+|**Defense** | There are multiple levels of defense against this type of attack:</br><ul><li>*Primary defense*: voting weight being tied to investment in the system; attempting to flip the ledger would be destructive to the system as a whole which would destroy their investment.</li><li>*Secondary defense*: cost of this attack is proportional to the market cap of all of Nano.  In proof of work systems, technology can be invented that gives disproportionate control compared to monetary investment and if the attack is successful, this technology could be repurposed after the attack is complete.  With Nano the cost of attacking the system scales with the system and if an attack were to be successful the cost of the attack can't be recovered.</li><li>*Tertiary defense*: In order to maintain the maximum quorum of voters, the next line of defense is representative voting.  Account holders who are unable to reliably participate in voting for connectivity reasons can name a representative who can vote with the weight of their balance.</li><li>Forks in Nano are never accidental so nodes can make policy decisions on how to interact with forked blocks.  The only time non-attacker accounts are vulnerable to block forks is if they receive a balance from an attacking account.  Accounts wanting to be secure from block forks can wait a little or a lot longer before receiving from an account who generated forks or opt to never receive at all.  Receivers could also generate separate accounts for receiving from dubious accounts in order to protect the rest of their balance.</li><li>A final line of defense is block cementing.  As blocks are confirmed in V19.0+, the node marks the height of the last block confirmed for every account and will refuse the replacement of an already confirmed block. Attempts to fork after previous confirmation of a block will immediately fail.</li><br />The most sophisticated version of a >33% attack is detailed in the diagram below.  "Offline" is the percentage of representatives who have been named but are not online to vote.  "Stake" is the amount of investment the attacker is voting with and will be lost if they successfully attack the system.  "Active" are representatives that are online and voting according to the protocol.  An attacker can offset the amount of stake they must forfeit by knocking other voters offline via a network denial of service attack.  If this attack can be sustained, the representatives being attacked will become unsynchronized and this is demonstrated by "Unsynced".  Finally, an attacker can gain a short burst in relative voting strength by switching their denial of service attack to a new set of representatives while the old set is resynchronizing their ledger, this is demonstrated by "Attacked".<br /><br />![Voting attack](https://raw.githubusercontent.com/nanocurrency/nano-node/master/images/attack.png)<br /><br />If an attacker is able to cause Stake > Active by a combination of these circumstances, they would be able to successfully flip votes on the ledger at the expense of their stake.  We can estimate how much this type of attack could cost by examining the market cap of other systems.  If we estimate 33% of representatives are offline or attacked via denial of service, an attacker would need to purchase 22% of the market cap in order to attack the system via voting.<br />Voting attack cost:<br /><ul><li>Euro - M1 in 2014 \~6 trillion, attack amount 1.3 trillion</li><li>USD - M0 in 2014 \~4 trillion, attack amount 0.9 trillion</li><li>UK pound sterling - M0 in 2007 \~1.5 trillion, attack amount 333 billion</li><li>Bitcoin - Market cap 2014 \~3 billion, attack amount 0.67 billion</li>
 
 ## Bootstrap poisoning