Relaunching Labels! 🎉

[andrewhong5297]

Relaunching Labels

Labels were first launched in October 2022, and have seen a steady growth from individual contributors in both static (manually labeled addresses) and query-based sources. Here is the current schema:

We want to make it easier to contribute and use labels, as right now, there is very little structure for query labels (those outside of static labels like CEX or multisig).

The first step towards doing this is being more specific on what can go into a category, and adding a label_type column that clarifies the types of labels we will accept. There will also be a label_name column to make it easier to navigate aggregated labels tables by category. There will also be a version column that defaults to 1 for all labels until there is some conflict (i.e. two different methodologies for the same model.

Label Types:

Here’s a list of label types:

• Identifiers: Most static labels should be this label type, as well as common usernames such as Farcaster, ENS, and Lens names. As a rule of thumb, identifiers should usually specify a unique entity name.
• Usage: These are the existing top volume and frequency (or some other percentile-able metric) within a domain and the usage of specific protocols. There must be some sort of ranking/percentile involved!
• Personas: These are for on-chain curated behaviors (like common CT memes) or protocol user tagging. They should be easily understood to non-analysts, though the underlying calculation methods may be more subjective.

This is just the starting list. If a label is created that clearly fits inside a new type, we will create a type for it. The idea is to try and keep types smaller in number and very clear so that it's easier for analysts to navigate, use, and contribute to.

Example Hierarchies:

To make this clear, let’s do some examples.

Category: NFT

• Label_types
  • Identifier: Opensea Username (traderName_opensea)
  • Usage: top volume by nft.trades
  • Usage: top transactions by nft.trades
  • Persona: Opensea User, Sudoswap User, Blur User
  • Persona: Wash Trader
  • Persona: Art Blocks Curator (holds all art blocks curated collections)
  • Persona: Airdrop Hunter
  • Persona: Early NFT Trader (first year of nft trading)

Category: Social

• Label_types
  • Identifier: Lens username (.lens) ENS reverse resolver (.eth), farcaster (_farcaster)
  • Usage: top holders from ENS
  • Usage: top posters from lens
  • Persona: Lens User, ENS User
  • Persona: Squatter (sitting on dozens of ENS names)

Category: DEX

• Label_types
  • Usage: top volume by dex.trades
  • Usage: top transactions by dex.trades
  • Persona: Uniswap v2 User, Cowswap User
  • Persona: Sandwiched User
  • Persona: Yield Farmer
  • Persona: Liquidity Provider

Migration of Current Labels:

I promise it isn’t as scary as it sounds. We will start by reorganizing the folder of labels structure to look like this:

"""
Labels (sector)
- NFT (category)
    - label_nft.sql ← aggregates all labels from the folders below
    - Identifier (folder)
        - label_opensea.sql
    - Usage (folder)
	- Ethereum (folder)
	- label_nft_volume_percentile.sql
    - Persona (folder)
	- Ethereum (folder)
	- label_wash_trader_millions.sql
"""

At a glance, it should be easy to explore from category down to label level.

After the folders and files are reorganized, we can clean up the actual schemas/sql. Most static labels need a label_type column added, and then that’s it. Many of the query-based models like dex_traders (here will need to be changed; henrystats and gentrexha mainly created these.

Models like ens and contracts will be hard to edit without breaking many people’s queries, so we will leave that alone.

For aggregated labels, there will also be a label_name column added. so within label_nft.sql , the label_name for label_nft_volume will be nft_volume_percentile.

⚠️ Please reply with any of your concerns/comments; once we have a general agreement, we can start work and codify this into a labels readme.

Once the structure of labels is in a good state and all cleaned up, we can launch a hackathon with rewards for the most creative, useful, memetic, etc. We’re really excited about unlocking the potential of labels more (and making it more multiplayer)!

[andrewhong5297]

tagging in all contributors of labels to kickoff the discussion! If you're okay with the changes, please give a thumbs up. When we have approval from enough contributors then I will go ahead and refactor the folders/labels (everything besides ens and contracts).

You all will be tagged on the PR again for final review before it goes through.

@hildobby @gentrexha @henrystats @MSilb7 @markusbkoch @Hosuke @Stefenon @0xRobin @agaperste @jeff-dude @soispoke @catherine-2 @AlexTheLion123 @jackiep00

[agaperste]

I like the idea - have short sentence descriptions. Feels like we can enforce that when PR is created for a new label category, i.e. schema yaml?

[andrewhong5297]

@markusbkoch @gentrexha Please see this draft PR to better understand how folders/models will be organized under the refactor.

https://github.com/duneanalytics/spellbook/pull/2659/files

I've only done DEX labels so far to keep it simpler. I will be moving around other labels here to consolidate categories after we have agreement.

[andrewhong5297]

we could also add an aggregate view at the usage, persona, and identifier levels to then make the overall labels_dex aggregation easier.

[andrewhong5297]

Okay, the final PR is up for review. You can explore around what it'll feel like and give feedback in the new PR until end of day 2/16 (Thursday).

[andrewhong5297]

Reminder last day to add any comments! :)

[dot2dotseurat]

For personas and usage types, I expect there are multiple ways to calculate or think about them. Do we want to have a framework where one definition is accepted or do we want to be able to have competing versions? I can think of scenarios where we might have uploaded the results of an ML-based model for identifying wash traders versus a strict SQL logic version etc.

The trade-off is that it's more confusing when there are multiple versions, but it's also a more flexible framework.

[andrewhong5297]

Ah I misunderstood. I think it will be exciting if we end up with a disagreement on a label, and we can host a public discussion about it and then a poll for contributors.

For conflicts like the one you proposed, labels just inherit from wash trades so if some person has an issue with what trades are being included then that is a wash trades table discussion, not a label one. The benefit of building more labels off of spells is the inherited data quality and aligned understanding. We should generally push for labels to be built off of existing spells more than raw/decoded data as much as we can (to minimize debates that can happen at a lower feed level).

[dot2dotseurat]

Ok, my rec is just that we have a version column so we are prepared for instances where the resolution to the disagreement on a label methodology is we have multiple versions that won't result in a schema change. Does that seem reasonable?

[hildobby]

Yeah I do expect some conflicting ideas behind different models and we could very well see multiple version of the same label but then wouldn't the creator be a sufficient differentiator? Adding a version column could also work ofc

[andrewhong5297]

Added version column that defaults to 1!

[andrewhong5297]

Maybe in the future there will be some "methodology" column to add, but can wait and see what happens :)

[markusbkoch]

Sorry if none of what I'm going to say makes sense. I'm not familiar with labels on Dune V2, only V1.

Labels are extremely useful and we've grown to become quite dependent on them in our queries and dashboards, and have been missing them since https://dune.com/labels was taken down.

IIUC the proposed architecture reduces creator's freedom by limiting them to a fixed set of label types, whereas today (or in V1 at least) they can/could create types and names.

My concern is that this risks stifling innovation. To illustrate what I mean, imagine we are labelling animals instead of addresses and we define that the only label types allowed are genus and species. Now if someone's use case requires that they label an animal according to their family or predominant_color or cuteness_score, they can't.

In other words, users should continue to be able to create dimensions (types) and assign to objects (addresses) a value (name) in that dimension.

[dot2dotseurat]

@markusbkoch sure, when I started looking at Dune labels I was new to the platform so I didn't have the context of which authors/type to trust. I think that relying on trust for a certain author works if you have a ton of context but gets tricky otherwise.

[andrewhong5297]

I've replied to an earlier comment with a PR example. I think in the example given, we would expect to just be a generated view or a model in the balancer sector in spellbook instead of in labels.

Being more intentional here will keep labels from bloating too much.

[markusbkoch]

Thank you for the PR. This and this for example seem to confirm my and 0xRobin's previous understanding that model_name is the equivalent of V1's label.type, which grants the model creator the same level of flexibility that they used to have. Which is good.

I think in the example given, we would expect to just be a generated view or a model in the balancer sector in spellbook instead of in labels.

I can understand where you are coming from, but this model would not have worked for our use case at the time.

LBPs are ephemeral, they don't usually last more than a few days. We needed the dashboard to be updated as soon as a new LBP was launched. Every piece of onchain data was immediately updated automatically, because all these pools come from factories so we don't have to submit contracts for decoding every time. But the missing piece, the "friendly name" lived off-chain. So we counted on the biz-dev team to contribute to the labels dataset via https://dune.com/labels.

https://dune.com/labels was super powerful because it was the first time we could merge on-chain and off-chain data on Dune. Technical and non-technical users could cooperate to develop something bigger that either group could have achieved by themselves. Seamlessly and instantly - no need to wait for a PR to be reviewed and merged!

I'll add another example. We have dashboards to help our community understand what drives volume on Balancer. dex.trades tells us what contract a user originally interacted with that caused a swap to occur. But we need to aggregate all the different 1inch router addresses into a single entity. We use labels for that. We are currently only using labels where "author" = 'balancerlabs', so one might think that your proposed view/model in the balancer sector would work just as well. But it prevents us from:

1. responding quickly to requests for enriching the dashboard; in V1 all we had to do was go to https://dune.com/labels, now we'd have to submit a PR and wait for review
2. evolving to a final, more efficient state, where we crowdsource this categorization to trustworthy members of the Dune/Balancer communities.

[andrewhong5297]

I totally see your point. I think more easily updatable static labels are an important problem to solve, following this labels refactor.

Maybe worth brainstorming with @augustog and @dot2dotseurat on how users could add quickly to static labels - maybe we can leverage the query-a-query feature such that part of the labels model could pull from query_1234 as a source so that balancer could update static labels in a query only they control and without our approval, and it would propogate into labels in spellbook automatically.

Would be a nice solve for project owned static labels, but maybe there is a better design.

[0xRobin]

Chiming in that as a generic workaround for having any static "personal" (not used by other parties) data in Dune.
You can have a static values query in DuneSQL that contains all your off-chain information in a view, and then leverage this view in your other queries.
https://dune.com/docs/reference/dune-v2/query-engine/#query-queries-as-views-in-dune-sql
This allows you to have direct control over the data (and no wait times for PR approvals)

[gentrexha]

I see that you, in the current schema, mention that the blockchain column is of type string. This wasn't the case until now, and it was of type List[string].

Is the plan to use just string from now? I've never understood the rationale behind the original type.

[andrewhong5297]

I think it would be easier to just use a string, and maybe have a "cross-chain" string for labels that apply to multiple chains.

This does affect current queries though, so something to keep in mind.

[andrewhong5297]

this is now closed, the labels have been merged :) you can query explore them here https://dune.com/queries/2010522?d=11&category_e15077=dex