Now that I’ve wrapped my head around trust circles, our browser extension is starting to support EVM addresses, and I’ve thought about how I expect them to function I want to be able to apply this vision to the MetaMask Snap
Here is how I expect it to go:
- Curators will start making relevant claims about EVM addresses, smart contract or EOA, etc
- Our Hive Mind dapps will recommend some of these curators to our users, especially since many Hive Mind users will be interacting with the addresses that the curators will be making claims about
- Users will use the Hive Mind Snap for MetaMask and be presented with the most important / insightful claims for each address they transact with. Hive Mind may also include insights from our own list of curators that WE follow, which would lighten the burden of users having to find curators to follow (high friction)
This begs the question of which triples should be displayed within the MetaMask Snap.
Currently my LLM latched onto the following claim types:
- Scam, Spam (via canonical
reported for predicate)
- Trustworthy, Bullish (via
has tag)
- Add Tag
Should we also add one for “has alias” or something like that? What are some other important claims to surface?
Once we settle upon which claims we’ll use then we can start encouraging curators to start making claims about said addresses, and I can display them in the Snap. We can also show the ENS names of the curators that agree or disagree with any given claim.
Is there anything else that you think the Snap should show? I don’t think we’re going to be showing as many global statistics as our earlier prototypes because they aren’t fully reliable and don’t convey the full picture.
Am I missing anything else here?
1 Like
Warning: scope creep
IMO, semantic claims about the wallets onchain behavior is a really interesting use case for triples. I hope to see more programmatic curators who automate the collection and interpretation of existing data and semantically structure it on the KG.
For example:
[has onchain tag] Diamond Handed
[has onchain tag] Whale
[has onchain tag] DeFi LP
Providing quick and useful context without the user needing to look at a wallet’s history.
But to address the original question, it would be nice to surface social accounts from the wallet level. If a user doesn’t have the same EOA and X handle, then claims about where to find them (their Medium / X / EthMagicians / etc) helps to unify their content footprint and opens up new ways to discover. And if someone makes a claim about themselves, then it can be filtered into a personal on-chain linktree.
I do think the data needs to be useful to not become cluttered. Whatever can be gleaned from the data should go to solve a problem someone else has or make something more convenient. Interpreting on-chain data about a wallet is very inconvenient for the onchain crypto niche. Also, finding someone across multiple platforms is inconvenient; however, I think I would still instinctively go to their X ‘about me’ section in the hope that they had all the relevant links already there.
1 Like
Great thread - this overlaps a lot with predicate work I’ve been doing for AgentScore, so a few concrete thoughts.
On the safety side: reported for (paired with Scam / Spam / Injection objects) is already minted on mainnet and designed to be reused exactly like this. The Injection object is worth surfacing in the Snap too - for contract addresses, “reported for Injection” flags a different and increasingly relevant risk than plain Scam.
On @matt_chain’s social-discovery point - this is something I’ve been building right now. A set of identity predicates: has x, has discord, has telegram, has github, has website. They turn a wallet into exactly the “personal on-chain linktree” you described - [Address] - has x - [handle], etc. Generic by design so any app can read them. Happy to coordinate so Hive Mind and AgentScore use the same canonical set rather than fragmenting.
On has alias - there’s already same as on mainnet (minted it last week after a similar question from Kylan). It handles the mutable-handle / immutable-ID case: [x.com/handle] - same as - [x.com/i/user/123]. Survives handle changes. That might cover what you had in mind for alias.
The one thing I’d push on, regardless of which predicates win: the Snap should filter every claim by trusted publisher address before display. A claim type like “reported for Scam” is only as good as who published it - anyone can write that triple. Showing curator ENS names (as Kylan suggested) is the right instinct, but it should be a hard filter, not just a label. Otherwise the Snap becomes a vector for griefing - someone mass-tags legit contracts as Scam.
On scope creep - matt’s right. I’d start the Snap with two buckets only: safety (reported for) and identity (has x / website / etc). Behavioral tags (Whale, Diamond Handed) are genuinely interesting but they need programmatic curators with reliable methodology first, otherwise they’re noise. Ship the two reliable buckets, add behavioral once there’s a curator actually producing it well.
Happy to share term_ids for any of the above - most are minted, the identity set is in progress and going into the next Intuition Ontology PR.