Dashboard Objectives

• The dashboard imagines NEAR blockchain as a ‘City’ and aims to deduce who the citizens of the city are!
• The dashboard walks the reader through various metrics/techniques to arrive at the definition of a user that gets classified as a ``Citizen``.
• Ultimately, the goal is to form a concrete definition of a ``Citizen of Near``.

Author:

• Twitter: @lelaughingman
• Flipside Bounty Hunter: TheLaughingMan
• Discord: TheLaughingMan#3062

Why do we want to classify various users as ‘Citizens’ ?

Let’s take a real-world example:

• When looking at a city, one wants to emphasize the locals more than the casual passing-by tourists/chain-hoppers.

• One will get far more genuine data points observing the citizens/local folks, which will better help draw conclusions regarding the day-to-day activity of the city.

• Whereas if you involve the tourists, you end up skewing your data and observations, which might be opposite to that of a regular Citizen!

  \

Makes sense, yeah? Now let’s apply a similar analogy to a Blockchain ( in our case NEAR)

• Plenty of users come and go, some don’t even stick around past the first transaction.
• Some never even do an on-chain transaction!
• During bull-runs, lots of users try out various things but most of the attempts don’t stick
• Only a true ‘citizen’ would stick around and be an active participant!

Alright, alright, alright!

Below, the dashboard discusses various metrics one can use to define a citizen and their purpose/drawbacks…

I. A Citizen will be a Recurring User

• Quite obvious isn’t it? A local resident will frequent the chain again and not just once!

Drawbacks

• However, we can’t simply rely on this metric alone. As a user could do single transactions ages apart!

Tables used:

• flipside_prod_db.mdao_near.transactions

II. A Citizen will be ``Active``

• A citizen will be active not just once a year but frequently, maybe even periodically to perform their chores/daily routines.

Drawbacks

• Simply looking at periods of transactions is not enough. We will have to merge this info with the types of transactions the users are doing too.
• A single transaction within the span makes that wallet eligible for the whole span! This issue is well-illustrated by the Active Wallets ( Various spans ) chart.

Tables used:

• flipside_prod_db.mdao_near.transactions

III. A Citizen will be ``Sophisticated``

• An initiated Citizen will often do sophisticated/high-order transactions, not mere transfers.

Drawbacks

• It is important that such transactions be done periodically to be classified as a citizen not just on a single day, one-off occurrence.

Tables used:

• flipside_prod_db.mdao_near.transactions
• flipside_prod_db.mdao_near.actions_events

Finally, Let’s Define the `Near Citizen`

• We want to club the metrics I, II, and III discussed above meaningfully together such that they overcome each individual metrics’ drawbacks!

• We arrive with the following conditions/constraints:

  • The user should have done multiple transactions across the period (60-day span )
  • These transactions should also have been spread across a minimum of 3 distinct weeks.
  • And the transactions should involve higher-order interaction, not mere transfers, i.e. Sophisticated users/usage.

Tables used:

• flipside_prod_db.mdao_near.transactions
• flipside_prod_db.mdao_near.actions_events

Advantages/Perks of the ``Near Citizen`` method/metric:

• The method removes most of the noise, especially the new/short-span users that pop up across metrics I, II and III.
• The noise removal is beautifully compared against metric II (Active Wallets), it simply tunes out the peaks!
• It leaves only the users most likely to keep using the City (NEAR) in the immediate future.