Acceso a Comunidades y Contenido con Token Gating
El acceso restringido por token (token gating) limita una comunidad, un área de contenido o una función de app a quienes poseen un NFT o token específico, reemplazando listas manuales por una verificación de propiedad en la blockchain. Encaja con proyectos que ya emiten tokens o NFTs y quieren niveles de membresía, canales privados de Discord o funciones de app ligadas a lo que una billetera tiene, en vez de una base de datos de miembros desactualizada frente a la blockchain. FreyreSoft construye la capa de verificación: un servicio backend que revisa el saldo de tokens o NFTs de billeteras conectadas, usando autenticación por firma en vez de contraseñas, y sincroniza el resultado con el sistema de acceso — un rol de bot en Discord, la sesión de una app web o un muro de pago. El trabajo incluye el contrato cuando se necesita un token o colección de NFTs nuevo, y la integración cuando el gating se apoya sobre un token desplegado en una red EVM.
¿Qué problema resuelve esto?
Las comunidades construidas alrededor de un token o NFT suelen empezar revisando la posesión a mano: alguien del equipo compara direcciones de billetera contra una hoja de cálculo o pide una captura del saldo. Eso deja de funcionar cuando la comunidad crece: no se actualiza cuando alguien vende su token, es fácil de falsificar y agrega una tarea manual recurrente cada vez que cambia la membresía. Los negocios con membresías por niveles — distintos roles de Discord, distintas funciones de app o distinto acceso a contenido según cuánto token tenga alguien — necesitan que esa verificación ocurra de forma automática y continua, usando la billetera como fuente de verdad en vez de una lista mantenida a mano que siempre queda atrás de lo que realmente está on-chain.
Cómo lo abordamos
Las verificaciones de acceso se hacen directamente contra la blockchain en vez de confiar en un saldo que envía el cliente: el backend consulta el contrato del token o NFT para leer la posesión actual de una billetera conectada, usando firmas de billetera (Sign-In with Ethereum o un esquema equivalente de desafío-respuesta) para confirmar que la billetera pertenece a quien pide el acceso. Para Discord, esto suele significar un bot que traduce la posesión verificada en roles del servidor y revisa periódicamente para que el acceso siga las ventas y transferencias automáticamente. Para una app web, significa restringir rutas o componentes desde el servidor y no solo ocultarlos en el cliente, porque un botón oculto no es control de acceso real. Cuando los niveles dependen de umbrales de saldo y no de posesión simple, la lectura del contrato y la lógica de niveles se mantienen separadas para que los límites de cada nivel puedan cambiar sin tocar el código de verificación. Se escriben contratos de token o NFT nuevos cuando el proyecto no tiene uno contra el cual verificar.
Tecnología que solemos usar
- Contratos en Solidity
- ERC-721 y ERC-1155
- Tokens ERC-20
- Sign-In with Ethereum
- ethers.js / viem
- API de bots de Discord
- The Graph / indexador
Qué suele incluir un proyecto así
- Login por firma de billetera en vez de contraseña o correo
- Lectura del saldo de tokens o NFTs directo desde la blockchain
- Sincronización de roles en Discord o gating desde el servidor
- Contrato de token o NFT nuevo si todavía no existe uno
- Revisiones periódicas para que el acceso siga ventas y transferencias
¿Tienes en mente algo parecido a esto?
Contáctanos