6680691_​EthereumIndividualProject

Preprocessing Data

String to Date&Time — the Date column starts as plain text (like "06/21/2026"). This node turns it into an actual date type, help KNIME understands it as a calendar date, not just a word.

2. Three parallel "assembly lines" for the Volume column
Raw Volume numbers come in three different shorthand styles: 12.4K, 3.1M, 1.2B (thousands/millions/billions). A computer can't do math on text like "12.4K", built one branch for each suffix:

• Row Filter — pulls out only the rows ending in that particular letter (K, M, or B)

• String Replacer — deletes the letter, leaving just the number as text (e.g. "12.4")

• String to Number — converts that text into an actual number KNIME can calculate with

• Math Formula — multiplies it back up to the true value (e.g. ×1,000 for K)

I run three copies of this same four-step process side by side because each suffix needs a different multiplier for it to work.

3. Stitch it back together

• Concatenate — Connect the three branches back into one table now that Volume is a real number everywhere

• String Replacer — removes the "%" symbol off the Change % column

• String to Number — converts that into a real number too

• Math Formula — divides by 100, turning "3.5%" into 0.035 (a decimal), which is the standard way to represent a percentage for calculations

4. Final tidy-up data to be use for other workflow

• Sorter — puts all rows in date order

• Duplicate Row Filter — removes any accidental duplicate dates

• Component Output — hands the finished clean table out to the rest of the workflow

• Statistics — produces a quick summary table (min/max/average/etc. for each column)

The preprocessing data is more accurate and consistent because it ensure the correct date format, no duplicate dates, corrected outliers, and only the necessary columns (Date and Price).

Visualization Data

Branch 1 (top) — basic visualization of the data

• Line Plot "Price" → raw price over time

• Line Plot "Log of Price" → log-transformed price over time (raw vs. transformed comparison)

• Histogram "Price" → how price values are distributed

• Histogram "Return" → how daily % moves are distributed (spikes here = outlier days)

Branch 2 (middle) — seasonality, static charts

• Extract a calendar unit (e.g. month) → do a calculation → Pivot into a comparable layout → Line Plot it

• Repeated a second time for a different calendar unit (e.g. year)

Branch 3 (bottom) — seasonality, one interactive dashboard (Candlestick)

• Extract a calendar unit → combine columns into a label (e.g. "2024-03") → GroupBy to average per period → rename columns → sort → render as an interactive chart (ECharts)

Top branch shows what the raw data looks like and flags outlier days; middle and bottom branches both check for seasonal patterns.

This component mainly focus on exploratory visualizations through raw-vs-log price comparison, return/price distributions, and two different seasonality breakdowns (one as static line plots, one as an interactive dashboard) in order to visually inspect the data and spot outliers before modeling.

Major Macroeconomic Shocks & Market Events (Observed from visualization data)

2017 bubble & crash: It could be observed from the price and log price chart that there is a sharp rise to $1,000+ during late 2017, then crash into 2018 due to "crypto winter"

2019-2020 slow grind: It could be observed from the chart that there is a Long flat/low period (~$100-300) before breakout in late 2020, aligning with DeFi summer momentum carrying into 2021.

2022 bear market: It could be observed from the candlestick chart that there is a steady decline from $4,800 down to $1,000 due to Luna and FTX collapses.

From the histogram chart for price. The big spikes at $6.7 is not a real outliers as it just reflects ETH years of low early prices

From the histogram chart for return. There is a peak near 0, with a long left tail out to -0.35 to -0.59, suggesting extreme crash days far outside normal daily volatility, is it likely link with known crashes such as the 2018 bear market and 2020 Luna and FTX collapses incident.

Outlier detection -> catch errors and maintain data quality

Outlier detection with rolling statistics : Used the moving aggregator to find the mean and standard deviation for Price. Then used the math formula in order to find both Upper limit and Lower limit. Lastly, used the rule engine node to flag the outliers. If the $Price is more than the UCL and lower than the LCL, it is considered as an outliers

Outlier detection and Hampel Filter Techniques: Used the moving aggregator to find the median. Then using the moving aggregator to find the median of absolute. After that used the math formula as to look for the control limit. Lastly, used the rule engine to flag for noticeable outliers. If the absoluate_deviation$ > $control_limit$ then it is an "outlier"

For this project,Hampel Filter with a rolling median is being used, where any noticeable outliers were then replaced with the rolling median. This made the data cleaner and helped KNIME produce more accurate forecasts which will later be used for ARIMA and Holt’s Exponential Smoothing models.

Trend and Momentum

Using Rule Engine Node to determine the strength of the trend based on the Hurst Exponent and Z-Score

$Hurst Exponent$ > 0.55 AND $MK_Z_Score$ > 1.96 => "Strong Bullish Trend"

$Hurst Exponent$ > 0.55 AND $MK_Z_Score$ < -1.96 => "Strong Bearish Trend"

$Hurst Exponent$ < 0.45 AND ($MK_Z_Score$ > -1.96 AND $MK_Z_Score$ < 1.96) => "Mean Reversion / Sideways"

$Hurst Exponent$ < 0.45 AND ($MK_Z_Score$ < -1.96 OR $MK_Z_Score$ > 1.96) => "Trend Exhuasion Warning"

Most periods show a clear trend because it could be observed that the Hurst Exponent is above 0.5 in all rows (around 0.66–0.80). This means the ETH price tends to continue moving in the same direction and is not always random.

Lag Column and Math formula before the outlier detection process, the price is converted using a logarithm ln($Price$/$Price(-1)$) as shown by the new added column Price(-1).

Holt’s Exponential Smoothing Models

The rolling price chart shows that the gap between the Upper Control Limit (UCL) and Lower Control Limit (LCL) becomes larger as the ETH price increases. For example, the gap is small during the low-price period in 2018 but much larger during the high-price periods in 2025. This means that price changes become larger when the price is higher, suggesting multiplicative behavior within the observing trend.

In order to reduce this effect, the ETH prices were log-transformed before modeling. The log transformation makes the size of the price changes more consistent over time.

Two Exponential Smoothing models were used in KNIME to compare a non-seasonal model with a seasonal model.

• Holt's Double Exponential Smoothing models: only the Level and Trend of the data and does not include seasonality.

• Holt's Triple Exponential Smoothing: models the Level, Trend, and Seasonality.

Unlike Bitcoin, Ethereum has no fixed block-reward "halving" schedule and does not follow a 4 year cycle like Bitcoin. Moreover, we could make an assumption that Ethereum's price historically moved along with Bitcoin's long-term market cycle with some sort of a correlation. Both models were applied to the price log-transformed data (Log_Price = log(Price)). The forecast results were then converted back to the original price values for evaluation.

Implemented via Java Snippet nodes were:

•      Level: Lt = α·yt + (1−α)·(Lt−1 + Tt−1)

•      Trend: Tt = β·(Lt − Lt−1) + (1−β)·Tt−1

•      Seasonality (Triple only): St = γ·(yt − Lt) + (1−γ)·St−m

•      Forecast (1-step-ahead): ŷt = Lt−1 + Tt−1 (plus St−m for Triple)

The Actual vs. Forecast plots show that both the Double and Triple Exponential Smoothing models closely follow the actual ETH prices throughout the entire period, including the major price changes in 2017, 2021, and 2025. This suggested that the Level and Trend components already explain most of the ETH price movement. Adding the seasonal component in the Triple model provides only a small improvement. Meaning that ETH's long-term price cycles are influenced mainly by the market events rather than fixed seasonal pattern.

The smoothing parameters for both models were automatically selected using KNIME's Parameter Optimization Loop. Different parameter values were tested to find the combination that produced the lowest Root Mean Squared Error (RMSE). Mean Absolute Error (MAE) and R² were also used to evaluate the model performance.

Moreover, The maximum values for α, β, and γ were limited to maximum of 0.30 because the log-transformed Ethereum data only required small smoothing values. This prevents the model from overreacting to short-term price changes and helps produce more stable forecasts.

ARIMA

Unlike the Holt's models, which used the log-transformed price data, the ARIMA model was directly applied to the Ethereum raw data price data. Instead of using a log transformation, ARIMA used differencing (d) to make the data more stable. The dataset was split into 80% training data (2,998 rows) and 20% testing data (750 rows). KNIME's Parameter Optimization Loop was then used to automatically find the best ARIMA parameters for the model.

ARIMA Learning -> Trains the ARIMA model using the training data as it uses the historical time series data (e.g., Ethereum prices), and is based on its selected p, d, and q values.

ARIMA Predictor -> Takes the trained model from the ARIMA Learner and produces the forecast results, which can be compared with the actual prices.

Automated grid-search over (p, d, q) to minimizing RMSE, using KNIME's Parameter Optimization Loop to tested different combinations of:

• p: 0 to 5 (step = 1)

• d: 0 to 2 (step = 1)

• q: 0 to 5 (step = 1)

Each combination was used to train an ARIMA model, and the predictions were evaluated using the Root Mean Squared Error (RMSE). The model with the lowest RMSE was selected as the best ARIMA model result.

Chosen parameters:

• Alpha (α): 0.01–0.30 (step 0.01) was chosen to test different levels of responsiveness to changes in Ethereum prices.

• Beta (β): 0.001–0.05 (step 0.001) was selected because long-term trends usually change more slowly comparing to daily price movements.

• Gamma (γ): 0.01–0.30 (step 0.01) was chosen to test different levels of seasonal smoothing while preventing the model from overreacting to temporary changes in the data.

• Small step sizes (0.01 for α and γ, and 0.001 for β) were used to allow KNIME to test many parameter combinations and identify the values that produced the lowest RMSE and the most accurate forecasts.

• The Parameter Optimization Loop automatically selected the best combination of α, β, and γ based on the lowest RMSE, ensuring the final model was optimized for the Ethereum dataset.

Comparing Holt's Exponential Smoothing and ARIMA using an 80/20 hold-out test set.

The Numeric Scorer Node are being used to help determine the Mean Absolute Error, Root Mean Square Error, and Mean Absolute Percentage Error, which will be use to evaluate which of the model is the most appropriate for forecasting the price.

Holt's Double Exponential Smoothing -> MAE is 108.749 , RMSE is 152.443 , MAPE is 0.038%

Holt's Triple Exponential Smoothing -> MAE is 142.37 , RMSE is 234.81 , MAPE is 0.117%

ARIMA -> MAE is 904.073 , RMSE is 1017.526 , MAPE is 0.3%

As for the comparison, it seems like Holt's Double Exponential Smoothing produced the most accurate forecasts, with the lowest MAE (108.75) and RMSE (152.44). Holt's Triple Exponential Smoothing ranked second (MAE = 142.37, RMSE = 234.81), while the ARIMA model had the highest forecasting errors (MAE = 904.07, RMSE = 1,017.53). The better performance of Holt's Double model suggests that modeling only the level and trend is more suitable for Ethereum, as Ethereum doesn't need to account for seasonality compare to other cryptocurrency like Bitcoin. Therefore, Adding a fixed 1,461 day ( 4 years) seasonal component did not improve the forecasts because Ethereum does not have a strong repeating seasonal pattern comparing to the Bitcoin's halving cycle.