Alright, so I guess we start simple. What is a balance sheet attack?
A Balance Sheet Attack (BSA) is an attempt to profit off of the logic of passed motions or fabricating situations that force shareholders to pass certain motions that can be profited off of. There are only three ways to defend against a BSA:
- Make the attack very expensive
- Make the attack require extremely large amounts of liquidity (preferably invested in the system)
- Make the attacker take on an extremely large risk
I think I will move away from the general now and right in to a specific, textbook case:
The Buy Slow Sell Fast (BSSF) Attack
This classic example uses the basic asymmetry of the peg against itself. The backing concept here is that shareholders have control over only one side of the peg in an NBT/BTC pair. Interestingly enough, the concept seems to disappear when NBT/NSR is considered, but in reality the risk has simply been spread out throughout the network. So in the case of an infinitely liquid NSR/USD price, this attack is equivalent to a well known PoS attack of simply buying a large portion of the network and holding stake.
So, the BSSF attack is therefore a figment of an illiquid NBT/NSR gateway as long as the NSR marketcap greatly exceeds the NBT marketcap. Still, we must consider the attack and the consequences. Let us examine it in chronological order by the attacker:
Step 1 must be buy NBT. Because the network needs time to create and release more NBT, it will be assumed that this will happen over time. The speed of purchase should be enough to keep Nu doing buybacks semi-continually and increasing the price over time.
Now that the attacker has a large percentage of the NBT in existence, when they sell they will smash safeguards and potentially promote either a long term breaking of the peg or forcing shareholders to go through messy illiquid NBT/NSR gateways quickly. The strategy here is to sell at a price just low enough to cause a panic and dump the peg (something like $0.95 or $0.9)
Profit Strategy: The purchase pressure of buying NBT at $1 will be symmetric with buying $1 of shares. Similarly, the sell pressure will apply direct market pressure. The basic statement is that buying at open market prices over time allows for a lot more liquidity than selling in a short period of time. The price could easily spike lower than it rises, assuming the buyback and dilution amount in $$ is the same. The attacker can certainly participate in the dilution and buy shares at a greatly reduced price. Or, the price could bottom out and the peg could fail indefinitely, thereby removing Nu as a competitor.
How the shareholders respond currently:
The response to a slow buy is to store the purchased liquidity in T1-3 first and use them as feedback sensors for T4, where the purchased liquidity is used to buyback NSR. Because this occurs over time, the NSR price trends upward and Nu enters a period of prosperity.
Step 2 is where it gets interesting. The sell walls would most likely happen on a number of different exchanges essentially at once, and after a day or two almost all T1-3 would get dumped, triggering T4 which would also get dumped. This leaves NSR sales, a messy business.
Liquidity required = ($0.95)*(Desired effect on NSR market) + T1-3 buy + T4 buy + market forces to keep peg at $0.95 > $200k
Cost = 0.05 * Desired effect on NSR market + Network Spread * Tiered liquidity
(i.e. act on NSR market with 20:1 leverage after tiers are depleted)
Clearly, this attack already requires a lot of liquidity. However, when Nu is a lot more valuable, will this liquidity requirement be enough? The T1-3 term will grow, as will the market forces and the desired effect on NSR. It makes logical sense that we make T4 also grow with the network. One of the most direct ways to do this is to tie it directly to the NBT supply. Under that logic, I will be introducing a motion to turn T4 buy threshold into a function of the NBT supply.
The Threshold Attack
The idea here is to take the BSSF to the next step and prey on the particular motion thresholds that have been implemented.
~ Work in progress