blog, crypto, futurism, newsletters, philosophy, politics, reflections, review, science, startup, venture capital

From token-gate to contract-gate

From token-gate to contract-gate

I am hosting a crypto dinner at the RICH hacker house in Oxford. However, the noise:signal ratio here is terrible. What should I do to make sure that everyone is actually actively building in Web3, rather than just being 'interested in Web3'?

By convention, the host bears the responsibility to invite high quality guests. In this case, this does not work because:

  1. I am lazy
  2. I am aware that my social network is biased towards misfits, weirdos and builders
  3. The Talent Dark Forest: the signals hide in an ecosystem and do not give a fuck about social events...think about a fierce nerd who does not go to parties...

The alternative is to token-gate events. Again, I bear the responsibility to airdrop tokens to high quality guests. What can I do to widen my reach?

Contract-gating 0xSupper

I decided to contract-gate the crypto dinner.

Here is the contract on Rinkeby testnet. It tracks an ERC-721 token called 0xSupper (RICHgang).

In order to RSVP, you have to find out where the RSVP link is. You can do so either by:

  1. looking at the contract code itself (if you are technical)


2. playing with the contract and dig around with the NFT you obtain (if you are non-technical)

Either way, you have to interact with the contract.

You have made this far... now how do you RSVP?

I sent this link around to group chats and Discord groups. I have received amazing feedback: 'Most fun way to get an invite!', 'behind the scenes is really cool', 'feels like a detective!'

A paradigm shift in user participation

Can we broadly apply this concept of 'contract-gating'?

Twitter -> Discord -> token-gated communities seems like the obvious 'evolution' of user participation. Solutions like Unlock allow protocol developers to easily token-gate access. There are also solutions that allow protocol <> token-holders communications e.g. RSS3. The most intuitive method is to just send an empty transaction with a message to all token-holders. Still, users do not get a notification on their wallet. The UX is not there yet.

Token-gating access is beneficial for protocols because it aligns economic incentives at a high level. Buying a $FWB token filters the excited from the bored.

What about contract-gating access? It is a low-level interaction that requires users to put in time as sunk cost. Theoretically, it filters and selects more technical and engaged user base. However, the UI right now is still stuck at Etherscan, lacking in visualization and user-friendliness (especially to non-technical folks).

Therefore, token-gate induces economic buyins; contract-gate attracts big brain meritocracy.

Further applications

  1. A chain of dynamic NFTs

Dynamic NFTs are way more fun than static JPEGs. Users first have to interact with the base contract. Then, their NFT status/data updates. Contract-gating leads to composability

2. Story telling with smart contracts

One obvious downside of contract-gating is that the code is open-source. In other words, the puzzle reveals its own inner-workings. Then, the true puzzle has to be a layer of abstraction on top of its code. The puzzle can be between lines of code. Or the codes hide an external URL. From one URL to another URL.

After all, one .sol file to rule them all.

3. Easter eggs

Gamers would love this! Hide a few Easter eggs here and there as code comments. If your users truly Do Your Own Research (DYOR), they would find these Easter eggs too!

The Dark Forest  

Contract-gating is intuitive for users who DYOR and code-auditors. There is a lot more derivations to contract-gating that my small brain just cannot precisely vocalize now.