Proposal - NFT Access Pass (DAO Press Pass)


Transferrable ERC721

Create an NFT collection that serves as a “press pass” allowing users access to token gated communities.

Ideally we would like to create a standard that our implementation adheres too so other projects can adopt / implement the same functionality

Implementation Details

Each pass would be an ERC721 token with the following information:

  • DID / VC ?
  • journalist name
  • twitter handle
  • organization they are associated with (e.g. Decrypt / CoinDesk etc.)
  • ?

Use on-chain registry to limit who can hold the NFT. This will prevent a token holder from selling their pass or giving it to an unapproved account. The registry could use DID to identify members.

Product Use Requirements

  • Token gated communities would need to update their Collab.Land integrations to add support for this NFT

Personally i think we should optimize for simplicity in design/ implementation here. No need to over-design this. The quick-and-dirty route would be:

  • Standard ERC-721 interface, with mint() and transfer() limited to adminOnly permission via modifier
  • adminOnly modifier derived from Open Zeppelin’s Ownable, and is controlled via Gnosis multi-sig
  • setTokenBaseURI() function adminOnly for setting versioned tokenURI endpoint, ex:
  • tokenURI metadata fields as follows (hosted via AWS Lambda or equiv). No need to be precious since this isn’t an art NFT, fields can be dynamic (can add DID later):
    – name
    – twitter_handle
    – organization

We make it all open source so if CoinDesk wants to implement it, they can, but they don’t need to go thru our DAO admins to do so, they would just deploy their own.

Can implement fancy DID or VC credentials later in metadata if desired.

1 Like

I like this quick-and-dirty approach to get something working.

How does adminOnly modifier controlled via multi-sig work? Would the multi-sig need to approve a wallet on the list of admins?

Regarding metadata. Is using server-less like Lambda typically the way? I’m new to this so curious what best practice is here.

Re: adminOnly: use Open Zeppelin’s Ownable modifier and set owner to Gnosis multisig address. There are other patterns of course as well that are very simple to implement, but if we end up using Gnosis Safe in general that’s probably the best way. Gnosis has a nice/ easy UI for approving transactions.

Re: Lambda for tokenURI metadata: that’s the quickest/ dirtiest/ cheapest way (esp if Decrypt is already using AWS) obvi. Best practice varies depending on NFT use-case. For art NFTs, its best to use something like IPFS because its more guaranteed to never change. Since we don’t really care about that for this use-case, i say go with cheapest/ easiest (Lambda).

1 Like

Okay cool, I am familiar with Open Zeppelin’s Ownable modifier.

We use GCP not AWS so could just use their Lambda equivalent, which I believe is called Cloud Functions.

Gotcha, yes i was going to ask if you already have a Decrypt REST API, can probably just add the press pass metadata as an endpoint there (if already existing), doesn’t matter to me. Was just proposing Lambdas or Cloud Functions in case you don’t already have something and are greenfielding.

Oh okay, in that case easiest to just add a REST endpoint. Our infrastructure is in k8es.

1 Like

Added another bullet point re: setTokenBaseURI() @luke

This is great, what are next steps? Invite reps from target social DAOs to review, reply, and agree to support and implement, then mint for our DAO reporter?

1 Like

Sounds right. Lets def get buy-in from target DAOs to start.

Have we socialized this with other DAOs yet? Also, funnily enough the AP reached out to me as they are exploring “Blockchains”. Yep. It may be a fun thing to chat through with them.

1 Like

So basically their Twitter handle will be their identifier? Just like open sea and others use for verification purposes? I think that’s useful as most journalists have Twitter, crypto or not.

There’s a team working on a decentralized LinkedIn that may also long term be used for verification. Just thinking out loud here. Then there would be verified place outside of Twitter to use for auth.

re: Twitter handle – I just put twitter_handle in there as a starting point but we can add any other social media or id system that people agree on.

1 Like