Comprobar si tu pool paga de forma justa: un método de 30 días que puedes ejecutar tú mismo

Tarde o temprano todo minero se hace la misma pregunta. Los ingresos bajaron mientras la dificultad se mantuvo estable, o el panel del pool muestra menos hashrate del que reporta la máquina, o la semana cerró con un 82% de suerte y el chat ya habla de robo.

Parte de esa pregunta tiene respuesta. Otra parte no la tiene, y ninguna cantidad de trabajo con hojas de cálculo va a cambiar eso. Los datos de los bloques, la atribución del coinbase y tus propias transacciones de pago son públicos. Lo que ocurre dentro del pool entre el share que enviaste y tu saldo solo es visible a través de los informes del propio pool.

POOL BTC no es un pool. Comparamos las condiciones de otros y calculamos cuánto le cuestan a un minero, así que lo que sigue es un procedimiento, no una acusación. Aplícalo con tus propios números.

¿Qué puedes verificar realmente y qué nunca se puede verificar?

Puedes verificar por completo cualquier cosa que quede escrita en la blockchain o que midas con tu propio hardware: los bloques que encontró el pool, las comisiones dentro de esos bloques, los montos que llegaron a tu dirección, tu hashrate y tu tasa de rechazo. Todo lo interno del pool, desde la contabilidad de shares hasta la ventana PPLNS, existe para ti solo como un informe.

La conclusión honesta de esa tabla es la siguiente: un minero no puede demostrar fraude. Un minero sí puede demostrarse a sí mismo que no existe ninguna discrepancia, y si existe, localizarla y presentársela al operador en forma de aritmética.

¿Por qué el panel del pool muestra menos hashrate que tu ASIC?

Porque miden cosas distintas. Tu máquina reporta la velocidad de hash instantánea. El pool estima tu hashrate a posteriori, a partir de los shares aceptados en una ventana de promedio. No pueden coincidir por construcción, ya que el pool solo cuenta lo que le llegó y pasó la validación.

Cuatro razones habituales de esa diferencia:

1. Ventana de promedio. Una cifra a cinco minutos oscila decenas de puntos porcentuales, una cifra a 24 horas es suave. Compara siempre día contra día, nunca instantáneo contra diario.
2. Varianza de shares. Encontrar un share es un proceso aleatorio, y las ventanas cortas llevan ruido real.
3. Shares rechazados y obsoletos. Quedan fuera de la contabilidad, así que tu hashrate efectivo queda por debajo del nominal.
4. Latencia de red. Cuanto más lejos esté el servidor stratum y peor sea el enlace, más trabajo llega ya desactualizado.

Algunos pools publican lo que consideran una tasa de rechazo normal. Las cifras publicadas no coinciden entre sí, y no existe un estándar de la industria.

Fuente: páginas de soporte de AntPool, ViaBTC y F2Pool, comprobado el 09.09.2026. Esas páginas devuelven un error 403 ante peticiones automatizadas, así que las citas provienen de fragmentos de búsqueda sobre esas mismas URL y no del cuerpo de la página. Vale la pena abrirlas a mano si la formulación exacta te importa.

La diferencia entre el 0.5% y el 3% tiene un sentido práctico: lo "normal" para tu pool lo define tu propio pool, no la industria. Un umbral de alarma razonable es una brecha persistente superior al 5% en la cifra diaria que tu tasa de rechazo no explica.

¿Cómo se calculan las ganancias esperadas y se comparan con las reales?

Toma tu cuota del hashrate de la red, multiplícala por la recompensa efectiva por bloque y por el número de bloques al día. Una sola fórmula cubre todos los esquemas. Lo que cambia entre esquemas es cuánto se le permite al crédito real desviarse de esa línea: casi nada en FPPS, de forma visible en PPLNS.

\`\`\`

miner share = miner hashrate / network hashrate

reward_eff = 3.125 BTC × (1 + transaction fee share)

BTC per day = miner share × 144 × reward_eff × (1 - pool fee)

\`\`\`

Usando la instantánea de red del 09.09.2026: hashrate de red 943.73 EH/s, cuota de comisiones de transacción en los últimos 4320 bloques 0.669%, por lo que reward_eff = 3.125 × 1.00669 = 3.1459 BTC. La dificultad en esa misma fecha fue de 127,450,789,715,843.1 (mempool.space, consultado el 09.09.2026).

FPPS y PPS+: el crédito diario debe ser plano

En FPPS el pool paga una tarifa fija por cada share enviado, comisiones de transacción incluidas, encuentre o no un bloque ese día. Por eso tu crédito diario debería seguir de cerca la línea calculada. Un lunes que paga la mitad que un martes con el mismo hashrate no es varianza propia del esquema en FPPS, es algo que hay que preguntar.

PPS+ funciona igual en cuanto al subsidio, pero distribuye las comisiones de transacción según los bloques realmente encontrados, así que se espera una variación modesta de un día a otro. En qué se traducen estos esquemas en dólares con el mismo hashrate se calcula en el artículo sobre FPPS, PPS+, PPLNS y SOLO.

PPLNS: comparar solo en una ventana larga

PPLNS te paga una porción de los bloques que el pool realmente encontró. Sin bloque no hay nada que repartir, y la cifra diaria salta de un lado a otro. Las comparaciones tienen sentido en un periodo de al menos un mes, y un trimestre es mejor todavía. Tus primeros días en un pool PPLNS nuevo casi siempre parecen un pago insuficiente, porque la ventana aún no se ha llenado con tus shares.

La comparación en sí:

1. Registra tu hashrate diario del panel del pool para cada día del periodo.
2. Registra el hashrate de la red y la cuota de comisiones de transacción para cada una de esas fechas, no un solo valor para todo el mes. Entre el 29.08 y el 09.09.2026 la red pasó de 896.89 a 943.73 EH/s, un aumento del 5.2%, y todo el que no cambió de hardware perdió exactamente eso.
3. Calcula la expectativa para cada día y súmala.
4. Suma los créditos reales de esos mismos días según el informe del pool.
5. Compara ambos totales y expresa la brecha en porcentaje.
6. Por separado, suma lo que realmente llegó a tu monedero y compáralo con lo que salió del saldo de tu pool. Son dos comprobaciones distintas: el crédito y la entrega.

Prueba tus propios números en la calculadora de minería, comprueba los tiempos de pago por pool en la página de tiempos de pago, y consulta cómo elaboramos nuestras propias estimaciones en la metodología.

¿Qué es la suerte del pool, y una suerte baja demuestra trampa?

La suerte es la relación entre los bloques realmente encontrados y el número esperado según el hashrate del pool en un periodo. Al 100% el pool encontró exactamente lo que predecía la estadística. Es una variable aleatoria, así que una semana al 80% o al 130% es dispersión normal y no es evidencia de nada.

Lo que la mayoría de los debates pasa por alto: en FPPS y PPS la suerte no afecta en absoluto a tu pago. El pool paga una tarifa y absorbe él mismo las malas rachas, que es exactamente lo que se compra con la comisión más alta frente a PPLNS. Pedir un recálculo tras una semana de mala suerte en FPPS no tiene sentido, porque esa semana ya se pagó a la tarifa de la fórmula.

En PPLNS y TIDES la suerte se transmite directamente: sin bloque no hay reparto. Ahí una suerte baja sí reduce de verdad tus ingresos, pero eso es una propiedad del esquema y no una acción del operador. Júzgalo a lo largo de un trimestre, y solo cuando la cuota de bloques del pool en las tablas públicas se mantenga estable.

Tres cosas que vale la pena comprobar antes de sacar conclusiones de una cifra de suerte:

1. La ventana: por ronda, por día, o promedio móvil de 30 días. Ventanas distintas cuentan historias distintas sobre los mismos datos.
2. Si la suerte se calcula por número de bloques o por shares de ronda. La segunda es más estable.
3. Si el número de bloques en el informe del pool coincide con el que le atribuyen los exploradores públicos.

No podemos darte una referencia lista del tipo "así se ve la suerte semanal en un pool importante", y vale la pena saber por qué de entrada. Ninguna de las fuentes que revisamos publica una serie de suerte semanal o mensual real de los últimos doce meses con una metodología declarada. Esto es lo que existe realmente a fecha de 2026-09-11:

1. F2Pool muestra widgets de suerte a 3, 7, 30 y 90 días en su página de estadísticas, y mantiene además un registro aparte de los bloques encontrados con la suerte de cada uno. Son ventanas móviles a fecha de hoy, no un archivo de las semanas del año pasado. El pool explica el método en su centro de ayuda: bloques realmente encontrados dividido por el número teóricamente esperado según el hashrate del pool.
2. ViaBTC explica la misma fórmula en su blog con un único ejemplo resuelto: una suerte semanal del 92,17% el 2024-05-07. Ahí no hay una serie publicada de forma continua, es una ilustración del método.
3. Antpool no mantiene ninguna página pública dedicada a la suerte en sus recursos oficiales.
4. Braiins publica una distribución histórica mes a mes del hashrate entre pools que se remonta a 2012, pero eso es cuota de potencia, no suerte.
5. Rastreadores independientes como soloblocks.io y blocksrace.com calculan la suerte con la misma fórmula en ventanas cortas, de unas pocas horas hasta 30 días. El primero de ellos declara abiertamente que todavía no tiene datos anuales acumulados: el servicio funciona desde marzo de 2026.

La conclusión práctica es sencilla. No compares tu pool con una "norma" de la industria que no es de acceso público, sino con su propia cifra en una ventana larga: mira la suerte a 90 días donde el pool la publique, y cruza el número de bloques con las tablas de exploradores públicos. Precisamente por eso el siguiente apartado trata de bloques y no de suerte.

¿Cómo se confirma que un pool realmente está encontrando bloques?

A través de la transacción coinbase. Todo bloque lleva una, y los pools ponen en ella una etiqueta de texto y la dirección de recompensa. Los exploradores recopilan esas etiquetas en tablas de atribución, por lo que cualquiera puede contar los bloques de un pool determinado sin ningún acceso a su panel.

El procedimiento:

1. Abre la tabla de pools en mempool.space para las ventanas de una semana y un mes.
2. Encuentra tu pool y anota su número de bloques y su cuota.
3. Compara esa cuota con lo que el pool afirma sobre su propio hashrate en su sitio.
4. Toma dos bloques concretos del propio informe del pool y búscalos por altura. El coinbase debería llevar la etiqueta de ese pool.
5. Si el pool nunca aparece en las tablas públicas, pregunta a soporte por qué. "No etiquetamos nuestro coinbase" es una respuesta comprobable. "Información comercialmente sensible" no lo es.

Esta es la distribución según mempool.space el 11.09.2026:

La ventana semanal abarca 1026 bloques, la mensual 4497. Fuente para ambas: API de Mining Pools de mempool.space, consultada el 11.09.2026.

Una advertencia metodológica. La cuota de bloques es un indicador de hashrate, no una medición directa, así que hay que leer las columnas semanal y mensual juntas. Una diferencia de uno o dos puntos entre ellas, como ocurre arriba con SECPOOL y NiceHash, es una varianza normal sobre recuentos pequeños y no un pool ganando o perdiendo máquinas. Quién ensambla realmente el contenido de un bloque, y por qué esa es una cuestión aparte, se trata en el artículo sobre Stratum V2.

¿Adónde van las comisiones de transacción de un bloque en FPPS?

En una implementación correcta de FPPS, esas comisiones entran en tu tarifa. El pool promedia la cuota de comisiones entre los bloques recientes, la suma al subsidio y le resta su propia comisión al total. Esa es toda la diferencia con el PPS puro, donde se te paga solo sobre el subsidio y las comisiones se quedan con el pool.

Ahora mismo el importe es pequeño. Según mempool.space, las comisiones de transacción supusieron el 0.66% de las recompensas de bloque en los últimos 4320 bloques el 08.09.2026 y el 0.669% el 09.09.2026, mientras que una ventana de 144 bloques dio 0.57%. Durante el último mes el rango se sitúa en 0.66-0.73%, un mercado de comisiones tranquilo sin ningún evento tipo Ordinals o Runes.

Distintos agregadores producen números distintos a partir de la misma cadena, y eso es metodología, no error. A principios de septiembre de 2026 las métricas diarias de Glassnode y Newhedge mostraban 0.40-0.56% frente al 0.66-0.70% de mempool.space sobre 4320 bloques. Así que cuando plantees una discrepancia a un pool, indica la fuente, la ventana y la fecha, o estarás discutiendo sobre cifras calculadas con reglas distintas.

Los mercados de comisiones tranquilos no duran para siempre. El 20.04.2024, el día después del halving y del lanzamiento de Runes, las comisiones llegaron al 73.8-75% de los ingresos de los mineros según la metodología, y el 08.05.2023, en el pico de Ordinals, al 40.8-42.59% ese día. En días así, la brecha entre FPPS y PPS deja de ser algo académico, y es un buen momento para releer lo que dice la documentación de tu pool sobre las comisiones de transacción.

Qué comprobar aquí:

1. Qué esquema nombra realmente la documentación: FPPS, PPS+ o PPS. Una palabra de diferencia en el texto, puntos porcentuales de diferencia en el dinero.
2. Si el pool publica la ventana sobre la que promedia la cuota de comisiones.
3. Si el componente de comisión de tu crédito coincide con la cuota de comisión pública para esas fechas, al menos en orden de magnitud.

¿Qué más se descuenta además de la comisión del pool?

Cuatro mecanismos: la comisión de red sobre la transacción de pago, el umbral mínimo de pago, el redondeo en los créditos, y el margen en cualquier conversión. Ninguno de ellos es una trampa, todos están documentados al menos por algunos pools, y juntos explican la mayoría de los casos en que el importe que llega es menor de lo esperado.

Las comisiones fijas de retiro merecen una nota aparte, porque se convierten en un porcentaje que depende del importe. Kryptex App cobra 0.00003 BTC en cadena frente a un mínimo de 0.00025 BTC, lo que supone un 12% del menor retiro posible y un 0.3% en uno de 0.01 BTC. Lightning en el mismo servicio cuesta un 2% con un mínimo de 0.00001 BTC: más barato en términos absolutos, más caro como tasa.

Cuánto tiempo permanece tu dinero en el saldo del operador es aritmética sencilla. Con los parámetros de red del 09.09.2026:

Este es un cálculo de expectativa basado en un hashrate de red de 943.73 EH/s y una recompensa efectiva de 3.1459 BTC, no datos del pool. No incluye la varianza de PPLNS y TIDES.

Para F2Pool y ViaBTC la regla sí existe en el centro de ayuda oficial, y favorece al minero.

F2Pool afirma en su página de ayuda que no cobra comisión de transacción por pagar los ingresos de minería una vez que el saldo supera el umbral mínimo. Ese umbral para BTC es de 0.005 BTC según la propia tabla del pool y es ajustable por el usuario. El caso aparte es un retiro manual por debajo del umbral: está disponible desde el 10% del valor por defecto, es decir, desde 0.0005 BTC, solo se realiza vía Lightning, y ahí la comisión de 0.000001 BTC la paga el minero. El pool detalla la regla contraria para ETHW y ALEO, que no se aplica a bitcoin.

ViaBTC lo expresa de forma aún más clara: el centro de ayuda describe el retiro automático por encima del mínimo como totalmente gratuito, y un aviso en la misma sección dice que el pool sigue asumiendo todo el coste de transacción. El mínimo de retiro automático en BTC es de 0.001 BTC. El único punto sin claridad es el Normal Transfer manual: las preguntas frecuentes oficiales admiten que su comisión fluctúa con la congestión de la red, pero la página no dice quién la paga. No vamos a adivinar en nombre del pool, así que comprueba el importe en la pantalla de retiro antes de confirmar.

Tres enlaces verifican todo esto: el artículo de ayuda de F2Pool sobre las comisiones de pago, la página de ViaBTC sobre cómo configurar el retiro automático y las preguntas frecuentes de ViaBTC sobre depósitos y retiros. Consultado el 2026-09-11.

¿Qué discrepancias son realmente preocupantes?

Las que la varianza no explica y el tiempo no borra. Una mala semana aislada en PPLNS, un déficit diario del 3% en FPPS, una caída de cinco minutos en el hashrate del panel: ruido. Un déficit que persiste durante un mes después de recalcular la expectativa con los parámetros de red correctos para cada fecha: una señal.

Esa última fila merece tomarse en serio por sí sola. Qué le pasa a un saldo cuando un pool cesa por completo se trata por separado en el artículo sobre el cierre de un pool.

La lista de comprobación de 30 días

Esta secuencia cubre todo lo anterior y no necesita nada más que acceso a tus máquinas, tu cuenta del pool y un navegador.

1. Día 0. Registra los datos de partida: modelo y número de equipos, hashrate nominal, esquema de pago, comisión declarada, umbral de pago, dirección de pago. Haz una captura de la página de tarifas en lugar de copiar la cifra. Las páginas cambian sin avisar.
2. Día 0. Configura un registro local de hashrate desde las propias máquinas. Sin eso estarás comparando datos del pool con datos del pool. La supervisión y las alertas mínimas viables se tratan en un artículo aparte.
3. Diario. Anota cuatro cifras: hashrate diario según tus máquinas, hashrate diario según el panel, el crédito del día, la tasa de rechazo.
4. Diario. Registra el hashrate de la red y la cuota de comisiones de transacción de esa misma fecha. Una sola instantánea para todo el mes distorsionará el resultado: la red sumó un 5.2% en once días a finales de agosto de 2026.
5. Semanal. Compara el número de bloques del pool en las tablas públicas con el de su propio informe.
6. Semanal. Comprueba cada pago que llegue en un explorador: importe de la transacción, importe cargado al saldo, comisión de red, y quién la pagó.
7. Día 30. Suma las expectativas diarias y los créditos reales, y expresa la brecha como porcentaje.
8. Día 30. Calcula por separado la diferencia entre lo acreditado y lo que llegó a tu monedero. Todo lo que desaparezca entre esas dos cifras debería explicarse por el umbral, la comisión de red o una conversión.
9. Día 30. Evalúa el porcentaje según tu esquema. En FPPS una brecha mensual superior al 10% necesita una explicación. En PPLNS, amplía la ventana a un trimestre antes de sacar ninguna conclusión.
10. Día 30. Si la brecha sobrevive a todo eso, ve a la siguiente sección en vez de a una sala de chat.

Qué hacer cuando la discrepancia se sostiene

Abre un ticket de soporte hecho de números, fechas y una sola pregunta. No de la frase "me están robando". Un operador que responde a este tipo de solicitud te responderá a ti, y uno que ignora un cálculo escrito de 30 días ya te ha dicho algo.

Qué adjuntar:

1. El periodo de comparación con fechas exactas, más tu login o los ID de tus workers.
2. Una tabla diaria: tu hashrate, hashrate del panel, crédito, tasa de rechazo.
3. El cálculo de la expectativa con la fórmula y la fuente de los parámetros de red para cada fecha.
4. La brecha total en BTC y en porcentaje.
5. La lista de transacciones de pago con hashes e importes.
6. Una pregunta concreta. Por ejemplo: qué explica la brecha entre las ganancias acreditadas y las esperadas en este periodo, a este hashrate, bajo este esquema.

Después lee la respuesta. Un desglose de tus números, una referencia a una regla documentada, o un incidente reconocido con un recálculo son resultados aceptables. Un discurso genérico sobre volatilidad y varianza de la red, sin cifras, en respuesta a una tabla llena de ellas, es una mala señal, especialmente la segunda vez.

Cuándo cambiar de pool es la decisión correcta:

1. La brecha se mantuvo durante 30 días y quedó sin explicar tras dos solicitudes.
2. Los retrasos en los pagos se volvieron sistemáticos.
3. El pool dejó de aparecer en las tablas públicas de bloques, o su cuota diverge enormemente de lo que afirma.
4. Las condiciones cambiaron de forma retroactiva sin previo aviso.

Cambiar cuesta dinero: un par de horas de inactividad, una ventana PPLNS perdida en el pool anterior, y un saldo por debajo del umbral que quizá simplemente se quede ahí. La regla de que un saldo por debajo del umbral se acumula en lugar de caducar está confirmada oficialmente para F2Pool, ViaBTC y Luxor. Para otros pools no encontramos una declaración explícita en ningún sentido, así que trátalo como una pregunta abierta antes de irte. Mantener un pool de respaldo configurado en las ranuras del ASIC convierte el cambio en un trabajo de unos minutos, algo que se trata en el artículo sobre failover. Compara las condiciones antes de mudarte en la tabla comparativa de pools.

Lo que este método no hace

No demuestra fraude ni sustituye a una auditoría. Te dice si existe una brecha entre lo que puedes calcular tú mismo y lo que se te acreditó. Todo lo que viene después es una conversación con un operador, no un caso legal.

Todavía sin confirmar en nuestros propios datos a fecha de 2026-09-11:

1. Las tarifas exactas de comisión en AntPool, Binance Pool, Foundry USA y Braiins. Las páginas oficiales o no cargan, o no publican una cifra, o se contradicen con otras fuentes.
2. Las comisiones de retiro y la regla de "quién paga la comisión de red" en F2Pool y ViaBTC.
3. Las tasas del margen de autoconversión en EMCD y Kryptex.
4. El umbral de pago de Ocean: la cifra de 0.01048576 BTC procede de reseñas secundarias y no se confirmó directamente con documentación oficial.
5. El hashprice exacto en vivo en la fecha de publicación. Leer la cifra directamente del índice de Luxor no funcionó: la página se renderiza mediante script y la caché sirve valores claramente desactualizados. Según reimpresiones fechadas de los datos de Hashrate Index para el 2026-09-05 y el 2026-09-08, el hashprice se mantuvo alrededor de 39 a 40 USD por PH/s al día, es decir, aproximadamente 0.039 a 0.040 USD por TH/s. Una reseña fechada el 2026-09-06 lo sitúa en cambio a mediados de los treinta, algo que no cuadra con las otras tres fuentes. Eso basta como orientación, pero para un cálculo de cierre consulta el valor tú mismo el día en que hagas las cuentas. Como referencia, según las reseñas mensuales publicadas por Luxor, el mínimo de seis meses es de 27.74 USD por PH/s al día el 2026-06-06 y el máximo es de 40.02 USD el 2026-08-27.

La versión breve

Los bloques, las comisiones que contienen, las transacciones de pago y tu propio hashrate son verificables. Lo interno de una ventana PPLNS y la capacidad real de un pool no lo son, y la cuota de bloques del explorador es solo un indicador aproximado de esta última.

Calcula tu expectativa con los parámetros de red de cada fecha en lugar de una instantánea de hace un mes. En FPPS la línea de crédito debería ser plana, en PPLNS júzgalo en un trimestre, y en FPPS la suerte no tiene nada que ver con tu pago.

Busca primero el dinero desaparecido en las deducciones. Los umbrales, las comisiones de red, los mínimos de retiro independientes y los márgenes de conversión explican la mayoría de los casos de "llegó menos de lo esperado". Solo cuando una brecha sobrevive a 30 días y a un recálculo deberías abrir un ticket, y hazlo con una tabla.