El airdrop
Desde el 2026-09-27, la tesorería de un mercado tiene un solo uso: el 100 % de las acciones tokenizadas que compra se distribuyen por airdrop a los holders de su token, a prorrata de sus tenencias, cada 24 horas. El buyback del creador que lo precedía queda eliminado.
Codificado y probado, no desplegado. El contrato del airdrop, AirdropDistributor, se
codificó y se probó el 2026-10-04, junto con los caminos que lo alimentan desde los dos
vaults; el paso diario del airdrop en el keeper y la pantalla de reclamación de la dapp se
escribieron el 2026-10-05. En los tests, LayerZero se sustituye por mocks, y no hay nada
desplegado. Queda por hacer: los adaptadores LayerZero de las acciones. Consulta
Estado de avance.
Qué se distribuye
Todo lo que compra la tesorería: el 2 % de cada trade, en compras y en ventas, más el excedente del anti-snipe de los diez primeros bloques del mercado, una vez convertido en acciones del basket del mercado.
La distribución es en especie: los holders reciben las acciones tokenizadas, en forma wrapped en Ethereum (ver más abajo), nunca efectivo. El ETH, el USDC o el USDG que aún esperan su conversión no se distribuyen como tales; sí se distribuyen una vez convertidos en acciones.
A quién, y dónde
A los holders del token del mercado, a prorrata de sus tenencias. Las direcciones propias del protocolo no reciben nada.
Las tenencias se cuentan como el saldo promedio de cada wallet durante las 24 horas anteriores al ciclo, lunes incluidos: tener el token durante una hora cuenta como 1/24 de un día completo. Una compra justo antes de que se cierre la ventana apenas recibe nada. Desde el 2026-09-28, las tenencias de cada wallet se registran onchain a lo largo del tiempo, así que un contrato calcula cada parte en Ethereum; el keeper nunca las proporciona. Desde el 2026-10-02, el registro se lleva fuera de los tokens, en un módulo, el registrador de tenencias: cada token le notifica cada cambio de saldo, y si la notificación falla, la transferencia falla. Es deliberado, la única excepción a la regla del protocolo según la cual un fallo nunca bloquea el resto: una notificación a la que se permitiera fallar dejaría que un holder la privara de gas en su propia transferencia, de modo que el registro omitiera el movimiento y su parte creciera. Consulta Arquitectura y la regla de operación más abajo.
Desde el 2026-10-01, el registro guarda también a lo largo del tiempo el supply
registrado de cada token: todos los saldos fuera del PoolManager de Uniswap. Es lo que
da a la parte su denominador:
parte = saldo promedio durante la ventana
÷ (supply registrado promedio − promedios de las direcciones excluidas)
Las direcciones excluidas son las que no reciben nada: la dirección de burn, siempre, y las direcciones de la lista de exclusiones del token; ver las exclusiones más abajo. El registrador solo da el supply registrado en horas en punto, así que las ventanas del airdrop empiezan y terminan en una hora en punto. Cuesta a cada swap una escritura más en el almacenamiento. El primer swap de un token en cada hora, compra o venta, cuesta unos 28 000 a 30 000 de gas más, medido en una transacción propia el 2026-10-01, antes de que el registro saliera de los tokens; los 23 000 que daba esta página hasta el pipeline de seguridad del 2026-10-01 se midieron dentro de una sola transacción. Por tanto, una estimación de gas hecha por una wallet al final de una hora puede quedarse corta, si la transacción llega como el primer swap de la hora siguiente. Desde la actualización Glamsterdam de Ethereum (activa en Sepolia desde el 2026-10-06, en mainnet cuando se produzca su fork), esa escritura crea su slot de almacenamiento al nuevo precio: en Sepolia, el primer swap de una hora costó 123 216 de gas más. La app da 150 000 de gas más a un trade que puede llegar como el primer swap de una hora: solo un límite más alto, ya que una transacción paga el gas que usa.
Las tenencias se miden en Ethereum, donde se opera el token, y desde el 2026-09-28 las acciones también se distribuyen allí. Se compran en Robinhood Chain, se bloquean allí en adaptadores LayerZero desplegados por StockFun, uno por acción, y se envían a Ethereum como acciones wrapped, una acción wrapped por cada acción bloqueada. Cada holder reclama su parte en Ethereum y paga el gas de la reclamación. Para tener la acción real, un holder envía la acción wrapped de vuelta por el bridge a Robinhood Chain, a su cargo. La configuración de LayerZero de los adaptadores está en manos del owner de StockFun, sin plazo y sin tope de retiros: consulta Modelo de confianza.
La regla se aplica a toda tesorería, incluida la de $STOCKFUN, que se distribuye por
airdrop a los holders de $STOCKFUN.
Cada 24 horas
El airdrop funciona como un ciclo diario, mercado por mercado. Su hora, las 13:00 UTC por defecto, cierra la ventana sobre la que se miden las tenencias, antes de que abra la bolsa estadounidense, todo el año: la apertura es a las 13:30 UTC en verano y a las 14:30 UTC en invierno. Las compras del ciclo se hacen después, durante la sesión que sigue, y sus envíos, por defecto, una vez terminada esa sesión:
- Si la tesorería del mercado ha acumulado al menos 0,1 ETH, el keeper la convierte, la envía a través del bridge y compra las acciones del basket.
- Una vez terminada la sesión del día, por defecto, el keeper envía las acciones compradas al contrato del airdrop en Ethereum, wrapped, donde el 100 % de ellas pasa a ser reclamable por los holders del token. Desde el séptimo bucle de auditoría, el 2026-10-06, las envía una vez que valen lo que cuesta enviarlas, incluida la apertura de la ventana; si no, esperan en el vault a una ventana posterior, con lo que se vaya acumulando (ver El keeper). Desde el décimo bucle de auditoría, el keeper solo vuelve a leer un vault que no tenía nada que enviar después del cierre en la siguiente sesión, así que una acción dada a un vault después del cierre, fuera de sus compras, sale con el envío de la siguiente sesión, a una ventana posterior; lo que traen las compras del día sigue yendo a la ventana que terminó ese día.
Por debajo de 0,1 ETH, ese día no ocurre nada en ese mercado: el ETH espera al siguiente ciclo. Con un 2 %, alcanzar el umbral requiere unos 5 ETH de volumen en el mercado, sumando compras y ventas. Superarlo durante el día no dispara nada: la conversión solo tiene lugar en el ciclo diario. El keeper comprueba cada vault en su primera pasada después de que se cierre la ventana y convierte su ETH una sola vez en esa ventana; se atiene a ello desde el 2026-10-06, y hasta entonces convertía el ETH de un vault en cualquiera de sus pasadas durante la sesión, en cuanto el vault contenía el umbral. El efectivo que ya espera en un vault sigue adelante, se alcance o no el umbral: desde el sexto bucle de auditoría, el 2026-10-06, el USDC de un vault una vez después de cada una de sus conversiones de ETH y como máximo una vez por ventana en los demás casos, y el USDG de un vault espejo en cada pasada.
Las acciones solo se pueden comprar mientras la bolsa estadounidense está abierta. Por tanto, no hay ciclo los fines de semana ni los festivos de la NYSE: las comisiones del viernes se distribuyen el lunes.
El umbral y el calendario son reglas del keeper: el contrato del airdrop no conoce ninguno de los dos. Conoce las ventanas, y abona cada envío a la última ventana cerrada en el momento de su llegada.
La duración y la hora de cierre del ciclo, el umbral, 0,1 ETH, y los límites del contrato del airdrop que se describen más abajo son ajustes del owner de StockFun desde el 2026-10-05; los valores de esta página son los valores por defecto. Un nuevo horario se aplica a las ventanas aún no abiertas: un ciclo ya abierto conserva su ventana.
Un ciclo que falla por el camino (un bridge que se retrasa, un feed desactualizado, un rechazo por límite) solo detiene lo que el fallo afecta. Desde el 2026-10-05, la compra de cada acción va por separado: una acción cuyo tramo falla conserva su efectivo para un ciclo posterior mientras se compran las demás acciones del basket, y un mercado que queda fuera de un lote del bridge espera mientras los demás cruzan. Lo que no siguió adelante espera en los vaults del mercado, en Ethereum o en Robinhood Chain, y se termina de procesar en el siguiente ciclo, aunque la tesorería no haya vuelto a alcanzar 0,1 ETH. El owner de StockFun también puede moverlo, en cualquier momento, con la transferencia de emergencia, que es inmediata: consulta Modo de emergencia.
Cómo funciona un ciclo
En el contrato del airdrop, desde el 2026-10-04:
- La ventana. La ventana de un ciclo es el periodo anterior a su fin: 24 horas que
terminan a las 13:00 UTC por defecto. El owner de StockFun fija la duración y la hora de
cierre, en horas enteras (
setCycleSchedule). Un envío pertenece a la ventana que termina en la última hora de cierre en o antes de su llegada, nunca a una anterior al último ciclo abierto del mercado. - La apertura congela las cifras. El primer envío de una ventana abre su ciclo. El
keeper puede abrirlo antes, con
openCycle, que cualquiera puede llamar: lo hace una vez cerrada la ventana, antes de que lleguen las acciones, de modo que cada entrega solo se suma al ciclo. La apertura congela, para siempre: el registrador de tenencias del token, la lista de exclusiones vigente al cierre de la ventana, se abra cuando se abra el ciclo, y el denominador, el supply registrado durante la ventana menos las tenencias de la dirección de burn y de las direcciones de la lista. Todos los holders de un ciclo se miden con las mismas cifras, cambie lo que cambie después. - Un ciclo por ventana. Los envíos posteriores de la misma ventana se suman al mismo ciclo.
- El keeper decide cuándo. Dispara los envíos; nunca designa una ventana, un holder ni un monto. Por eso, un envío que llega después de la siguiente hora de cierre se mide sobre la ventana del día siguiente. Está asumido y documentado.
Cómo llegan las acciones
Dos caminos, y nada más abona un ciclo.
- Desde Robinhood Chain. El keeper llama al vault espejo del mercado,
sendToAirdrop(stocks), y paga las comisiones de LayerZero; lo que paga de más se le devuelve. Desde el 2026-10-06, la llamada también indica el gas que recibe cada entrega en Ethereum,sendToAirdrop(stocks, receiveGas, composeGas), que el hub remoto mantiene entre un suelo y un techo que fija el owner de StockFun (ver El rail de Robinhood y El keeper). Por cada acción de la lista, el vault envía todo su saldo a través del adaptador que el hub remoto designa para esa acción, hacia el contrato del airdrop que designa el hub remoto, con el identificador del mercado como carga útil. LayerZero transporta seis decimales: menos de 10^12 unidades de una acción de 18 decimales, una millonésima de token, se quedan en el vault para un envío posterior. En Ethereum, el OFT de la acción acuña la acción wrapped al contrato del airdrop, y luego el endpoint de LayerZero lo llama. El contrato solo abona la entrega si viene de su endpoint, de un OFT de acción que el owner de StockFun registró, desde Robinhood Chain, enviada por el vault espejo del mercado que designa la carga útil, y si ese mercado existe. - Desde Ethereum. En un vault que compra sus acciones en Ethereum, el rail local, el
keeper llama a
sendToAirdrop(stocks)en elTreasuryVaultdel mercado. El vault aprueba los montos exactos, el contrato del airdrop los retira y abona lo que realmente ha recibido, y las aprobaciones se vuelven a cerrar. Solo el vault del propio mercado puede enviar por él. Un vault conectado al hub del bridge rechaza este camino: sus acciones están en Robinhood Chain.
En ambos casos, el keeper decide cuándo, nunca cuánto, qué ni adónde: el monto es el saldo del vault, el destino es el contrato que designa el protocolo, y una acción listada dos veces o fuera del basket hace fallar la llamada.
Desde el 2026-10-05, cada acción de la lista va por separado. Una acción que su emisor
congeló, cuyo saldo no se puede leer o, desde Robinhood Chain, que no tiene adaptador o
cuya comisión no cubre el pago del keeper se queda en el vault, con un evento
(AirdropSendFailed), y las demás se envían; saldrá con un envío posterior. Cuando no
sale ninguna acción, la llamada falla e indica el motivo.
Partes y reclamaciones
- Reclama el holder. Cada holder reclama su propia parte, en Ethereum, y paga el gas:
un ciclo con
claim, varios conclaimMany. Nadie puede reclamar por otra persona, y el keeper no envía nada. Desde el 2026-10-05, la pantalla de reclamación de la dapp muestra todas las ventanas que la wallet puede reclamar y envía las reclamaciones, cinco ciclos por transacción (diez hasta el 2026-10-06): consulta La dapp. El monto. Por cada acción de un ciclo:
debido = suelo(monto × tenencia durante la ventana ÷ tenencias elegibles) − lo que ya se le pagó al holdernunca más de lo que le queda al ciclo en esa acción. Un envío posterior a una reclamación aumenta el monto, y el holder reclama la diferencia. Lo que deja el redondeo se queda en el contrato.
- Sin vencimiento, sin tope, sin mínimo. Una parte se puede reclamar en cualquier momento, sin fecha límite. No hay tope por wallet ni monto mínimo.
- Las direcciones excluidas no reclaman nada.
- Nunca con cargo a otro ciclo. Desde el 2026-10-05, el contrato del airdrop lleva la
cuenta, acción por acción, de lo que debe y de lo que lo respalda, y solo paga una
acción mientras lo que lo respalda cubra lo que debe. Lo que lo respalda se contabiliza
a partir de las acciones abonadas a los ciclos, nunca se lee del saldo del contrato, que
también contiene entregas aún no abonadas: las acciones que van de camino a otro mercado
nunca pagan una reclamación. Tras una transferencia de emergencia que se llevó parte de
una acción, las reclamaciones de esa acción esperan, en todos los mercados que la
tienen, hasta que la acción vuelva mediante
restore, que cualquiera puede llamar (una simple transferencia no cuenta), o hasta que el owner de StockFun impute la pérdida al ciclo que la sufrió. Mientras nadie haya reclamado esa acción del ciclo, se puede dar de baja cualquier parte de ella, y cada holder pierde la misma proporción; una vez que algunos holders han cobrado, solo se puede dar de baja todo el resto, que pierden los holders que aún no han cobrado. Lo que llega al ciclo después de una baja así se reparte a prorrata entre todos sus holders, como si el monto dado de baja nunca hubiera estado allí. Consulta Modo de emergencia. - Una reclamación paga lo que puede. Desde el 2026-10-05,
claimyclaimManypagan todas las acciones que pueden. Una acción para la que las cuentas se quedan cortas, como más arriba, o cuya transferencia se rechaza, por ejemplo porque su emisor la congeló, se difiere (ClaimDeferred): sigue adeudada, y una reclamación posterior la paga.claimManyomite un ciclo cuya lista de exclusiones nombra a quien llama;claimlo rechaza (Excluded). Una reclamación que no paga nada falla e indica el motivo: cuentas que se quedan cortas para una acción (Underfunded), una transferencia rechazada (TransferRefused) o nada que reclamar (NothingToClaim). Hasta entonces, una sola acción así hacía fallar toda la reclamación, y un ciclo excluido todo elclaimMany. - El costo. Reclamar un ciclo de dos o tres acciones cuesta aproximadamente de 120 000
a 210 000 de gas según lo medido en los tests, que se ejecutan con almacenamiento
caliente. Medido en frío el 2026-10-05, con cinco acciones por ciclo, un primer ciclo
cuesta entre unos 508 000 y 528 000 de gas como transacción completa, y cada ciclo
adicional del mismo
claimMany, entre unos 321 000 y 332 000: entre unos 3,4 y 3,5 millones de gas por diez ciclos, en ese momento el tamaño de los lotes de la pantalla de reclamación, y hasta unos 5,3 millones cuando las acciones de cada ciclo también están frías. Esos son los precios del gas anteriores a la actualización Glamsterdam de Ethereum. Con ella, activa en Sepolia desde el 2026-10-06, un nuevo slot de almacenamiento cuesta unas cinco veces más, y cada acción que paga una reclamación puede escribir tres: en Sepolia, la reclamación de un ciclo de tres acciones costó 1 177 679 de gas al primer reclamante del ciclo y entre 878 713 y 888 051 a los siguientes. Diez ciclos de cinco acciones requerirían entre unos 8 y 14 millones de gas, dentro de los 16 777 216 que EIP-7825 fija por transacción (con Glamsterdam, sobre su gas de ejecución), y los lotes de la pantalla de reclamación son de cinco ciclos.
claimable indica lo que una dirección puede reclamar de un ciclo, acción por acción.
Exclusiones
Cada token tiene su propia lista, fijada por el owner de StockFun: 16 direcciones como
máximo por defecto (setMaxExcluded), ninguna repetida, ninguna nula. La dirección de
burn, 0x…dEaD, siempre está excluida y queda fuera de la lista. Cada cambio crea una
nueva versión de la lista, fechada: una ventana se mide con la lista vigente cuando se
cerró, se abra cuando se abra su ciclo, y un cambio solo se aplica a las ventanas que se
cierran después.
Por defecto solo está excluida la dirección de burn en el token de un mercado. El
PoolManager de Uniswap nunca se registra, así que no necesita entrada. El único
proveedor de liquidez de los pools de StockFun es el lock de liquidez, que no contiene
nada fuera de un lanzamiento. Un pool en otro exchange que tuviera el token sería un
holder registrado ordinario, que el owner puede incluir en la lista.
En $STOCKFUN, la lista incluye además al operador del lanzamiento, que tiene todo el
supply durante los pocos bloques entre la acuñación y el lock. Desde el 2026-10-05, el
script de lanzamiento incluye esa dirección en la lista antes de que el token exista, en
la dirección que tomará el token, y después acuña, de modo que ninguna ventana puede
cerrarse entre la acuñación y la lista: el operador no recibe nada. Si el owner cambia esa
lista antes de que se cierre la primera ventana posterior al lanzamiento, la nueva lista
debe conservar esa dirección.
Acciones apartadas
Un envío para una ventana sin tenencias elegibles queda apartado para el mercado: por ejemplo, acciones enviadas el día en que se lanzó un mercado, para una ventana que terminó antes de que existiera.
Las acciones apartadas van a la primera ventana con tenencias elegibles después de la
última encontrada sin ellas, mire quien mire y cuando sea. openCycle, o un envío, para
la ventana inmediatamente siguiente se las lleva. Si no, assignUnassigned, que
cualquiera puede llamar, revisa las ventanas terminadas en orden, 30 como máximo por
llamada por defecto (setMaxWindowsPerAssign), y abre la primera con tenencias
elegibles, aunque ya haya ciclos posteriores abiertos. Por tanto, los ciclos pueden
abrirse fuera de orden.
Eso se cumple mientras, entretanto, el horario de los ciclos no cambie y el registrador de tenencias del token no se sustituya. Un nuevo horario vuelve a recortar las ventanas aún no abiertas, incluidas las que las acciones apartadas todavía tienen que revisar; un registrador sustituido entretanto no mide ninguna ventana que empezara antes de él, y las acciones esperan a la primera ventana que cubre por completo (ver la regla de operación más abajo).
Un envío que no encuentra él mismo tenencias elegibles, mientras quedan ventanas
anteriores sin revisar, falla: primero assignUnassigned, y luego el envío de nuevo. Una
entrega desde Robinhood Chain queda almacenada en Ethereum y puede volver a ejecutarse:
desde el 2026-10-06, el keeper vuelve a ejecutar él mismo una entrega almacenada, una vez
que su simulación sale adelante, y alerta con el comando para ejecutarla a mano cuando no
puede (ver El keeper). Desde el 2026-10-05, un envío para una ventana que
termina en o antes de la última
revisada, algo que un cambio a ventanas más largas puede provocar, se suma en su lugar a
las acciones apartadas: un mercado que tiene acciones apartadas sigue recibiendo sus
envíos.
Los principios
- Un airdrop de activos, nunca un buyback de participaciones. Nadie devuelve un token al vault. Lo que cuenta es tener el token.
- Premia la tenencia, no el trading.
- Ningún monto prometido. Un airdrop depende del volumen pasado, no de una tasa. Puede ser cero, y nada promete que mañana vaya a haber volumen.
- Sin rescate. Un holder recibe su parte de cada airdrop y nada más: sigue sin existir ningún derecho de retiro sobre el vault.
- El keeper dispara, nunca elige. El reparto lo calcula un contrato a partir de las tenencias que guarda el registrador de tenencias. El keeper elige cuándo envía, nunca cuánto, qué, adónde ni para quién, y no puede asignarse una parte a sí mismo ni asignársela a nadie fuera de ese cálculo.
- Nunca más de lo que contiene un ciclo. Cada ciclo paga como máximo lo que contiene, acción por acción, y ningún holder recibe más que su parte a prorrata, redondeada a la baja.
- Un fallo solo se detiene a sí mismo. Desde el 2026-10-05, una acción que no se puede enviar o pagar, o un mercado que no puede cruzar, espera por separado, y los demás siguen. Consulta Arquitectura.
El modo de emergencia se aplica al contrato del airdrop como a cualquier contrato que
guarde activos del protocolo: la transferencia del owner, inmediata, mueve acciones y deja
las partes como están. Desde el 2026-10-05, los demás ciclos nunca pagan por ella: las
reclamaciones de una acción que la transferencia se llevó difieren esa acción, y pagan las
demás, hasta que la acción vuelva mediante restore o hasta que el owner impute la
pérdida al ciclo que la sufrió (ver más arriba y Modo de emergencia).
El procedimiento del owner nunca deja que las cuentas se queden cortas: primero imputar la
pérdida al ciclo (writeDownCycle, o writeDownUnassigned para las acciones apartadas),
y luego mover la acción. La pausa del contrato del airdrop detiene los envíos, la apertura
de ciclos y la colocación de las acciones apartadas; no mueve nada y nunca detiene una
reclamación. El contrato del airdrop y el registrador de tenencias son upgradeables por el
owner de StockFun, con efecto inmediato, como todos los módulos salvo los tokens y el lock
de liquidez.
De ahí se sigue una regla de operación: el registrador de tenencias de un token recibe un
upgrade en el propio contrato, lo que conserva todo su historial; no se sustituye en un
token en circulación. Desde el 2026-10-05, una sustitución ya no bloquea el trading: el
nuevo registrador parte del supply del token fuera del PoolManager de Uniswap en ese
momento, un registrador que ya registró el token lo rechaza y, desde el segundo bucle de
auditoría de ese día, un token rechaza un registrador ligado a un PoolManager distinto
de aquel donde vive su pool, que contaría el pool como un holder. Desde el tercer bucle,
el nuevo registrador empieza un registro nuevo en el momento del cambio: el contrato del
airdrop no mide ninguna ventana que empezara antes de él, cuyas acciones esperan,
apartadas, a la primera ventana que el nuevo registrador cubre por completo, y el token
notifica el saldo de la dirección de burn en el momento del cambio, de modo que los tokens
quemados siguen excluidos. Pero el nuevo registrador no conoce los saldos de los holders:
aquellos a los que no ha visto moverse se leen como si no hubieran tenido nada hasta su
siguiente movimiento, así que una ventana que abarquen les paga menos, y nadie cobra más.
Los ciclos ya abiertos conservan el registrador que congelaron. Un registrador que haya
que sustituir se cambia justo después del final de una ventana, una vez abiertos los
ciclos de las ventanas ya cerradas. Hasta el 2026-10-05, un registrador nuevo partía de un
supply de cero: cada venta fallaba, y las partes de los ciclos abiertos después quedaban
rotas para siempre.
Como una notificación que falla hace fallar la transferencia, el owner de StockFun
conserva dos palancas inmediatas, de una transacción cada una: un upgrade del registrador
en el propio contrato, o setRecorder(0) en el token, que detiene su registro. Mientras
un token no tiene registrador, el contrato del airdrop no abre ningún ciclo suyo, y las
acciones enviadas para él quedan apartadas hasta que se designe un registrador.
Lo que estaba abierto, y cómo se resolvió
El registro del proyecto, doc/DECISIONS.md, recogía tres puntos abiertos como
TBD 5, 7 y 8. Los tres se resolvieron el 2026-10-04:
- Un envío por parte del keeper (TBD 5). No: solo reclama el holder, para sí mismo, a su cargo.
- Los límites (TBD 7). Ningún tope por wallet, ningún monto mínimo, y las partes nunca vencen.
- Las exclusiones (TBD 8). Una lista por token, fijada por el owner de StockFun, 16 direcciones como máximo por defecto, con la dirección de burn siempre excluida; por defecto, solo la dirección de burn. Ver más arriba.
Lo que queda
- Los adaptadores de acciones. Los adaptadores LayerZero que llevan cada acción a Ethereum, uno por acción: el adaptador de bloqueo en Robinhood Chain y su OFT en Ethereum. No están en el repositorio; los tests usan mocks
- Un despliegue. No hay nada desplegado
El paso del airdrop en el keeper y la pantalla de reclamación de la dapp, que figuraban aquí hasta entonces, se escribieron el 2026-10-05: consulta El keeper y La dapp.
¿Y el Treasury Ratio?
El Treasury Ratio —valor de la tesorería dividido por la capitalización de mercado circulante— era la métrica insignia del producto. Ya no significa nada: la tesorería se vacía en cada distribución. Está obsoleto desde el 2026-09-27.
La métrica que lo sustituye está aún por decidir. La propuesta actual: el valor acumulado de las acciones distribuidas a los holders de un mercado, en dólares. Entre dos distribuciones, la dapp sigue mostrando lo que contiene la tesorería, a la espera del próximo airdrop.
¿Y el buyback del creador?
Eliminado. Del 2026-08-27 al 2026-09-27, el creador de un mercado podía hacer vender acciones de la tesorería para recomprar y quemar su token. El creador ya no tiene ningún poder sobre la tesorería: solo recibe acciones como cualquier holder, si tiene el token.
Con él desaparece el camino de vuelta del bridge, de Robinhood Chain a Ethereum, que solo servía al buyback del creador. El bridge funciona ahora en un solo sentido. Las acciones cruzan en el otro sentido para el airdrop, wrapped, a través de los adaptadores de acciones: un camino distinto, que solo transporta acciones.
El buyback y burn de $STOCKFUN no se ve afectado: el 0,5 % de cada trade que compra
$STOCKFUN y lo envía al burn no toca ninguna tesorería, y se mantiene. Consulta
$STOCKFUN.
La redacción
Redacción propuesta para la dapp, pendiente de validación:
Las acciones que compra la tesorería se distribuyen por airdrop a los holders del token, a prorrata, en cada distribución. Esto no es ni un rendimiento ni una garantía.
El vocabulario prohibido se aplica íntegramente al airdrop. El proyecto nunca escribe passive income, earn stocks, returns ni your stocks are safe in the vault, y nunca presenta como cierto un monto futuro de airdrop.
Acciones tokenizadas emitidas por Robinhood, no disponibles para US persons.