search

hypercerts-org / hypercerts-indexer

Indexing service for hypercerts metadata
2 stars 0 forks source link

[Indexer] A claimed token should indicate whether it was claimed from an allowlist #26

Closed ccerv1 closed 6 months ago

ccerv1 commented 1 year ago

Describe the feature you'd like to request

a way of flagging in the subgraph whether a hypercert token was claimed from an allowlist (or claimed by creating a degenerate hypercert with no allowlist)

Describe the solution you'd like

a boolean field in claimToken that specifies whether it was claimed from an allowlist or not

Describe alternatives you've considered

From Lucian at Gitcoin:

I had a question regarding the update to the Hypercerts stamp, to restrict it to only hypercerts created with batchMintClaimsFromAllowlists. I was just wondering if you had an idea in mind for the source we should use for that data. If not, I might look into indexing the events on our side!. We were previously using the Graph for hypercerts but it doesn't look like that will tell me the method used for minting. Oh wait! It's the allowlists in the subgraph, isn't it? I think I'm good to go! Oh nope that's not it, it'd be the handleBatchValueTransfer function in the subgraph code. And it doesn't look like that currently stores any indication on the ClaimToken of whether or not it was created with a batchMintClaimsFromAllowlists call It looks like the Hypercerts contract is only ever going to emit a BatchValueTransfer from the 0 address for a batchMintClaimsFromAllowlists call. Would it work for you if I made a PR for your repo to add a flag to the ClaimToken object that gets set in this scenario? That'd probably be the easiest thing, especially if you all would appreciate that info on your end as well! I'm also happy to do the lookup and/or indexing on our side instead

ryscheng commented 1 year ago

I'm curious if they can use the metadata? We store the allowlist in the metadata, so that's an easy way to check without updating the contracts.

ccerv1 commented 1 year ago

It's a possibility, though that would still require them to do some form of indexing. They are interested in validating whether an address owns a hypercert that came from an allowlist or not.

bitbeckers commented 1 year ago

Using the metadata is a good idea. The Graph allows for reading IPFS since a few months, so this would be a nice validation of the functionality. If that works, we could potentially scale it to getting all metadata from the Graph.

Sounds reasonable to me

ccerv1 commented 1 year ago

Minor nit:

  • If metadata.allowlist is not empty, label as "hasAllowlist"

Could the label be "fromAllowlist"

ryscheng commented 1 year ago

FWIW hasAllowlist is more idiomatic if its a boolean, but it doesn't really matter I guess

bitbeckers commented 1 year ago

Ok, it's being pushed on Goerli right now. We already indexed the Allowlist so I simply updated the mapping. Because all hypercerts from a claim originate from an allowlist, if they have an allowlist, they should have a relationship.

This way, we also have the set up to store all the metadata in the Graph under the Allowlist entity.

Query:

{
  claimTokens {
    claim {
      allowlist {
        id
        root
      }
    }
    id
    units
  }
}

Data:


  "data": {
    "claimTokens": [
      {
        "claim": {
          "allowlist": null
        },
        "id": "0x822f17a9a5eecfd66dbaff7946a8071c265d1d07-0",
        "units": "0"
      },
      {
        "claim": {
          "allowlist": null
        },
        "id": "0x822f17a9a5eecfd66dbaff7946a8071c265d1d07-10208471007628153903901238222953046343681",
        "units": "10000"
      },
      {
        "claim": {
          "allowlist": {
            "id": "0x822f17a9a5eecfd66dbaff7946a8071c265d1d07-10548753374549092367364612830384814555136",
            "root": "0x6c1cd4cb48b2907fe68a724d9a75b81a0682d42c25d4c77810e955d280d58f41"
          }
        },
}

@ccerv1 would this work for the case you envision?

bitbeckers commented 1 year ago

Also @ccerv1 one consideration: This marks all fractions that belong to the claim as 'from allowlist' even if it's after splitting, merging and selling

ccerv1 commented 1 year ago

Also @ccerv1 one consideration: This marks all fractions that belong to the claim as 'from allowlist' even if it's after splitting, merging and selling

Hmmm ... good point. You've given me an idea for an alternative approach.

Query:

{
  claimTokens{
      claim {
        tokenID
        creator
        owner
     }
  }
}

And then in the app check that claim.creator !== claim.owner

wdyt?

bitbeckers commented 1 year ago

Can you help me understand how this would help the validation process for Passport?

The goal for GC Passport is to use Hypercerts as one variable in the passport score? How about these checks:

I understand rules can be perceived as guidelines for cheating, but this increases the cost from having 1 or 2 accounts mint faux hypercerts to operating a set of accounts to mint and claim. In addition with the other Passport parameters, this might be sufficient.

ccerv1 commented 1 year ago

Yes, the goal is to have a GC Passport check for a user, ideally without Passport needing to do a lot of indexing.

As you can see on Dune, there are a lot of spammy hypercerts that have been created recently. I think what you're proposing eventually leads to there being some concept of a verified hypercert. Let me set up a chat with Lucian on Discord so we can come up with a Pareto optimal solution :)

bitbeckers commented 1 year ago

Notes from chatting with @ccerv1 and Gitcoin team:

I'll try to sneak this in over the next week

holkexyz commented 1 year ago

As discussed in person, this isn't something that makes sense in the long-term, so I would deprioritize this (except this is useful for some other use case or it doesn't take much time at all)

bitbeckers commented 6 months ago

Technically this is currently in the new indexer, closing this for now