Note

The findings in this dashboard are inconclusive given the current state of data on NEAR blockchain and Flipside.

This is a write-up on the methodological limitations of using NEAR transfers to estimate NEAR balances on-chain.

NEAR Supply

A total of 1,000,000,000 NEAR tokens were created at Genesis on April 22, 2020.

Allocation at genesis. The tokens were allocated based on the pie chart on the right.

Circulating supply. Tokens allocated may be vested across time. In addition, new supply of NEAR, inflating a 5% annually, will be issued as epoch rewards for validators that help secure the network.

• 90% of the inflation to validators (4.5% total)
• 10% to the protocol treasury (0.5% total).

The emission schedule of NEAR can be seen on the right.

*Reference: *

Challenges in estimating NEAR Balances.

Here I document the challenges of estimating NEAR balance through the conventional approach with Flipside’s current tables.

Data limitation: There is no ERC-20 balances-like table for NEAR to allow ease of querying token balances from users. This leaves us with having to estimate NEAR from in and outflows from wallet-to-wallet transfers. This assumes that users can only receive NEAR from other users and not conjure it up.

If we have a log of NEAR transferred from users to users, we should be able to obtain the balance of NEAR from a user. near.core.fact_tranfers intuitively is the default table to use to calculate this net in and out flow of NEAR. However, things are not so simple.

From the problem-workaround log on the left, you can see the challenge so far. The current approach is definitely not scalable.== Each problem has a specific workaround given the current state of the tables.

Furthermore, there are other several unaddressed challenges:

• Flipside current data is not completely backfilled (+/- NEAR balances in all of the above transactions period to the backfilled date will not be obtained)

• Staking-related transactions (NEAR rewards from staking, deducted from slashing, liquid NEAR staking, and swapping of liquid derivates to other assets)

• Providing Liquidity (NEAR added as wNEAR to LP), need to account for impairment loss from pool balances

• This transaction 7NMykPipJdYitSudswqLuTQeLSiR9ZyoNWBgJspK5YEy involving movement of NEAR cannot be counted effective - none of the tables (fact_transcations, receipts,

  actions_events have the variable to parse out the amount of NEAR)

Problem List

Problem 1 and workaround:

Not all transfers of NEAR will be in near.core.fact_tranfers table. Example: 6vLNZ2eyYvPq34WeVAeWermU7cgJNWDPJJBJDPvUVeRT - payment from Flipside that users the multicall.app. This transfer is registered as a function_call. The users and the amount of NEAR have to be parsed out individually from args in the near.core.fact_actions_events_function_call table.

Problem 2 and workaround:

Swaps are not included in near.core.fact_transfers==.== Swaps involve wrapping NEAR to wrapped NEAR to exchanging it in the liquidity pool for another asset. To circumvent this, NEAR (wrapped NEAR). As the swap tables have missing transactions, swaps were manually obtained from near.core.fact_receipts - please examine the code for the specific approach.

Problem 3 and workaround:

NEAR is used also used as gas, so you have to account for NEAR spent on all transactions. For this, the near.core.fact_transactions table’s transaction_fee column was used. The total amount of NEAR spent on gas was calculated and subtracted.

Problem 4 and workaround:

NEAR on NFT purchases and sales are not included.== Similar to swaps, there are no tables for NFT mints, purchases, and sales, which all involve NEAR moving from wallets to wallets.

Problem 5 and workaround:

NEAR locked up from vested are transferred by function call and not picked up in the transfers table → this was identified from an account with a negative balance after solving problem 4. Tx hash for NEAR lock-up transfers:

4uuR6phqy7JgCb2a5gYncijxqzKB68GBYGPdrAYEcmx8

NEAR Balances with incomplete data

Approach: The movement of NEAR was grouped by the wallet address. NEAR movement into the account was grouped by the positive sum of NEAR for each user.

The movement of NEAR out of the wallets is grouped by the negative sum of the NEAR for each user as well.

The table on the right shows that there were still a large amount of wallets with negative balances.

The chart below presents the distribution of NEAR balances by wallet count with data backfilled to September 2021 with the workarounds mentioned above

Wallets were grouped into increase tiers of NEAR balance calculated.

Clearly, the lack of backfills and transactions hidden cannot identify the true NEAR balances. Here, we see that the total NEAR accumulated in the top 4 wallets (with >10M NEAR) was greater than all the other categories.

NEAR accumulated in other accounts in the early days was not identified as it is not backfilled. Hence, the total supply here is < 1Bil and there was also a negative supply -165.7M of NEAR amongst those with negative balances.

Similar to other chains, the users who form the bulk of the wallet count (with 0-1 NEAR) only held ~736k of NEAR, a fraction of the total supply.

Not that the y-axis is on log-scale

• ~13.9M of the 16M+ wallets identified had 0-1 NEAR balance.

• We also see that there were a total of 2.4M wallets with negative balances.

• The number of users with 1 to 100 NEAR sharply declined to ~182k

• 40 and 5 wallets were found to have 1-10m and >10m NEAR balances

Current supply of NEAR

The present supply of NEAR can be viewed here:

Taking the first block_timestamp from all of the transactions explored to calculate the NEAR balances of each user, we can estimate the wallet age of each user.

Here, we find that lower wallet were newer by age (~100 days). Wallets with more balances generally were created for a longer duration.

Here, we find the average and median calculated balances of NEAR across different wallet tiers.

This is to verify that the filters for binning the wallet balances are accurate and there are no anomalies.

Conclusions

The data storage and structure on NEAR do not allow for a good estimation of NEAR balances through transfers.

Many NEAR transfers are “wrapped” in ft_call transactions that cannot be teased out by a general query.

Incomplete backfill of data adds a layer of complexity.

In all, this has led to a rather poor estimation of the distribution of NEAR in wallets.

The findings in the chart above should be taken with caution.