1. Por qué las recompensas superan a “¿quién quiere ayudar?”
Las llamadas a voluntarios obtienen respuestas puntuales. Un miembro ayuda una vez, se siente bien y vuelve a la inactividad — porque no hubo registro, recompensa ni seguimiento. Una recompensa convierte la misma solicitud en un contrato público, con precio y estado: título, recompensa, propietario, estado e historial que cualquiera en el servidor puede ver.
El precio es el punto clave. Una recompensa de 20 euros por una tarea de documentación indica que el trabajo tiene un valor real. Los miembros que nunca se ofrecerían como voluntarios responden al trabajo con precio, porque el trabajo con precio elimina la ambigüedad sobre si su esfuerzo será reconocido.
2. El ciclo de vida: cuatro comandos, cinco estados
Sovereign implementa las recompensas como una máquina de estados estricta: OPEN → IN_PROGRESS → REVIEW → PAID, con una ruta explícita CLOSED para publicaciones abandonadas. Cualquiera con una identidad vinculada puede crear una recompensa con /bounty create <Título> | <Cantidad> (mínimo 5 EUR, almacenado en céntimos), buscar las abiertas con /bounty list, tomar una con /bounty claim <ID>, y enviar el trabajo terminado con /bounty done <ID>.
La máquina de estados hace el trabajo de moderación por usted. Una recompensa no puede ser reclamada dos veces, el creador no puede reclamar su propia publicación, y solo el trabajador asignado puede enviar. Cada transición notifica a la persona correcta: el creador recibe un DM cuando su recompensa es reclamada y de nuevo cuando se envía el trabajo, y el envío llega al Dashboard Exchange para su aprobación.
Los fondos se liberan solo después de una aprobación explícita en el Dashboard. Eso mantiene el ciclo humano donde importa —la confianza— y automatizado en todas partes.
// Command routing and the guard clauses that make the state machine safe
switch (action) {
case 'create': return await createBounty(tenantId, member.id, args); // -> OPEN
case 'list': return { reply: await listBounties(tenantId) }; // 5 latest OPEN
case 'claim': return await claimBounty(tenantId, member.id, args); // OPEN -> IN_PROGRESS
case 'done': return await completeBounty(tenantId, member.id, args); // IN_PROGRESS -> REVIEW
}
// Guards enforced inside the transition functions:
// - status must match the expected state or the command is rejected
// - creatorId !== workerId (no self-claims)
// - only the assigned workerId may call /bounty done
// Funds are released after owner approval: Dashboard > Exchange (REVIEW -> PAID)3. Ajustando las recompensas para que generen retención, no solo producción
Las recompensas que funcionan son pequeñas, específicas y se pueden ganar en una tarde. Una comunidad que publica tres o más recompensas nuevas a la semana da a los miembros una razón constante para revisar el servidor: el trabajo abierto es una razón regularmente actualizada para volver, que es exactamente el comportamiento que los ingenieros de retención intentan fabricar.
La estrategia compuesta es publicar recompensas por cosas que mejoran el funcionamiento de la comunidad: scripts de incorporación, documentación, creación de clips, cobertura de moderación, logística de eventos. Cada recompensa completada es un activo permanente, no un entregable único.
El mínimo filtra el ruido. Una recompensa inferior a 5 EUR no vale el costo de la máquina de estados ni la atención que roba al trabajo real. El precio mínimo, al igual que la puerta de REVIEW, es un control de fraude y spam disfrazado de regla de producto.