Verificar Polygon técnicamente: comprobar whitepaper, código fuente y contratos activos

Resumen

Este artículo muestra en siete pasos cómo verificar técnicamente las afirmaciones centrales sobre el token POL.

La revisión técnica arroja, para el estado analizado, tres conclusiones principales. Primero, la cantidad total inicial de 10.000 millones de POL puede rastrearse directamente en el contrato Token. Segundo, la lógica de emisión en el código actual está implementada de forma determinista y corresponde a una tasa anual de alrededor del 2 % con interés compuesto. Tercero, mediante la comprobación de roles y el historial del Proxy se puede determinar qué versión del contrato ejecuta actualmente esa lógica.

Así, unas afirmaciones generales sobre tokenomics se convierten en una afirmación técnica verificable. El artículo no solo muestra lo que Polygon afirma públicamente, sino también cómo comprobar por cuenta propia si esos datos son consistentes con el código publicado y el Deployment activo.

Objetivo de este artículo

Este artículo describe cómo verificar técnicamente afirmaciones clave en torno al token POL. Se centra en tres preguntas:

1. ¿Qué afirma el whitepaper o la comunicación oficial?
2. ¿Dónde se encuentra la lógica correspondiente en el código fuente?
3. ¿Cómo se puede comprobar que exactamente esa lógica también se ejecuta en los contratos actualmente activos en la Blockchain?

El enfoque es un recorrido de verificación reproducible. Por tanto, no se trata de sentimiento de mercado ni de especulación, sino de cómo contrastar afirmaciones públicas con código visible públicamente y datos On-Chain.

Qué deberías haber verificado al final

Si recorres los pasos siguientes, podrás comprobar por ti mismo, en particular, estos puntos:

• la oferta total inicial de POL,
• la lógica técnica de emisión de POL,
• los contratos implicados para la tesorería comunitaria (Treasury) y el staking de tokens,
• la implementación de emission manager actualmente activa,
• el historial completo de upgrades del proxy de emission manager

Fuentes y herramientas necesarias

Para esta verificación bastan fuentes de acceso libre:

• Whitepaper de POL¹
• Información técnica de POL
• PIP-17: Polygon Ecosystem Token (POL)
• Repositorio del token POL en GitHub
• Token POL en Etherscan
• PIP-26: Council Transparency Report
• PIP-40: Support for Community Treasury Contracts
• Gráficos de PolygonScan

Paso 1: aislar las afirmaciones verificables

El proceso no empieza con código, sino con la comunicación pública de Polygon Labs. Solo cuando está claro qué debe verificarse exactamente, se puede comprobar de forma dirigida.

En POL, las afirmaciones centrales incluyen, entre otras:

1. La emisión inicial es de 10.000 millones de POL.
2. Las emisiones posteriores siguen una tasa predefinida y determinista.
3. La emisión suele describirse como aproximadamente un 2 % anual.
4. Parte de la emisión va a la tesorería comunitaria (Treasury) y al staking de tokens.
5. La gobernanza puede influir en la lógica de emisión mediante upgrades.

Estas afirmaciones se reparten entre el whitepaper, la documentación técnica y textos de gobernanza. Para una verificación técnica, es útil reformularlas como preguntas concretas de comprobación:

• ¿Dónde está definida en código la emisión inicial?
• ¿Qué contrato crea nuevos tokens (Minting)?
• ¿Qué fórmula determina la emisión anual?
• ¿Qué contratos reciben los tokens recién creados?
• ¿Qué contrato está activo actualmente?
• ¿La implementación activa es idéntica al código fuente de GitHub, o al menos consistente?

Paso 2: comprobar la cantidad inicial de POL en el contrato del token

La primera comprobación técnica de base es el propio contrato del token. Para ello, abre el código fuente publicado de POL en GitHub:

• PolygonEcosystemToken.sol en GitHub

Busca allí la instrucción de mint para la emisión inicial. La línea relevante es la 39:

 _mint(migration, 10_000_000_000e18);

Qué significa esto

En el número 10_000_000_000e18, los guiones bajos se usan únicamente para mejorar la legibilidad. El compilador de Solidity los ignora por completo. El sufijo e18 es notación científica y significa “por 10 elevado a 18”; por lo tanto, el punto decimal se desplaza 18 posiciones hacia la derecha. Por ello, el valor corresponde a 10.000.000.000 × 10^18 y, escrito completo, a 10.000.000.000.000.000.000.000.000.000.

Ejemplo: El valor 0.02856915219677089e18, escrito completo, es 28,569,152,196,770,890.

Qué demuestra este paso

Con esto se verifica directamente:

• La cantidad inicial de POL se fijó técnicamente en 10.000 millones de tokens.
• El número no es solo una afirmación de marketing, sino que está codificado de forma fija en el código del Contract.
• El valor inicial para la evolución posterior de la oferta es, por tanto, técnicamente trazable.

Lo que este paso aún no demuestra

Esto no aclara todavía

• cuánto se emite más adelante,
• qué contratos controlan el minting,
• ni si la lógica de emisión actual sigue correspondiendo a la comunicación original.

Paso 3: identificar los contratos de emisión mediante PIP-17

A continuación, hay que aclarar qué contratos son responsables de las emisiones posteriores.

Para ello, el Polygon Improvement Proposal PIP-17 es un buen punto de partida:

• PIP-17 en el foro de Polygon

En este documento se describen los componentes implicados. Son especialmente relevantes:

• el código fuente actual en GitHub
• el contrato Emission Manager actualizable con su implementación DefaultEmissionManager,
• la dirección del contrato para recompensas por staking de tokens (Staking Rewards) 0x5e3ef299fddf15eaa0432e6e66473ace8c13d908,
• la dirección 0x2ff25495d77f380d5F65B95F103181aE8b1cf898 del monedero multifirma de la tesorería comunitaria (community treasury), que según PIP-17 estaba previsto como solución transitoria; la fecha de corte del 24-06-2024 se deriva de la fecha de creación de la dirección de tesorería posterior 0x86380e136A3AaD5677A210Ad02713694c4E6a5b9 en Etherscan. Además, PIP-40 describe explícitamente la migración de la lógica de tesorería a la nueva dirección de community treasury 0x86380e136a3aad5677a210ad02713694c4e6a5b9.

Esto desplaza la verificación desde una comparación general del whitepaper hacia una búsqueda técnica concreta: ahora sabemos qué nombres de contrato y direcciones debemos buscar en Etherscan y GitHub.

Paso 4: inspeccionar el contrato DefaultEmissionManager en el código fuente

Ahora llega la parte más importante de la verificación técnica: la lógica de emisión concreta. Abre en GitHub el contrato DefaultEmissionManager actual:

• DefaultEmissionManager.sol en el repositorio de GitHub

Primero, observa la descripción en la línea 14 del código fuente en GitHub:

 /// @dev The contract allows for a 2% mint per year (compounded). 1% staking layer and 1% treasury
 

Esta línea de comentario es importante porque muestra cómo los propios desarrolladores describen la lógica. Después viene la constante clave en la línea 19:

 uint256 public constant INTEREST_PER_YEAR_LOG2 = 0.02856915219677089e18;
 

Representación de punto fijo

La escala de 0.02856915219677089 por diez elevado a dieciocho (10^18) tiene una explicación sencilla: En la Ethereum Virtual Machine que utiliza Polygon no existen tipos reales de coma flotante (float, double), así que en on-chain solo se calcula con enteros. Por eso, el lenguaje Solidity también admite únicamente enteros y utiliza la representación de punto fijo. El número de posiciones decimales queda fijado: 1e18 = 1 * 10^18.

Dicho de otro modo, en representación de punto fijo, 10,000,000,000e18 significa que la parte anterior a e son diez mil millones de tokens, es decir, la parte entera, y que dieciocho posiciones representan la unidad base del token, “Wei”, por así decirlo la parte fraccionaria en punto fijo de un token:

• 1e18 unidades base = 1 token completo
• 1e17 unidades base = 0,1 token
• 1 unidad base = 1 Wei

Cómo interpretar esta línea

Según el comentario de la línea 14, la constante INTEREST_PER_YEAR_LOG2 de la línea 19 representa un incremento del 2 %. Se refiere al aumento de la oferta circulante inicial de 10_000_000_000e18 POL. Para simplificar, llamaremos x a esa oferta circulante.

Si se quiere aumentar una cantidad x en un dos por ciento, hay que calcular x + x * 0.02.

  // "Porcentaje" = por cada cien
  // Dos por cada cien => 2/100 = 0.02
   x + x * 0.02
= (1 + 0.02) * x
= x * 1.02

Logaritmo en base dos

Además, el comentario de la línea 14 sugiere que la constante INTEREST_PER_YEAR_LOG2 debe ser el resultado de un logaritmo en base 2: log2(p) = INTEREST_PER_YEAR_LOG2.

En la línea 89 se encuentra la prueba de ello en forma de cálculo inverso:

  uint256 supplyFactor = PowUtil.exp2((INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days);

La función PowUtil.exp2(q) calcula dos elevado a q: 2^q. Por tanto, nuestro valor buscado p es p = PowUtil.exp2(q) = PowUtil.exp2( log2(p) )

Así pues, se cumple:

    p = PowUtil.exp2((INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days)
<=> p = 2^ ((INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days);
<=> p = 2^ ((log2(p) * timeElapsed) / 365 days);

Lo que esto significa en la práctica puede comprobarse fácilmente con una calculadora:

  // recordatorio:
  INTEREST_PER_YEAR_LOG2 = 0.02856915219677089e18 // ~ 0.02857

  // compruébalo con la calculadora
  2 ^ 0.02857 => 1.02 => ~2.0 %  // => p=1.02, es decir, factor para un aumento del 2 %

  // comprobación con la función inversa
  log2(1.02)= 0.02857 // = INTEREST_PER_YEAR_LOG2

Este cálculo demuestra que la constante INTEREST_PER_YEAR_LOG2 representa un incremento del dos por ciento.

Interés proporcional en el tiempo

Hasta ahora, sin embargo, habíamos pasado por alto que q en el término 2^q es en realidad q = (INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days. Aquí hay que tener en cuenta que en Solidity 365 days es un literal de unidad temporal y se evalúa en segundos.

    (log2(p) * timeElapsed) / 365 days   // 365 días = 31,536,000 segundos
<=>  log2(p) * timeElapsed  / 31,536,000
<=>  0.02857 * (timeElapsed / 31,536,000)

// 0.02857 = interés anual del 2 %
// 1 año = 365 días = 31,536,000 segundos
// 0.02857 * (timeElapsed / 365 days) => parte proporcional del interés por segundo

Aquí, un interés del 2 % anual se prorratea en segundos.

Por qué esto importa

Este paso permite demostrar con precisión:

• La constante matemática del código actual en GitHub representa efectivamente un 2 % en esta versión.
• Si alguien interpreta mal este valor, puede llegar a una tasa de inflación incorrecta.

Paso 4.1: reconstruir la cantidad de tokens recién creados

En el contrato DefaultEmissionManager, en la línea 88 se indica:

   function inflatedSupplyAfter(uint256 timeElapsed) public view returns (uint256 supply) {
      uint256 supplyFactor = PowUtil.exp2((INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days);
      supply = (supplyFactor * START_SUPPLY_1_4_0) / 1e18;
   }
 

En la línea 68 se pasa el valor block.timestamp - startTimestamp, que establece el parámetro de función timeElapsed.

block.timestamp usa segundos y da la marca temporal de creación del bloque actual en la blockchain de Ethereum. Es el tiempo de ejecución actual de la función inflatedSupplyAfter().

La variable startTimestamp se fijó en el punto de inicio, es decir, la inicialización o reinicialización de la oferta inicial del token POL. Véanse las dos funciones en las líneas 44 y 49.

La fórmula que establece la variable supplyFactor modela una tasa del 2 % con interés compuesto. Para ello usa una fracción continua de tiempo en segundos por año.

En resumen, la variable supply aumenta aproximadamente un 2,0 % cada año desde el inicio de POL. Esto se puede reproducir fácilmente con una hoja de cálculo:

La columna C muestra la evolución anual de la oferta circulante con base en la fórmula del contrato Default&shyEmission&shyManager. La columna D muestra, para comparar, un cálculo de interés ordinario basado en el valor del año anterior.

Qué demuestra este paso

Las emisiones anuales de POL se determinan mediante una fórmula determinista basada en la constante identificada en el paso anterior. En concreto, esto demuestra:

• La cantidad de tokens recién creados no es arbitraria, sino que se deriva matemáticamente del tiempo transcurrido desde el inicio.
• La fórmula implementa exactamente el interés compuesto: cada año, el crecimiento se aplica no solo a la oferta inicial, sino también a la oferta ya incrementada.
• La emisión de alrededor del 2 % anual se puede reproducir y verificar de forma independiente con una hoja de cálculo sencilla usando la fórmula.
• El instante de inicio (startTimestamp) está fijado en el contrato, de modo que la curva de emisión puede rastrearse desde un punto inicial definido.

Paso 4.2: comprobar en código la distribución de los tokens recién creados

En el mismo contrato, puede rastrearse hacia dónde fluyen los tokens emitidos. Son relevantes las líneas 74 y 75:

 uint256 treasuryAmt = amountToMint / 2;
 uint256 stakeManagerAmt = amountToMint - treasuryAmt;
 

Amt corresponde a la palabra inglesa “Amount”, es decir, “cantidad”. La cantidad de tokens recién acuñados (amountToMint) se divide en dos mitades iguales.

Unas líneas después, en las líneas 82 y 84:

 _token.safeTransfer(treasury, treasuryAmt);

 _token.safeTransfer(stakeManager, stakeManagerAmt);
 

Los importes se envían a la dirección treasury y a la dirección stakeManager. Ambas direcciones se fijan durante el despliegue en la blockchain y después son inmutables.

 constructor(address migration_, address stakeManager_, address treasury_) {
   if (migration_ == address(0) || stakeManager_ == address(0) || treasury_ == address(0)) revert InvalidAddress();
   DEPLOYER = msg.sender;
   migration = IPolygonMigration(migration_);
   stakeManager = stakeManager_;
   treasury = treasury_;

   // so that the implementation contract cannot be initialized
   _disableInitializers();
 }
  

Qué muestra este paso

La cantidad acuñada se divide en:

• parte para treasury
• parte para staking

Esto es relevante porque en whitepapers o textos de blog suele destacarse solo la tasa de emisión aproximada, mientras que el impacto económico solo se entiende cuando queda claro quién recibe los nuevos tokens.

Paso 5: comprobar en la blockchain las versiones del contrato emission manager

En PIP-17 se indica que el emission manager es actualizable. Por ello, debemos identificar la versión activa actualmente. Si abres en Etherscan un contrato DefaultEmissionManager visible más antiguo, verás que las constantes allí difieren claramente del código fuente actual de GitHub:

Véase la línea 19

 uint256 public constant INTEREST_PER_YEAR_LOG2 = 0.04264433740849372e18;
 

y las líneas 65 y 66

 uint256 treasuryAmt = amountToMint / 3;
 uint256 stakeManagerAmt = amountToMint - treasuryAmt;
 

Un solo contrato no es suficiente cuando el sistema es actualizable. El siguiente paso, por tanto, es comprobar qué versiones existen en total.

Para esto resulta útil la búsqueda de contratos en Etherscan:

• Buscar más contratos DefaultEmissionManager

No obstante, no está claro si contratos con este nombre se usaron exclusivamente para POL. Además, aquí solo interesan los contratos que realmente estuvieron activos. Etherscan ofrece una solución directa: a través del contrato proxy se pueden inspeccionar todas las implementaciones que estuvieron activas alguna vez, en orden cronológico y sin herramientas adicionales:

• Contratos históricos del proxy de emission manager

Objetivo de este paso

Quieres averiguar:

• cuántas versiones de contrato existen,
• qué versiones han estado activas detrás del proxy,
• qué versión está activa actualmente.

Esto es crucial en sistemas actualizables. Un estado limpio en GitHub aporta poco si en on-chain lleva tiempo activa otra implementación distinta.

Fuente: captura de pantalla del 31-03-2026 - etherscan.io

Procedimiento

1. Abre la vista Historical Proxy de la dirección proxy 0xbC9f74b3b14f460a6c47dCdDFd17411cBc7b6c53.
2. Identifica la entrada activada más recientemente como la implementación que se está ejecutando actualmente.
3. Abre cada dirección de implementación y comprueba el código fuente verificado en su página Contract.

Qué verificar allí

• notas de versión
• parámetros de emisión (INTEREST_PER_YEAR_LOG2)
• reparto entre treasury y staking
• valores iniciales y lógica de inicialización

Qué permite este paso

Puedes ver de un vistazo qué versión está activa y qué versiones estuvieron en producción anteriormente. Esto hace transparente el historial de upgrades y robusta la interpretación de la lógica de emisión.

Paso 6: verificar si el emission manager tiene el rol requerido

El propio contrato proxy tampoco está activo automáticamente. Por eso, debes comprobar si la dirección proxy del emission manager tiene realmente derechos de emisión para POL.

Para ello, ve a la vista de lectura del contrato del token POL:

• Read Contract del token POL

Procedimiento

1. Busca la entrada 4. EMISSION_ROLE.
2. Copia el valor bytes32 de ese rol, por ejemplo:
   • 0x573321b8a13c75b2702bc4b0ad9afaae98bf6985285411964a564e68bf6da1c9
3. Abre la función 14. asRole.
4. Introduce el valor copiado como role.
5. Introduce el proxy de emission manager como account (address):
   • 0xbC9f74b3b14f460a6c47dCdDFd17411cBc7b6c53
6. Ejecuta la consulta haciendo clic en Query.

Nota: La dirección proxy del emission manager 0xbC9f74b3b14f460a6c47dCdDFd17411cBc7b6c53 se tomó del Council Transparency Report: PIP-26.

Resultado esperado

Si la respuesta es true, esto demuestra técnicamente que esa dirección proxy tiene el rol de emisión.

Por qué este paso es indispensable

Con esto no solo se identifica un contrato, sino una ruta de contrato activa. Solo entonces la verificación de la lógica de emisión en ejecución se vuelve robusta.

Paso 7: clasificar el historial de contratos y la oferta circulante

Una mirada a la oferta circulante muestra por qué el total ya rondaba los 10.617.468.716 POL el 31-03-2026: la regla actual del 2 % no se aplicó durante todo el período, sino que es el resultado de varias versiones de contrato.

La vista Historical Proxy documenta la secuencia de implementaciones activas:

1. Contrato del 25-10-2023, 0x2126E6952C3af75C9D4CF21f63F509195C79ce44

   • 3 % de emisión anual (con interés compuesto), de los cuales 2 % para staking de tokens y 1 % para la tesorería comunitaria.

2. Contrato del 06-07-2024, 0x5e875267f65537768435c3c6c81cd313a570b422

   • 2,5 % de emisión anual (con interés compuesto), de los cuales 1,5 % para staking de tokens y 1 % para la tesorería comunitaria.

3. Contrato del 04-09-2024, 0x152442D77E9fB9C210953d583Cbb2da88027fCB9

   • 2,5 % de emisión anual (con interés compuesto), de los cuales 1,5 % para staking de tokens y 1 % para la tesorería comunitaria.

4. Contrato del 09-07-2025, 0x282FD46E108E40A45e4CE425bA75f80245e6C2E0

   • 2 % de emisión anual (con interés compuesto), de los cuales 1 % para staking de tokens y 1 % para la tesorería comunitaria.

Recalculado

La cantidad de emisión inicial es de 10.000.000.000 POL. Si las emisiones se calculan paso a paso según cada versión activa de contrato y se ignoran efectos de gas, el resultado es una oferta circulante máxima teórica.

En Etherscan puedes ver la oferta circulante actual. El 31-03-2026 era Circulating Supply: 10.617.468.716,00 POL.

Por tanto, la oferta circulante real es ligeramente inferior, entre otras razones porque partes de tokens se queman mediante comisiones de transacción. En el momento de la verificación, la diferencia era de unos 84.322 POL.

Nota: Con la hoja de cálculo y dependiendo de la tasa de emisión, se pueden hacer proyecciones de cómo podría evolucionar la oferta de Polygon en el futuro. Estos valores son extrapolaciones basadas en un modelo y pueden diferir ligeramente según el uso real de gas y efectos de redondeo. Para finales de 2026, esperamos menos de 10.777.152.308 POL.

Resultado

Realizamos esta verificación el 31-03-2026.

1. En ese momento, el contrato emission manager activo era
   • 0x282fd46e108e40a45e4ce425ba75f80245e6c2e0.
2. La dirección almacenada en el contrato para recompensas de staking de tokens era
   • 0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908.
3. La dirección registrada de la tesorería comunitaria es un contrato proxy ERC-1967. Etherscan muestra la dirección de despliegue previa con el nametag “Agglayer: Deployer”; esto es un indicio de su vinculación con el entorno de Polygon, pero no una prueba de propiedad por sí sola. El proxy es la community treasury establecida de forma permanente y sustituyó al monedero multifirma temporal:
   • 0x32bdc6a4e8c654df65503cbb0edc82b4ce9158e6 Nametag de Etherscan: Agglayer: Deployer
   • 0x86380e136A3AaD5677A210Ad02713694c4E6a5b9 contrato proxy ERC-1967
   • 0x2ff25495d77f380d5F65B95F103181aE8b1cf898 monedero multifirma

Nuestra comparación mostró:

1. INTEREST_PER_YEAR_LOG2 = 0.02856915219677089e18
2. START_SUPPLY = 10_000_000_000e18;
3. uint256 treasuryAmt = amountToMint / 2; uint256 stakeManagerAmt = amountToMint - treasuryAmt;
4. version() = "1.4.0"
5. Arg[1]: stakeManager_ (address): 0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908
6. Arg[2]: treasury_ (address): 0x86380e136A3AaD5677A210Ad02713694c4E6a5b9
7. Circulating Supply
   • 10.617.468.716,00 POL - el 31-03-2026
   • 10.777.152.308,67 POL - esperado para el 31-12-2026

Conclusión

Con esta guía de 7 pasos, la verificación técnica de las afirmaciones centrales sobre POL puede realizarse de forma sistemática. El punto clave es este: no te quedas en formulaciones generales de whitepapers, entradas de blog o contribuciones de gobernanza, sino que sigues cada afirmación relevante hasta el contrato realmente activo en la blockchain.

La verificación muestra que tres preguntas centrales pueden responderse con claridad:

• La emisión inicial de 10.000 millones de POL puede rastrearse directamente en el contrato del token.
• La emisión posterior sigue una lógica determinista en el código actual, de alrededor del 2 % anual con interés compuesto.
• Mediante el historial del proxy y la asignación de roles, se puede verificar qué versión del contrato ejecuta actualmente esa lógica.

La comparación entre GitHub, Etherscan y las fuentes de gobernanza es indispensable. Un repositorio por sí solo no basta cuando los contratos son actualizables. Solo cuando está claro qué implementación estuvo o está activa y qué derechos tiene el proxy, la lectura de código se convierte en una verificación técnica robusta.

Para POL, esto produce una imagen coherente en el momento de la verificación: las afirmaciones centrales comunicadas públicamente sobre oferta inicial, lógica de emisión y distribución entre tesorería comunitaria y staking de tokens pueden reproducirse técnicamente en todos los puntos esenciales.

Al mismo tiempo, el método demuestra su fortaleza más allá de este caso concreto. No solo es útil para Polygon, sino en general para proyectos de tokens con contratos actualizables, mecanismos de emisión y estructuras de gobernanza. Quien procede de esta forma no verifica narrativas, sino la realidad técnica efectivamente operativa.