project screenshot 1
project screenshot 2
project screenshot 3
project screenshot 4
project screenshot 5
project screenshot 6

User verification using decentralised identity and custom conditions. Gates enables dapps, metaverse games, and NFT projects to seamlessly verify users via custom conditions.

Created At


Winner of


๐Ÿง‘โ€โš–๏ธ Optimism โ€” Governance and Community Infrastructure


๐Ÿค Worldcoin โ€” Best Social App


๐Ÿฅˆ Coinbase โ€” Built on Coinbase Cloud


๐Ÿ—ƒ Coinbase โ€” ๐Ÿฅ‡ Best Integration of Coinbase Wallet


๐Ÿ‘ ENS โ€” I Saw The Sign


๐ŸŠโ€โ™‚๏ธ ENS โ€” Pool Prize


๐Ÿ•ธ The Graph โ€” ๐Ÿฅ‡ Best Use of Existing Subgraph


๐Ÿฅ‡ Ceramic โ€” Best use of Data Composites


๐Ÿฅ‡ Quicknode โ€” Best Use

Project Description

We want to simplify access to personalized content for users, creators, and communities.

Today, we see a poor range of end-user experiences utilizing conditioned access, a narrow data source offering, and a troublesome developer experience.

We think thereโ€™s room for more custom condition logic, better end-user applications, and a smoother experience to set it up.

With gates, we expand the concept of access management by combining on- and off-chain identities, arbitrary conditions, and increased customizability. As a result, managing access and creating a world of personalized experiences cross-contexts has never been easier.

To protect usersโ€™ data, weโ€™re utilizing DID (decentralized identities) for Ceramic, where only the user owns and can modify their (encrypted) data.

For creative communities and the humans who build them: letโ€™s build a public good together.

How it's Made

To build Gates, we used Sign in with Ethereum and Ceramic to create a DID and let users store data connected to their identity. Since the data is on IPFS, we also encode it with a secret so only our server will be able to read from it and sensitive information is safe.

Furthermore, when reading the data from Ceramic, we decrypt it and only read the values on the server to determine if conditions are met.

The conditions that we create are supposed to be dynamic. Therefore, each condition is structured like 'service:method:args' that is converted to bytes and stored on-chain. With this structure, we can support any service we can think of.

When a user asks our API to verify, we decode the steps iterate through them, execute the connected method with our arguments and require all of them to pass. In the future, we are looking to implement OR/NAND/NOR. The API will only return a boolean to mimic a zkproof as much as possible.

background image mobile

Join the mailing list

Get the latest news and updates