Trajectory-Based Behavioral Analytics for Blockchain Systems

Abstract

Blockchain systems generate massive volumes of transactional data, yet most existing analytical approaches rely on query-based retrieval mechanisms that treat transactions as isolated records. In this paper, a trajectory-based framework for blockchain analysis is introduced where user activity is modeled as temporally ordered behavioral patterns. Four types of blockchain trajectories are formally defined: miner reward trajectories, sender value-and-fee trajectories, receiver value trajectories, and sender–receiver interaction trajectories. Unlike traditional query frameworks, trajectories are treated as first-class analytical objects, explicitly constructed and returned as outputs, thereby enabling structured temporal reasoning over blockchain behavior. To demonstrate the practicality of the approach, the proposed trajectory functions are implemented in Python 3.12 and experiments are conducted using real data from the Ethereum blockchain. Compared with conventional query-based approaches that return isolated transactions, the experimental results show that the proposed trajectory-based framework enables a more systematic identification of temporal behavioral patterns, including persistent miner dominance, recurrent zero-value interactions, sender–receiver role reversals and sender dominance by sending the highest values across several periods. The results show that trajectory-based modeling provides a systematic lens for uncovering temporal and structural regularities that are not readily observable through conventional query techniques. This work establishes a formal foundation for behavioral blockchain analytics and opens new research directions in centralization measurement, predictive modeling, and trajectory similarity analysis.

1. Introduction

A blockchain is a distributed database (DB) that stores records of transactions (as a result of peer-to-peer transfers or smart contract calls) in blocks, and each block linked to a previous one (except the first one, the “genesis” block), creating a chain of data blocks. It is append-only, i.e., a block cannot be updated or deleted, and decentralized, since a network of nodes must agree before any new data is written.

This chain includes controls (cryptographic ones and protocols, among others) that make it almost impossible to alter its data [1]. Because of this, the first and one of the main applications of blockchain is to store data about financial transactions. Although blockchains were originally developed as a means for interchanging money (cryptocurrencies) without an intermediary [2] (i.e., without a financial entity like a bank or a company specialized in sending money), today, blockchain technology is used in hundreds of case studies across different fields such as education, government, healthcare, and insurance, among many others.

Blockchain DBs offer a rich data source for conducting analyses, enabling the detection of recurrent patterns and the generation of insights for decision-making. Although the data is rich, it is also raw. To make it useful for analysis, it must be processed and presented in a meaningful and interpretable form.

This research study introduces the concept of trajectory as a framework for analyzing blockchain data. Informally, a trajectory is a series of events of an entity (an object) that takes place in a space during a time interval. In the context of the Ethereum blockchain, four types of trajectories are formally defined: the miner reward trajectory, sender value-and-fee trajectory, receiver value trajectory, and sender–receiver interaction trajectory. For example, the miner reward trajectory represents the series of rewards (i.e., the events) of a miner (an actor of a blockchain, i.e., the object) that he earns in a blockchain (i.e., the space) during a given time interval. These trajectories can support the identification of blockchain patterns, including recurrent events, anomalous behaviors and similarities among groups of trajectories. They can also help determine whether two users, such as a sender and a receiver, tend to interchange their roles over time, with the sender later acting as the receiver and vice versa. The feasibility and usefulness of the proposed method were demonstrated through Python-based implementations using real Ethereum blockchain data.

Although previous studies have developed languages and operators for blockchain analysis (Section 2), this work introduces the trajectory concept as an analytical object for blockchain systems, formalized through a specialized class that includes composition, inheritance, and associated methods. This offers a natural and intuitive framework for analyzing transactional data as time-ordered behavioral sequences rather than as isolated records. In this way, the paper establishes a first foundational step toward behavioral blockchain analysis through trajectories.

The main contributions of this paper are (1) the formal specification of four distinct types of blockchain trajectories, (2) a UML class diagram, including trajectories and group of trajectories, and (3) the design of an experimental setup, including the implementation in Python and an SQL-Like solution along with basic experiments on real data from the Ethereum blockchain to demonstrate the expediency of the proposed framework.

The paper is organized as follows. Section 2 surveys existing query languages and frameworks for blockchain analysis. Section 3 introduces the proposed trajectory-based model and provides formal definitions of the four types of blockchain trajectories. Section 4 details the Python-based implementation, describes the dataset, the experimental design, and analyzes the results, emphasizing the behavioral patterns revealed. Finally, Section 5 concludes the paper and outlines future research.

2. Related Works

Several query languages, especially for Ethereum and analytical frameworks, have been proposed for blockchain systems. In what follows, the most relevant works are reviewed. The review first considers query languages, including EQL, EtherQL, Quorum-Based SQL, and related approaches, and then examines analytical frameworks such as The Graph, vChain, a blockchain framework with spatio-temporal query capabilities, and Datachain. The section concludes with a comparative analysis in which their key aspects are presented side by side.

2.1. EQL

The Ethereum Query Language (EQL) [3] is a query language designed for Ethereum-based blockchains. It enables the querying of block and transaction data and adopts a syntax based on SQL. EQL supports the typical clauses SELECT, FROM, WHERE, ORDER BY (although it does not include GROUP BY), and LIMIT, which is not part of the SQL standard, but is part of several DBMSs. It also provides mechanisms for defining views and indexes. Thus, in EQL, it is possible to formulate queries such as “Retrieve the identifiers of blocks generated between 18 January 2026 and today, that contain more than 200 transactions; present the results in descending order by the total number of transactions per block and limit the results to the first 25 rows”:

SELECT b.number AS block_number, b.transactions.size AS number_of_transactions

FROM ethereum.blocks AS b

WHERE b.timestamp BETWEEN date(‘2026−01−18’) AND now() AND

b.transactions.size > 200

ORDER BY b.transactions.size

LIMIT 25;

Proposals similar to EQL include Bitcoin-Abe [4] developed for Bitcoin-based blockchains, Hyperledger Blockchain Explorer [5] designed for Hyperledger Fabric-based blockchains, Blockchair API [6], an API that supports SQL-like queries for 16 cryptocurrency blockchains, and BlockSci [7], a high-performance tool for blockchain exploration, where transactions are periodically extracted from a blockchain and then stored in an in-memory DB. This DB can be queried using Python or C++ snippets.

2.2. EtherQL

EtherQL [8] is a query API designed for Ethereum-based blockchains. The API includes query primitives for querying blocks and transactions and supports range and top-k queries. Analysts can configure predefined queries through interfaces, including: (i) transactions related to a specified account, (ii) the top-k accounts ranked by balance (top-k query), and (iii) transactions within a given time interval range query. However, the authors do not present examples of the queries generated through these interfaces.

2.3. Quorum-Based SQL Query System

In [9], the authors propose a system that enables SQL query operations for retrieving smart contract data and standard transaction data within a blockchain system. Their implementation is built on Quorum, which is an Ethereum-based blockchain system [10]. The system supports (i) single record queries, e.g., the state of a smart contract at one point, (ii) range queries, e.g., the transactions of a user in a temporal range (see Figure 1a), and (iii) conditional queries, i.e., data based on specific conditions, e.g., transactions between two users (see Figure 1b). Like EtherQL, analysts can configure predefined queries through interfaces; however, the paper does not provide explicit formulations of the queries.

None of these languages or APIs (EQL, EtherQL, Quorum-Based SQL, and the ones mentioned at the end of Section 2.1) offer specialized operators aimed at pattern detection, e.g., detecting recurrent user behaviors, which constitutes a central objective of the trajectory-based approach proposed in this work. Indeed, the concept of a trajectory is absent from all these works. Generally, these languages or APIs only provide basic SQL-like capabilities—such as SELECT, FROM, WHERE, ORDER BY, GROUP BY, and LIMIT—while some also incorporate regular expressions, range queries, and top-k queries.

2.4. The Graph

The Graph [11,12] is a platform that provides a development framework for indexing and querying blockchain data. The Graph stores and indexes blockchain data based on a subgraph description provided by the analyst, known as the subgraph manifest. Once stored and indexed, these subgraphs can be queried using GraphQL (https://graphql.org (accessed on 15 July 2025)). GraphQL is a query language and runtime environment that allows clients (e.g., a server, a mobile app) to request exactly the data they need through a strongly typed schema. Consequently, the expressiveness of the queries is constrained by the capabilities of GraphQL. As an example of data indexed into subgraphs, consider CryptoKitties [13], a blockchain-based game in which users create and exchange CryptoKitties. An analyst may formulate queries such as: (i) How many CryptoKitties does a specific Ethereum account own? (ii) When was a particular CryptoKitty created? (iii) Who are the owners of the CryptoKitties created between August and September of 2025? [12].

For example, in a subgraph defined to analyze auctions in CryptoKitties, consider the following GraphQL query, shown in Figure 2, that returns the startedAt attribute (the auction start date expressed in Unix Time, https://www.epochconverter.com (accessed on 15 July 2025)) and the cryptoKitty id for all auctions whose state is “live”.

2.5. vChain

In [14], a framework called vChain is proposed for querying transactions. A transaction defined in a general sense, not necessarily restricted to blockchain systems, includes date, recipient, sender, type, value, and potentially other attributes. vChain supports two query types:

(i)

Time-window query: This query type allows users to query transactions of a given time interval. For example, the query: q = ⟨[2026/05, 2026/06], [1, +∞], sender: 1FFYc ∧ recipient: 2DAAf⟩ returns all transactions from May to June 2026, with a value greater than or equal to one unit ([1, +∞]), associated with the addresses 1FFYc (sender address) and 2DAAf (recipient address).

(ii)

Subscription query: This query type allows users to query transactions over an open time interval, with results updated continuously in real time. For example, the query: q = ⟨-, [1, 3], sender: 1FFYc⟩ returns all transactions whose value lies between 1 and 3 units, associated with the address 1FFYc (sender address). Whenever a new transaction satisfying these conditions is recorded, it is automatically appended to the result; this will continue until the query is removed by the user.

Although additional processing of the results generated by these queries could reveal some patterns (e.g., based on the results of the aforementioned subscription query, it is possible to determine the average time a user issues transactions), vChain is not specifically designed for pattern detection.

2.6. A Blockchain Framework with Spatio-Temporal Query Capabilities

A spatio-temporal blockchain model and a set of dedicated query operators are proposed in [15]. Each transaction is associated with latitude, longitude, a timestamp, and a uid identifying the user (creator) of the transaction. Blocks have a header and a body (the set of transactions). The header includes startTime and endTime attributes, where startTime corresponds to the earliest date among all the transactions included in the block and endTime to the latest date.

The following query types are considered.

(i)

Temporal range query: Given a time interval β, this query returns the header of those blocks whose intersection of the time interval of the block [startTime, endTime] with β is non-empty. For example, the query σ_{β = (2026/05/10, 2026/05/20)} returns the headers of the blocks containing transactions between 10 and 20 May 2026.

(ii)

Spatial range query with hyper-rectangle delimitation: Let D = {x | x ∈ ℝⁿ} be the set of spatial points corresponding to transaction coordinates obtained from a temporal range query. Given a hyper-rectangle q of coordinates q = x, x ∈ ℝⁿ, this query returns all points of D that are inside q. For example, the query σ_{q = ((0,0), (0,4), (4,0), (4,4))}(D) returns the points of D located inside the rectangle defined by the vertices (0,0), (0,4), (4,0), and (4,4).

(iii)

Spatial range query with hyper-sphere delimitation: Given a set of points D = {x|x ∈ ℝⁿ}, a radius r (r ∈ ℝ⁺), and a point q = {x}, x ∈ ℝⁿ, this query returns all points in D within the hyper-sphere of radius r centered at q. For example, the query σ_{q = (3, 1), r = 4}(D) returns all points of D located inside the circle of radius 4 centered at (3, 1).

(iv)

k-nearest neighbors: Given a set of points D = {x | x ∈ ℝⁿ}, a number k (k ∈ ℕ), and a point q = x, x ∈ ℝⁿ, this query returns a subset of k points in D closest to q. For example, the query σ_{k = 2, q = (3, 1)}(D) returns the two points in D nearest to (3, 1).

(v)

k-nearest neighbors with hyper-sphere delimitation: Given a set of points D = {x|x ∈ ℝⁿ}, a number k (k ∈ ℕ), a radius r (r ∈ ℝ⁺), and a point q = x, x ∈ ℝⁿ, this query returns a subset of k points in D nearest to q within the hyper-sphere of radius r centered at q. For example, the query σ_{k = 2, q = (3, 1), r = 4}(D) returns the two points in D nearest to (3, 1) inside the circle of radius 4 centered at (3, 1).

In a similar way to vChain, these queries generate a list of results consisting of spatio-temporal points associated with transactions; however, they are not specifically designed for pattern detection.

2.7. Datachain

Datachain [16] is a framework designed for asset management in blockchain platforms. An asset can be tangible, such as a bicycle or a house, or intangible, such as a cryptocurrency transfer or a stock certificate. An asset can have a wide range of properties. The framework supports SQL-like queries over blockchain assets and their associated properties. Asset properties vary according to application domain. For example, in the case of a bike as an asset, properties include bike id, distance, distance unit, last update, and owner. Datachain allows users to perform ad hoc queries instead of a pre-determined set of queries. Query results can be generated in different formats including JSON, XML, and CSV, among others. Datachain was developed in Python and can be used as a library. For example, in Figure 3, an SQL ad hoc query that returns the three most recent updates (in ascending order) for the asset with id = aXz2r12wQ34 is shown. The query returns three properties: distance, distance unit, and last_update. With respect to pattern detection, Datachain exhibits the same drawbacks as those identified in Section 2.3.

Table 1. Comparison of proposals.

Language/ Framework	Detection of Patterns	Database	Query Language		Supported Queries	Supported Blockchains
			SQL-like	Proprietary
EQL [3]	No	External	✓		SQL-like language to query blocks and transactions	Ethereum
EtherQL [8]	No	Embedded		✓	Query primitives for querying blocks and transactions, top-k and range queries	Ethereum
Quorum-Based SQL Query System [9]	No	Embedded	✓		SQL query operations for smart contracts	Ethereum
The Graph [11,12] + GraphQL	String and relationship pattern matching	Embedded		Queries are formulated with GraphQL	GraphQL queries	Any
vChain [14]	No	No database		✓	Time-window and subscription queries	General transactions
A Blockchain Framework with Spatio-Temporal Query Capabilities [15]	No	No database		✓	Temporal range, spatial range, and k-nearest neighbors queries	Any
Datachain [16]	No	External	✓		SQL-like language to query assets	Any

presents a comparative summary of the main features of the analyzed proposals.

Existing works (both frameworks and query languages) mainly focus on querying a blockchain DB through filtering mechanism (selectors). In contrast, the research presented in this work formally introduces the concept of trajectory as the core abstraction for blockchain analysis. A trajectory is treated as a first-class entity: it is formally defined and explicitly returned as an output of the analytical process, rather than being an implicit result that the analyst must create from query results. This explicit high-level construct allows analysts to reason in terms of temporal behavior and to detect patterns that are not always visible from isolated transactions or lists of transactions. Thus, the main contribution of the proposed work lies in the formulation of a trajectory-based framework that supports behavioral analysis over time.

3. Blockchain Trajectories

3.1. Blockchain DB

A blockchain DB (BCDB) can be formally defined as a finite set of blocks: BCDB = {bl₁, bl₂, …, bl_n}. For i = 1 to n, each block bl_i is represented as a tuple (idBlock, idPreviousBlock, dateBlock, idMiner, reward, TRS). The attribute idBlock ∈ ℕ denotes the identifier of the block, while idPreviousBlock ∈ ℕ denotes the identifier of the preceding block. The attribute dateBlock ∈ Timestamp specifies when the block was created (mined). The attribute idMiner ∈ Hash number denotes the identifier of the miner who created the block. The attribute reward ∈ ℝ+ represents the mining reward, expressed as an amount of cryptocurrency such as ether (ETH). Finally, TRS = { tr₁, tr₂, …, tr_m} denotes the set of transactions contained in the block.

The first block in the BCDB, referred to as the “genesis” block, has no predecessor block; this is indicated with the symbol “--”. The genesis block has idBlock = 1, the next block has idBlock = 2, and so on. Given a block with idBlock = k, k > 1, then idPreviousBlock = k − 1. Thus, the idPreviousBlock attribute is redundant; however, in blockchain systems, where blocks are identified by hash numbers instead of natural numbers, this attribute becomes essential to preserve the explicit linkage between consecutive blocks.

• Example 1

Consider BCDB = {bl₁, bl₂, bl₃} where bl₁ = (1, --, 1717293600, a222, 6.39, {tr₁, tr₂}), bl₂ = (2, 1, 1717294200, b105, 6.81, {tr₁, tr₂, tr₂}), and bl₃ = (3, 2, 1717294680, a222, 6.65, {tr₁, tr₂}). For dates, Unix Time is used; thus, 1717293600 = 2024-06-02 02:00:00 GMT+0, 1717294200 = 2024-06-02 02:10:00 GMT+0, and 1717294680 = 2024-06-02 02:18:00 GMT+0.

3.2. Transaction

A transaction tr_i, for i = 1 to m, is represented as a tuple (idTransaction, idSender, idReceiver, value, fee) where idTransaction ∈ Hash number denotes the identifier of the transaction and idSender ∈ Hash number the identifier of the user (sender) that is transferring a value (an amount of a cryptocurrency), idReceiver ∈ Hash number denotes the identifier of the user (receiver) receiving a value, value ∈ ℝ⁺ represents the amount of cryptocurrency transferred from the sender to the receiver, and fee ∈ ℝ⁺ is the fee (also an amount of a cryptocurrency) paid by the sender for processing the transaction. Thus, each transaction formalizes a value transfer between two users (a sender and a receiver) together with the associated processing cost (fee).

• Example 2

Consider the set of transactions presented in

Table 2. Examples of transactions.

Block	Transaction	idTransaction	idSender	idReceiver	Value	Fee
${bl}_1$	${tr}_1$	01d4	cD96	Aaa5	5.5	0.025
	${tr}_2$	a721	cD96	231E	2	0.0002
${bl}_2$	${tr}_1$	b931	aS47	Aaa5	4.3	0.03
	${tr}_2$	a8u7	cD96	231E	6.2	0.048
	${tr}_3$	fT50	R27a	uN53	4.7	0.04
${bl}_3$	${tr}_1$	05d3	aS47	5b3c	2.5	0.0036
	${tr}_2$	a897	cD96	231E	3.8	0.0005

.

3.3. Trajectory

A trajectory is defined over a BCDB during a time interval [startDate, endDate]. A trajectory is a time-ordered sequence of points associated with an actor (e.g., a user or a couple of users) of the blockchain. A point corresponds to a distinct blockchain event involving that actor. For example, if the actor is a miner, a point may represent the timestamp at which the miner successfully mined a block. A point may include attributes describing the underlying blockchain event. In the case of a miner, such attributes may include the mining date and the corresponding reward received for validating the block. Thus, a trajectory is a chronologically ordered sequence of points: Trajectory = {pt₁, pt₂, …, pt_k}, where each point pt_i represents an event (with its corresponding attributes, e.g., id, date, and value) in the trajectory of an actor.

In what follows, four trajectory types are defined: the miner reward trajectory (MinerTrajectory), sender value-and-fee trajectory (SenderTrajectory), the receiver value trajectory (ReceiverTrajectory), and the sender–receiver interaction trajectory (SenderReceiverTrajectory). Each of these is a subclass of the trajectory class, as shown in Figure 4.

(a)

Miner reward trajectory: The miner reward trajectory of a miner represents the history of all blocks mined by the miner during a time interval [startDate, endDate]. Formally, given a BCDB, the miner reward trajectory of idMiner = mnr, mnr ∈ Hash number, is defined over the time interval [startDate, endDate], where startDate ∈ Timestamp, endDate ∈ Timestamp, and startDate ≤ endDate.

A miner reward trajectory is a chronologically ordered sequence of miner points:

MinerTrajectory = {mpt₁, mpt₂, …, mpt_k},

A miner point mpt_i, for i = 1 to k, is defined as the tuple:

mpt_i = (winnerDate, reward),

where winnerDate ∈ Timestamp denotes the creation time (dateBlock) of a block mined by mnr and reward ∈ ℝ⁺ denotes the corresponding mining reward.

The points in MinerTrajectory are in ascending order with respect to winnerDate, i.e., for any two points mpt_i, mpt_j, for i = 1 to k and j = 1 to k, if i < j, then mpt_i.winnerDate < mpt_j.winnerDate. Moreover, the trajectory is constrained to the specified interval, such that mpt₁.winnerDate ≥ startDate and mpt_k.winnerDate ≤ endDate.

The function MinerTrajectory is defined as follows. Let MinerTrajectory be a function that returns the miner reward trajectory. The prototype of MinerTrajectory is:

MinerTrajectory: Hash number × Timestamp × Timestamp → Powerset (MPT),

where MPT = {mpt | mpt is a miner point}, i.e., MPT is the universal set of all miner points in the BCDB. That is, the MinerTrajectory function receives a hash number (i.e., the identifier of a miner), two timestamps (start and end date), and returns a subset of miner points (i.e., a subset of Powerset (MPT)) restricted to the specified interval.

• Example 3

Consider again BCDB = {bl₁, bl₂, bl₃}; see Example 1. The miner reward trajectory for idMiner = a222 over the time interval [1717293500, 1717294680] is {(1717293600, 6.39), (1717294680, 6.65)}. Formally: MinerTrajectory (a222, 1717293500, 1717294680) = {(1717293600, 6.39), (1717294680, 6.65)}.

This trajectory is shown in Figure 5 where timestamps are expressed in UTC (Coordinated Universal Time) format (YYYY-MM-DD hh:mm:ss). The time difference between the two points of this trajectory (18 min) represents the elapsed time between two consecutive blocks mined by the miner a222.

Next, Algorithm 1 presents the pseudocode for computing MinerTrajectory.

Algorithm 1. Pseudocode for Computing MinerTrajectory

Function MinerTrajectory (minerId, startDate, endDate, blockchainData)

1. filteredData ← rows in blockchainData WHERE idMiner = minerId AND

dateBlock BETWEEN startDate AND endDate

2. SORT filteredData BY dateBlock IN ASCENDING ORDER

3. dateList ← LIST dateBlock FROM filteredData

4. rewardList ← LIST reward FROM filteredData

/*The function ZIP pairs an element from dateList with its corresponding element from rewardList */

5. trajectory ← ZIP (dateList, rewardList)

RETURN trajectory

//Main Program

Input minerId, startDate, endDate, blockchainData

1. minerTr = MinerTrajectory(minerId, startDate, endDate, blockchainData)

2. FOR EACH (dateBlock, reward) IN minerTr:

3.                     PRINT (dateBlock, reward)

The algorithms corresponding to the remaining three trajectory types follow the same structure and are provided in Appendix A in a universal generic algorithm.

(b)

Sender value-and-fee trajectory: The sender value-and-fee trajectory of a sender represents the history of outgoing cryptocurrency transfers (outflows) performed by the sender during the interval [startDate, endDate]. Formally, in a similar way to the miner reward trajectory, the sender value-and-fee trajectory of idSender = sdr, where sdr ∈ Hash number, is defined over a BCDB within a time interval [startDate, endDate], with startDate ∈ Timestamp, endDate ∈ timestamp, and startDate ≤ endDate.

A sender value-and-fee trajectory is a chronologically ordered sequence of sender points:

SenderTrajectory = {spt₁, spt₂, …, spt_k}.

A sender point spt_i, for i = 1 to k, is defined as the tuple:

(sSentDate, sValue, sFee),

where sSentDate ∈ Timestamp denotes the timestamp of the block (dateBlock) containing a transaction of sender sdr with value sValue ∈ ℝ⁺ and fee sFee ∈ ℝ⁺. The points in SenderTrajectory are in ascending order according to sSentDate and spt₁.sSentDate ≥ startDate and spt_k.sSentDate ≤ endDate.

The function SenderTrajectory is defined as follows. Let SenderTrajectory be a function that returns the sender value-and-fee trajectory. The prototype of SenderTrajectory is:

SenderTrajectory: Hash number × Timestamp × Timestamp → Powerset (SPT),

where SPT = {spt|spt is a sender point}, i.e., SPT is the universal set of all the sender points in the BCDB. That is, the SenderTrajectory function takes as input a sender identifier and a time interval and returns a subset of sender points (i.e., a subset of Powerset (SPT)) restricted to the specified interval.

• Example 4

Consider the BCDB = {bl₁, bl₂, bl₃}; see Example 1. The sender value-and-fee trajectory for idSender = cD96 during the time interval [1717293500, 1717294680] is given by {(1717293600, 5.5, 0.025), (1717293600, 2, 0.0002), (1717294680, 3.8, 0.0005)}. Formally, SenderTrajectory(cD96, 1717293500, 1717294680) = {(1717293600, 5.5, 0.025), (1717293600, 2, 0.0002), (1717294680, 3.8, 0.0005)}.

This trajectory is shown in Figure 6. The temporal distances between consecutive points of a trajectory (in minutes) represents the elapsed time between successive transactions initiated by the sender cD96. Note that the sender cD96 has two transactions included in the same block; therefore, these two points share the same timestamp.

(c)

Receiver value trajectory: The receiver value trajectory of a receiver represents the history of the cryptocurrency inflows of the receiver during [startDate, endDate]. Formally, the receiver value trajectory for idReceiver = rcvr, where rcvr ∈ Hash number, is defined over a BCDB during a time interval [startDate, endDate], with startDate ∈ Timestamp, endDate ∈ timestamp, and startDate ≤ endDate.

A receiver value trajectory is a chronologically ordered sequence of receiver points:

ReceiverTrajectory = {rpt₁, rpt₂, …, rpt_k}.

A receiver point rpt_i, for i = 1 to k, is defined as the tuple:

rpt_i = (rReceivedDate, rValue),

where rReceivedDate ∈ Timestamp denotes the timestamp of the block (dateBlock) that contains a transaction in which rcvr is the receiver and rValue ∈ ℝ⁺ denotes the amount of cryptocurrency received. The points in ReceiverTrajectory are in ascending order according to rReceivedDate and rpt₁.rReceivedDate ≥ startDate and rpt_k.rreceiptdate ≤ endDate.

The function ReceiverTrajectory is defined as follows. Let ReceiverTrajectory be a function that returns the receiver value trajectory. The prototype of ReceiverTrajectory is:

ReceiverTrajectory: Hash number × Timestamp × Timestamp → Powerset (RPT),

where RPT = {rpt|rpt is a receiver point}, i.e., RPT is the universal set of all the receiver points in the BCDB. That is, ReceiverTrajectory takes as input a receiver identifier and a time interval and returns a subset of receiver points (i.e., a subset of Powerset (RPT)) restricted to the specified interval.

• Example 5

Consider the BCDB = {bl₁, bl₂, bl₃}; see Example 1. The receiver value trajectory for idReceiver = Aaa5 over the time interval [1717293500, 1717294680] is given by {(1717293600, 5.5), (1717293600, 0.0002), (1717294200, 4.3)}. Formally, ReceiverTrajectory (Aaa5, 1717293500, 1717294680) = {(1717293600, 5.5), (1717293600, 0.0002), (1717294200, 4.3)}.

This trajectory is shown in Figure 7. The temporal difference between successive points (expressed in minutes) corresponds to the elapsed time between consecutive transactions received by the receiver Aaa5.

(d)

Sender–receiver interaction trajectory: The sender–receiver interaction trajectory of a sender and receiver represents the history of transactions (outflows/inflows of some cryptocurrency) from the sender to the receiver during the interval [startDate, endDate]. Formally, the sender–receiver interaction trajectory between a sender with idSender = sdr, where sdr ∈ Hash number and a receiver with idReceiver = rcvr, where rcvr ∈ Hash number, is defined over a BCDB within a time interval [startDate, endDate], with startDate, endDate ∈ Timestamp, and startDate ≤ endDate.

A sender–receiver interaction trajectory is a chronologically ordered sequence of sender–receiver points:

SenderReceiverTrajectory = {srpt₁, srpt₂, …, srpt_k}.

A sender–receiver point srpt_i, for i = 1 to k, is defined as a tuple:

(sendRecTransDate, srValue),

where sendRecTransDate ∈ Timestamp denotes the timestamp of the block (dateBlock) that contains a transaction from sender sdr to receiver rcvr with value srValue ∈ ℝ⁺. The points of SenderReceiverTrajectory are in ascending order according to sendRecTransDate and srpt₁.sendRecTransDate ≥ startDate and srpt_k.sendRecTransDate ≤ endDate.

The function SenderReceiverTrajectory is defined as follows. Let SenderReceiverTrajectory be a function that returns the sender–receiver interaction trajectory. The prototype of SenderReceiverTrajectory is:

SenderReceiverTrajectory:

Hash number × Hash number × Timestamp × Timestamp → Powerset (SRPT).

where SRPT = {srpt: srpt is a sender–receiver point}, i.e., SRPT is the universal set of all the sender–receiver points in the BCDB. That is, the SenderReceiverTrajectory function receives two hash numbers (i.e., the identifiers of a sender and a receiver) and two timestamps (start and end date), and returns a subset of sender–receiver points (i.e., a subset of Powerset (SRPT)) restricted to the specified interval.

• Example 6

Consider the BCDB = {bl₁, bl₂, bl₃}; see Example 1. The sender–receiver interaction trajectory for idSender = cD96 and idReceiver = 231E over the time interval [1717293500, 1717294680] is {(1717293600, 5.5), (1717294680, 3.8)}. Formally, SenderReceiverTrajectory(cD96, 231E, 1717293500, 1717294680) = {(1717293600, 5.5), (1717294680, 3.8)}.

This trajectory is shown in Figure 8. The temporal distance between consecutive trajectory points (measured in minutes) represents the elapsed time between successive transactions involving the specified sender (cD96) and receiver (231E) pair.

Table 3. Blockchain trajectory types.

Trajectory Type	Entity (Blockchain Actor)	Trajectory Function: Input (Parameters)	Trajectory Function: Output
Miner reward trajectory	Miner mnr	MinerTrajectory (mnr, startDate, endDate)	{mpti}, mpti = {(winnerDatei, rewardi)}, where winnerDatei is the timestamp of a block mined by miner mnr and rewardi ∈ ℝ+ denotes the corresponding mining reward.
Sender value-and- fee trajectory	Sender sdr	SenderTrajectory (sdr, startDate, endDate)	{spti}, spti = {(sSentDatei, sValuei, sFeei)}, where sSentDatei is the timestamp of a block containing a transaction of sender sdr with sValuei and sFeei ∈ ℝ+ represent the transferred value and the associated transaction fee respectively.
Receiver value trajectory	Receiver rcvr	ReceiverTrajectory (rcvr, startDate, endDate)	{rpti}, rpti = {(rReceivedDatei, rValuei)}, where rReceivedDatei is the timestamp of a block containing a transaction of receiver rcvr with rValuei ∈ ℝ+ denotes the received value.
Sender–receiver interaction trajectory	Sender sdr and receiver rcvr	SenderReceiverTrajectory (sdr, rcvr, startDate, endDate)	{srpti}, srpti = {(sendRecTransDatei, srValuei)} where sendRecTransDatei is the timestamp of a block containing a transaction between sender sdr and receiver rcvr with srValuei ∈ ℝ+ denotes the transferred value.

summarizes the four trajectory types defined above.

To facilitate the analysis of trajectory groups, the model can be extended as follows. A trajectory group, denoted as TrajectoryGroup = {traj₁, traj₂, …, traj_m} is defined, where traj_i is a trajectory, for i = 1 to m. The model considers the following constraints: (i) |TrajectoryGroup| > 1, i.e., a trajectory group must contain at least two trajectories (although this constraint can be relaxed to permit groups of zero or one trajectory, if desired) and (ii) let TrajectoryType: Trajectory → {MinerTrajectory, SenderTrajectory, ReceiverTrajectory, SenderReceiverTrajectory} be a function, where Trajectory is the set of all trajectories in the system, then the function TrajectoryType returns the type of a trajectory. Formerly, TrajectoryType(traj_i) = TrajectoryType(traj_j), ∀i, j, i = 1 to m, and j = 1 to m, i.e., all trajectories within a trajectory group must be of the same type. For example, a trajectory group may consist of only miners or only senders. However, at the analyst’s discretion, this latter constraint could be relaxed to permit, e.g., trajectory groups composed of different types. In Figure 9, the corresponding UML class diagram is presented. Note that in this diagram, constraint (ii) is not enforced; if desired, this can be managed by, e.g., specializing the TrajectoryGroup class and associating each subclass with its corresponding trajectory subclass. For example, a TrajectoryGroupMiner subclass would be associated with the MinerTrajectory subclass.

Note also that both classes in Figure 9 include methods that may be useful for analysis tasks. For example, let tgs denote a trajectory group of senders, i.e., an instance of TrajectoryGroup. To identify the maximum value transferred across all transactions in that group, the following call may be used: tgs.merge().getHighestValPoint(). This operation can help detect unusual transaction amounts, such as outliers. It is assumed that the method merge() generates a new trajectory that includes the sender points (chronologically ordered) of all the trajectories within tgs and that the method getHighestValPoint() returns the highest value from the resulting trajectory.

For the implementation of the methods of these classes the analyst can use well-known algorithms, e.g., for the clustering() method, either DBSCAN or K-means may be employed, while the similarity() method can use a wide variety of trajectory similarity algorithms [17].

4. Experiments

To illustrate real-world examples of the four trajectory types defined in the present work, a series of experiments was conducted using Ethereum data obtained from Etherscan (https://etherscan.io (accessed on 4 October 2025)). The first set of experiments considered the time interval from 15 October 2024, 2:40:35 p.m. to 3:39:35 p.m. The second set focused on two specific timeframes of one hour each: (i) 3 February 2025, from 8:00:59 a.m. to 9:00:59 a.m., and (ii) 10 February 2025, from 8:00:59 a.m. to 9:00:59 a.m. (exactly one week later). By analyzing these timeframes, potential behavioral patterns are identified. The data were downloaded and structured into an Excel spreadsheet. Prior to analysis, irrelevant data were removed. Ethereum includes several data fields not required in this proposal such as Slot, Gas Used, or Burnt Fees. The resulting datasets were structured as described below.

4.1. Block Dataset

From the original Ethereum block dataset, comprising 15 columns, only four fields were kept for the experiments: Block (i.e., idBlock, Block ∈ ℕ), Datetime (timestamp (dateBlock) indicating when the block was mined, originally provided in UTC and converted to Unix Time), Fee Recipient (hash number of the miner (idMiner) who won the reward), and Reward (block reward expressed in ETH). In

Table 4. Sample of a block dataset.

Block	DateTime (UTC)	Fee Recipient	Reward
20971623	1729003235	0x4838b106fce9647bdf1e7877bf73ce8b0bad5f97	0.23631 ETH
20971624	1729003247	0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5	0.04987 ETH
20971625	1729003259	0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5	0.06861 ETH
20971626	1729003271	0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5	0.15387 ETH
20971627	1729003283	0x98b92fde3f215f25e9d8ca1c6ec67b65440bf38a	0.02788 ETH
20971628	1729003295	0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5	0.34787 ETH
20971629	1729003307	0xdf99a0839818b3f120ebac9b73f82b617dc6a555	0.04468 ETH
20971630	1729003319	0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5	0.10684 ETH
20971631	1729003331	0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5	0.4448 ETH
20971632	1729003343	0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5	0.0679 ETH
20971633	1729003355	0x1f9090aae28b8a3dceadf281b0f12828e676c326	0.01792 ETH
20971634	1729003367	0x4838b106fce9647bdf1e7877bf73ce8b0bad5f97	0.19533 ETH
20971635	1729003379	0x4838b106fce9647bdf1e7877bf73ce8b0bad5f97	0.09638 ETH
20971636	1729003391	0x4838b106fce9647bdf1e7877bf73ce8b0bad5f97	0.36904 ETH

, a representative data sample is shown.

4.2. Transaction Dataset

From the original Ethereum transaction dataset, comprising 12 columns, only five fields were kept for the experiments: Blockno (i.e., block (idBlock) containing the transaction), From and To (sender and receiver hash numbers, i.e., idSender and idReceiver), Amount (amount (i.e., value) of ETH transferred in the transaction), and Txn Fee (transaction fee associated with the transaction). In

Table 5. Sample of a transaction dataset.

Blockno	From	To	Amount	Txn Fee
20971775	0xa83114a443da1cecef50368531cace9f37fcccbb	0x388c818ca8b9251b393131c08a736a67ccb19297	0.082336796 ETH	0.00089999
20971775	0x52ea50713aa2c6733726e624ea22e65687b1dc20	0xa35723947d25bdcf0714f19be9bd9779b293128d	0.002868324 ETH	0.0008549
20971775	0xd4e4cc2d34fc7417b56db8f8ba9293e80bc0b79e	0xa35723947d25bdcf0714f19be9bd9779b293128d	0.002863703 ETH	0.0008549
20971775	0xe68801eaf234f62801821ffe2d786d0a0237f97	0x6769c3b616ba73991ebb7be349bb64696aca61bd	0.198272459 ETH	0.0008549
20971775	0xc81b47414541ffc261b5d1cc38e367b1d27ac280	0xa35723947d25bdcf0714f19be9bd9779b293128d	0.002793576 ETH	0.0008549
20971775	0xf6d4e5a7c5215f9159a95065190cca24bf64554	0xdac17958d2ee523a2206206994597c13d831ec7	0 ETH	0.0025731
20971775	0x453c67140542c09577bf69d7847e4e93cbe0166	0xa35723947d25bdcf0714f19be9bd9779b293128d	0.002978427 ETH	0.0008561
20971775	0x7ddf93dd3d37ea2631faf20a948f213e7e558e3b	0xa35723947d25bdcf0714f19be9bd9779b293128d	0.00296584 ETH	0.0008561
20971775	0x5c45cf5d4c8068d2dc8b08fe1e3680e2d8d84333	0xa35723947d25bdcf0714f19be9bd9779b293128d	0.003011815 ETH	0.0008561
20971775	0xd2b829adf9525d0c6ed09e48aeda9240dd4254d2	0xa35723947d25bdcf0714f19be9bd9779b293128d	0.003004141 ETH	0.0008561
20971775	0x2f13d388b85e0ecd32e7c3d7f36d1053354ef104	0x5270c9b8142fc1bfceea575fbc1da35d76c23ea6	0.000102 ETH	0.0008757
20971775	0x2f13d388b85e0ecd32e7c3d7f36d1053354ef104	0x5270c9b8142fc1bfceea575fbc1da35d76c23ea6	0.000102 ETH	0.0008568
20971775	0x55b86f93beacf282b97d96962c90ec0dfd591f	0xec77535bedce9fc7ae335969ccd2aee6b7cb641	0.027539863 ETH	0.0008568
20971775	0x29a4cca691e4c83b1fc0c8d63d9a3eef0a196de1	0x843d042c9c158e58fb5a88bcc0fbc24f8ecf2f2	100 ETH	0.0008568

, a representative data sample is shown.

In what follows, Python functions were implemented to generate the four trajectory types. Their implementation is essentially the same as the pseudocode presented in Algorithm 1 and the algorithm detailed in Appendix A. The output of each function is a set of points corresponding to the respective trajectory. Henceforth, for brevity, user identifiers (for miners, senders, or receivers) are displayed using only the first 15 characters of their hash numbers. On the other hand, Appendix B presents a SQL implementation (using Oracle 23ai). This demonstrates how trajectories can be generated across different languages. It should be noted that the objective is not to compare the performance of Python versus Oracle, but rather to demonstrate the feasibility and usefulness of the proposed framework.

4.3. First Series of Experiments: 15 October 2024

4.3.1. Function MinerTrajectory

The function MinerTrajectory allows the identification of top miners based on their rewards. When the Python function is executed, the user must provide (i) the id of a miner, (ii) the start timestamp, and (iii) the end timestamp. The function returns the set of tuples (winnerDate, reward) corresponding to all blocks mined by the miner within the specified time interval. Figure 10 illustrates the results for a specific miner (id miner = 0x1f9090aae28b8). The time interval is [1729003235, 1729006799] = [15 October 2:40:35 p.m., 15 October 3:39:35 p.m.].

The miner reward trajectory earned by the above miner on October 15 from 2:40:35 p.m. to 3:39:35 p.m. is shown in Figure 11.

Figure 11 shows the temporal evolution of the miner’s rewards during a specific time interval. Note that rewards occur at irregular time intervals rather than at fixed intervals. This behavior is consistent with the nature of block mining where miner rewards are not uniformly distributed over time.

Figure 12 shows the top ten miners ranked by total rewards during the time interval [Oct. 15 2:40:35 p.m., Oct. 15 3:39:35 p.m.]. Note that the previously analyzed miner appears among the top participants (ranked 3rd) with 18 rewards.

The top miner was 0x95222290dd727, who earned a total of 24.05 ETH corresponding to 150 rewards, and the second top miner was 0x4838b106fce96, who earned a total of 12.13 ETH corresponding to 98 rewards. Note that the total rewards earned by each miner from the third position onwards did not exceed 1 ETH. This distribution indicates that some miners win more frequently than others [18]. This behavior was also observed in the second series of experiments (see Section 4.4). In [18], it is suggested that there are some policies (e.g., preferred access for some miners, and pool mining dominance) that drive the miner market towards centralization (monopolies), creating conditions that favor a group of dominant miners.

Figure 13 displays the reward trajectories over the one-hour interval for miners 0x1f9090aae28b8 (ranked 3rd), 0xdf99a0839818b (ranked 4th), and 0x388c818ca8b92 (ranked 5th).

As expected in Ethereum, the rewards for each miner over the one-hour interval demonstrate irregular behavior. Each miner exhibits a different performance: the blue miner (ranked 3rd) shows the highest variability, the red miner (ranked 4th) appears to be more stable and maintains relatively high rewards, and the green miner (ranked 5th) declines from an initially high reward to consistently lower values over the hour.

4.3.2. Function SenderTrajectory

The function SenderTrajectory allows the identification of top senders based on the number of transactions they initiate. To execute the Python function, the user must provide (i) the id of a sender, (ii) the start timestamp, and (iii) the end timestamp. The function returns the set of tuples (sSentDate, sValue, sFee), i.e., money outflows, corresponding to all transactions issued by the sender within the specified time interval. Figure 14 shows the Python output for a specific sender (id sender = 0xef8801eaf234f).

Figure 15 displays the top ten senders during the time interval [Oct. 15 2:40:35 p.m., Oct. 15 3:39:35 p.m.].

Figure 15 shows a striking behavior with the seventh sender (0x93793bd1f3e35), who executed more than 300 transactions (outflows of money) while transferring a total of zero ETH. A similar behavior was also observed in the trajectories of: (i) receivers (function: ReceiverTrajectory; see Section 4.3.3), where some addresses received several transactions with a total of zero ETH, and (ii) sender–receiver pairs (function: SenderReceiverTrajectory; see Section 4.3.4), where several transactions occurred with a total of zero ETH. To understand this behavior, dust and internal transactions [19] must be considered: these are not necessarily cryptomonetary transactions. Instead, they represent interactions with smart contracts (e.g., triggering specific functions) or system-level operations (e.g., network testing). Thus, the sender, the receiver, or both may correspond to smart contract addresses rather than externally owned accounts (EOAs).

4.3.3. Function ReceiverTrajectory

The function ReceiverTrajectory allows the identification of the top receivers based on the number of transactions they receive. To execute the Python function, the user must provide (i) the id of a receiver, (ii) the start timestamp, and (iii) the end timestamp. The function returns the set of tuples (rReceivedDate, rValue), i.e., money inflows, corresponding to all transactions received by the receiver within the specified time interval. Figure 16 shows the results for a specific receiver (id: 0x70bf6634ee8cb).

Figure 17 displays the top ten receivers ranked by number of incoming transactions during the time interval [Oct. 15 2:40:35 p.m., Oct. 15 3:39:35 p.m.].

Note that high transaction activity does not necessarily imply high financial flow. The top-ranked receiver recorded more than 600 transactions, but the total amount of ETH transferred was 0. In such cases, transaction counts may constitute misleading indicators of economic activity, and it is more appropriate to interpret them as system interactions rather than monetary exchanges.

4.3.4. Function SenderReceiverTrajectory

The function SenderReceiverTrajectory allows the identification of the top sender–receiver pairs based on the number of transactions they exchanged. To execute the Python function, the user must provide (i) the id of a sender, (ii) the id of a receiver, (iii) the start timestamp, and (iv) the end timestamp. The function returns the set of tuples (sendRecTransDate, srValue) between the sender and receiver within the specified time interval. Figure 18 presents the results for a specific pair: id sender = 0x95222290dd727 and id receiver = 0x388c818ca8b92.

Figure 19 displays the top ten sender–receiver pairs within the time interval [Oct. 15 2:40:35 p.m., Oct. 15 3:39:35 p.m.].

Note that in eight out of the ten couples, the total transferred ETH was 0. Additionally, another interesting pattern was identified: multiple senders frequently send zero ETH to the same receiver (e.g., to the user 0xdac17f958d2ee). Such behavior is typically associated with interactions involving widely used smart contracts, e.g., the wrapped Ether contract (https://ethereum.org/wrapped-eth (accessed on 20 January 2026)), that provide specific services (functions).

4.3.5. Inverse Function SenderReceiverTrajectory

Βased on the SenderReceiverTrajectory results (see Figure 19), an additional question arises: how many of these sender–receiver pairs engage in transactions in the reverse direction (i.e., does the sender usually act as receiver and vice versa)? To address this question, a Python program was implemented to analyze whether such inverse transactions occurred. However, as observed in

Table 6. Inverse transactions of the sender–receiver pairs from Figure 17.

Sender	Receiver	Original Transactions	Original Amount	Inverse Transactions	Inverse Amount
0x93793bd1f3e35a0efd098c30e486a860a0ef7551	0x68d3a973e7272eb380022a5c6518d9b2a2e66fbf	317	0.000000	0	0
0xae2fc483527b8ef99eb5d9b44875f005ba1fae13	0x1f2f10d1c40777ae1da742455c65828ff36df387	208	9297.000165	0	0
0x46340b20830761efd32832a74d7169b29feb9758	0xdac17f958d2ee523a2206206994597c13d831ec7	205	0.000000	0	0
0x89e51fa8ca5d66cd220baed62e01e8951aa7c40	0xdac17f958d2ee523a2206206994597c13d831ec7	148	0.000000	0	0
0xdfd5293d8e347dfe59e90efd55b2956a1343963d	0xdac17f958d2ee523a2206206994597c13d831ec7	133	0.000000	0	0
0x96f97605c3da68e0ab70164977f539e4418112	0xf73e98d49346a053cdcda0847fc83e9a0ef8128	132	0.000000	0	0
0x56eddb7aa87536c09ccc2793473599fd21a8b17f	0xdac17f958d2ee523a2206206994597c13d831ec7	132	0.000000	0	0
0xb23360ccdd9e11b5d54e5d3824bb409c8d7c460	0xdac17f958d2ee523a2206206994597c13d831ec7	128	0.000000	0	0
0x16501fea28e598c9585ae438a535363589fb4c57	0x26a3c34ea5d989be0516788443a9bf43a8652d7a	124	3.000000	0	0
0x21a31ee1afc51d94c2efcca2092ad1028285549	0xdac17f958d2ee523a2206206994597c13d831ec7	121	0.000000	0	0

, no inverse transactions were recorded among these sender–receiver pairs. This indicates that, at least for the pairs identified in Figure 19, senders and receivers do not interchange their roles within Ethereum.

4.4. Second Series of Experiments: 3 February and 10 February 2025

Following the same methodology, a second series of experiments was conducted for these dates: 3 and 10 February 2025, both within the time interval from 8:00:59 a.m to 9:00:59 a.m. The results revealed that some of the top miners, senders, and receivers were also present among the top-ranked entities in the first series of experiments (on 15 October 2024), which suggests the existence of users or smart contracts that operate frequently on the network.

4.4.1. Function MinerTrajectory

Figure 20 and Figure 21 show the results for 3 February and 10 February 2025.

Note that the top three miners on 3 and 10 February coincide with those identified in the first series of experiments (on 15 October 2024), which indicates that certain miners win more frequently than others. Figure 20 and Figure 21 exhibit a similar structure: the top five miners remain the same, despite the one week interval between the analyzed dates. In addition, note that the top two miners differ from the rest of miners in the number of rewards, with a difference of almost 100 rewards. Therefore, these two miners can be characterized as “dominant” miners, indicating a clear centralization trend among the miners of Ethereum.

4.4.2. Function SenderTrajectory

Figure 22 and Figure 23 show the results for 3 and 10 February 2025.

Note that six of the top ten senders on February 3 are also present among the top ten senders on 10 February (not necessarily in the same ranking position), and also that on 10 February only one sender (0x93793bd1f3e35) sent a total of zero ETH.

4.4.3. Function ReceiverTrajectory

Figure 24 and Figure 25 show the results for 3 February and 10 February 2025.

Figure 24 and Figure 25 show that the top three receivers are identical on both dates, with the top two consistently receiving a total of zero ETH. This pattern suggests that these two receivers correspond to smart contracts.

4.4.4. Function SenderReceiverTrajectory

Figure 26 and Figure 27 show the results for 3 February and 10 February 2025.

Note that of the top ten sender–receiver pairs, only one pair actually represents cryptomonetary transactions, while the remaining nine pairs involve zero-ETH transactions.

4.4.5. Inverse Function SenderReceiverTrajectory

The inverse analysis of SenderReceiverTrajectory was then performed, using the same approach as in the first series of experiments (15 October 2024). Consistent with the earlier findings, this second experiment does not reveal inverse transactions between the analyzed sender–receiver pairs (see

Table 7. Inverse transactions of the sender–receiver pairs from Figure 26 during [Feb. 3 8:00:59 a.m., Feb. 3 9:00:59 a.m.].

Sender	Receiver	Original Transactions	Original Amount	Inverse Transactions	Inverse Amount
0x93793bd1f3e35a0efd098c30e486a860aef7551	0x68d3a973e7272eb388022a5c6518d9b2a2e66bfb	221	0.000000	0	0
0xae2fc483527b8ef99eb5d9b44875f005ba1fae13	0x1f2f10d1c40777ae1da742455c65828ff36df387	186	10,157.000026	0	0
0x710bda329b26a624e4b4833de30f38e7f81d564	0xb8901acb165ed027e32754e0ffe830802919727f	182	0.000000	0	0
0x1b9fcb24c533839dc847235bd8eb80e37ec42f85	0x22a956c4755d8c4294b35dc346e74250e175622	166	0.000000	0	0
0xf89d7b9c864f589bbf53a82105107622b35eaa40	0xdac17f958d2ee523a2206206994597c13d831ec7	148	0.000000	0	0
0x89e51fa8ca56d6cd220baed62ed01e8951aa7c40	0xdac17f958d2ee523a2206206994597c13d831ec7	138	0.000000	0	0
0x538d72ed42a76a30f730292d9a39e0577f22f57	0x48ec5560bf59b5895965cce48cc244cfd6fb0c	132	0.000000	0	0
0x00dbb5699745f5b860228c8f939abf1b9ae374ed	0x152290bb6dafac587d499a862861c0869be6e428	129	0.000000	0	0
0x7830c87c02e56aff27fa8b1241711331fa86f43	0xa9d1e08c7793af67e9d92fe308d5697fb813de43	126	0.000000	0	0
0xb1b2d032aa2f52347fbcfd08e5c3cc5521688404	0x7d0ccaa3fac1e5a943c5168b6ed828691b46b36	122	0.000000	0	0

and

Table 8. Inverse transactions of the sender–receiver pairs from Figure 27 during [Feb. 10 8:00:59 a.m., Feb. 10 9:00:59 a.m.].

#	Sender	Receiver	Original Transactions	Original Amount	Inverse Transactions	Inverse Amount
0	0x93793bd1f3e35a0efd098c30e486a860aef7551	0x68d3a973e7272eb388022a5c6518d9b2a2e66bfb	363	0.000000	0	0
1	0xae2fc483527b8ef99eb5d9b44875f005ba1fae13	0x1f2f10d1c40777ae1da742455c65828ff36df387	199	10,126.000026	0	0
2	0xd2c82fe25fa236e114a81173e375a73664610998	0x8d1f2ebfacff1136db76fdd1b86f1dede2d23852	147	0.000000	0	0
3	0x89e51fa8ca56d6cd220baed62ed01e8951aa7c40	0xdac17f958d2ee523a2206206994597c13d831ec7	136	0.000000	0	0
4	0xb1b2d032aa2f52347fbcfd08e5c3cc5521688404	0x7d0ccaa3fac1e5a943c5168b6ed828691b46b36	132	0.000000	0	0
5	0xe93685f3bba3016f02bd1828badd619598d850	0x173272739bd7aa6e46214714048a9fe699453059	130	0.000000	0	0
6	0xfb50526f4894b78541b776f5aaefe43e3bd8590	0x17ae7649db8685602d410472facb2e00471194	108	0.000000	0	0
7	0xe93685f3bba3016f02bd1828badd619598d850	0xc02aba410f0734efa3f14628780e6e695156024c2	107	0.000000	0	0
8	0xdc5a902b7c85fb7d28eae914d70d1e8533bbe63	0xd01a363ac6612749ce94694778990bc913aae0ba	104	0.000000	0	0
9	0x56eddb7aa87536c09ccc2793473599fd21a8b17f	0xdac17f958d2ee523a2206206994597c13d831ec7	100	0.000000	0	0

).

To further investigate the temporal behavior of reciprocal roles within sender–receiver pairs, the analysis was conducted across three timeframes: one day, one week, and one month (randomly chosen). The results identified distinct behavioral profiles that fluctuate based on the observation window. Notably, a single pair (0x4097dcf525f58 and 0xb5d85cbf7cb3e) consistently maintained the highest interaction volume across all periods, totaling 559, 3164, and 12,216 transactions, respectively (see

Table 9. Inverse transactions of the sender–receiver pairs: for one day, one week, and one month.

One day
Row	User_A	User_B	Send_A_B	Send_B_A	Total_Sends	ETH_A_B	ETH_B_A
1	0x4097dcf525f…	0xb5d85cbf7cb3…	141	418	559	1071.704003346	3047.439235758
2	0x59855c07cd492…	0xeba88149813ec…	70	18	88	264.48168024	104.274075
3	0x1471c356a051ec…	0x9a10fe5a761282…	20	20	40	3.088945695	3.088500777
4	0xb334a61a6209f…	0xbe0562201362d…	36	3	39	0.00815545	47.00152241
5	0x1b930709d91d…	0x6928f3e126db…	4	31	35	0.001884136	0.015719979
6	0xe86479f16386e…	0xfd976b9cb14f9…	1	34	35	0.001	0.000571085
7	0x4945ce21b5bd…	0x5a0128e21cb8d…	26	2	28	28.856928588	0.02
8	0xcec7dbd3f2371…	0xfdcc8aff007890…	1	23	24	0.6487509	1.0754
9	0x4f67d2d406cd…	0xfd099ad56b31c…	11	13	24	0.00075449	5.865975164
10	0x536c4921d1aad…	0xa9ac43f5b5e38…	4	17	21	8868.25	8779.797104
One week
Row	User_A	User_B	Send_A_B	Send_B_A	Total_Sends	ETH_A_B	ETH_B_A
1	0x4097dcf525f…	0xb5d85cbf7cb3…	766	2398	3164	5846.983327535	17482.677716475
2	0x59855c07cd492…	0xeba88149813ec…	313	115	428	1405.58334124	820.245362
3	0xb334a61a6209f…	0xbe0562201362d…	259	12	271	0.0603943	201.19582768
4	0x1ab4973a48dc8…	0xfed2399b20011…	261	6	267	0.001718455	23.519515753
5	0xb1a36b00ddb058…	0xc41b82fd1d926…	100	118	218	130.465714354	0.942593724
6	0x4986cf8c9c45aca…	0xcec7dbd3f2371…	148	7	155	8.0133	6.768
7	0x536c4921d1aad…	0xa9ac43f5b5e38…	18	126	144	58597.23	57225.074003
8	0x7c040c7040938e…	0xb5d85cbf7cb3…	36	86	122	2.032876697	4.31507302
9	0x2345804130f13a…	0xa9ac43f5b5e38…	14	103	117	6665	7201.814245
10	0xa7a5c7602bd8a0…	0xb334a61a6209f…	1	114	115	99.24291447	0.02729349
One month
Row	User_A	User_B	Send_A_B	Send_B_A	Total_Sends	ETH_A_B	ETH_B_A
1	0x4097dcf525f…	0xb5d85cbf7cb3…	2751	9465	12216	21069.549706128	68997.522512058
2	0x77021d475e36b…	0x877613c53d646…	6110	1	6111	0.202596	10.999025768
3	0x71800fc47ae36db…	0x77021d475e36b…	5	5939	5944	1861.873187762	0.195161
4	0x77021d475e36b…	0xe45e89fba33f5…	5928	1	5929	0.19881	19.499994144
5	0x77021d475e36b…	0xcdea03850147e…	4242	1	4243	0.131873	4.93007659
6	0x1dbe883eb1ebc9…	0x67a029e8fcb13…	3583	1	3584	548.628141525	0.472019918
7	0x11a2daab541f469…	0x8d6db8959d3f0…	2	3067	3069	1.791954072	871.916698824
8	0x77021d475e36b…	0x7f7d4ab25981f…	2729	8	2737	0.068784	104.98020288
9	0x024b9e8e4cc996…	0xd5adabc8f98a4…	2309	1	2310	0	0.1
10	0x889c81fdea6672…	0xd5adabc8f98a4…	1958	1	1959	0	0

). Their interactions are reciprocal, with both users sending volumes of transactions and ETH back and forth. This behavior is consistent with automated market makers (AMMs) or algorithmic trading bots. These findings underscore a critical methodological point: narrow observation windows may introduce significant sampling bias. A broader temporal scale is required to characterize the true behaviors within the network.

Within the one-month timeframe, user 0x77021d475e36b appears frequently as a sender interacting with numerous receivers. This user is likely a “central institutional hub,” representing an exchange’s hot wallet processing withdrawals or a large-scale smart contract. Interestingly, this behavior only becomes notable in the one-month timeframe.

Regarding the values interchanged (ETH), consider, e.g., row 4 from Table 9 (one month table): user A (0x77021d475e36b) sent a total of 0.19881 ETH in 5928 transactions. Meanwhile, user B (0xe45e89fba33f5) sent 19.49999 ETH in a single transaction. This shows that user B executes a single payout or a large withdrawal of accumulated funds back to user A, grouping the accumulated capital into a single transfer, possibly to minimize gas fees. User A may be a smart contract sending instructions to user B, hence the value of 0.19881 ETH.

4.5. Highest Value Sent of a Group of Trajectories: tgs.merge().getHighestValPoint()

In another experiment, the transactions of 50 senders were analyzed across three timeframes—one day, one week, and one month—during January, February, and March of 2026. For each month, the trajectories of the 50 most active senders (determined by their total number of transactions) were chosen. The highest value sent within each timeframe was then identified for this set of 50 trajectories by implementing the following calls: tgs.merge().getHighestValPoint() (see the end of Section 3).

From the results (see Figure 28), two key observations can be made: (i) a single sender (0x28c6c06298d51) dominates across all three months, with the exception of day 1 in January; (ii) in March, the highest value sent in a week was 30133 ETH, whereas the value for the entire month was 143211 ETH. This difference of more than 100000 ETH reveals irregular behavior that warrants further attention. This indicates that a narrow observation window may significantly underestimate a user’s true activity.

The main findings across all experiments are summarized in

Table 10. Main findings across all experiments.

Trajectory	Findings
Miner reward trajectory	Some miners win more frequently than others. The rewards for each miner over one-hour intervals demonstrate irregular behavior.
Sender value-and-fee trajectory	Some senders executed more than 300 transactions while transferring a total of zero ETH. High transaction activity (outflows) does not necessarily imply high financial flow.
Receiver value trajectory	Some receivers recorded more than 600 transactions while receiving a total of zero ETH. High transaction activity (inflows) does not necessarily imply high financial flow.
Sender–receiver interaction trajectory	Multiple senders frequently send zero ETH to the same receiver. High transaction activity (ETH exchanges) does not necessarily imply high financial flow. Some senders and receivers interchange their roles within Ethereum.
Sender value-and-fee trajectory: Highest value sent (group of trajectories)	Certain senders dominate sending the highest values across several months. Differences exceeding 100,000 ETH can be found between the highest value sent within a single week and the entire corresponding month.

.

5. Conclusions and Future Work

In this paper, four types of trajectories were formally introduced in the context of blockchain analysis. These trajectories provide a structured mechanism for uncovering behavioral patterns, enabling analysts to better understand specific behaviors of users (miners, senders, and receivers) within the blockchain. To validate the practicality of the proposed approach, the algorithms were implemented in Python using real Ethereum data. In addition, an SQL-like solution was presented to demonstrate the feasibility of implementing the approach in different languages.

The experimental results revealed several recurring patterns, e.g., the presence of “winner monopolies”. Although this behavior can easily be observed directly in raw blockchain data, the trajectory-based framework not only detects this “evident” pattern but also facilitates the identification of more subtle behaviors. For example, sender–receiver trajectories sometimes indicate role inversion, i.e., when user u1 transfers money to user u2, the reverse transaction occasionally occurs within the observed time window. Another finding is that certain senders dominate, sending the highest values across several months and differences exceeding 100,000 ETH can be found between the highest value sent within a single week and the entire corresponding month.

The recurring presence of the dominant miners may reflect structural advantages, such as more powerful hardware or better network connections, which could lead to concentrating the power in fewer miners. The role inversion in sender–receiver pairs indicates that transfers are sometimes bidirectional. Moreover, the prevalence of zero-ETH transactions highlights the central role of contract-driven state changes rather than monetary transfers.

Overall, trajectory-based analysis provides a systematic perspective for examining recurring blockchain behavioral patterns. By elevating trajectories to first-class analytical entities, this approach enables the detection of dominant miners, transactional asymmetries between users, and smart contract interaction patterns.

This work establishes the groundwork for future research directions. One line of research concerns predictive modeling to address a series of related questions as follows. Can future mining outcomes be estimated based on historical reward trajectories? Given a miner m, what is the probability that m will be the next winner? What is the expected number of blocks until m becomes the next winner?

Another promising direction involves analyzing transaction trajectories during significant market events such as market crashes, to determine whether such events induce measurable structural changes in user behavior. Furthermore, the proposed framework is applicable to other blockchains, thereby enabling cross-chain comparisons of trajectory types, such as miner trajectories. In addition, further studies could identify other types of trajectories emerging in diverse blockchain environments.

Finally, comparative trajectory analysis may provide additional insights. For instance, how can similarity between two senders’ trajectories over a given interval be formally defined and quantified? Developing robust similarity metrics for trajectory comparison could further enhance behavioral analytics in blockchain environments.