En el ecosistema Web3, la reputación se está convirtiendo gradualmente en una capa tan fundamental como los tokens y los NFT. @Yield Guild Games a través del Guild Protocol y Onchain Guilds ya han convertido los logros de los jugadores y las guildas en una capa de reputación on-chain personalizable. El siguiente paso lógico es abrir esta reputación como un servicio para aplicaciones descentralizadas externas a través de una API conveniente que permita a cualquier aplicación "ver" el historial verificable de acciones de las guildas y los jugadores y utilizarlo en su lógica.
En la base del modelo hay una idea simple: $YGG fija logros clave y la contribución de los participantes en forma de tokens soulbound (SBT) que no se pueden transferir a otra dirección. Tales tokens se convierten en bloques de construcción del perfil on-chain: misiones, torneos, participación en programas, contribución a la comunidad: todo esto se transforma en un conjunto inmutable de etiquetas, accesibles para cualquiera que sepa leer la blockchain.
El Protocolo de Gremios describe a Gremios Onchain como la suma de tres elementos: el gremio mismo, sus activos y sus actividades on-chain. La reputación aquí no es un 'rating' abstracto, sino una composición de datos: qué SBT tienen los miembros, qué programas ha pasado el gremio, qué volumen de recompensas se ha distribuido, con qué frecuencia participa en campañas. La API abierta sobre esta estructura debería ser capaz de proporcionar cortes a todos estos niveles en forma de modelos convenientes para aplicaciones.
El concepto del Protocolo de Gremios implica directamente que cualquier desarrollador puede construir aplicaciones que 'apunten' a Gremios Onchain como conjuntos listos de usuarios involucrados. Para que esto funcione a gran escala, se necesita no solo acceso crudo a la cadena, sino también una API estandarizada: un conjunto de métodos a través de los cuales una dApp externa puede buscar gremios y jugadores por criterios de reputación, sin tener que entender cada tabla interna o contrato.
En el nivel superior, el modelo de API se puede representar como 'reputación como servicio'. El Protocolo de Gremios proporciona una capa de protocolo básico, y sobre ella se despliega un servicio público que ofrece: búsqueda de gremios por atributos, filtrado de jugadores por logros on-chain, evaluación de involucramiento y calidad, así como suscripciones a eventos de cambios en la reputación. Para la dApp, esto se presenta como una interfaz REST/GraphQL familiar, que oculta un trabajo complejo con la blockchain y los indexadores.
Arquitectónicamente, este modelo se divide en tres capas. La primera: datos on-chain: contratos de gremios, SBT, eventos de misiones, billeteras on-chain de tesorerías. La segunda: indexación: servicios especializados que leen eventos, los desnormalizan, construyen agregados y clasificaciones. La tercera: puerta de enlace API pública, que ya trabaja con entidades familiares: 'Gremio', 'Miembro', 'HistoriaDeMisiones', 'PuntuaciónDeReputación', y así sucesivamente.
La parte on-chain permanece lo más minimalista y verificable posible. La dirección del gremio, su id en #YGGPlay , la lista de atributos básicos, el hecho de la membresía, los eventos de obtención de SBT: estos son datos que deben estar disponibles para cualquier nodo de la red y ser iguales para todos. Aquí, la API proporciona principalmente un puente 'read-only' conveniente: en lugar de llamadas RPC crudas, el desarrollador obtiene estructuras comprensibles con campos claros, filtros y paginación.
La capa off-chain se encarga de todo lo que es pesado, agregado o cambia con frecuencia. Aquí se incluye el cálculo de puntos de reputación, la agrupación de gremios, la agrupación de actividades por juegos o tipos de tareas, heurísticas contra bots y múltiples cuentas. Aquí es donde se pueden implementar diferentes modelos de puntuación, desde 'suma simple de SBT' hasta fórmulas complejas con atenuación temporal de logros y consideración del peso de programas individuales. La API, en este caso, proporciona índices ya listos, sin revelar detalles internos.
La API pública sobre la reputación #YGG debe estar orientada a escenarios, y no solo a 'datos crudos'. A una dApp le puede interesar un método 'encontrar 100 gremios con historial de participación en ciertos tipos de misiones y un número suficiente de participantes activos'. A otra, 'encontrar jugadores con ciertos SBT y un nivel mínimo de actividad en los últimos N meses'. A una tercera, 'saber cómo ha cambiado el perfil de reputación del gremio después de una serie de campañas'. Todo esto son en realidad variaciones de algunas solicitudes universales a la misma capa de datos.
Un bloque separado es el modelo de eventos. Además de las solicitudes sincrónicas, la API puede proporcionar suscripciones a cambios: nuevos SBT, cambios en el estado de los gremios, alcanzar ciertos umbrales de reputación. Esto se puede hacer a través de webhooks o interfaces de flujo. Entonces, la dApp no solo 'toma una muestra' periódicamente, sino que reacciona a eventos de reputación en tiempo real: invita automáticamente a un gremio a una campaña, abre acceso a funciones especiales o, por el contrario, limita derechos ante sospechas de abuso.
La cuestión de la privacidad aquí es crítica. La fortaleza de YGG radica en que la reputación se construye sin el almacenamiento explícito de identificadores tradicionales: la edad, el género, el país y otros datos sensibles no son necesarios para registrar logros. La API abierta debe continuar en esta línea: trabajar principalmente con direcciones, IDs de gremios y SBT, evitando la entrega de información que puede facilitar la desanonimización de una persona específica sin su consentimiento.
La gestión de tal API se convierte inevitablemente en un área de responsabilidad de DAO y gobernanza de protocolo. A través de votaciones se pueden aprobar fórmulas básicas de reputación por defecto, reglas de limitación de acceso, cuotas para solicitudes intensivas y principios para agregar nuevos tipos de SBT. Al mismo tiempo, nadie impide que equipos externos construyan sus propios indexadores alternativos y puntuaciones sobre la misma capa on-chain, si prefieren un enfoque más personalizado o experimental.
Las aplicaciones de tal API son mucho más numerosas que solo los juegos. Los estudios de juegos pueden seleccionar gremios para pruebas de juego y lanzamientos. Las plataformas de misiones pueden filtrar a los participantes por experiencia demostrada. Los protocolos DeFi pueden utilizar la reputación como una señal adicional al acceder a productos más complejos. Fuera del ámbito de los juegos, se pueden construir modelos de reputación para equipos que trabajan con datos, contenido, tareas de IA: YGG ya concibe a los Gremios Onchain como un primitivo común para diferentes tipos de comunidades.
A largo plazo, una API abierta sobre la reputación de YGG convierte al Protocolo de Gremios de 'capa interna para los suyos' en un nivel de coordinación accesible al público de Web3. Una vez que decenas de dApp se conectan a ella simultáneamente, la reputación deja de ser una historia local y comienza a funcionar como un capital social común: el mismo logro abre puertas en diferentes aplicaciones, y un gremio con un perfil fuerte se convierte en un socio deseado para toda una red de servicios. Esta es la dirección hacia la que se dirige gradualmente el ecosistema de YGG: de misiones individuales a una API de reputación completa, sobre la cual pueden construirse nuevas olas de productos.
@Yield Guild Games #YGGPlay $YGG
