Building blocks are functional units of DeFi protocols that can be derived from the call structure of single transactions and are constructed as follows. Beginning with an EOA as the initiator of the transaction, the call of a CA can lead to subsequent internal transactions, i.e. calls of other CAs’ methods, and ultimately culminate in a cascading, tree-like transaction structure. Building blocks can be extracted as sub-trees, where the root node (i.e., the top node of the tree structure) is a protocol-specific CA with no incoming but at least one outgoing link. Furthermore, a building block may also encompass additional sub-trees, essentially forming nested structures of blocks. Figure 1 provides graphic support to understand this concept. It represents two frequently appearing building blocks from the popular DEX Uniswap (A) and one from the aggregator protocol 1inch (B). Nodes represent account addresses and links represent the calls of CAs’ methods. It illustrates the tree-like structure of building blocks and reveals the atomic swap block of Uniswap (A) to exchange assets. The more complex 1inch building block (B) derives the best price across DEXs (when the method unoswap is called) and then executes two swaps by leveraging both building block (A) and an equivalent SushiSwap building block. Overall 1inch is creating a DeFi composition, as intuitively described in Section 2.2.

2.4. Related Work—Compositions of DeFi protocols increase the ecosystem complexity, which makes systemic risk even harder to assess.16–20 Early works were conducted for decomposing other elements of DeFi but not across protocols. Moin et al. (2019) decomposed the design of stablecoins into various component design elements and discussed the strengths and drawbacks.21 Tolmach et al. (2021) specified systems compositions in automated market makers (AMMs) decentralized exchanges.22 Von Wachter et al. (2021) described the “composed” derivatives of assets, in other contexts also known as “wrapped” tokens, and showed that the complexity of wrapping operations has been peaking in the third quarter of 2020, a period often referred to as “DeFi Summer”.23 Existing online tools, such as DeFiLlama, provide categories of protocols, but do not necessarily distinguish among financial functionalities offered.

Other related studies are various machine learning-based analyses built upon extracting features of blockchain transactions to reveal the insights of the transactions in the blockchain blocks. Methods were proposed to process the input transaction graphs to construct desired sub-structure graphs or newly derived graphs for further analysis. Weber et al. (2019) explored the potential of Graph Convolutional Networks (GCN) for anti-money laundering (AML) in Bitcoin, contributing a publicly available labelled dataset of Bitcoin transactions for financial forensics.24 Li et al. (2022) introduced a graph neural network-based model that incorporates temporal transaction data for the identification of phishing scams on the Ethereum network.25 Pocher et al. (2023) demonstrated that employing Graph Convolutional Networks (GCN) and Graph Attention Networks (GAT) for modelling blockchain transactions as complex networks enhances the detection of AML and Countering the Financing of Terrorism (CFT) anomalies.26 Han et al. (2023) developed a multi-layer graph neural network-based model for temporal transaction anomaly detection within Ethereum’s multi-token transaction networks.27 These studies leverage graph learning for transaction pattern recognition; yet, they lack a specific focus on smart contract interoperability and structural similarities across DeFi protocols, which our work aims to investigate.

3. Building Block Embedding

This section describes the dataset and the methodology devised to produce embeddings for DeFi building blocks. To uncover functional similarities and recurring interaction patterns, we first produce an embedding space where each building block is mapped to a high-dimensional vector by a graph representation algorithm; in this procedure, we assign various features to each node (i.e., smart contract) of each building block. Similarity searches are conducted based on their distance within the space. We utilize two different target labels for evaluating the performance of our approaches in grouping DeFi building blocks into clusters based on their similarity.

3.1. Dataset and Sources Description—Following the approach introduced in Kitzler et al.,5 building blocks are extracted utilizing all Ethereum transactions involving 23 DeFi protocols and their contracts from January 1, 2021 (block 11,565,019) to August 5, 2021 (block 12,964,999).28 The algorithm extracts the building blocks by mapping the transactions into edge-induced subtrees, subsequently hashed based on a combination of their execution order, target nodes’ outdegrees, and associated method. Each building block in the dataset has fields including the executed method’s name, subtraces that outline the tree structure and participating addresses of the transactions within a building block, and a count that reflects the frequency of the building block’s occurrence. The dataset we analyze consists of the top 10,000 building blocks identified using the building block extraction algorithm and ranked by count.

3.2. Methods of Producing Embedding—Given the building block tree-shaped structure, and since each node represents a smart contract with distinct features, the data are well-suited to apply graph representation learning to obtain graph-level embedding.6 The method we employ, graph2vec,29 is based on the Weisfeiler-Lehman (WL) method and was subsequently applied in performing graph isomorphism testing.30, 31 The graph2vec algorithms leveraging the WL subtree kernel measure graph similarity quantitatively based on the commonality of their subgraph components, asserting that graphs share a higher number of common subgraph components and exhibit higher similarity. We apply graph2vec to generate a graph-level embedding space, yielding a singular vector for each building block. The embedding vectors abstract building block similarity relationships into a generalized representation, offering interpretability and predictive utility when used as input for models like classifiers or clustering algorithms.

3.3. Node Features—In graph2vec, the differentiation of the building block node features directly influences the characterization of the subgraphs, consequently affecting how closely graphs are positioned in the embedding space; graphs containing similar node features in addition to similar subgraphs are placed closer to each other. With graph2vec, we can provide node features or leave the field empty during the embedding vector generation process. We utilize various node features, detailed below, to investigate how they affect subgraph similarity in the embedding space.

3.3.1. None—For the baseline setting, no features are assigned to nodes. In this case, graph2vec will assign the node degree by default. The examination of the embeddings is based only on the building block graph structure without the influence of node-specific information.

3.3.2. 3-Class—We assigned features to the building block nodes following the distinction across simplified contract types described in the literature and reported in Section 2: factory deployed contracts (i.e., contracts that generate other contracts), assets, and other contracts.5

3.3.3. Signatures Selectors—Each node \(N_i\) in a building block represents a contract address and therefore contains a list of functions. A function selector can be produced for each function, which refers to the first 4 bytes (8 characters) of the Keccak-256 (SHA3) hash of a function’s signature,i.e., the name of the function and its input argument types.32 We utilized the signature extraction tools suggested by Di Angelo et al. for obtaining the selectors, representing the signatures, for every node within each building block across the entire building block dataset.33, 34 For each node, we generated a list of function selectors and assigned a unique marker to identical lists, utilizing this marker as the feature for the node.

3.3.4. Signatures Group—A potential limit of the signatures feature is that two contracts with mostly identical functions but minor variations would be assigned a different marker indicating distinct node features in the above function selectors feature. To precisely represent a smart contract node features by its functionality regardless of minor functional differences, we categorize contracts into distinct groups by evaluating the pairwise similarities of function selectors using the Jaccard metric (comparing the overlap between two sets of contract functions); e.g., ERC20 contracts, despite minor variations, share common functions like transfer, approve, and balanceOf, resulting in high Jaccard scores and same grouping. Each building block will be assigned a marker indicating the function selector (representing the signature) group as its node feature.

3.4. Building Block Labels—To assess the performance of the embedding vectors in tasks that utilize these embeddings as input, we employed two sources as the target label: Protocol and Financial Functional Category (FFC). To employ Protocol as the target label, the root node’s protocol serves as the target label for the building block, meanwhile to use Financial Functional Category the process is slightly more complex.

To use FFC, we assign each building block to one of eight categories representing its financial functionality based on its root method name using regular expression patterns with the keywords detailed below in Table 1. Regular expressions are used to search for specific keywords within the root method names of the building blocks. For instance, if a root method name contains substrings such as “deposit” or “lend”, it is categorized under the “Lock Capital” action. The presence of terms negated by “NOT” qualifiers, such as in “stake NOT unstake”, makes a method only categorized as “Lock Capital” if it involves “stake” without simultaneous involving “unstake”. We note that the information used for the building block target label Financial Functionality Category differs from that used as node feature for the Signatures Selectors and the Signatures Group; indeed, the former uses information from the name of the function invoked only, while the latter two use data of all functions of a contract, included their arguments. Moreover, for the target label Protocol, we have labels for all 10,000 building blocks. For the Financial Functionality Category label, instead, not all building blocks contained one of the regular expressions defined in Table 1; these were categorized as “other” and excluded from the evaluation. We filtered out single-node building blocks, as they lack meaningful structural information for clustering and analysis purposes. Further details on the target labels are reported in Tables 3 and 4 in the Appendix.

‌Table 1. Financial Functionality Category and the associated signature keywords.

4. Clustering Analysis

In this section, we describe the analysis devised to assess how effectively our embeddings categorize DeFi building blocks into clusters that reflect their financial functionalities, or other information such as the protocol they are associated with.

The procedure is presented in the workflow formulated in Algorithm 1. We conducted the analyses using each node feature \(\mathcal{F}_{B_i}\) (see Section 3.3) and the target building block labels \(\mathcal{L}_{B_i}\) (see Section 3.4), as described in line 3. We applied the graph2vec algorithm (line 4-8) with an embedding dimension of \(\mu = 128\), a learning rate \(\gamma = 0.05\), and \(e = 100\) epochs to all the 10,000 building blocks. We used a threshold of 1.5 for Jaccard Ward distance when producing Signatures Group node features. After we obtained an embedding vector for each building block, we applied agglomerative clustering on all the embeddings.35 To determine the optimal clustering distance threshold \(delta\) (line 9), we examined values within the range of [0.6, 1]. The value in this range that yielded the highest V-measure was chosen to have an optimal balance between homogeneity (to which extent each cluster contains only building blocks of a single target label) and completeness (to which extent all building blocks of a given target label are assigned to the same cluster), calculated by their harmonic mean. V-Measure and Normalized Mutual Information (NMI) with the arithmetic mean yield the same mathematical outcome since both ultimately measure the ratio of shared information (MI) relative to the total entropy.36

4.1. Results—We evaluate the clustering performance by computing the homogeneity, completeness, V-measure, and purity over both target labels and the four node features defined in Section 3. Table 2 reports the results of our analyses. We highlight in gray the best-performing specifications. Interestingly, we find that in all cases save one the node feature Signatures Group yields the best results. This is in line with our expectations since this feature is the most advanced and captures best the characteristics of the building blocks; the more information incorporated into the features, the better the results become.

We first focus on the Financial Functionality Category target label. In this specification, the outcomes yielded the highest value among the feature sets for purity with .888 (using Signatures Group as node feature). To further interpret these results, we reduce the embedding space into two dimensions using t-SNE method.37 Figure 2 shows the embedding space of building blocks using Signatures Group as the node feature and Protocol as the label. In the figure, each dot represents a building block’s embedding vector, with dimension reduced to 2D using t-SNE and its colour indicating the corresponding building block label. We find that building blocks associated with swapping functions, which are the vast majority of building blocks, are clustered close to each other. On the other side, completeness and V-measure are relatively low. This could be caused by clusters, such as “Redeem or Withdraw” and “Lock Capital”, being not well separated. However, this shows an interesting pattern, as the two functionalities are actually reciprocal to each other. In summary, the results suggest that the clustering categorizes DeFi building blocks into clusters where a substantial portion aligns with their distinct financial functionalities.