GongFu 功夫

Versión 1.0 - Edición mainnet

Toma lo suficiente. Fortalece el sistema que sostiene a todos.

#Sobre este documento

Este libro blanco describe las reglas de la primera versión de GongFu en mainnet: la reserva, los derechos de los participantes, las restricciones, las fuentes de precio, la lógica de recompensas, WindDown y los riesgos principales.

El documento explica el sistema, pero no sustituye la verificación del contrato desplegado. Antes de interactuar, el usuario verifica la dirección oficial de GF, la dirección de GongFu, el código fuente, el bytecode y los parámetros inmutables mediante el manifiesto público de despliegue y el explorador de bloques de Robinhood Chain.

GongFu no es un depósito bancario, un contrato de inversión ni una promesa de rentabilidad. El precio de GF, la liquidez de mercado, la recompensa efectiva y la duración de la fase de recompensas no pueden conocerse de antemano.

Prioridad del protocolo:

Seguridad > Sostenibilidad > Simplicidad > Funciones.

#1. GongFu en dos minutos

GongFu es un contrato inteligente inmutable de Solidity en Robinhood Chain. Mantiene una reserva compartida de GF y acepta Positions de participantes con plazo definido bajo las mismas reglas para todos.

El usuario no transfiere GF a un equipo ni a una empresa gestora. Los GF van directamente al contrato inteligente. El contrato no tiene clave privada, propietario, administrador ni función oculta de retiro. Los GF solo pueden salir de la reserva conforme a las reglas públicas codificadas en el bytecode desplegado.

El participante elige un plazo, transfiere GF al contrato y espera hasta el vencimiento. En 90 y 180 días la recompensa llega en partes mensuales, y el capital vuelve al final del plazo. El capital (principal) sigue siendo una obligación exacta del protocolo frente al titular de la Position. La recompensa no se crea de la nada ni se emite: solo puede asignarse desde la porción libre de la reserva existente.

La protección central de GongFu es WindDown. Si la reserva libre no basta para continuar la fase de recompensas, el contrato detiene de forma irreversible las nuevas Positions y las nuevas recompensas. El capital de cada participante sigue disponible para su titular mediante una reclamación manual. GongFu no convierte el capital de un participante en la recompensa de otro ni genera una pérdida para el último usuario solo por haber llegado después.

WindDown no es un botón de emergencia controlado por el desarrollador. Es el final predefinido y honesto de la fase de recompensas, que nadie puede cancelar ni modificar.

#2. Por qué existe el protocolo

Muchos protocolos de recompensas dependen de una o varias de estas condiciones:

• emisión continua de nuevos tokens;
• entrada interminable de nuevos participantes;
• rendimiento externo que puede desaparecer;
• gestión discrecional de la reserva.

GongFu parte de la premisa opuesta. La reserva es finita. Por ello, el contrato no promete recompensas infinitas, no oculta obligaciones ni deja sin definir el resultado de una escasez.

La pregunta económica detrás de GongFu es:

¿Puede una reserva compartida funcionar durante mucho tiempo cuando el capital está protegido, los límites personales más altos deben ganarse con el tiempo y las reglas no pueden cambiarse a favor del creador?

GongFu no afirma demostrar la respuesta mediante marketing. El protocolo publica sus reglas, código, manifiesto de despliegue y laboratorio de investigación. Un buen resultado de simulación no garantiza un resultado futuro.

#3. Conceptos fundamentales

La interfaz usa nombres sencillos. Los términos técnicos siguen visibles para poder relacionar las acciones del panel con las funciones del contrato.

#4. Red, token y lanzamiento

#4.1 Robinhood Chain

GongFu funciona en Robinhood Chain, una L2 de Ethereum compatible con EVM y construida sobre Arbitrum. El ID de cadena de mainnet es 4663 y el activo nativo para gas es ETH.

Quien paga la transacción asume todo el gas de red. GongFu no reembolsa ETH ni deduce comisiones del capital, la recompensa, la contribución, los saldos de referidos ni la reserva. Puede existir patrocinio voluntario de gas por terceros, pero no es una obligación del protocolo.

#4.2 Token GF

GF se crea en la plataforma de lanzamiento Pons (V2) de Robinhood Chain como un único ERC-20 canónico de suministro fijo:

1 000 000 000 GF

El GF canónico no tiene:

• emisión posterior al lanzamiento;
• pausa, congelación ni lista negra;
• comisión por transferencia;
• rebase;
• hooks ni callbacks;
• actualización;
• una segunda representación canónica del token.

Técnicamente, GF es un token estándar de Pons: un ERC-20 pequeño e inmutable sin propietario. Todo el suministro se emite una sola vez al crearlo y pasa directamente a la curva de lanzamiento de Pons (sección 4.5). El token solo tiene transferencias, autorizaciones (approve) y quema de los GF propios del titular (burn); no hay emisión, pausa, cambio de código ni cambio de saldos ajenos. La quema solo puede reducir el suministro, nunca aumentarlo.

GongFu solo acepta el GF fijado en el contrato. La dirección del token, los decimales, el suministro total y el código de ejecución se verifican antes de activar el protocolo.

#4.3 Reserva inicial permanente

Antes de la activación se transfiere a GongFu, como mínimo, la siguiente cantidad:

500 000 000 GF

Es la mitad del suministro total. Pons no da al creador ninguna asignación separada: todos los tokens se venden desde la curva. Por eso la reserva se compra. La dirección de servicio de lanzamiento compra 500 000 000 GF en la misma transacción que crea el token (launchAndBuy), antes de que nadie más pueda comprar. Con los parámetros de Pons en el momento de redactar este documento, cuesta unos 3 269 USDG, incluida la comisión de la curva del 1%.

Justo después, la dirección de servicio despliega el contrato GongFu y le transfiere los 500 000 000 GF (fundPermanentSupport); lo comprado por encima de 500 000 000 GF también va a la reserva. Entre la compra y la transferencia pasan unos minutos. Es el único momento en que la reserva depende de una clave privada: si la clave se viera comprometida justo entonces, la reserva podría no llegar al contrato. Todas las transacciones de lanzamiento se publican en el manifiesto de despliegue, y cualquiera puede comprobar que los GF comprados se transfirieron íntegros a GongFu. El contrato no puede activarse sin la reserva completa (sección 4.4).

Tras el lanzamiento, el suministro de 1 000 000 000 GF se distribuye así:

Pons aparta las dos últimas partes por sí mismo y no las vende en la curva; el equipo no recibe nada de ellas.

Estos GF forman el colchón inicial de la reserva compartida. Tras la transferencia:

• no son tesorería del desarrollador;
• no dan al creador derecho de devolución;
• no pueden retirarse mediante una función separada de propietario o administrador;
• solo pueden salir mediante las reglas inmutables de reclamación y liquidación.

El origen del token se divulga públicamente, pero no crea ningún derecho especial del creador dentro de GongFu.

#4.4 Activación

La publicación y activación en mainnet solo se producen tras verificar conjuntamente:

• un único GF canónico;
• una reserva efectiva de al menos 500 millones de GF;
• el mercado canónico y el activo de cotización;
• liquidez suficiente y un coste de manipulación aceptable;
• una ruta válida y fijada de precio spot GF/USDG de Uniswap V4;
• parámetros inmutables del constructor y el manifiesto de despliegue.

A nivel de estado en cadena, la transición a Active no requiere permiso: cualquier dirección puede invocarla, pero solo después de que el contrato observe la reserva inicial exacta y la única ruta válida. El mercado canónico, su liquidez y su coste de manipulación se divulgan y verifican por separado en el manifiesto de despliegue de mainnet. GongFu no tiene una función privilegiada de activación con condiciones menos estrictas.

La activación solo es posible después de que GF se gradúe de la curva de Pons al pool de Uniswap V4 (sección 4.5). Mientras la curva no se haya vendido, no hay pool, la ruta de precio no ve mercado y Active es inalcanzable. Tras la graduación cualquiera puede activar el contrato; la primera generación se activa manualmente, sin bot.

La activación también fija el precio de referencia inicial (sección 14). Es igual al precio mínimo válido de la ruta, es decir, el umbral de activación, y no al precio spot en el momento de activar. Por eso no sirve inflar el precio para activar antes y sacar provecho inmediato de ese precio inflado.

#4.5 Mercado de lanzamiento

El mercado de GF pasa por dos fases.

La curva de Pons. Tras la creación, el token cotiza en la curva de Pons en el par GF/USDG. Es una curva de producto constante con una reserva virtual («fantasma») de 3 236 USDG; al inicio no contiene USDG reales y el precio solo sube con las compras. Parámetros de la curva en el momento de redactar este documento:

• la primera compra de la dirección de servicio (500 000 000 GF) lleva el precio de unos 3,2 a 12,9 µUSD por GF; el mercado libre empieza a partir de ese precio;
• la curva se cierra cuando ha recibido 8 090 USDG; el mercado compra los ≈214 millones de GF restantes por unos 4 900 USDG, y el precio de cierre es ≈39,6 µUSD (FDV ≈ 39 600 USD);
• cada operación en la curva paga una comisión del 1%;
• en los primeros segundos tras la creación, Pons aplica un impuesto antisnipers más alto; la compra de la dirección de servicio en la transacción de creación no está sujeta a él;
• no hay límite de saldo por dirección.

Mientras la curva esté abierta, la ruta de precio de GongFu no ve mercado y la activación es imposible (sección 4.4).

El pool de Uniswap V4. Cuando la curva se vende por completo, cualquiera puede activar la graduación (createGraduatedPool). Pons crea un pool GF/USDG de Uniswap V4 (comisión del pool 0, tickSpacing 200, hook de Pons) al precio de cierre de la curva y deposita en él los 8 090 USDG recaudados y ≈204 millones de GF. Es el pool del que GongFu toma su precio (sección 14):

• la liquidez del pool queda bloqueada para siempre y no puede retirarla ni el equipo ni Pons;
• no hay más migraciones: el pool sigue siendo el mercado principal de GF;
• nadie ajeno puede inicializar el pool antes de que se cierre la curva: el hook de Pons rechaza ese intento.

El kit de lanzamiento comprueba los parámetros exactos de la curva y del pool antes de enviar la primera transacción, y se publican en el manifiesto de despliegue; si Pons los cambia antes del lanzamiento, el lanzamiento se detiene sin enviar nada.

#5. Qué almacena el contrato inteligente

#5.1 Estado del protocolo

El contrato almacena:

• modo Bootstrap, Active o WindDown;
• la obligación total de capital;
• la obligación total de recompensas liquidadas;
• la obligación total personal de referidos;
• el número de Positions abiertas;
• la cola de épocas de liquidación de recompensas;
• la marca de tiempo de entrada irreversible en WindDown.

#5.2 Estado del participante

Para cada dirección solo se almacena la información necesaria:

• si el participante está registrado;
• el plazo más largo desbloqueado;
• el historial de Continue exitosos;
• el nocional activo en USD de cada plazo y el total;
• el saldo acumulado de referidos;
• el nocional acumulado de donaciones;
• el número de Positions cuyo capital se ha reclamado mientras Exit o Continue siguen sin resolverse;
• si Exit ha cerrado permanentemente la dirección a nuevas Positions.

El registro de un participante es permanente. No se cierra ni se confisca porque puedan acreditársele derechos de referido posteriormente.

#5.3 Position

Cada Position tiene una secuencia única dentro de la dirección de su titular y almacena:

• titular;
• capital en unidades mínimas de GF;
• plazo seleccionado;
• marca de tiempo de apertura y vencimiento exacto;
• instantánea aceptada de GF/USD;
• nocional de entrada en USD;
• recompensa máxima;
• referidores almacenados;
• estado del capital, la recompensa del titular y los componentes de referido;
• indicador de elección pendiente del titular;
• indicador de finalización.

Una Position existente no se vuelve a valorar después de que cambie el mercado.

#6. Contabilidad de la reserva

El saldo completo del contrato no puede tratarse como reserva libre. GongFu separa las obligaciones protegidas del excedente disponible.

protected liabilities = principal liability
                      + settled epoch liability
                      + personal referral liability

available surplus = contract GF balance - protected liabilities

El invariante principal es:

contract GF balance >= protected liabilities

El capital nunca es reserva libre. Una recompensa máxima no liquidada se sigue como riesgo futuro, pero no se convierte en deuda protegida hasta que se liquide su época.

Todos los cálculos de producción usan aritmética entera con comprobaciones. El contrato no usa coma flotante. La dirección del redondeo se fija de antemano y no puede variar entre usuarios.

La pérdida de una clave no transfiere GF a la comunidad. Una cantidad no reclamada sigue siendo una obligación protegida sin vencimiento.

#7. Plazos, acceso y recompensa máxima

GongFu admite exactamente cinco plazos:

Son máximos, no rentabilidades prometidas. La recompensa efectiva puede ser menor y solo se determina tras la liquidación a partir del excedente realmente disponible.

En 90 y 180 días la recompensa máxima llega en partes mensuales iguales: 3 partes de 1/3 para 90 días y 6 partes de 1/6 para 180 días (sección 9.3). Las tasas y los límites no cambian, y el capital sigue bloqueado hasta el final del plazo.

Una dirección nueva comienza en el nivel de historial SevenDays, con una capacidad obtenida por historial del 20%. La Position de 1 día sigue siendo opcional bajo su propio límite de duración del 10% y recompensa máxima del 0.16%, pero un Continue exitoso de 1 día no avanza el historial. Un Continue exitoso del máximo actual de 7 días desbloquea el siguiente paso:

7D -> Continue -> 30D -> Continue -> 90D -> Continue -> 180D

La mera finalización del plazo no desbloquea el nivel siguiente. Un Continue exitoso de una Position de 180 días desbloquea el 100% del límite obtenido por historial.

Por encima del 20% inicial, el límite obtenido por historial también está acotado por el tamaño del propio historial. No puede superar cuatro veces el valor, al precio actual, del capital de la Position cuya finalización desbloqueó el nivel actual. Cuando el participante ya está en el nivel completo, cuenta la mayor de esas Positions. La medida es en GF, así que una subida del precio nunca impide continuar con la misma cantidad de GF. Un historial hecho de Positions diminutas desbloquea plazos más largos, pero no un límite mayor: esa dirección se queda en el 20% inicial, como una nueva.

El número de Positions no tiene un límite independiente. El valor activo agregado en USD sí está limitado, por lo que dividir una cantidad en muchas transacciones no crea capacidad adicional.

#8. MaxCap personal

MaxCap limita el valor activo en dólares de las Positions de una dirección. Es un mecanismo contra las ballenas y para la sostenibilidad, no un tamaño de Position recomendado.

La base de mercado se calcula a partir del precio GF/USD aceptado y el suministro fijo:

GF FDV = GF/USD price * 1 000 000 000 GF
m = GF FDV / 1 000 000 USD

TotalCapUSD = max(
  500,
  100 000 * m^0.746 / (m^0.746 + 39)
)

El MaxCap total base empieza en 500 USD y se aproxima gradualmente a 100 000 USD. El crecimiento es sublineal: aumentar el FDV no crea un límite personal ilimitado.

Para un nuevo Open o Continue, primero debe estar disponible la única ruta de precio; después el contrato usa el menor límite aplicable:

available capacity = min(
  remaining Total MaxCap,
  remaining duration ceiling,
  remaining earned-history ceiling
)

Un refuerzo por donación solo puede elevar la capacidad para Positions de 30, 90 y 180 días. No elude las restricciones de plazo, historial ni capacidad ocupada.

Una Position ocupa MaxCap hasta que su titular reclama el capital. El vencimiento, la liquidación y el paso del tiempo por sí solos nunca liberan capacidad. El nocional almacenado se elimina exactamente una vez, solo en la misma transacción exitosa que devuelve el capital. Una reclamación fallida o Continue no libera nada.

Para MaxCap, una Position se valora al mayor de dos precios, el spot y el de referencia (sección 14), y el MaxCap total usa ese mismo precio. Por eso no sirve bajar el precio dentro de la propia transacción para que quepan más GF.

Las Positions existentes no se vuelven a valorar. Si la ruta actual no está disponible, no hay nueva capacidad dependiente del precio; las Positions existentes no cambian.

V1 no tiene un límite global separado para el capital total sin reclamar ni un límite separado de concentración para una época de seis horas. La cobertura exacta del capital y el MaxCap personal siguen siendo obligatorios.

#9. Ciclo de vida de una Position

#9.1 Registro

El participante registra una dirección una sola vez. Si la cola de referidores elegibles está vacía, el registro se realiza sin referidor y los componentes de referido de esa relación son cero.

Cuando existen participantes elegibles, la asignación automática usa un turno rotativo determinista y acotado O(1). Quien llama no puede elegir un referidor más favorable. Solo entra en la cola un participante con al menos un usuario invitado personalmente que mantenga una Position activa de al menos 50 USD. El valor se mide al precio de bloqueo de esa Position. Las Positions de menos de 50 USD funcionan con normalidad, pero no ponen a quien invitó en la cola, lo que encarece llenar la cola con miles de carteras vacías. Una relación asignada automáticamente no cuenta como invitación personal.

#9.2 Apertura de una Position

El participante elige una cantidad y un plazo disponible. En una transacción, el contrato:

1. verifica el modo Active;
2. verifica el registro, el acceso al plazo y la ausencia de una elección pendiente del titular;
3. obtiene el precio spot canónico GF/USD y el precio de referencia;
4. calcula MaxCap y el nocional exacto en USD al mayor de los dos, y registra el precio de bloqueo de la Position al menor;
5. recibe la cantidad exacta de GF;
6. crea la Position y la vincula a una época de vencimiento;
7. incrementa la obligación de capital y el nocional activo con valores coincidentes y verificados.

El usuario no proporciona el precio, la ruta de precio, la tasa de recompensa, el referidor ni un MaxCap precalculado. Esos valores se derivan del estado inmutable.

#9.3 Plazo activo

El retiro anticipado está deshabilitado antes del vencimiento. La única excepción comienza tras WindDown irreversible, cuando el capital queda disponible con independencia del plazo restante.

La recompensa no se transfiere diariamente, no se capitaliza automáticamente y no aumenta después del vencimiento.

Partes mensuales para 90 y 180 días. La recompensa máxima de una Position de 90 días se divide en 3 partes iguales; la de 180 días, en 6. Cada parte, salvo la última, está ligada a la época de vencimiento de su mes: la época que contiene «apertura + 30 días», «+ 60 días», etc. La última parte se liquida en la época de vencimiento de la propia Position.

• Una parte se liquida junto con todas las Positions de su época y recibe el mismo coeficiente proporcional de pago (sección 9.4). No se reserva nada para ella por adelantado.
• Una vez liquidada, el titular la reclama cuando quiera (claimMonthlyReward). Si la época ya venció pero aún no se liquidó, la misma transacción la liquida primero.
• Las participaciones de referidos del 7/3/2% se toman de cada parte por separado cuando se paga. Cualquiera puede trasladarlas antes a los referidores (rollupMonthlyReferrals) sin esperar al titular.
• El capital sigue bloqueado hasta el final del plazo. La reclamación de capital primero, Exit y Continue funcionan como antes y cubren el capital y la última parte.
• El resto de la división (fracciones de la unidad mínima de GF) se suma a la última parte, de modo que las partes suman exactamente la recompensa máxima.

Las Positions de 1, 7 y 30 días no cambian: toda su recompensa se liquida en su época de vencimiento.

#9.4 Liquidación de recompensas

Las Positions se agrupan en épocas globales de vencimiento de seis horas solo para liquidar recompensas. Cada Position conserva su vencimiento exacto; no se retrasa hasta el final de la época.

Las épocas se liquidan estrictamente de la más antigua a la más reciente, una época por paso, por lo que el contrato nunca recorre una lista ilimitada de usuarios. No hace falta un operador aparte: cada nuevo depósito, cada Continue y cada salida con recompensa liquidan primero por sí mismos las épocas vencidas (hasta 32 por transacción; una salida, solo hasta su propia época) y después realizan su propia acción. Tras el WindDown, la reclamación de un participante cancela por sí misma las épocas que están en la cola antes de la suya. Si nadie ha usado el sistema durante mucho tiempo, cualquiera puede liquidar las épocas acumuladas en una sola llamada (settleMatureHeads) o, tras el WindDown, cancelarlas del mismo modo (cancelWindDownHeads). Si esa liquidación inicia por sí misma el WindDown, o hay más épocas vencidas de las que liquida una transacción, la liquidación se conserva y la acción termina sin ejecutarse y sin mover fondos: basta con repetir el depósito o el Continue. Tras el WindDown, una salida paga directamente según las reglas del WindDown. Si hay más de 256 épocas por delante de la propia, la reclamación tras el WindDown conserva las cancelaciones hechas y también pide repetirla. Si el precio no está disponible cuando un depósito ya ha liquidado épocas vencidas, la liquidación se conserva y el depósito termina sin ejecutarse.

Una parte mensual de una Position de 90 o 180 días es una entrada más en la época de su mes. Para la liquidación no se distingue de una Position que vence en ella.

La recompensa máxima de una Position no se reserva al abrirla. La recompensa solo se determina al liquidarse su época, a partir del excedente libre en ese momento. Las épocas se liquidan por orden de vencimiento, no por orden de apertura. Por eso una Position larga puede esperar detrás de otras cortas más recientes que vencen antes y cobran primero de la misma reserva.

Todas las Positions de una época reciben una escala de pago proporcional común. Si su recompensa máxima agregada es de 100 000 GF y solo hay disponibles 60 000 GF, cada Position recibe el 60% de su máximo. El orden de reclamación no da ventaja al primer usuario.

#9.5 Reclamación de capital primero

Justo después del vencimiento exacto, el titular puede reclamar el capital aunque la época de recompensas aún no se haya liquidado. Esa transacción:

• devuelve exactamente el capital;
• libera el nocional de la Position exactamente una vez;
• no paga recompensa;
• no retiene contribución;
• conserva los futuros derechos del titular y de los referidos;
• no elige Exit ni Continue en nombre del usuario.

Hasta que se resuelva la elección posterior, la dirección no puede abrir una Position nueva no relacionada. Tras la liquidación, el titular completa esa Position exacta mediante Exit o Continue. Si WindDown comienza antes, se aplica una reclamación terminal y no es posible continuar.

#10. Dos opciones tras la liquidación

#10.1 Exit: retirar todo

Exit devuelve:

• todo el capital no reclamado todavía;
• la totalidad de la recompensa efectiva liquidada del titular (en 90 y 180 días, la de la última parte; las partes mensuales se reclaman por separado y no necesitan Exit);
• sin contribución.

Si el capital ya se recibió mediante una reclamación de capital primero, Exit solo paga la recompensa liquidada y no libera MaxCap una segunda vez.

Tras Exit, la dirección queda cerrada permanentemente a nuevas acciones Open y Continue. Las demás Positions existentes siguen siendo reclamables. Los fondos no se confiscan. Una dirección nueva vuelve a comenzar en el nivel de historial de 7 días; la Position opcional de 1 día no avanza el historial.

#10.2 Continue: seguir participando

Continue completa la Position anterior y crea una nueva en una sola transacción atómica. El contrato:

1. determina el capital no reclamado y la recompensa liquidada del titular (en 90 y 180 días, la de la última parte);
2. calcula el MaxCap actual y el plazo disponible;
3. determina la cantidad efectiva de la nueva Position;
4. calcula la contribución sobre la recompensa liquidada del titular de la Position anterior (en 90 y 180 días, solo sobre la última parte);
5. traslada los derechos de referido a los saldos personales de los referidores;
6. crea la nueva Position;
7. paga el resto al titular.

Si la cantidad anterior de GF ya no cabe en el MaxCap actual expresado en dólares, el contrato coloca solo la cantidad permitida y devuelve el resto. No existe una cantidad mínima de Continue. Si no se crea una nueva Position, la contribución es cero.

Si el capital ya se reclamó, los GF de la nueva Position deben llegar realmente del titular. El capital anterior no puede reutilizarse virtualmente por segunda vez.

La contribución depende del múltiplo bruto de valor. El contrato compara el valor del capital al precio de bloqueo registrado con el valor de principal + settled owner reward al mayor del precio spot y el de referencia en el momento de Continue. Por eso no sirve bajar el precio dentro de la propia transacción para caer en una tasa menor:

La contribución se aplica solo a Continue y solo a la recompensa obtenida: la tasa se aplica a toda la recompensa liquidada del titular de la Position anterior, aunque en la nueva Position entren menos GF. En 90 y 180 días es la recompensa de la última parte: las partes mensuales ya recibidas nunca se tocan, y el múltiplo también se mide con la última parte. El capital nunca se retiene, cualquiera que sea el múltiplo.

#11. WindDown: el capital no queda bloqueado

WindDown es un estado irreversible que protege los derechos del titular cuando la reserva libre ya no puede sostener nuevas recompensas.

Al liquidar la época de vencimiento más antigua, el contrato conserva primero la cobertura del capital y todos los derechos liquidados previamente. Si la reserva libre no puede cubrir el máximo completo de la nueva época, el excedente disponible se distribuye proporcionalmente y GongFu entra en WindDown.

Después de WindDown:

new Open = disabled
Continue = disabled
new rewards = disabled
contribution = disabled
all principal = owner pull-claimable

El capital de cada Position queda disponible para su titular, haya terminado o no el plazo original. Las recompensas liquidadas existentes siguen siendo obligaciones protegidas. Esto incluye las partes mensuales de las Positions de 90 y 180 días: una parte cuya época se liquidó antes de WindDown (incluida la época que lo inició) puede reclamarse en cualquier momento, y las partes de épocas no liquidadas se cancelan con ellas. Una época que no se hubiera liquidado recibe un estado final sin recompensa, mientras el capital de sus Positions permanece intacto.

El contrato no realiza distribuciones masivas. Cada titular reclama manualmente su Position. Esto no crea una carrera en la que el primer usuario tome el capital del último: todo el capital ya se contabiliza por separado del excedente.

WindDown no puede cancelarse mediante una donación, el creador, una ruta de precio, la interfaz ni ninguna transacción posterior. No cambia reglas anteriores ni crea una salida privilegiada.

Según las reglas de GongFu, el capital no se usa para recompensas, contribuciones ni donaciones y siempre conserva una vía de reclamación autorizada por el titular. Como en todo mecanismo en cadena, la ejecución de transacciones sigue dependiendo de la disponibilidad de red, la custodia de claves y la ausencia de defectos de código desconocidos.

WindDown termina la fase de recompensas de esta generación de GongFu, no el experimento en su conjunto. Lo que sucede después se describe en la sección 19, «Generaciones».

#12. Sistema de referidos

V1 utiliza como máximo tres niveles de referidos:

La parte total de referidos nunca supera el 12% y nunca se calcula a partir del capital.

Durante Exit o Continue, cada componente de referido restante de la Position recibe un estado final. Las cantidades positivas pasan de la obligación de la época de vencimiento a los saldos personales acumulados de los referidores almacenados. Los GF no salen del contrato, no se necesita firma del referidor y el total de obligaciones protegidas no cambia.

Cualquier dirección puede trasladar los derechos de referido de una Position liquidada sin esperar a su titular, tanto en Active como tras el WindDown. Así, el referidor no depende de que el invitado vuelva alguna vez por su propio pago. El pago del titular no cambia.

Posteriormente, un referidor reclama todo el saldo acumulado en una transacción manual. El saldo no vence, no puede confiscarse ni convertirse en donación y no depende de que el referidor siga participando.

La pérdida de una clave mantiene protegido el saldo de referido, pero no deja abierta la Position original después de transferirse correctamente el derecho.

En la siguiente generación se conservan los vínculos de invitación (sección 19.8).

#13. Donaciones y recompra con comisiones

#13.1 Donación

Una donación es apoyo irreversible a la reserva. No crea capital, recompensa, derecho de referido, derecho de gobernanza ni derecho a recibir GF de vuelta.

El contrato acepta cualquier cantidad positiva de GF. Una donación aumenta el excedente y no aumenta la tasa de recompensa.

Para Positions de 30, 90 y 180 días, el historial de donaciones puede aportar un aumento adicional limitado de MaxCap:

D = cumulative donated USD notional

donationBoostUSD = 15 000 * D / (D + 250 000)

Con 250 000 USD de nocional acumulado de donaciones, el aumento es de 7 500 USD. Con 1 000 000 USD es de 12 000 USD. El límite teórico es 15 000 USD, por lo que la base agregada máxima es 115 000 USD antes de aplicar otras restricciones.

El aumento de capacidad es un beneficio secundario, no la finalidad de una donación. Se acepta cualquier cantidad positiva incluso si el redondeo produce cero crédito nuevo en USD. Cuando el precio no está disponible, la donación se acepta igualmente, pero puede otorgar cero crédito de capacidad nuevo.

El crédito en USD de una donación usa el menor del precio spot y el de referencia, así que un precio inflado dentro de una transacción no aumenta el refuerzo.

Tras el WindDown no se aceptan donaciones: ninguna Position nueva podría usarlas y los GF quedarían bloqueados para siempre.

#13.2 Recompra para la reserva con las comisiones del creador

Pons paga al creador del token una parte de las comisiones de negociación de GF (sección 4.5). Pons fija el tamaño de esa parte; se acumula en USDG y queda en el escrow de comisiones de Pons hasta que el destinatario la reclama. El destinatario de la parte del creador de GF no es el equipo, sino un contrato inmutable independiente, GongFuFeeCollector (el recolector de comisiones). Se despliega antes de crear el token y se indica como destinatario en la transacción de creación, así que recibe comisiones desde la primera operación.

El recolector no tiene propietario ni ninguna función que pague USDG a nadie. Solo puede:

• reclamar los USDG acumulados en el escrow de Pons (claimFees);
• mientras la generación está Active, comprar GF con esos USDG en el pool de Uniswap V4 y transferir lo comprado directamente al contrato GongFu (buybackToReserve). La operación solo se ejecuta si compra al menos lo que implica el precio de referencia (sección 14), menos un 3% por deslizamiento; si no, se revierte. Quien llama elige el tamaño de cada recompra, de modo que una cantidad grande puede dividirse en partes;
• mover a la reserva los GF que acaben en el recolector (sweepGfToReserve);
• después del WindDown, reenviar los USDG al Puente de la siguiente generación (sección 19.7).

Cualquiera puede llamar a todas las funciones. Solo el destinatario actual puede cambiar el destinatario de comisiones en Pons, y el recolector no tiene esa función.

Las comisiones acumuladas antes de la activación se guardan en el recolector en USDG y se usan para recompras después de la activación. El precio de referencia parte del umbral de activación y alcanza al mercado como máximo un 25% por hora, así que las primeras recompras pueden revertirse hasta que se acerque al spot; cualquiera puede acelerarlo con observeReferencePrice.

La recompra es una transferencia directa de GF, no una llamada de donación. Aumenta el excedente igual que una donación, pero no crea historial de donaciones ni da a nadie un aumento de capacidad. Su volumen depende de la actividad comercial y no es una fuente garantizada de solvencia: ni el capital ni las reclamaciones dependen de ella.

Pons conserva una vía de toma de control: el propietario del protocolo Pons puede asignar él mismo otro destinatario de las comisiones del creador (según la documentación de Pons, con un retraso de 3 días). Es un límite de confianza fuera del control de GongFu (sección 18.10). Una toma de control solo privaría a la reserva de recompras futuras; no afectaría a la reserva, al capital ni a las reclamaciones.

Las comisiones de otros mercados, exchanges o plataformas de lanzamiento fuera de la curva y el pool de Pons existen fuera del núcleo de GongFu y no se consideran una fuente de solvencia.

#14. Fuente de precio y valor de mercado

El precio GF/USD es necesario para MaxCap y para calcular el múltiplo de valor en Continue. No determina el capital ni es necesario para las reclamaciones protegidas. V1 usa una ruta inmutable de precio spot GF/USDG de Uniswap V4, vinculada al PoolManager fijado y al PoolKey exacto; poolId se deriva de ese PoolKey y nunca lo proporciona quien llama. La ruta lee slot0 y la liquidez activa, rechaza estados malformados, no inicializados, fuera de límites, de baja liquidez o intermedios desbloqueados, y falla de forma cerrada. No hay alternativa ni modo del 60%. La ruta está fijada al pool GF/USDG que Pons crea en la graduación (sección 4.5); antes de eso el pool no está inicializado, la ruta falla de forma cerrada y la activación es imposible. Si la ruta no está disponible, solo se bloquean los nuevos Open y Continue; el capital, Exit, la recompensa liquidada, el saldo de referidos, la liquidación, WindDown y las demás reclamaciones protegidas no dependen del precio. Las donaciones positivas siguen aceptándose, pero pueden recibir cero crédito de capacidad.

El precio spot en sí no es un TWAP ni un oráculo independiente. Las operaciones, la liquidez flash, los hooks y el MEV en el mismo bloque pueden moverlo. Por eso el contrato guarda junto a él un precio de referencia que no puede moverse dentro de una transacción:

• la referencia solo se mueve hacia el spot visto por transacciones anteriores, como máximo un 25% de sí misma por hora;
• cada observación se limita antes a una banda de ±25% alrededor de la referencia, de modo que una transacción manipulada la mueve como máximo un 25%, pase el tiempo que pase;
• la referencia empieza en el precio mínimo válido de la ruta (el umbral de activación) y sube desde ahí.

Cada valor que depende del precio usa el menos favorable para quien llama:

Mover el spot dentro de la propia transacción no ayuda a quien lo mueve. La manipulación repetida en un periodo tranquilo puede arrastrar la referencia poco a poco, pero cada intento cuesta comisiones y está limitado por la banda. Ante un movimiento real y rápido del mercado, la referencia se retrasa unas horas. Las nuevas Positions pueden entonces registrar un precio de bloqueo inferior al de mercado, y la contribución en un Continue posterior será algo mayor. Los límites y el umbral de liquidez de la ruta se mantienen. El usuario no puede elegir el PoolManager, token, pool, precio ni ruta.

#15. Seguridad del contrato inteligente

#15.1 Sin control oculto

El contrato de producción se despliega sin:

• propietario ni administrador;
• proxy ni actualización;
• pausa;
• rescate ni retiro genérico;
• delegatecall;
• selfdestruct;
• asignación oculta de ruta de precio o beneficiario.

Tras el despliegue, la dirección de servicio de lanzamiento puede realizar exactamente dos acciones: en el lanzamiento, vincular una sola vez el recolector de comisiones a este contrato (sección 13.2) y, una sola vez y solo después del WindDown, indicar el Puente de la siguiente generación para las comisiones (sección 19.7). No puede cambiar GF, USDG ni ninguna regla.

La inmutabilidad protege las reglas frente al desarrollador, pero hace que los defectos no puedan repararse. Por tanto, deben verificarse el código fuente publicado, el bytecode y el manifiesto del constructor antes de interactuar. GongFu se lanza sin una firma de auditoría pagada: el código fuente verificado es público en la dirección del contrato y la revisión está abierta a la comunidad, a investigadores de seguridad y a las propias herramientas de cualquiera, incluidos agentes de IA.

#15.2 Autorización y tokens

• Las acciones sobre el capital y la recompensa del titular solo están autorizadas para el titular de la Position.
• El contrato usa msg.sender, no tx.origin, por lo que las carteras de contrato funcionan.
• Cada Position tiene una pareja única de titular/secuencia que nunca se reutiliza.
• Las entradas y salidas de GF se verifican mediante cambios exactos de saldo.
• Una comisión por transferencia, transferencia incompleta, datos de retorno malformados o callbacks inesperados revierten toda la transacción.
• Checks-effects-interactions y una protección contra reentradas cubren toda ruta que mueva tokens.
• Una disposición con contabilidad cero no realiza una transferencia ERC-20 innecesaria.

#15.3 Invariantes del ciclo de vida

• La obligación de capital disminuye solo junto con el pago exacto del capital.
• El nocional de MaxCap se libera exactamente una vez en la misma transacción exitosa.
• Se rechaza una reclamación, Exit, Continue o consolidación de referidos repetidos.
• La elección pendiente del titular cambia solo con el indicador de la Position exacta.
• La obligación de referidos solo puede pasar de una época de vencimiento a un saldo personal o salir mediante una reclamación total de referidos.
• El polvo de enteros sigue protegido hasta la finalización única de la época.
• WindDown es irreversible.
• Ninguna acción recorre una lista ilimitada de usuarios o Positions; el trabajo se limita a una Position, una época y no más de tres componentes de referido.

#15.4 Verificación pública de mainnet

El manifiesto de despliegue vincula:

• ID de cadena 4663;
• dirección de GongFu y hash del código de ejecución;
• dirección de GF, decimales, suministro total y hash del código de ejecución;
• dirección del mercado canónico;
• PoolManager de Uniswap V4 fijado, USDG, poolId derivado, PoolKey, límites de precio y parámetros mínimos de liquidez activa;
• hash de fuente y hash de bytecode reproducible;
• verificación del código fuente en el explorador y enlaces a revisiones independientes a medida que se publiquen.

La interfaz no reemplaza esta verificación ni puede sustituir sus propios valores por el estado derivado del contrato.

#16. Laboratorio de escenarios y límites de modelado

El laboratorio público de GongFu es una herramienta de estrés para investigación, no una previsión de marketing. Explora una reserva finita bajo distintas tasas de entrada, toma de ganancias, pérdida de participación y choques combinados.

Los invariantes obligatorios del modelo son:

• conservación del suministro fijo de GF;
• contabilidad de capital primero;
• ninguna salida forzada antes del vencimiento salvo WindDown;
• contribución solo desde la recompensa;
• las ventas externas cambian el mercado, pero no financian GongFu;
• perfil permanente del participante en todas las compras y acciones Continue;
• WindDown irreversible;
• ninguna interpretación de resultados como previsión de FDV o rentabilidad.

El simulador no es la fuente de precio de producción y no define el mercado canónico. Sus resultados no están codificados en el contrato.

#17. Parámetros inmutables de V1

No se garantiza ningún porcentaje de recompensa. La inmutabilidad implica que estas reglas no pueden sustituirse discretamente después de la activación.

#18. Riesgos y límites de confianza

#18.1 Riesgo de mercado

El precio de GF puede caer de forma sustancial. La liquidez puede desaparecer y una venta puede sufrir un deslizamiento grave. Devolver la misma cantidad de GF no garantiza conservar el valor en dólares.

#18.2 Riesgo de precio spot

Un precio V4 válido de slot0 puede seguir reflejando un mercado poco líquido manipulado. No es un TWAP ni un oráculo independiente. El precio de referencia (sección 14) elimina la ganancia de mover el precio dentro de una transacción, pero no protege frente a un cambio duradero del mercado. Puede arrastrarse poco a poco con manipulaciones repetidas y pagadas mientras nadie más actúa. Los límites y el umbral de liquidez reducen el riesgo, pero no lo eliminan.

#18.3 Riesgo de L2

La disponibilidad de transacciones depende del secuenciador de Robinhood, RPC, la disponibilidad de datos de Ethereum y la finalidad. Una interrupción temporal o censura puede retrasar una reclamación, aunque las reglas de GongFu preservan el derecho del titular.

#18.4 Riesgo de código inmutable

Un defecto desconocido en un contrato inmutable no puede corregirse mediante una actualización. No hay auditoría profesional pagada en el lanzamiento. La revisión independiente de la comunidad, investigadores o herramientas de IA reduce el riesgo, pero no puede eliminarlo por completo.

#18.5 Riesgo de clave

El contrato no puede restaurar una cartera. Una clave perdida mantiene el capital o el saldo de referidos protegido en la contabilidad, pero imposibilita la firma del titular.

#18.6 Gas y disponibilidad

Los usuarios pagan sus propias transacciones. La liquidación de las épocas vencidas está integrada en los depósitos, en Continue y en las salidas con recompensa, y la cancelación tras el WindDown, en las reclamaciones, por lo que no se necesita un bot aparte para mover la cola. Si antes de la época de un participante se han acumulado más de 32 épocas sin liquidar, una llamada aparte las liquida primero; puede hacerla cualquiera, incluido el sitio web. La transacción a la que le toque liquidar un atraso acumulado cuesta más que una normal. Un gas elevado o una carga intensa de red pueden retrasar las acciones, pero no convierten el capital en excedente.

#18.7 Sybil e identidad de dirección

MaxCap, el historial de donaciones y la progresión se vinculan a una dirección, no a una persona. Una misma persona puede usar varias carteras, pero cada dirección comienza por separado en el nivel de historial de 7 días; la Position opcional de 1 día no avanza el historial. Cada dirección sigue sujeta a su propio MaxCap. Calentar muchas direcciones con Positions diminutas les desbloquea plazos más largos, pero el límite por encima del 20% inicial solo crece con cantidades realmente continuadas (sección 7). Es un límite, no una defensa contra Sybil: varias direcciones de una misma persona siguen recibiendo cada una su límite inicial. Lo mismo ocurre con los referidos: una persona puede invitar a sus propias carteras y recibir hasta el 12% de sus recompensas.

#18.8 Riesgo legal y fiscal

Las normas sobre propiedad y tributación de activos digitales varían según la jurisdicción. Cada participante evalúa de forma independiente los requisitos aplicables.

#18.9 Riesgo de la siguiente generación

El lanzamiento de la siguiente generación (sección 19) es un evento independiente posterior a WindDown, no una función de este contrato. Puede retrasarse o no producirse por razones técnicas, de mercado o externas. Esto no cambia ninguna obligación de la generación actual: el capital, las recompensas liquidadas y los saldos de referidos siguen protegidos y reclamables según las reglas de este documento. La prioridad en la siguiente generación no compensa una caída del precio de GF ni garantiza ingresos.

#18.10 Riesgo de la plataforma Pons

El mercado de GF lo crea una plataforma de lanzamiento de terceros, Pons, y GongFu no controla su código:

• el propietario del protocolo Pons puede asignar otro destinatario de las comisiones del creador (según la documentación de Pons, con un retraso de 3 días). Las recompras para la reserva se detendrían; la reserva, el capital y las reclamaciones no se ven afectados;
• en el momento de redactar este documento, los contratos de Pons V2 no tienen una auditoría publicada. Un error en la curva, el hook o el pool de Pons podría afectar al mercado de GF y, a través de la ruta de precio, a la disponibilidad de nuevos Open y Continue;
• Pons puede restringir qué direcciones pueden lanzar. El kit de lanzamiento lo comprueba antes de la primera transacción; si el lanzamiento está cerrado, no empezará;
• entre la compra de la reserva y su transferencia a GongFu pasan unos minutos, durante los cuales los 500 000 000 GF están en la dirección de servicio (sección 4.3).

#19. Generaciones: qué sucede después de WindDown

#19.1 Principio

Cada generación de GongFu es finita. Su reserva no se repone con emisión y sus reglas no cambian tras la activación. Cuando la fase de recompensas de una generación termina mediante WindDown, el experimento continúa con la siguiente generación: un nuevo protocolo con un nuevo token y una nueva reserva.

La generación actual no se prolonga ni se reescribe. Su contrato sigue funcionando según sus reglas inmutables hasta que cada participante reclame sus GF. La siguiente generación no puede incautar, mover ni «convertir» los fondos de la actual.

#19.2 Compromisos fijos para cualquier generación siguiente

Sea cual sea la siguiente versión, debe cumplir estas condiciones:

• sin propietario, administrador, actualización, pausa ni retirada oculta;
• el capital de cada participante se contabiliza aparte de la reserva y nunca se convierte en recompensa de otro participante;
• WindDown sigue siendo un final irreversible y honesto de la fase de recompensas;
• el nuevo token tiene un suministro fijo, y al menos el 50% de ese suministro se compra en la transacción de creación del token y se transfiere al contrato de la nueva generación durante el mismo lanzamiento; el equipo no se queda nada de esa parte;
• una parte fija del suministro del nuevo token (la cesta del Puente de generaciones, sección 19.4) se destina a los participantes de la generación actual según una fórmula anunciada de antemano;
• el lanzamiento solo es posible después de que la generación actual haya entrado en WindDown, y esta condición se comprueba con los datos del contrato;
• el código fuente de la siguiente generación y del Puente se publica, se verifica en el explorador de bloques y se audita de forma independiente antes del lanzamiento.

#19.3 Dos vías de lanzamiento

Vía base. La siguiente generación usa el mismo código auditado de GongFu que la actual, con un nuevo token y nuevos parámetros de mercado, más el Puente de generaciones. Esta vía no requiere nuevas decisiones ni depende del creador del protocolo. El kit de lanzamiento de la vía base (parámetros del token y del mercado y orden de despliegue) se fija antes de activar la generación actual: su hash criptográfico se publica en el manifiesto de despliegue y el kit se revela a más tardar en el momento del lanzamiento. Cualquiera puede comparar el kit revelado con el hash publicado.

Vía mejorada. Si para el momento de WindDown está lista una versión mejorada y auditada, se lanza en lugar de la base. Las mejoras pueden afectar a los parámetros de recompensas y límites, los plazos, la mecánica de continuación y la profundidad del mercado. Se basan en datos públicos en cadena del funcionamiento de la generación actual. La versión mejorada debe cumplir todas las condiciones de la sección 19.2. Si no está lista, se lanza la vía base.

#19.4 Puente de generaciones: prioridad para los participantes actuales

El Puente de generaciones es un contrato inmutable, pequeño e independiente de la siguiente generación. Durante el lanzamiento del nuevo token, recibe una cesta fija:

5% del suministro del nuevo token

La cesta se reparte entre los participantes de la generación actual que recibieron menos de su recompensa máxima a causa de WindDown. El Puente lee por sí mismo los datos del contrato actual; ninguna lista ni importe se elabora a mano.

El peso de cada Position:

peso = capital de la Position en GF
     × días en que los GF estuvieron realmente bloqueados
       (hasta el vencimiento o WindDown, lo que ocurra primero)
     × parte no pagada de la recompensa máxima

La parte no pagada es:

• 100% si la ventana de la Position fue cancelada por WindDown;
• la reducción aplicada si la ventana se liquidó con un coeficiente proporcional;
• cero si la Position recibió su recompensa máxima completa o si su recompensa máxima es cero (una Position demasiado pequeña para ganar algo).

En las Positions de 90 y 180 días la parte no pagada abarca todas las partes mensuales a la vez: cada parte cuenta con su propio máximo y la fracción que su época no pagó. Por ejemplo, si la primera de tres partes se pagó completa, la segunda a la mitad y la tercera se canceló, la parte no pagada es del 50%.

Contar el tiempo real de bloqueo hace inútil entrar «un día antes del final» por el bono: una Position abierta recientemente casi no pesa. El peso se cuenta en GF, no en dólares: el precio al abrir no influye, así que inflar el precio al entrar no compra una parte mayor. Dividir una cantidad entre varias direcciones no aumenta el peso, que es proporcional a la cantidad de GF.

El Puente solo se activa después de que la generación actual haya entrado en WindDown, la siguiente generación haya sido activada y la cesta haya llegado a la dirección del Puente.

La distribución se realiza en dos etapas:

1. Una ventana de registro de 30 días tras la activación del Puente. El participante indica sus Positions; el Puente verifica cada una con los datos del contrato actual. Cada Position puede registrarse una sola vez.
2. Distribución. Al cerrarse la ventana, la cesta se reparte en proporción a los pesos. No hay carrera: el orden de registro no afecta a la parte.

Solo una dirección registrada en la siguiente generación puede recibir su parte. Es una prioridad para quienes siguen participando, no un pago por marcharse. La parte puede reclamarse durante los 180 días posteriores al cierre de la ventana de registro. Lo que quede en la cesta tras ese plazo (partes no reclamadas y restos de redondeo) no vuelve al equipo: cualquiera puede activar su transferencia a la reserva de la siguiente generación. Si durante la ventana no se registra ninguna Position, la cesta pasa a la reserva en cuanto se cierra la ventana.

#19.5 Quién lanza la siguiente generación

El lanzamiento lo ejecuta una dirección de servicio indicada en el manifiesto de despliegue de la generación actual. Su papel es técnico: crea el token y despliega los contratos según el kit publicado. No se queda tokens ni controla la reserva: en la transacción de creación del token compra el 55% del suministro (50% para la reserva y 5% para la cesta del Puente) y los transfiere a las direcciones de los contratos durante el mismo lanzamiento. La compra se paga con USDG de la propia dirección de servicio. Cualquier desviación del kit es visible para quien compare el despliegue con el hash publicado. Tras el lanzamiento, esa misma dirección vincula una vez el Puente de la siguiente generación al contrato actual (sección 19.7).

#19.6 Lo que «Generaciones» no promete

• los GF de la generación actual no se convierten en el token de la siguiente generación;
• la prioridad no compensa los cambios del precio de GF y no es un ingreso;
• el tamaño de la parte en la cesta del Puente se desconoce de antemano: depende del número y del peso de las Positions registradas;
• la siguiente generación también es finita y sigue los mismos principios.

#19.7 Las comisiones tras el WindDown van a la siguiente generación

Después del WindDown, recomprar GF para la reserva de esta generación ya no financia la recompensa de nadie. Pero el mercado de GF sigue funcionando y las operaciones siguen aportando USDG al recolector de comisiones (sección 13.2). Por eso, tras el WindDown, el recolector deja de comprar GF y envía los USDG a la siguiente generación:

1. Fin de la recompra. En cuanto la generación entra en WindDown, ya no es posible comprar GF para su reserva (buybackToReserve). Los USDG se acumulan en el recolector.
2. Vinculación. La dirección de servicio de lanzamiento (sección 19.5) indica una sola vez, y solo después del WindDown, el Puente de la siguiente generación. El contrato comprueba que ese Puente apunta a la generación actual como la anterior y que su siguiente generación ya ha empezado. La dirección de servicio no tiene ningún otro poder: no puede tomar GF ni USDG ni cambiar las reglas o la vinculación.
3. Reenvío. Cualquiera puede llamar a forwardToNextGeneration en el recolector: todo su USDG va al Puente vinculado al contrato de esta generación. El recolector no puede elegir ninguna otra dirección.
4. Recompra hacia la reserva. Cualquiera puede llamar a buybackNextGenerationToken en el Puente. El Puente compra el token de la siguiente generación en su mercado y lo envía directamente a la reserva de esa generación como liquidez libre. La operación solo se ejecuta si compra al menos la cantidad que implica el precio de referencia de la siguiente generación, menos un 3% por deslizamiento; si no, se revierte. Quien llama elige el tamaño de cada recompra, de modo que una cantidad grande puede dividirse en partes. El precio de referencia de la siguiente generación se actualiza con su actividad y sus donaciones; si no las hay, cualquiera puede llamar a observeReferencePrice, la misma observación de precio que hace cualquier donación, con los mismos límites (sección 14).

La siguiente generación usa el mismo código y su propio recolector, así que tras su propio WindDown sus comisiones seguirán el mismo camino.

Este flujo no está garantizado. Su tamaño depende del comercio de GF después del WindDown. Hasta la vinculación, el USDG se acumula en el recolector de esta generación y no puede ir a ningún sitio salvo al Puente vinculado; si no se lanza ninguna siguiente generación, se queda allí.

#19.8 Los referidos pasan a la siguiente generación

La siguiente generación es un contrato nuevo con su propio registro, pero los vínculos de invitación no se pierden. Si al registrarse en la siguiente generación una persona no indica quién la invita, el contrato lee quién invitó a esa dirección en la generación anterior. Si esa persona ya está registrada en la nueva generación, pasa a ser quien invita, como en una invitación personal. Si aún no lo está, se aplica la cola habitual (sección 12). Quien invita indicado de forma explícita siempre tiene prioridad sobre el heredado.

La lectura del contrato anterior tiene un límite de gas: cualquier fallo solo significa que no hay herencia y el registro sigue como siempre. Los saldos de referidos de la generación anterior no se trasladan: se reclaman en su contrato.

#20. Fuentes

1. Robinhood Chain: visión general
2. Robinhood Chain: conexión de red
3. Robinhood Chain: despliegue de contratos inteligentes
4. Uniswap v4 core: derivación de PoolId
5. Uniswap v4 core: lecturas del estado del pool
6. PROJECT_CHECKPOINT_v1.json y los documentos raíz del protocolo GongFu.

#Conclusión

GongFu no oculta la reserva finita ni la disfraza mediante emisión ilimitada. Separa el capital del excedente y define de antemano un final honesto para la fase de recompensas. La idea central es sencilla: reglas inmutables, contabilidad transparente y un WindDown en el que el capital no se convierte en el precio de la salida de otra persona. Y cuando una generación termina de forma honesta, la siguiente comienza según reglas anunciadas de antemano.