The following document explains the way Devonomics amounts are attributed to Starknet contracts in the first iteration of Devonomics. We stress that the computation applied here will be modified in the future as we manage to measure more accurately the exact fees that are attributed to each node in the transaction tree.

We consider blocks on mainnet from the beginning of the network (16/11/2021) to the end of November 2023. More precisely, we consider block numbers between 1 and 448500. The total fees collected are ~16.3K ETH. When all is said and done, we want to distribute 8% of this amount (~1,300 ETH) to dapps and an additional 2% (~320 ETH) to core devs. The protocol regarding the 2% redistribution is not described in this document. Regarding the 8%, below we describe how we computed the amounts to be distributed per contract addresses.

Step 1

Divide the data per block.

• Call $F$ the total paid fees per block.
  • Calculate the total gas per block due to Cairo steps and builtins (according to the tariffs in the docs: step = 0.01 gas, builtins = different tariff per builtin), call it $G_2$.
• Calculate the total gas per block due to storage diffs (without considering the other components of the state diffs: nonces, declares, deploys, deprecations and replaces), as read from the starknet_getStateUpdate response. The gas cost due to storage diffs can be read from the docs: if the storage diffs dictionary looks like $\{contract_1: dict_1, … , contract_n: dict_n\}$, where $dict_i$ is a dictionary of key-value pairs, then the total gas $G_1$ due to storage diffs is $1024 * (n + \sum_{i=1}^n len(dict_i))$. The 1024 comes from 16*64: 16 gas on L1 to write 1 byte, the 64 is: 1 key-value pair is 2 words (64 bytes), and the contract address (32 bytes) is written with an additional word (32 bytes) that encodes auxiliary information (see the docs).
• Now, $(G_1 + G_2)*gas\_price < F$, for various reasons. Some are listed above, e.g. nonces; others, which come from OS overhead, are harder to approximate because the overhead includes many different things, among them syscalls (most notably, the fees for send_message_to_l1 syscall belong here).
• At this experimental stage, we decide to distribute 8% of all of $F$ (which, as noted above, is a higher amount than $(G_1 + G_2)*gas\_price$). Hence, we define fees due to steps+builtins as $F_2:= \frac{G_2}{G_1 + G_2}F$ and fees due to storage diffs as $F_1 := \frac{G_1}{G_1 + G_2}F$.

Step 2

Distribute $F_1$ and $F_2$ per contract (in the block), at the level of internal calls.

• Case of $F_2$: The only available metric at the level of internal calls is Cairo steps. If $S$ denotes the total number of steps in the block, and contract $x$ did $S_x$ steps during this block, then contract $x$ will be allocated $\frac{S_x}{S}F_2$ fees in this block.
• Case of $F_1$. If contract $x$ had $m$ storage diffs in the block (recall that these diffs are taken from the block’s state diff) then contract $x$ is allocated its portion of the state diff, i.e., $\frac{1024*(1 + len(dict_x))}{G_1}F_1.$

Step 3

Aggregate the data per contract over all blocks between 1 and 448500. This leads to a table of the form

Note that in the linked table the fees due to storage diffs are called “L1 fees” and fees due to steps and builtins are called “L2 fees”. Moreover, the table only lists the top 10K contracts by fees, therefore the total fees sum to less than the total fees of the network.

Step 4

Take a weighted sum of the [Fees due to storage diffs] column and [Fees due to steps and builtins] column, with weights $a_1, a_2$ respectively. At this stage the weights are $a_1 = 0.055, a_2 = 2$. This gives the final amount to be distributed to the contract.

Scripts