Backend de economía para juegos Web3
La economía de un juego Web3 tiene un patrón de acceso distinto al de una fintech: el game loop consulta estado constantemente, así que el costo de leer inventario y precios importa tanto como la correctitud. Esta arquitectura de referencia describe cómo resolver inventario, acciones on-chain y valoración de ítems en fiat sin mantener ABIs a mano y sin disparar el consumo de credits por el polling continuo.
El desafío
El backend de un juego tiene que reflejar el inventario del jugador leyendo eventos on-chain, ejecutar acciones como mint, trade o entrega de recompensas, y mostrar el valor de los ítems en moneda local. El problema práctico es doble: mantener y actualizar ABIs por cada contrato del juego es trabajo constante, y el game loop consulta con tanta frecuencia que una fuente de datos cara por llamada vuelve inviable el polling. Además, el estudio no quiere custodiar las keys de los jugadores.
- Balances / portfolio / net-worthC2
- Decoded transactions / logsC2
- Build / sign / broadcastC2
- Spot / OHLCVC1
Inventario con logs decodificados, sin mantener ABIs
El inventario se reconstruye leyendo balances y decoded logs: los eventos de los contratos llegan ya decodificados, así que el backend no tiene que mantener ni versionar ABIs por cada colección o mecánica del juego. Al salir de nodos de archivo propios, el histórico completo está disponible para reconstruir el estado de un jugador desde cero.
Acciones del juego con firma del lado del cliente
Mint, trade y recompensas se ejecutan con el flujo build/sign/broadcast: la plataforma arma la transacción y la difunde, pero la firma queda del lado del cliente. El estudio no custodia keys de jugadores; cada acción se firma con la wallet del propio usuario o con el esquema que el juego integre, y la plataforma solo se encarga de construir y transmitir.
Valoración en fiat con precios spot y caché por render
Los ítems se valoran con precios spot, el tier más económico. La clave para no quemar credits está en cachear el precio por intervalo de render: aunque el game loop consulte constantemente, el valor se recalcula por ciclo de pintado y no por cada frame, así que el polling intenso del juego consume muy poco. Inventario, acciones y precios usan la misma key.
Lo que entrega la arquitectura
- Inventario reconstruido con decoded logs, sin el trabajo continuo de mantener y versionar ABIs por contrato.
- Acciones on-chain con firma del lado del cliente: el estudio nunca custodia las keys de los jugadores.
- Precios spot cacheados por intervalo de render: el polling del game loop apenas consume credits.
Preguntas frecuentes
¿El polling constante del game loop me va a disparar el consumo de credits?
No si cacheas por intervalo de render. Spot es el tier más barato y el valor se recalcula por ciclo de pintado, no por frame, así que un game loop intenso genera muy poco consumo real.
¿Necesito subir el ABI de cada contrato del juego para leer el inventario?
No. Los decoded logs llegan ya decodificados, así que reconstruyes inventario y eventos sin mantener ni actualizar ABIs por cada colección o mecánica.
Recarga, obtén tu clave y publica.
Autoservicio. Paga en cripto o con tarjeta. Medido por créditos: las primitivas pesadas cuestan más, las simples son baratas.
Obtener clave API