Documento técnico de Polygon
Abstract
Abstract
This paper proposes POL, the native token of the revised Polygon protocol architecture, commonly referred to as Polygon 2.0. As the successor of MATIC, POL is envisioned to become an instrumental tool for coordination and growth of the Polygon ecosystem and the main driver of the vision of Polygon as the Value Layer for the Internet. We start by analyzing relevant work, identifying opportunities and threats and, based on that, we establish POL design goals. We propose design, utility and tokenomics of POL that achieve all the design goals. We describe the concept of the Staking Layer, a one-of-a-kind, POL-powered chain coordinator, capable of supporting a practically unlimited number of Polygon chains with arbitrary features and configurations. We believe the introduction of the Staking Layer and the wider Polygon 2.0 architecture can establish Polygon as the third most important and impactful breakthrough in Web3 (the first two being Bitcoin and Ethereum), given the magnitude of innovation and adoption it can facilitate. We introduce the Community Treasury, an in-protocol, community-governed fund designed to provide ongoing economic support for further development and growth of the Polygon ecosystem. We describe the process of migration from MATIC to POL. To analyze the proposed design, we define an economic simulation model and run simulations to confirm the hypothesis of the model, derived from the aforementioned design goals. Based on everything above, we conclude that POL is a novel, next generation asset that provides a solid foundation for the ambitious vision of the Value Layer.
Resumen
Este artículo propone POL, el token nativo de la arquitectura del protocolo Polygon revisada, comúnmente conocido como Polygon 2.0. Como sucesor de MATIC, se prevé que POL se convierta en una herramienta instrumental para la coordinación y el crecimiento del ecosistema Polygon y el principal impulsor de la visión de Polygon como la capa de valor para Internet. Comenzamos analizando el trabajo relevante, identificando oportunidades y amenazas y, en base a eso, Establecer objetivos de diseño de POL. Proponemos diseño, utilidad y tokenómica de POL que logre todos los objetivos del diseño. Describimos el concepto de Stake Layer, un coordinador de cadena único en su tipo impulsado por POL, capaz de soportar un número prácticamente ilimitado de cadenas Polygon con características arbitrarias y configuraciones. Creemos que la introducción de la capa de participación y la versión más amplia Polygon 2.0 La arquitectura puede establecer Polygon como el tercer avance más importante e impactante en Web3 (siendo los dos primeros Bitcoin y Ethereum), dada la magnitud de la innovación y adopción que puede facilitar. Presentamos el Tesoro Comunitario, un fondo gobernado por la comunidad dentro de un protocolo diseñado para proporcionar apoyo económico continuo para un mayor desarrollo y crecimiento de Polygon ecosistema. Describimos el proceso de migración de MATIC a POL. Para analizar el diseño propuesto, definimos un modelo de simulación económica y ejecutamos simulaciones. confirmar la hipótesis del modelo, derivada de los objetivos de diseño antes mencionados. Con base en todo lo anterior, concluimos que POL es un activo novedoso de próxima generación que proporciona una base sólida para la ambiciosa visión de la capa de valor.
Vision
Vision
The vision behind Polygon as the Value Layer of the Internet is to usher a world in which value can be created and exchanged freely and globally, similarly to how we create and exchange information today. A world which enables new – fairer, more inclusive and more efficient – forms of human organizations and governance. We strongly believe that realizing this vision can significantly advance our society. In order to make this ambitious vision a reality, Polygon’s infrastructure must improve. Specifically, it must become exponentially more scalable, without sacrificing security and user experience. To address this, a reimagined protocol architecture is being introduced as part of the Polygon 2.0 effort. This radical redesign turns Polygon into a network of ZK-powered L2 chains, unified via a novel cross-chain coordination protocol. The network can support a practically unlimited number of chains, and cross-chain interactions can happen seamlessly and instantly without additional security or trust assumptions. This design fully delivers on the aforementioned requirement – exponential scalability without sacrificing security and user experience. Figure 1. Polygon protocol architecture To coordinate, secure and grow this powerful network, an advanced, well-designed protocol economy and mechanism design are necessary. This inspired the creation of POL.
Visión
La visión detrás de Polygon como capa de valor de Internet es marcar el comienzo de un mundo en el que el valor pueden crearse e intercambiarse libre y globalmente, de manera similar a cómo creamos e intercambiamos información hoy. Un mundo que permita nuevas formas (más justas, más inclusivas y más eficientes) de las organizaciones humanas y la gobernanza. Creemos firmemente que hacer realidad esta visión puede hacer avanzar significativamente nuestra sociedad. Para hacer realidad esta ambiciosa visión, la infraestructura de Polygon debe mejorar. En concreto, debe volverse exponencialmente más escalable, sin sacrificar la seguridad y el usuario. experiencia. Para solucionar este problema, se está introduciendo una arquitectura de protocolo reinventada como parte del Polygon Esfuerzo 2.0. Este rediseño radical convierte a Polygon en una red de cadenas L2 impulsadas por ZK, unificadas a través de un novedoso protocolo de coordinación entre cadenas. La red puede soportar una cantidad prácticamente ilimitada número de cadenas, y las interacciones entre cadenas pueden ocurrir de manera fluida e instantánea sin supuestos adicionales de seguridad o confianza. Este diseño cumple plenamente con lo mencionado anteriormente. requisito: escalabilidad exponencial sin sacrificar la seguridad y la experiencia del usuario. Figura 1. Arquitectura del protocolo Polygon Para coordinar, proteger y hacer crecer esta poderosa red, se necesita un protocolo avanzado y bien diseñado. La economía y el diseño del mecanismo son necesarios. Esto inspiró la creación de POL.
Relevant work
Relevant work
In this chapter we outline relevant native token design examples, the utility they assign to the token as well as notable advantages and disadvantages. 2.1 Bitcoin (BTC) BTC is the native token of the Bitcoin protocol, and it’s the first prominent native token implementation. The utility of BTC is twofold: ● Miner rewards: The protocol emits BTC and distributes it to protocol validators, aka miners; ● Transaction fees: Users pay fees in BTC for every transaction, which prevents spam and provides additional incentives for miners. One advantage of the BTC design is a deterministic, i.e. predictable supply. Normally, tokens with deterministic supply are more attractive to holders and can capture value better than those with non-deterministic supply. We consider BTC a legacy token design and we argue its disadvantages are multifold: ● It is an unproductive asset, it does not give its holders any meaningful role in the protocol nor the incentives to performs such a role; ● It does not leverage the opportunity to require stake in the native token for protocol validators and instead requires them to stake, i.e. invest external resources (mining equipment and electricity), thus making protocol less resilient and self-sustainable; ● It gradually reduces emission for mining rewards until it reaches zero, which introduces sustainability and security concerns (it is unclear if the security can be maintained once the emission rate becomes low or reaches zero); ● It does not introduce any type of economic support to the ecosystem; ● It does not give any governance rights to holders, although it can be argued that Layer 1 protocols such as Bitcoin should not utilize tokens for governance. 2.2 Ethereum (ETH) ETH is the native token of the Ethereum protocol and ecosystem. With its innovative design, it established the next generation of native protocol tokens.
The utility of ETH is multifold: ● Validators staking: Ethereum’s PoS (Proof-of-Stake) protocol requires validators to stake ETH in order to join the validator pool; ● Validator rewards: The protocol emits ETH and distributes it to protocol validators; ● Transaction fees: Users pay fees in ETH for every transaction, which prevents spam and provides additional incentives for validators. The design of ETH has multiple advantages: ● It is a productive asset, its holders can participate in securing the network and they receive incentives for doing that; ● It disincentivizes malicious behavior of validators via in-protocol slashing, i.e. destroying tokens of malicious validators; ● It does not introduce security and sustainability concerns, given that it doesn’t have supply cap like BTC; ● It provides economic support to the ecosystem via a predetermined portion of the initial supply allocated to the stewarding foundation. One potential disadvantage of the ETH design is that it does not have fully predictable supply, given that token emission for validator rewards increases as more tokens get staked. However, this is successfully countered by the built-in mechanism that burns1 a portion of every transaction fee, thus countering the impact of token emission for validator rewards. Another disadvantage is that the aforementioned economic support can not last indefinitely; the initial token allocation to the stewarding foundation will eventually get depleted. Lastly, it does not assign any governance right to token holders, although, as mentioned above, it can be argued that Layer 1 protocols should not utilize tokens for governance. 2.3 Cosmos (ATOM) ATOM is the native token of the Cosmos Hub, the intended central blockchain of the Cosmos multi-chain ecosystem. It has multifold utility, but only within Cosmos Hub: ● Validators staking; ● Validator rewards; ● Transaction fees; 1 https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md
● Governance. The design of ATOM has the following advantages: ● It is a productive asset, its holders can participate in securing Cosmos Hub and receive incentives for doing that; ● It does not introduce security and sustainability concerns, given that it doesn’t have supply cap; ● It provides economic support to the ecosystem via a predetermined allocation to the stewarding foundation; ● It gives its holders governance rights via a comprehensive governance model. The disadvantages of ATOM design: ● It only has utility within Cosmos Hub; it is not used to run and secure other chains in the ecosystem, although there are initiatives to enable this; ● It facilitates a token-only governance model, which excludes other relevant stakeholders of the ecosystem (developers, prominent contributors, applications etc.) from decision making; ● Economic support it facilitates can not last indefinitely, since the token treasury will eventually get depleted. 2.4 Polkadot (DOT) DOT is the native token of the Polkadot multi-chain ecosystem. It has the same utility as ATOM, but generally across the whole Polkadot ecosystem: ● Validators staking; ● Validator rewards; ● Transaction fees; ● Governance. The design of DOT has the following advantages: ● It is a productive asset; ● It does not introduce security and sustainability concerns, given that it doesn’t have supply cap; ● It provides economic support to the ecosystem via a predetermined allocation to the stewarding foundation; ● It gives its holders governance rights via a comprehensive governance model;
● It provides security for the whole ecosystem, i.e. all participating blockchains. The disadvantages are: ● It mandates the usage of DOT as the validator staking token for all participating chains, thus reducing architectural options for developers of Polkadot chains; ● It introduces a significant level of friction for developers of Polkadot blockchains who are required to bid and lock significant amounts of DOT in order for their chains to become part of the ecosystem; ● It facilitates a token-only governance model, which excludes other relevant stakeholders of the ecosystem from decision making; ● Economic support it facilitates can not last indefinitely, since the token treasury will eventually get depleted. 2.5 Aave (Aave) AAVE is the native token of Aave, an on-chain token lending platform. Given that AAVE is not a protocol but an application token, we do not analyze its design, advantages and disadvantages. The relevance of AAVE for POL design is twofold: ● AAVE is the successor of LEND, the initial native token of Aave; the Aave community executed a successful and beneficial migration from LEND to AAVE; ● AAVE provides its holders governance rights via a comprehensive governance model.
Trabajo relevante
En este capítulo describimos ejemplos de diseño nativo token relevantes, la utilidad que asignan al token así como ventajas y desventajas notables. 2.1 Bitcoin (BTC) BTC es el token nativo del protocolo Bitcoin y es el primer token nativo destacado implementación. La utilidad de BTC es doble: ● Recompensas de minero: el protocolo emite BTC y lo distribuye al protocolo validators, también conocido como mineros; ● Tarifas de transacción: los usuarios pagan tarifas en BTC por cada transacción, lo que evita el spam y proporciona incentivos adicionales para los mineros. Una ventaja del diseño BTC es un suministro determinista, es decir, predecible. Normalmente, tokens con oferta determinista son más atractivos para los tenedores y pueden capturar valor mejor que aquellos con oferta no determinista. Consideramos que BTC es un diseño heredado token y argumentamos que sus desventajas son múltiples: ● Es un activo improductivo, no otorga a sus poseedores ningún papel significativo en el protocolo. ni los incentivos para desempeñar tal papel; ● No aprovecha la oportunidad de exigir participación en el token nativo para el protocolo. validators y en su lugar les exige apostar, es decir, invertir recursos externos (minería equipos y electricidad), lo que hace que el protocolo sea menos resiliente y autosostenible; ● Reduce gradualmente las emisiones de recompensas mineras hasta llegar a cero, lo que introduce preocupaciones de sostenibilidad y seguridad (no está claro si la seguridad se puede mantener una vez la tasa de emisión se vuelve baja o llega a cero); ● No introduce ningún tipo de apoyo económico al ecosistema; ● No otorga ningún derecho de gobernanza a los titulares, aunque se puede argumentar que Layer 1 protocolos como Bitcoin no deben utilizar tokens para la gobernanza. 2.2 Ethereum (ETH) ETH es el token nativo del protocolo y ecosistema Ethereum. Con su diseño innovador, estableció la próxima generación de protocolo nativo tokens.
La utilidad de ETH es múltiple: ● Validadores staking: El protocolo PoS (Prueba de participación) de Ethereum requiere que validators participen ETH para unirse al grupo validator; ● Recompensas del validador: el protocolo emite ETH y lo distribuye al protocolo validators; ● Tarifas de transacción: los usuarios pagan tarifas en ETH por cada transacción, lo que evita el spam y proporciona incentivos adicionales para validators. El diseño de ETH tiene múltiples ventajas: ● Es un activo productivo, sus poseedores pueden participar en la seguridad de la red y recibir incentivos por hacerlo; ● Desincentiva el comportamiento malicioso de validators mediante la reducción dentro del protocolo, es decir, la destrucción tokens de validators maliciosos; ● No introduce preocupaciones de seguridad y sostenibilidad, dado que no tiene límite de suministro como BTC; ● Proporciona apoyo económico al ecosistema a través de una porción predeterminada del capital inicial. suministro asignado a la fundación administradora. Una posible desventaja del diseño de ETH es que no tiene un suministro totalmente predecible, dado que la emisión de token para recompensas de validator aumenta a medida que se apuestan más token. Sin embargo, Esto se contrarresta con éxito mediante el mecanismo incorporado que quema1 una parte de cada tarifa de transacción, contrarrestando así el impacto de la emisión de token para las recompensas validator. otro La desventaja es que el mencionado apoyo económico no puede durar indefinidamente; la inicial La asignación token a la fundación administradora eventualmente se agotará. Por último, no asignar cualquier derecho de gobernanza a los titulares de token, aunque, como se mencionó anteriormente, se puede argumentar que los protocolos Layer 1 no deben utilizar tokens para la gobernanza. 2.3 Cosmos (ÁTOMO) ATOM es el token nativo del Cosmos Hub, el blockchain central previsto del Cosmos ecosistema multicadena. Tiene múltiples utilidades, pero solo dentro del Cosmos Hub: ● Validadores staking; ● Recompensas del validador; ● Tarifas de transacción; 1 https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md● Gobernanza. El diseño de ATOM tiene las siguientes ventajas: ● Es un activo productivo, sus poseedores pueden participar en la obtención de Cosmos Hub y recibir incentivos para hacerlo; ● No introduce preocupaciones de seguridad y sostenibilidad, dado que no tiene límite de suministro; ● Proporciona apoyo económico al ecosistema a través de una asignación predeterminada al fundación administradora; ● Otorga a sus titulares derechos de gobernanza a través de un modelo de gobernanza integral. Las desventajas del diseño ATOM: ● Sólo tiene utilidad dentro del Cosmos Hub; no se utiliza para correr y asegurar otras cadenas en el ecosistema, aunque existen iniciativas para permitirlo; ● Facilita un modelo de gobernanza exclusivo de token, que excluye a otras partes interesadas relevantes. del ecosistema (desarrolladores, contribuyentes destacados, aplicaciones, etc.) a partir de la decisión hacer; ● El apoyo económico que facilita no puede durar indefinidamente, ya que el tesoro token eventualmente se agota. 2.4 Polkadot (PUNTO) DOT es el token nativo del ecosistema multicadena Polkadot. Tiene la misma utilidad que ATOM, pero generalmente en todo el ecosistema Polkadot: ● Validadores staking; ● Recompensas del validador; ● Tarifas de transacción; ● Gobernanza. El diseño del DOT tiene las siguientes ventajas: ● Es un activo productivo; ● No introduce preocupaciones de seguridad y sostenibilidad, dado que no tiene límite de suministro; ● Proporciona apoyo económico al ecosistema a través de una asignación predeterminada al fundación administradora; ● Otorga a sus titulares derechos de gobernanza a través de un modelo de gobernanza integral;
● Proporciona seguridad para todo el ecosistema, es decir, todos los blockchain participantes. Las desventajas son: ● Exige el uso de DOT como validator staking token para todas las cadenas participantes. reduciendo así las opciones arquitectónicas para los desarrolladores de cadenas Polkadot; ● Introduce un nivel significativo de fricción para los desarrolladores de Polkadot blockchains que están obligados a ofertar y bloquear cantidades significativas de DOT para que sus cadenas se conviertan en parte del ecosistema; ● Facilita un modelo de gobernanza exclusivo de token, que excluye a otras partes interesadas relevantes. del ecosistema desde la toma de decisiones; ● El apoyo económico que facilita no puede durar indefinidamente, ya que el tesoro token eventualmente se agota. 2.5 Aave (Aave) AAVE es el token nativo de Aave, una plataforma de préstamos en cadena token. Dado que AAVE no es un protocolo sino una aplicación token, no analizamos su diseño, ventajas y desventajas. La relevancia de AAVE para el diseño POL es doble: ● AAVE es el sucesor de LEND, el token nativo inicial de Aave; la comunidad aave ejecutó una migración exitosa y beneficiosa de LEND a AAVE; ● AAVE proporciona a sus titulares derechos de gobernanza a través de un modelo de gobernanza integral.
Design goals
Design goals
Based on the analysis of relevant work, several major opportunities for POL to benefit the Polygon ecosystem were identified. These opportunities are brought forward here as POL design goals. 1. Ecosystem security. POL should help establish a highly decentralized pool of validators that can run and secure any Polygon chain. Validators should be incentivized to join and stay in the validator pool and help secure as many chains as possible, and at the same time disincentivized to do anything malicious. 2. Infinite scalability. POL should support exponential growth of the Polygon ecosystem and eventual “hyperblochainization” of the world. Primarily, it should enable the validator pool to scale to support thousands of Polygon chains.
3. Ecosystem support. Being a global network in the making, Polygon will require ongoing economic support for further development and growth. POL should help establish a self-sustaining funding mechanism for those activities. This funding “vehicle” should be governed by the Polygon community. 4. No friction. Blockchain networks often require both users and developers to hold, stake or consume their native tokens in order to use the network. This causes friction and degrades user and developer experience. POL should be designed in a way that does not introduce any such friction. 5. Community ownership. Polygon is envisioned as a decentralized network governed by its community. Assigning governance rights to POL holders can enable creation of effective governance models in which decision makers are directly incentivized to support proposals that are in the best interest of the Polygon ecosystem.
Objetivos de diseño
Según el análisis del trabajo relevante, varias oportunidades importantes para que POL beneficie a la Se identificaron Polygon ecosistema. Estas oportunidades se presentan aquí como POLÍTICA objetivos de diseño. 1. Seguridad del ecosistema. POL debería ayudar a establecer un grupo altamente descentralizado de validators que pueden ejecutar y asegurar cualquier cadena Polygon. Se debe incentivar a los validadores para unirse y permanecer en el grupo validator y ayudar a asegurar tantas cadenas como sea posible, y en al mismo tiempo, desincentivados a hacer algo malicioso. 2. Escalabilidad infinita. POL debería apoyar el crecimiento exponencial del ecosistema Polygon y una eventual “hiperblochainización” del mundo. Principalmente, debería habilitar el validator grupo a escala para admitir miles de cadenas Polygon.
3. Apoyo al ecosistema. Al ser una red global en ciernes, Polygon requerirá apoyo económico para un mayor desarrollo y crecimiento. POL debería ayudar a establecer un mecanismo de financiación autosostenible para esas actividades. Este “vehículo” de financiación debería ser gobernado por la comunidad Polygon. 4. Sin fricción. Las redes blockchain a menudo requieren que tanto los usuarios como los desarrolladores mantengan y apoyen o consumir sus tokens nativos para poder utilizar la red. Esto causa fricción y degrada la experiencia del usuario y del desarrollador. POL debe diseñarse de manera que no no introducir ninguna fricción de este tipo. 5. Propiedad comunitaria. Polygon se concibe como una red descentralizada gobernada por su comunidad. Asignar derechos de gobernanza a los titulares de POL puede permitir la creación de modelos de gobernanza eficaces en los que los tomadores de decisiones sean directamente incentivados a apoyar propuestas que sean lo mejor para el ecosistema Polygon.
Utility
Utility
POL is the native token of Polygon, and as such represents the major tool for coordination and incentivization of the whole Polygon ecosystem. It has multi-fold utility, namely: ● Validator staking; ● Validator rewards; ● Community ownership, i.e. governance. 4.1 Validator staking Polygon validators are required to stake POL in order to join the validator pool. Validator staking increases security of the ecosystem by: ● Preventing Sybil attacks; ● Aligning validators with the success of the ecosystem; ● Enabling slashing, i.e. punishment of malicious validators. By staking POL and joining the validator pool, validators become eligible to subscribe to validate any Polygon chain. Validation and its benefits for validators are further explained in § 6.3.
4.2 Validator rewards Decentralization and size of the validator pool is critically important for security, resilience and neutrality of the whole Polygon ecosystem. To incentivize validator onboarding and retention, predefined amounts of POL should be continuously distributed to Polygon validators as protocol rewards. Protocol rewards should be distributed to validators proportionally to the amount of POL they stake. POL emission is described in § 5.2. Protocol rewards provide base incentives for validators and establish a level playing field for the whole validator pool. On top of it, validators can then secure additional incentives by validating individual Polygon chains. Additional validator incentives are described in § 6.3. 4.3 Governance To facilitate efficient, community-run governance of important aspects of the Polygon ecosystem, POL should be technically enabled to hold governance rights, i.e. be utilized in governance frameworks. Describing the Polygon governance framework is out of the scope of this paper.
Utilidad
POL es el token nativo de Polygon y, como tal, representa la herramienta principal para la coordinación y incentivación de todo el ecosistema Polygon. Tiene múltiples utilidades, a saber: ● Validador staking; ● Recompensas del validador; ● Propiedad comunitaria, es decir, gobernanza. 4.1 Validador staking Polygon validators deben apostar POL para poder unirse al grupo validator. El validador staking aumenta la seguridad del ecosistema al: ● Prevención de ataques de Sybil; ● Alinear validators con el éxito del ecosistema; ● Habilitar la reducción, es decir, el castigo de validators maliciosos. Al staking POL y al unirse al grupo validator, validator son elegibles para suscribirse para validar cualquier cadena Polygon. La validación y sus beneficios para validators se explican con más detalle en el § 6.3.
4.2 Recompensas del validador La descentralización y el tamaño del grupo validator son de vital importancia para la seguridad, la resiliencia y neutralidad de todo el ecosistema Polygon. Para incentivar la incorporación y retención de validator, cantidades predefinidas de POL deben distribuirse continuamente a Polygon validators como protocolo recompensas. Las recompensas del protocolo deben distribuirse a validators proporcionalmente a la cantidad de POL que apuestan. La emisión de POL se describe en el § 5.2. Las recompensas del protocolo proporcionan incentivos básicos para validators y establecen igualdad de condiciones para los todo el grupo validator. Además, los validators pueden obtener incentivos adicionales validando cadenas individuales Polygon. Los incentivos validator adicionales se describen en el § 6.3. 4.3 Gobernanza a facilitar eficiente, administrado por la comunidad gobernanza de aspectos importantes del Polygon ecosistema, POL debería estar técnicamente habilitado para tener derechos de gobernanza, es decir, ser utilizado en marcos de gobernanza. Describir el marco de gobernanza Polygon está fuera del alcance de este documento.
Supply
Supply
Here we cover the initial supply and the emission policy of POL, and describe the rationale behind both. 5.1 Initial supply The initial supply of POL is 10 billion tokens. The entirety of the initial supply should be dedicated for migration, i.e. token swap from MATIC to POL. This migration would need to take place in order for POL to succeed MATIC as the native token of the Polygon ecosystem, and it is discussed in § 8. The initial supply of POL matches the supply of MATIC, which should make the migration quite straightforward. Once the migration is complete, the distribution of POL would essentially match the current distribution of MATIC. MATIC has already gone through an extensive process of token distribution which has resulted in more than 600,000 holder addresses2, and likely even more 2 Source: https://etherscan.io/token/0x7d1afa7b718fb893db30a3abc0cfc608aacfebb0#balances
actual holders, given that centralized crypto exchanges’ and DeFi protocols’ addresses represent multiple users. This implies that POL would be widely distributed from day one, which is instrumental for overall decentralization and resilience of the ecosystem. 5.2 Emission POL is emitted at a predefined, deterministic rate for two purposes: 1. Validator rewards. To incentivize validator onboarding and retention, POL should be continuously emitted at a predetermined rate and distributed to validators as the base, protocol reward. We propose a yearly emission rate of 1% of the POL supply for this purpose. The emission rate would not be possible to change for the initial 10 years, and after that period the community can decide to decrease it in an arbitrary way via the governance framework. The emission rate can never be increased beyond 1%. 2. Ecosystem support. To provide ongoing support for further development and growth of the Polygon ecosystem, we propose to introduce the Community Treasury, a community-governed ecosystem fund, described in § 7. We propose a yearly emission rate of 1% of the POL supply for this purpose. Just like the emission for validator rewards, this emission rate can be decreased after 10 years via a governance framework, and it can never be increased beyond 1%. Figure 2. Possible POL emission rate scenarios The rationale for the proposed emission and the emission rates is that the Polygon ecosystem and Web3 in general will need time to mature and reach mainstream adoption. Based on the
historical Internet and computing platforms adoption cycles, the maturity phase could be realistically expected to happen in about 10-15 years. During that period, the ecosystem will need economic support. Once the Polygon ecosystem and Web3 reach maturity, transaction fees and other incentives secured by validating Polygon chains (described in § 6.3) should alone generate sufficient returns for Polygon validators. Once that happens, the community can decide to intervene and reduce or completely discontinue the emission for validator rewards, without impacting security and decentralization of the ecosystem. Similarly, the community can then decide to decrease or discontinue the emission for the Community Treasury as well, given that the ecosystem will not need significant economic support anymore. Obviously, the adoption cycle of Web3 might look slightly or completely different. In case it turns out that reaching mainstream adoption takes more time and the ecosystem still needs support after 10 years, the community can choose not to intervene and the emission will continue to happen for as long as required. We consider the proposed emission policy optimal, as it achieves the equilibrium between: ● Sufficient ecosystem support. Sufficient, future-proof support to the Polygon ecosystem is critically important for security and success of Polygon. To validate the hypothesis that the proposed emission rates are indeed sufficient, we developed an economic model, ran simulations and presented results in § 9. ● Security via scarcity. Scarcity of native tokens is instrumentally important for blockchain networks; high token dilution can dramatically affect security. To estimate POL scarcity, we can compare the proposed emission rate to the emission rate of BTC, which is currently at ≈1.8%3, and has been significantly higher in the past. Also, although gradually declining, BTC emission is guaranteed to happen for more than another century, whilst POL emission could potentially be reduced or discontinued even after 10 years. Given that (i) Bitcoin is considered a highly scarce asset, and (ii) total POL emission rate is comparable to (and potentially more strict than) BTC, we conclude that POL is sufficiently scarce, i.e. its emission does not introduce protocol security concerns. 3 Source: https://charts.woobull.com/bitcoin-inflation/
Lastly, it is important to note that the emission policy we propose has a high degree of predictability. The predetermined emission schedule makes POL supply predictable in the long term, even if the community decides to intervene. As explained, the community can only decrease the rates, thus effectively complementing the predetermined emission policy and potentially increasing scarcity of POL. Predictability and scarcity attract protocol and market participants and provide a sense of reliability. As the Polygon ecosystem continues to grow, this should contribute to establishing POL as an attractive and reliable digital asset, which subsequently could further ignite adoption and reliability, thus creating a virtuous circle.
Suministro
Aquí cubrimos el suministro inicial y la política de emisiones de POL, y describimos el fundamento. detrás de ambos. 5.1 Suministro inicial El suministro inicial de POL es de 10 mil millones de tokens. La totalidad del suministro inicial debe ser dedicado para la migración, es decir, token intercambio de MATIC a POL. Esta migración tendría que tomar lugar para que POL suceda a MATIC como el token nativo del ecosistema Polygon, y se analiza en el § 8. El suministro inicial de POL coincide con el suministro de MATIC, lo que debería hacer que la migración sea bastante sencillo. Una vez que se complete la migración, la distribución de POL esencialmente coincidirá con la actual. distribución de MATIC. MATIC ya ha pasado por un extenso proceso de token distribución que ha resultado en más de 600.000 direcciones de titulares2, y probablemente incluso más 2 Fuente: https://etherscan.io/token/0x7d1afa7b718fb893db30a3abc0cfc608aacfebb0#balances
titulares reales, dado que las direcciones de los intercambios criptográficos centralizados y los protocolos DeFi representar a varios usuarios. Esto implica que POL se distribuiría ampliamente desde el primer día, lo que es fundamental para la descentralización general y la resiliencia del ecosistema. 5.2 Emisión POL se emite a una velocidad determinista predefinida con dos propósitos: 1. Recompensas del validador. Para incentivar la incorporación y retención de validator, POL debe ser emitido continuamente a una velocidad predeterminada y distribuido a validators como base, recompensa del protocolo. Proponemos una tasa de emisión anual del 1% del suministro de POL para este propósito. La tasa de emisión no sería posible cambiar durante los 10 años iniciales, y transcurrido ese plazo la comunidad puede decidir disminuirlo de forma arbitraria a través de la marco de gobernanza. La tasa de emisión nunca podrá aumentarse más allá del 1%. 2. Apoyo al ecosistema. Proporcionar apoyo continuo para un mayor desarrollo y crecimiento de el Polygon ecosistema, nosotros proponer a introducir el Comunidad Hacienda, un fondo ecosistémico gobernado por la comunidad, descrito en el § 7. Proponemos una emisión anual tasa del 1% del suministro de POL para este fin. Igual que la emisión de validator recompensas, esta tasa de emisión se puede reducir después de 10 años a través de una gobernanza y nunca podrá incrementarse más allá del 1%. Figura 2. Posibles escenarios de tasas de emisión de POL El fundamento de la emisión propuesta y las tasas de emisión es que el ecosistema Polygon y Web3 en general necesitarán tiempo para madurar y alcanzar una adopción generalizada. Basado en elciclos históricos de adopción de plataformas informáticas e Internet, la fase de madurez podría ser realistamente Se espera que esto suceda en unos 10 a 15 años. Durante ese período, el ecosistema Necesita apoyo económico. Una vez que el ecosistema Polygon y Web3 alcancen la madurez, las tarifas de transacción y otros incentivos asegurado mediante la validación de cadenas Polygon (descritas en el § 6.3) debería por sí sola generar suficiente devoluciones por Polygon validators. Una vez que eso suceda, la comunidad puede decidir intervenir y reducir o suspender por completo la emisión de recompensas validator, sin afectar la seguridad y descentralización del ecosistema. De manera similar, la comunidad puede entonces decidir disminuir o suspender también la emisión para el Tesoro Comunitario, dado que el ecosistema no ya no necesitamos un apoyo económico significativo. Obviamente, el ciclo de adopción de Web3 podría verse ligeramente o completamente diferente. En caso de que resulte Señaló que alcanzar la adopción generalizada lleva más tiempo y el ecosistema aún necesita apoyo. Después de 10 años, la comunidad puede optar por no intervenir y la emisión seguirá aumentando. suceder durante el tiempo que sea necesario. Consideramos óptima la política de emisiones propuesta, ya que logra el equilibrio entre: ● suficiente ecosistema apoyo. suficiente, preparado para el futuro apoyo a el Polygon El ecosistema es de vital importancia para la seguridad y el éxito de Polygon. Para validar el hipótesis de que las tasas de emisión propuestas son realmente suficientes, desarrollamos modelo económico, realizó simulaciones y presentó los resultados en el § 9. ● Seguridad vía escasez. La escasez de tokens nativos es fundamental para blockchain redes; una dilución alta de token puede afectar drásticamente la seguridad. para estimar Escasez de POL, podemos comparar la tasa de emisión propuesta con la tasa de emisión de BTC, que actualmente es ≈1,8%3, y ha sido significativamente mayor en el pasado. Además, aunque disminuyendo gradualmente, se garantiza que la emisión de BTC se producirá durante más de un año siglo, mientras que las emisiones de POL podrían potencialmente reducirse o suspenderse incluso después de 10 años. Dado que (i) Bitcoin se considera un activo muy escaso, y (ii) el POL total La tasa de emisión es comparable (y potencialmente más estricta) a BTC, concluimos que POL es suficientemente escaso, es decir, su emisión no introduce problemas de seguridad del protocolo. 3 Fuente: https://charts.woobull.com/bitcoin-inflation/
Por último, es importante señalar que la política de emisiones que proponemos tiene un alto grado de previsibilidad. El calendario de emisiones predeterminado hace que el suministro de POL sea predecible a largo plazo. plazo, incluso si la comunidad decide intervenir. Como se explicó, la comunidad sólo puede disminuir las tarifas, complementando así de manera efectiva la política de emisiones predeterminada y escasez potencialmente creciente de POL. La previsibilidad y la escasez atraen el protocolo y el mercado participantes y proporcionar una sensación de confiabilidad. A medida que el ecosistema Polygon continúa creciendo, este debería contribuir a establecer POL como un activo digital atractivo y confiable, que posteriormente podría impulsar aún más la adopción y la confiabilidad, creando así un círculo virtuoso.
Staking Layer
Staking Layer
Realizing the vision of the Value Layer of the Internet will eventually require the Polygon network to host billions of users and millions of Web3 applications. To enable this vast level of activity, hundreds or thousands of Polygon chains will be running in parallel, secured by tens or hundreds of thousands of validators. In order to coordinate all Polygon chains and validators, the redesigned Polygon protocol architecture introduces the Staking Layer. The Staking Layer is a one-of-a-kind programmable multi-chain coordinator protocol. By orchestrating all Polygon validators and chains, it enables: ● Unlimited scalability of the ecosystem; ● Simple, automated access to dedicated Web3 infrastructure to any Web3 project. The Web3 industry was started by Bitcoin, the first successful blockchain with a single application – digital currency. As new applications and use cases were being proposed, they were normally launching their own blockchains, which was slow and complex. This was addressed by the second major breakthrough of Web3 – Ethereum, a programmable blockchain that can support any application or use case. Despite being a huge paradigm shift, the main limitation of Ethereum is that it is not able to scale to support mainstream adoption. To mitigate this limitation, the Ethereum community turned to Layer 2 chains – blockchain architectures that offer higher scalability without sacrificing security. With the introduction of Staking Layer, Polygon becomes capable of supporting a practically unlimited number of Layer 2 chains, each fully programmable both on the application and the configuration level. We believe this can be the third most important breakthrough since the commencement of Web3, given the magnitude of innovation and adoption it enables.
Describing and specifying the Staking Layer in detail is out of the scope of this paper. Instead, and in order to get better understanding of this POL-powered layer and its potential, we provide an overview of its following aspects: ● Design and implementation; ● Polygon chains management; ● Validator management. 6.1 Design and implementation As mentioned above, the Staking Layer is a programmable multi-chain coordinator. It manages two main logical components: 1. Validator registry: Maintains the up-to-date registry of validators, with their corresponding POL stakes and chains they are subscribed to; 2. Chain registry: Maintains the up-to-date registry of Polygon chains, with their corresponding configurations. The main feature the Staking Layer requires is full programmability; it allows it to support and coordinate: ● Arbitrary configurations of Polygon chains; ● All validator-related operations; ● Arbitrary supporting operations and applications, e.g. staking derivatives. The optimal way to achieve programmability is by utilizing EVM (Ethereum Virtual Machine), since it provides a number of benefits: ● Turing-completeness; ● Maturity of the EVM, higher level languages (e.g. Solidity) and tooling; ● Developer base etc. Practically, this means that the Staking Layer will be implemented as a set of EVM smart contracts. These smart contracts can be deployed on any EVM blockchain, likely on Ethereum or Polygon zkEVM rollup, given that both offer a high level of security. 6.2 Polygon chains management The Staking Layer can support a practically unlimited number of Polygon chains, each with arbitrary features and configuration, and provide them the required level of decentralization.
The main service that the Staking Layer provides to Polygon chains is the management of their validator requirements and validator sets established according to those requirements. Validator requirements are specified in a config smart contract that every Polygon chain deploys in order to get initiated. This smart contract can define arbitrary validator requirements, including but not limited to: ● Maximal validator number: Specifies the maximum number of validators the chain accepts in its validator set. ● Minimal validator number: The minimal number of validators required to initiate the chain. ● Slashable offenses: On-chain attributable validation offenses that cause slashing of the stake; ● Validator criteria: The only common criteria for all validators in the Staking Hub is a stake in POL. Arbitrary additional criteria can be specified, such as authorization by a third party, additional stake in other tokens (e.g. native tokens of individual Polygon chains) etc. In addition to the ability to configure validator requirements, Polygon chains can arbitrarily configure all other parameters and features of their architecture. These are not defined on the Staking Layer level, but instead in the client code of Polygon chains. Some notable parameters and features are: ● Native token: Chains can create their native tokens which can be used for various purposes, e.g. transaction fees, user incentivization etc. ● Fee management: Chains can decide how to manage transaction fees. Normally, transaction fees would be passed to validators in their entirety, but other distribution models are possible, e.g. burning a portion of fees and passing the remaining portion to validators. ● Additional rewards: All Polygon validators receive base protocol rewards (as described in § 4.2) and normally transaction fees from Polygon chains they validate. In order to attract more validators, Polygon chain can offer additional rewards on top of these. These rewards will likely often be in native tokens of those chains. ● Block time and size: It is possible to configure the frequency and size, i.e. gas limit of blocks. ● Checkpoint time: Validator sets provide fast, local finality for Polygon chains. In addition to this, all Polygon chains periodically generate and submit zero-knowledge proofs to
Ethereum, thus leveraging its high security. The frequency of these checkpoints can be configured (e.g. every 5 minutes). ● Data availability: The data availability model can also be specified. Chains can decide to leverage Ethereum (rollup model) or their own validator sets or other external data availability service (validium model). With the proposed framework, launching a new Polygon chain practically boils down to writing and deploying the aforementioned config smart contract. Once the contract gets deployed to the Staking Layer, validators can start subscribing to it. When the minimal required number of validators is reached, the chain gets launched. We believe that this simple way of configuring and launching chains can usher a new era of innovation and adoption. The game-changing design decision of Ethereum was to not try to predict what applications and use cases developers will want to build. Instead, it offered a Turing-complete programmable environment that can support any application or use case. With the Staking Layer, Polygon is taking the same approach for launching new chains – it supports practically any chain design, in a programmable manner and without scaling limitations. 6.3 Validator management The Staking Layer can support a practically unlimited number of validators. It manages validators throughout their whole lifecycle and enables them to secure different types of incentives for performing useful work. There are four possible phases, i.e. statuses, in the validator lifecycle: 1. Activation: Validators get initiated as part of the validator pool by depositing POL into the staking contract on the Staking Layer. Once initiated, validators become eligible to receive base protocol rewards (described in § 4.2). 2. Subscription: Once initiated, validators are allowed to subscribe to validate any Polygon chain. 3. Validation: If a validator meets all the criteria of the Polygon chain it subscribed to, it becomes a member of that chain’s validator set. Validators can validate multiple chains, and their POL stake is acknowledged on each of those chains. If a validator gets slashed for a predefined slashable offense on one of the chains, its POL balance gets updated and reflected on all chains it validates. The validation and subscription phases can
overlap; a single validator can be in the subscription phase on one Polygon chain and in the validation phase on another. 4. Retirement: Validators can leave the validator pool at any point. Once the retirement is initiated, a predefined waiting period commences, allowing for potential pending slashing. After the waiting period, validators are able to withdraw their POL stake from the deposit contract. In return for validating Polygon chains, validators can establish at least three incentive streams: 1. Protocol rewards: As described above, every active Polygon validator is receiving base protocol rewards. The total POL emission for validator rewards (described in § 5.2), is distributed to active validators proportionally to their POL stake. 2. Transaction fees: Validators are allowed to validate any number of Polygon chains. In return, these chains will normally award the entirety or a portion of transaction fees to validators. 3. Additional rewards: As mentioned above, some Polygon chains can choose to introduce additional rewards to attract more validators. These rewards can be in any token, including but not limited to POL, stablecoins or native tokens of those Polygon chains. As we describe validator incentives, it is worth noting that the concept of validation in Polygon is broader than the usual, narrow definition. This further improves the value proposition of the validator role – in addition to validating multiple chains, validators can also perform multiple roles on a single chain. The most common roles will likely be: ● Validation in the narrow sense: Accepting user transactions, determining their validity and generating blocks; ● Proving: Producing zero-knowledge proofs of transaction validity; ● Data availability: Providing guarantees that transaction data is published and publicly available.
Capa de replanteo
Hacer realidad la visión de la capa de valor de Internet eventualmente requerirá la red Polygon para albergar miles de millones de usuarios y millones de aplicaciones Web3. Para permitir este vasto nivel de actividad, cientos o miles de cadenas Polygon correrán en paralelo, aseguradas por decenas o cientos de miles de validators. Para coordinar todas las cadenas Polygon y validators, La arquitectura del protocolo Polygon rediseñada presenta la capa de participación. La capa de participación es un protocolo coordinador de múltiples cadenas programable único en su tipo. Por Al orquestar todos los Polygon validators y cadenas, permite: ● Escalabilidad ilimitada del ecosistema; ● Acceso simple y automatizado a la infraestructura Web3 dedicada a cualquier proyecto Web3. La industria Web3 fue iniciada por Bitcoin, el primer blockchain exitoso con un solo aplicación – moneda digital. A medida que se proponían nuevas aplicaciones y casos de uso, normalmente lanzaban sus propios blockchains, lo cual era lento y complejo. Esto fue abordado por el segundo gran avance de Web3: Ethereum, un blockchain programable que pueda soportar cualquier aplicación o caso de uso. A pesar de ser un gran cambio de paradigma, el principal La limitación de Ethereum es que no puede escalar para respaldar la adopción generalizada. para mitigar esta limitación, la comunidad Ethereum recurrió a Layer 2 cadenas – blockchain arquitecturas que Ofrecer una mayor escalabilidad sin sacrificar la seguridad. Con la introducción de Stake Layer, Polygon se vuelve capaz de soportar un número prácticamente ilimitado de Layer 2 cadenas, cada una Totalmente programable tanto a nivel de aplicación como de configuración. Creemos que esto puede ser el tercer avance más importante desde el inicio de Web3, dada la magnitud de innovación y adopción que permite.
Describir y especificar la capa de replanteo en detalle está fuera del alcance de este documento. En cambio, y para comprender mejor esta capa impulsada por POL y su potencial, proporcionamos una visión general de sus siguientes aspectos: ● Diseño e implementación; ● Polygon gestión de cadenas; ● Gestión de validadores. 6.1 Diseño e implementación Como se mencionó anteriormente, la capa de participación es un coordinador de cadenas múltiples programable. se las arregla dos componentes lógicos principales: 1. Validador registro: Mantiene el actualizado registro de validators, con su correspondientes participaciones y cadenas POL a las que están suscritos; 2. cadena registro: Mantiene el registro actualizado de las cadenas Polygon, con sus configuraciones correspondientes. La característica principal que requiere la capa de replanteo es la capacidad de programación total; le permite soportar y coordinar: ● Configuraciones arbitrarias de cadenas Polygon; ● Todas las operaciones relacionadas con validator; ● Operaciones y aplicaciones de soporte arbitrarias, p.e. staking derivados. La forma óptima de lograr programabilidad es utilizando EVM (Ethereum Máquina virtual), ya que proporciona una serie de beneficios: ● integridad de Turing; ● Madurez del EVM, lenguajes de nivel superior (por ejemplo, Solidity) y herramientas; ● Base de desarrolladores, etc. En la práctica, esto significa que la capa de participación se implementará como un conjunto de EVM inteligentes. contratos. Estos smart contract se pueden implementar en cualquier EVM blockchain, probablemente en Ethereum o Polygon zkEVM rollup, dado que ambos ofrecen un alto nivel de seguridad. 6.2 Polygon gestión de cadenas La capa de replanteo puede soportar un número prácticamente ilimitado de Polygon cadenas, cada una con funciones y configuraciones arbitrarias y proporcionarles el nivel requerido de descentralización.El principal servicio que brinda Stake Layer a las cadenas Polygon es la gestión de sus validator requisitos y validator conjuntos establecidos según dichos requisitos. Los requisitos del validador se especifican en una configuración smart contract que implementa cada cadena Polygon para iniciarse. Este smart contract puede definir requisitos validator arbitrarios, incluidos pero no limitado a: ● Número máximo de validator: especifica el número máximo de validators de la cadena. acepta en su conjunto validator. ● Número mínimo de validator: el número mínimo de validator necesarios para iniciar el cadena. ● Delitos reducibles: delitos de validación atribuibles en cadena que causan reducción del estaca; ● Criterios del validador: el único criterio común para todos los validators en Stake Hub es una participación en POL. Se pueden especificar criterios adicionales arbitrarios, como la autorización por parte de un tercero. parte, participación adicional en otros tokens (por ejemplo, tokens nativos de cadenas individuales Polygon) etc. Además de la capacidad de configurar los requisitos validator, las cadenas Polygon pueden configurar todos los demás parámetros y características de su arquitectura. Estos no están definidos en el Nivel de capa de replanteo, sino en el código de cliente de las cadenas Polygon. Algunos parámetros notables y las características son: ● Nativo token: Las cadenas pueden crear sus token nativos que se pueden usar para varios propósitos, p.e. tarifas de transacción, incentivos al usuario, etc. ● Gestión de tarifas: las cadenas pueden decidir cómo gestionar las tarifas de transacción. Normalmente, las tarifas de transacción se pasarían a validators en su totalidad, pero otras distribuciones Son posibles modelos, p.e. quemar una parte de las tarifas y pasar la parte restante a validators. ● Recompensas adicionales: todos los Polygon validator reciben recompensas del protocolo base (como se describe en § 4.2) y normalmente las tarifas de transacción de las cadenas Polygon que validan. Para atraer más validators, la cadena Polygon puede ofrecer recompensas adicionales además de estas. estos Es probable que las recompensas a menudo estén en tokens nativos de esas cadenas. ● Tiempo y tamaño del bloque: Es posible configurar la frecuencia y el tamaño, es decir, el límite de gas de bloques. ● Tiempo de punto de control: los conjuntos de validadores proporcionan una finalidad local rápida para las cadenas Polygon. Además Además, todas las cadenas Polygon generan y envían periódicamente pruebas de conocimiento cero aEthereum, aprovechando así su alta seguridad. La frecuencia de estos puntos de control puede ser configurado (por ejemplo, cada 5 minutos). ● Disponibilidad de datos: También se puede especificar el modelo de disponibilidad de datos. Las cadenas pueden decidir aprovechar Ethereum (modelo rollup) o sus propios conjuntos validator u otros datos externos Servicio de disponibilidad (modelo validum). Con el marco propuesto, lanzar una nueva cadena Polygon prácticamente se reduce a escribir e implementar la configuración antes mencionada smart contract. Una vez que el contrato se implementa en el Stake Layer, validators pueden comenzar a suscribirse a ella. Cuando el número mínimo requerido de Se alcanza validators, se lanza la cadena. Creemos que esta forma sencilla de configurar y lanzar cadenas puede marcar el comienzo de una nueva era de innovación y adopción. La decisión de diseño revolucionaria de Ethereum fue no intentar predecir qué aplicaciones y casos de uso querrán crear los desarrolladores. En cambio, ofreció una Entorno programable completo de Turing que puede admitir cualquier aplicación o caso de uso. con la capa de participación, Polygon está adoptando el mismo enfoque para lanzar nuevas cadenas: admite prácticamente cualquier diseño de cadena, de forma programable y sin limitaciones de escala. 6.3 Gestión del validador La capa de replanteo puede admitir un número prácticamente ilimitado de validators. se las arregla validators durante todo su ciclo de vida y les permite proteger diferentes tipos de incentivos para realizar un trabajo útil. Hay cuatro fases posibles, es decir, estados, en el ciclo de vida validator: 1. Activación: los validadores se inician como parte del grupo validator depositando POL en el staking contrato en la capa de replanteo. Una vez iniciado, validators se vuelven elegibles para recibir recompensas del protocolo base (descritas en el § 4.2). 2. Suscripción: una vez iniciada, validators pueden suscribirse para validar cualquier Polygon cadena. 3. Validación: si un validator cumple con todos los criterios de la cadena Polygon a la que se suscribió, se convierte en miembro del conjunto validator de esa cadena. Los validadores pueden validar múltiples cadenas, y su participación en POL es reconocida en cada una de esas cadenas. Si un validator es cortado para una ofensa cortable predefinida en una de las cadenas, su saldo POL se actualiza y reflejado en todas las cadenas que valida. Las fases de validación y suscripción pueden
superposición; un solo validator puede estar en fase de suscripción en una cadena Polygon y en la fase de validación en otro. 4. Retiro: los validadores pueden abandonar el grupo validator en cualquier momento. Una vez que la jubilación es iniciado, comienza un período de espera predefinido, lo que permite posibles pendientes cortando. Después del período de espera, validators pueden retirar su apuesta POL de el contrato de depósito. A cambio de validar Polygon cadenas, validators pueden establecer al menos tres flujos de incentivos: 1. Recompensas del protocolo: como se describió anteriormente, cada Polygon validator activo recibe base recompensas del protocolo. La emisión total de POL para las recompensas validator (descritas en el § 5.2) es distribuido a los validator activos proporcionalmente a su participación en POL. 2. Tarifas de transacción: los validadores pueden validar cualquier número de cadenas Polygon. en retorno, estas cadenas normalmente otorgarán la totalidad o una parte de las tarifas de transacción a validators. 3. Recompensas adicionales: como se mencionó anteriormente, algunas cadenas Polygon pueden optar por introducir recompensas adicionales para atraer más validators. Estas recompensas pueden ser en cualquier token, incluidos, entre otros, POL, monedas estables o token nativos de esos Polygon cadenas. Mientras describimos los incentivos validator, vale la pena señalar que el concepto de validación en Polygon es más amplia que la definición habitual y estrecha. Esto mejora aún más la propuesta de valor de la Rol validator: además de validar múltiples cadenas, los validators también pueden realizar múltiples roles en una sola cadena. Los roles más comunes probablemente serán: ● Validación en sentido estricto: aceptar transacciones de usuarios, determinar su validez y bloques generadores; ● Demostración: Producir pruebas de validez de transacción sin conocimiento cero; ● Disponibilidad de datos: Proporcionar garantías de que los datos de las transacciones se publiquen y sean públicos. disponible.
Community Treasury
Community Treasury
The Polygon ecosystem and the whole Web3 industry are still in the early adoption and heavy development phase. To remain on the current growth trajectory, the Polygon ecosystem will need ongoing economic support in years to come.
To address the need for ongoing ecosystem support, we propose the Community Treasury, an in-protocol, community-governed ecosystem fund. It introduces at least three major benefits to the Polygon ecosystem: ● Ongoing, self-sustainable economic support for as long as required; ● Increased decentralization by reducing dependency on the Polygon Foundation; ● Achieving the next level of transparency and community inclusion. As described in § 5.2, the Community Treasury is funded by a predetermined emission of POL. The emission rate dedicated to this purpose is 1% per year, or ≈100 million POL in absolute terms, and can not be changed for 10 years. This guarantees strong ecosystem support during this period, critical for development, growth and positioning of Polygon. Once the Polygon ecosystem and Web3 reach maturity, the ecosystem will likely not need significant economic support anymore. At that point, the community should intervene and decrease or discontinue the emission for the Community Treasury. In an optimistic scenario, where maturity is reached before the 10-year period of guaranteed funding expires, the Community Treasury might end up having more funds than the ecosystem realistically needs. In that case, the community should decide how to utilize this excess POL. For example, a decision can be made to burn it. As mentioned, and as the name indicates, the Community Treasury should be governed by the community, via an agreed upon governance process. The governance process and the wider Polygon governance framework are being designed and established as part of the Polygon 2.0 effort, and explaining them in detail is out of the scope of this paper. Instead, we give a brief overview of its two likely concepts: 1. Polygon Funding Proposals (PFPs): Formal proposals for funding or other activities or improvements related to the Community Treasury. PFPs can be submitted by anyone, and should be publicly available and discussed. Similar concepts can be observed in other prominent governance frameworks4,5. 2. Consensus gathering: The process of making a decision on a specific PFP. The decision can be made in a direct manner, where every community member can participate, or via delegates who represent the community. As mentioned in § 4.3, POL should be technically enabled to hold governance rights, so it can potentially be utilized 5 https://docs.aave.com/governance/ 4 https://uniswap.org/governance
as part of the consensus gathering or the delegate election process. POL holders are directly economically incentivized to approve good proposals and reject the bad ones, which makes the decision making process more likely to benefit the ecosystem. We simulated ongoing Community Treasury inflows in § 9.
Hacienda Comunitaria
El ecosistema Polygon y toda la industria Web3 aún se encuentran en las primeras etapas de adopción y fase de desarrollo. Para permanecer en la trayectoria de crecimiento actual, el ecosistema Polygon necesitarán apoyo económico continuo en los próximos años.
Para abordar la necesidad de un apoyo continuo al ecosistema, proponemos el Tesoro Comunitario, un Fondo ecosistémico dentro del protocolo y gobernado por la comunidad. Introduce al menos tres beneficios principales para el ecosistema Polygon: ● Apoyo económico continuo y autosostenible durante el tiempo que sea necesario; ● Mayor descentralización al reducir la dependencia de la Fundación Polygon; ● Alcanzar el siguiente nivel de transparencia e inclusión comunitaria. Como se describe en el § 5.2, el Tesoro Comunitario se financia mediante una emisión predeterminada de POL. La tasa de emisión dedicada a este propósito es del 1% anual, o ≈100 millones de POL en absoluto términos, y no se puede cambiar durante 10 años. Esto garantiza un fuerte soporte del ecosistema durante este período, crítico para el desarrollo, crecimiento y posicionamiento de Polygon. Una vez que el ecosistema Polygon y Web3 alcancen la madurez, es probable que el ecosistema no necesite apoyo económico significativo. En ese punto, la comunidad debe intervenir y disminuir o suspender la emisión para el Tesoro Comunitario. En un escenario optimista, cuando el vencimiento se alcance antes de que expire el período de 10 años de financiación garantizada, el El Tesoro Comunitario podría terminar teniendo más fondos de los que el ecosistema realmente necesita. en En ese caso, la comunidad debería decidir cómo utilizar este exceso de POL. Por ejemplo, una decisión se puede hacer para quemarlo. Como ya se ha dicho, y como su nombre indica, la Hacienda Comunitaria debería regirse por el comunidad, a través de un proceso de gobernanza acordado. El proceso de gobernanza y la visión más amplia Polygon marco de gobernanza se están diseñando y estableciendo como parte del Polygon 2.0 esfuerzo, y explicarlos en detalle está fuera del alcance de este documento. En lugar de ello, damos una breve descripción general de sus dos conceptos probables: 1. Polygon Propuestas de financiación (PFP): propuestas formales de financiación u otras actividades o mejoras relacionadas con la Hacienda Comunitaria. Cualquier persona puede presentar PFP, y debería estar públicamente disponible y discutido. Se pueden observar conceptos similares en otros marcos de gobernanza destacados4,5. 2. Obtención de consenso: El proceso de tomar una decisión sobre una PFP específica. el La decisión se puede tomar de manera directa, donde cada miembro de la comunidad puede participar, o a través de delegados que representen a la comunidad. Como se menciona en el § 4.3, POL debe estar técnicamente habilitado para tener derechos de gobernanza, por lo que potencialmente puede ser utilizado 5 https://docs.aave.com/governance/ 4 https://uniswap.org/governance
como parte de la reunión de consenso o del proceso de elección de delegados. Los titulares de POL son directamente incentivados económicamente para aprobar buenas propuestas y rechazar las malas, lo que hace que el proceso de toma de decisiones tenga más probabilidades de beneficiar al ecosistema. En el artículo 9 simulamos las entradas en curso del Tesoro Comunitario.
Migration
Migration
Given that POL is being proposed as the successor of MATIC, the current native token of Polygon, migration from the old to the new token would need to take place. The initial supply of POL proposed in § 5.1 matches the current supply of MATIC and was proposed to simplify the migration process as much as possible. For self-custodying MATIC holders, the migration would require a simple action – swap from MATIC to POL, using the swapping smart contract that should be created for that purpose. The swapping contract should accept MATIC from any address and return the equivalent amount of POL to the same address. For MATIC holders who keep their tokens with centralized crypto exchanges and custodians, the migration would normally be automatic, i.e. would not require any action. Every MATIC holder should be able to swap their tokens for POL, including those who have MATIC “locked” for multiple years in various DeFi or vesting contracts, or the uninformed holders who find out about POL at some point in the future. For this reason, the migration should be allowed to happen during a prolonged period of time (e.g. 4 years), if not indefinitely. The migration should be voluntary, i.e. it cannot be forced. However, if POL is accepted by the majority of the community as the new native token, there will be little to no reason to hold MATIC instead of POL. In this situation, it is reasonable to expect that the migration will practically be fully executed, i.e. the vast majority of MATIC will be migrated.
Migración
Dado que se propone POL como sucesor de MATIC, el actual nativo token de Polygon, sería necesario realizar la migración del antiguo al nuevo token. El suministro inicial de POL propuesto en el § 5.1 coincide con el suministro actual de MATIC y fue propuso simplificar el proceso de migración tanto como fuera posible. Para MATIC de autocustodia titulares, la migración requeriría una acción simple: cambiar de MATIC a POL, usando el intercambiando smart contract que debe crearse para tal fin. El contrato de permuta debe acepte MATIC desde cualquier dirección y devuelva la cantidad equivalente de POL a la misma dirección. Para los titulares de MATIC que mantienen sus token con custodios y intercambios de cifrado centralizados, la migración normalmente sería automática, es decir, no requeriría ninguna acción. Todos los titulares de MATIC deberían poder cambiar sus tokens por POL, incluidos aquellos que tienen MATIC “bloqueado” durante varios años en varios DeFi o contratos de adquisición de derechos, o los desinformados titulares que se enteren de POL en algún momento en el futuro. Por esta razón, la migración Se debe permitir que esto ocurra durante un período de tiempo prolongado (por ejemplo, 4 años), si no indefinidamente. La migración debe ser voluntaria, es decir, no puede ser forzada. Sin embargo, si POL es aceptado por el mayoría de la comunidad como el nuevo nativo token, habrá poca o ninguna razón para mantener MATIC en lugar de POL. En esta situación, es razonable esperar que la migración sea prácticamente completamente ejecutado, es decir, la gran mayoría de MATIC se migrará.
Model
Model
Based on the design of POL and the Staking Layer, we propose a model to simulate important performance indicators of the POL-powered ecosystem, provide required inputs and analyze the results of simulations.
9.1 Hypothesis The purpose of the model is to validate the hypothesis that the proposed POL-powered ecosystem can simultaneously meet the following goals, derived from § 3: ● Sufficient ecosystem security: We measure security through POL staking ratio, i.e. percentage of the POL supply staked by validators. The minimal satisfactory ratio is 30-40%, roughly equivalent to the current staking ratio on the Polygon PoS chain6. ● Sufficient validator incentives: To estimate sufficiency of validator incentives, we introduce Return on Work (ROW), the measure of total validator earnings relative to the value of staked POL. The minimal satisfactory return is 4-5%; lower returns are not considered attractive enough, considering the work being performed, the risks and the opportunity costs. ● Sufficient ecosystem support: We measure ecosystem support through yearly inflow to the Community Treasury. The minimal satisfactory inflow is $50-100 million, and it is determined based on the current level of economic support the Polygon ecosystem needs. We explicitly define these indicators (staking ratio, validator returns and treasury inflow) in § 9.3. 9.2 Inputs In this chapter we outline the required model inputs and estimate their respectable values. First, we define three growth scenarios, projecting the abstract number of chains in the Polygon ecosystem during the initial 10-year period. We refer to the number of chains as abstract because it is not necessarily expressing the exact number of Polygon chains (although that might be the case), but more the cumulative level of activity, i.e. transactions in the ecosystem. 6 Source: https://staking.polygon.technology/
Figure 3. 10-year growth scenarios The rationale for the growth scenarios is based on the following data and observations: ● Current growth trajectory. Since the inception in 2020, the Polygon ecosystem has grown to thousand of applications and 3 million daily transactions7. If this trend even remotely continues, the proposed growth scenarios seem realistic. ● Web2 app marketplaces: The App Store hosts around 1.8 million applications8 and Google Play around 2.7 million9; both were introduced around 14 years ago. It could be reasonable to expect a comparable level of adoption for Web3 in a comparable timeframe. ● Supernets adoption: At the moment of writing this paper, one year since the introduction of Supernets, there are more than 100 Supernets candidate projects, many of them under active development. Based on this, the proposed growth scenarios for Supernets seem realistic, especially given that Supernets’ deployment should become significantly easier once the Staking Layer (described in § 6) is introduced. Additionally, it is noticeable that the trend of interest in Supernets is stronger in relative terms than the one for public chains. For this reason, we are assuming the same for the proposed growth scenarios. To further justify this, a meaningful parallel with Web2 adoption history can be drawn. In the earlier days of Web2, shared application hosting – Web2 equivalent to public chains – was much more common than nowadays. As the industry matured, 9 Source: https://www.appbrain.com/stats/number-of-android-apps 8 Source: https://www.apple.com/newsroom/2022/04/report-finds-third-party-apps-see-global-success-on-the-app-st ore/ 7 Source: https://polygonscan.com/chart/tx
dedicated hosting – Web2 equivalent to Supernets – became the norm for every application with a meaningful user base and level of activity. Again, the number of Polygon chains is an abstract concept in our model; in conjunction with the number of transactions per chain, it should primarily reflect the level of economic activity in the ecosystem. Similarly, the prevalence, i.e. ratio of Supernets compared to public chains, is an abstract, conservative assumption. If it would turn out that public chains are more popular relative to Supernets, the results of the simulation presented in § 9.4 would look similar or better, due to their respective transaction fee levels. To complement the aforementioned growth scenarios, we estimate the following inputs: ● Initial supply of 10 billion POL, as described in § 5.1; ● Yearly emission rate of 1% for validator incentives, as described in § 5.2; ● Yearly emission rate of 1% for the Community Treasury, as described in § 5.2; ● $5 average POL price during the 10-year period; ● 38 transactions/second on average per public chains, comparable to current Polygon PoS chain usage10; ● 19 transactions/second on average per Supernet, an estimate based on the requirements of Supernet projects; ● $0.01 average transaction fee on public chains, an estimate based on current average fees on Polygon PoS chain;11 ● $0.001 average transaction fee on Supernets, conservative estimate given abundant blockspace and a “race to the bottom” that it will likely cause for transaction fees; ● 100 validators on average per public chain, equivalent to the current validator set size of Polygon PoS; ● 15 validators on average per Supernet, based on requirements and realistic needs of Supernet candidates; ● $6,000/year average running costs per validator, equivalent to current Polygon PoS data, gradually decreasing according to a modified version of Moore’s Law (50% decrease in 3 years). It is worth noting that POL price, although one of the required model inputs, directly and significantly affects only the Community Treasury inflow, not the other key performance indicators. Also, transaction fee estimates do not account for the cost of data availability on 11 Source: https://polygonscan.com/chart/gasprice
Modelo
Basado en el diseño de POL y la capa de replanteo, proponemos un modelo para simular importantes indicadores de desempeño del ecosistema impulsado por POL, proporcionar los insumos necesarios y analizar el resultados de simulaciones.
9.1 Hipótesis El propósito del modelo es validar la hipótesis de que la propuesta impulsada por POL ecosistema puede cumplir simultáneamente los siguientes objetivos, derivados del § 3: ● Seguridad suficiente del ecosistema: Medimos la seguridad a través del ratio POL staking, es decir porcentaje del suministro de POL apostado por validators. La relación mínima satisfactoria es 30-40%, aproximadamente equivalente a la proporción actual staking en la cadena PoS Polygon6. ● Incentivos validator suficientes: Para estimar la suficiencia de los incentivos validator, introducir el retorno del trabajo (ROW), la medida de los ingresos totales validator en relación con el valor del POL apostado. El rendimiento mínimo satisfactorio es del 4-5%; Los rendimientos más bajos no son considerado lo suficientemente atractivo, considerando el trabajo que se realiza, los riesgos y las costos de oportunidad. ● Soporte suficiente del ecosistema: medimos el soporte del ecosistema a través del flujo anual al Tesoro Comunitario. La entrada mínima satisfactoria es de 50 a 100 millones de dólares, y es determinado en función del nivel actual de apoyo económico al ecosistema Polygon necesidades. Definimos explícitamente estos indicadores (índice staking, rendimientos validator y entradas de tesorería) en el § 9.3. 9.2 Entradas En este capítulo describimos las entradas requeridas del modelo y estimamos sus valores respetables. Primero, definimos tres escenarios de crecimiento, proyectando el número abstracto de cadenas en el Polygon ecosistema durante el período inicial de 10 años. Nos referimos al número de cadenas como abstracto. porque no necesariamente expresa el número exacto de cadenas Polygon (aunque eso podría ser el caso), sino más bien el nivel acumulado de actividad, es decir, las transacciones en el ecosistema. 6 Fuente: https://staking.polygon.technology/
Figura 3. Escenarios de crecimiento a 10 años La justificación de los escenarios de crecimiento se basa en los siguientes datos y observaciones: ● Trayectoria de crecimiento actual. Desde su inicio en 2020, el ecosistema Polygon ha creció a miles de aplicaciones y 3 millones de transacciones diarias7. Si esta tendencia incluso continúa remotamente, los escenarios de crecimiento propuestos parecen realistas. ● Mercados de aplicaciones Web2: la App Store alberga alrededor de 1,8 millones de aplicaciones8 y Google Play alrededor de 2,7 millones9; Ambos se introdujeron hace unos 14 años. podría ser Es razonable esperar un nivel comparable de adopción de Web3 en un período comparable. plazo. ● Adopción de Supernets: Al momento de escribir este artículo, un año desde la introducción de Supernets, hay más de 100 proyectos candidatos a Supernets, muchos de ellos en desarrollo activo. En base a esto, los escenarios de crecimiento propuestos para Las Superredes parecen realistas, especialmente teniendo en cuenta que su implementación debería ser mucho más fácil una vez que se introduce la capa de replanteo (descrita en el § 6). Además, Es notable que la tendencia del interés en las Supernets es más fuerte en términos relativos que la uno para cadenas públicas. Por esta razón, asumimos lo mismo para la propuesta. escenarios de crecimiento. Para justificar aún más esto, un paralelo significativo con la historia de adopción de Web2 se puede dibujar. En los primeros días de Web2, alojamiento compartido de aplicaciones: equivalente a Web2 a cadenas públicas – era mucho más común que hoy en día. A medida que la industria maduró, 9 Fuente: https://www.appbrain.com/stats/number-of-android-apps 8 Fuente: https://www.apple.com/newsroom/2022/04/report-finds-third-party-apps-see-global-success-on-the-app-st mineral/ 7 Fuente: https://polygonscan.com/chart/txEl alojamiento dedicado (Web2 equivalente a Supernets) se convirtió en la norma para todos. aplicación con una base de usuarios significativa y un nivel de actividad. Nuevamente, el número de cadenas Polygon es un concepto abstracto en nuestro modelo; en conjunto con el número de transacciones por cadena, debería reflejar principalmente el nivel de actividad económica en el ecosistema. De manera similar, la prevalencia, es decir, la proporción de Supernets en comparación con las cadenas públicas, es un Suposición abstracta y conservadora. Si resulta que las cadenas públicas son más populares En relación con las Superredes, los resultados de la simulación presentada en el § 9.4 serían similares o mejor, debido a sus respectivos niveles de tarifas de transacción. Para complementar los escenarios de crecimiento antes mencionados, estimamos los siguientes insumos: ● Suministro inicial de 10 mil millones de POL, como se describe en el § 5.1; ● Tasa de emisión anual del 1 % para los incentivos validator, como se describe en el § 5.2; ● Tasa de emisión anual del 1% para el Tesoro Comunitario, tal como se describe en el § 5.2; ● Precio promedio de POL de $5 durante el período de 10 años; ● 38 transacciones/segundo en promedio por cadena pública, comparable al Polygon actual Uso de la cadena PoS10; ● 19 transacciones/segundo en promedio por superred, un estimación basado en el requisitos de proyectos Supernet; ● Tarifa de transacción promedio de $0,01 en cadenas públicas, una estimación basada en el promedio actual tarifas en Polygon cadena PoS;11 ● Tarifa de transacción promedio de $0,001 en Supernets, estimación conservadora dada la abundancia espacio de bloques y una “carrera hacia el fondo” que probablemente generará tarifas de transacción; ● 100 validators en promedio por cadena pública, equivalente al tamaño establecido actual validator de Polygon Punto de venta; ● 15 validators en promedio por Supernet, según los requisitos y necesidades realistas de Candidatos a Supernet; ● Costos de funcionamiento promedio de $6,000/año por validator, equivalente al Polygon PoS actual datos, disminuyendo gradualmente según una versión modificada de la Ley de Moore (50% disminución en 3 años). Vale la pena señalar que el precio POL, aunque es uno de los insumos requeridos del modelo, directa y afecta significativamente sólo a las entradas del Tesoro Comunitario, no a otros resultados clave indicadores. Además, las estimaciones de tarifas de transacción no tienen en cuenta el costo de la disponibilidad de datos en 11 Fuente: https://polygonscan.com/chart/gasprice
Source: https://polygonscan.com/chart/tx
Source: https://polygonscan.com/chart/tx
Ethereum for Polygon chains that use the rollup model; we ignore this cost because it is passed to Ethereum. 9.3 Methodology We define a simple model to estimate the key performance indicators of the ecosystem, and validate the hypothesis from § 9.1. The key indicators and the methodology to determine them are as follows: ● Staking ratio ( ): The portion of the POL supply staked by validators. 𝑆𝑟 𝑆𝑟= 𝑆𝑠 / 𝑆𝑡 Where is staked supply, i.e. total amount of POL staked by validators, and is total 𝑆𝑠 𝑆𝑡 supply, i.e. current supply of POL. ● Validator emission incentives ( ): Yearly validator incentives that come from POL 𝑉𝑖𝑖 emission. 𝑉𝑖𝑖= 𝑆𝑡 × 𝐼𝑣 × 𝑃 Where is total supply, is yearly emission rate for validator rewards and is POL 𝑆𝑡 𝐼𝑣 𝑃 price. ● Validator fees incentives ( ): Yearly validator incentives that come from gas fees. 𝑉𝑖𝑓 𝑉𝑖𝑓= 𝐶𝑝 × 𝑇𝑝× 𝐹𝑝 + 𝐶𝑠 × 𝑇𝑠× 𝐹𝑠 Where is number of public chains, is number of transactions per public chain, 𝐶𝑝 𝑇𝑝 𝐹𝑝 is average transaction fee per public chain, is number of Supernets, is number of 𝐶𝑠 𝑇𝑠 transactions per Supernet and is average transaction fee per Supernet. 𝐹𝑠 ● Validator running costs ( ): Cumulative yearly running costs of all Polygon validators. 𝑉𝑐 𝑉𝑐= (𝑁𝑝 × 𝐶𝑝+ 𝑁𝑠 × 𝐶𝑠) × 𝑌 Where is number of validators per public chain, is number of public chains, is 𝑁𝑝 𝐶𝑝 𝑁𝑠 number of validators per Supernet, is number of Supernets and are yearly running 𝐶𝑠 𝑌 costs for a single validator. ● Return on Work ( ): Total validator earnings expressed as a percentage of the value 𝑉𝑟 of staked POL. 𝑉𝑟= (𝑉𝑖𝑖 + 𝑉𝑖𝑓 − 𝑉𝑐) / (𝑆𝑠 × 𝑃)
Where are validator issuance incentives, are validator fee incentives, are 𝑉𝑖𝑖 𝑉𝑖𝑓 𝑉𝑐 validator running costs, is staked supply and is POL price. 𝑆𝑠 𝑃 ● Community Treasury inflow ( ): Total yearly inflow to the Community Treasury. 𝑋𝑖 𝑋𝑖= 𝑉𝑖𝑖= 𝑆𝑡 × 𝐼𝑡 × 𝑃 Where is total supply, is yearly emission rate for the Community Treasury and is 𝑆𝑡 𝐼𝑡 𝑃 POL price. 9.4 Results The model accepts the required inputs and processes them using the presented methodology. The results for varying input sets can provide interesting insights into the ecosystem and its dynamics, including but not limited to: ● The attractiveness and sustainability of validator incentives; ● The amount and dynamics of the the Community Treasury inflows; ● The structure of validator incentives and their changes over time; ● The effect of price on all observed indicators; ● The effect of different adoption levels to all observed indicators etc. Here we run the model with the inputs provided in § 9.2 and observe the three indicators required to validate our initial hypothesis: staking ratio ( ), validator incentives ( ) and treasury 𝑆𝑟 𝑉𝑖 inflow ( ). 𝑋𝑖 Based on the model results, we are reasonably confident that the described POL-powered ecosystem can meet all three goals outlined in § 9.1: ● Sufficient ecosystem security: We fixed the staking ratio ( ) at 30% and ran the 𝑆𝑟 model. Given that the remaining two indicators – validator incentives ( ) and treasury 𝑉𝑖 inflow ( ) – are showing expected or higher than expected values, we conclude that the 𝑋𝑖 staking ratio should retain satisfactory or higher than satisfactory levels. ● Sufficient validator incentives: The results show that the targeted Return on Work ( ) 𝑉𝑟 of 4-5% is realistic to expect. Moreover, it reaches ≈7% for medium growth and ≈10% for fast growth scenario. In reality, this would likely cause the staking ratio to increase (thus further increasing security of the ecosystem), until the market determines the equilibrium between staking ratio and returns.
● Sufficient ecosystem support: The results show that the minimal satisfactory level of the Community Treasury inflows ( ) of $50-100 million per year is realistic to expect. 𝑋𝑖 Moreover, it reaches significantly higher levels towards the end of the 10-year period. However, the treasury inflow is directly related to the price of POL, and thus highly speculative. If the treasury ends up having more funds than the ecosystem realistically needs, the community might decide to burn the excess POL, as mentioned in § 7. Figure 4. Return on Work and Community Treasury inflow The full model is open-source and can be accessed on GitHub, and used to produce and analyze results for arbitrary sets of inputs. 10 Conclusion The vision behind Polygon is to build the Value Layer of the Internet. To achieve this vision, the redesigned Polygon protocol architecture introduces a novel, infinitely scalable and seamlessly interconnected network of Layer 2 chains. In this paper, we introduced POL, the proposed native token of Polygon, designed to secure, coordinate and align the Polygon ecosystem and supercharge its growth. The proposed design and tokenomics of POL achieve the rigorous design goals that we defined. We created a model to simulate the key performance indicators of the POL-powered ecosystem, provided required model inputs and analyzed the results of the simulation. The results confirmed the hypothesis of the model, derived from the aforementioned design goals.
Based on everything above, we conclude that POL is a novel, next generation asset that provides a solid foundation for Polygon to achieve its ambitious vision.
Fuente: https://polygonscan.com/chart/tx
Ethereum para cadenas Polygon que utilizan el modelo rollup; ignoramos este costo porque se pasa a Ethereum. 9.3 Metodología Definimos un modelo simple para estimar los indicadores clave de desempeño del ecosistema, y validar la hipótesis del § 9.1. Los indicadores clave y la metodología para determinarlos son los siguientes: ● Proporción de apuesta ( ): La porción del suministro de POL apostada por validators. 𝑆𝑟 𝑆𝑟= 𝑆𝑠 / 𝑆𝑡 donde es el suministro apostado, es decir, la cantidad total de POL apostado por validators, y es total 𝑆𝑠 𝑆𝑡 suministro, es decir, suministro actual de POL. ● Incentivos de emisión del validador ( ): Incentivos anuales validator que provienen de POL 𝑉𝑖𝑖 emisión. 𝑉𝑖𝑖= 𝑆𝑡 × 𝐼𝑣 × 𝑃 donde es la oferta total, es la tasa de emisión anual para validator recompensas y es POL 𝑆𝑡 𝐼𝑣 𝑃 precio. ● Incentivos de tarifas de validador ( ): Incentivos anuales validator que provienen de las tarifas del gas. 𝑉𝑖𝑓 𝑉𝑖𝑓= 𝐶𝑝 × 𝑇𝑝× 𝐹𝑝 + 𝐶𝑠 × 𝑇𝑠× 𝐹𝑠 donde es el número de cadenas públicas, es el número de transacciones por cadena pública, 𝐶𝑝 𝑇𝑝 𝐹𝑝 es la tarifa de transacción promedio por cadena pública, es el número de Supernets, es el numero de 𝐶𝑠 𝑇𝑠 transacciones por Supernet y es la tarifa de transacción promedio por Supernet. 𝐹𝑠 ● Costos de funcionamiento del validador ( ): Costes de funcionamiento anuales acumulados de todos los Polygon validators. 𝑉𝑐 𝑉𝑐= (𝑁𝑝 × 𝐶𝑝+ 𝑁𝑠 × 𝐶𝑠) × 𝑌 donde es el número de validators por cadena pública, es el número de cadenas públicas, es 𝑁𝑝 𝐶𝑝 𝑁𝑠 número de validators por Supernet, es el número de Supernets y son anuales 𝐶𝑠 𝑌 costos para un solo validator. ● Retorno del trabajo ( ): Ganancias totales validator expresadas como porcentaje del valor 𝑉𝑟 de POL apostado. 𝑉𝑟= (𝑉𝑖𝑖 + 𝑉𝑖𝑓 − 𝑉𝑐) / (𝑆𝑠 × 𝑃)
donde son validator incentivos de emisión, son validator incentivos de tarifas, son 𝑉𝑖𝑖 𝑉𝑖𝑓 𝑉𝑐 validator costos de funcionamiento, está en juego la oferta y es el precio POL. 𝑆𝑠 𝑃 ● Entradas del Tesoro Comunitario ( ): Entradas totales anuales al Tesoro Comunitario. 𝑋𝑖 𝑋𝑖= 𝑉𝑖𝑖= 𝑆𝑡 × 𝐼𝑡 × 𝑃 donde es la oferta total, es la tasa de emisión anual para el Tesoro Comunitario y es 𝑆𝑡 𝐼𝑡 𝑃 Precio POL. 9.4 Resultados El modelo acepta los insumos requeridos y los procesa utilizando la metodología presentada. Los resultados para distintos conjuntos de insumos pueden proporcionar información interesante sobre el ecosistema y sus dinámica, que incluye, entre otros: ● El atractivo y la sostenibilidad de los incentivos validator; ● El importe y la dinámica de las entradas del Tesoro Comunitario; ● La estructura de los incentivos validator y sus cambios a lo largo del tiempo; ● El efecto del precio en todos los indicadores observados; ● El efecto de diferentes niveles de adopción en todos los indicadores observados, etc. Aquí ejecutamos el modelo con las entradas proporcionadas en el § 9.2 y observamos los tres indicadores. requerido para validar nuestra hipótesis inicial: staking ratio ( ), validator incentivos ( ) y tesorería 𝑆𝑟 𝑉𝑖 afluencia ( ). 𝑋𝑖 Según los resultados del modelo, tenemos una confianza razonable en que el sistema POL descrito El ecosistema puede cumplir los tres objetivos descritos en el § 9.1: ● Seguridad suficiente del ecosistema: arreglamos la proporción staking ( ) al 30% y ejecutó el 𝑆𝑟 modelo. Dado que los dos indicadores restantes – validator incentivos ( ) y tesorería 𝑉𝑖 afluencia ( ) – están mostrando valores esperados o superiores a los esperados, concluimos que el 𝑋𝑖 La relación staking debe mantenerse en niveles satisfactorios o superiores a los satisfactorios. ● Incentivos validator suficientes: Los resultados muestran que el retorno del trabajo objetivo ( ) 𝑉𝑟 Es realista esperar un aumento del 4-5%. Además, alcanza ≈7% para crecimiento medio y ≈10% para crecimiento medio. escenario de rápido crecimiento. En realidad, esto probablemente causaría que la proporción staking aumentara (por lo tanto aumentando aún más la seguridad del ecosistema), hasta que el mercado determine el equilibrio entre staking ratio y rentabilidad.● Soporte suficiente del ecosistema: Los resultados muestran que el nivel mínimo satisfactorio de las entradas del Tesoro Comunitario ( ) es realista esperar entre 50 y 100 millones de dólares al año. 𝑋𝑖 Además, alcanza niveles significativamente más altos hacia el final del período de 10 años. Sin embargo, la entrada de tesorería está directamente relacionada con el precio de POL y, por lo tanto, es altamente especulativo. Si el tesoro acaba teniendo más fondos que el ecosistema de forma realista necesidades, la comunidad podría decidir quemar el exceso de POL, como se menciona en el § 7. Figura 4. Rentabilidad del trabajo y entrada del tesoro comunitario El modelo completo es de código abierto y se puede acceder a él en GitHub y usarse para producir y Analizar resultados para conjuntos arbitrarios de entradas. 10 Conclusión La visión detrás de Polygon es construir la capa de valor de Internet. Para lograr esta visión, el La arquitectura de protocolo Polygon rediseñada presenta una novedosa, infinitamente escalable y sin problemas. Red interconectada de Layer 2 cadenas. En este artículo, presentamos POL, el token nativo propuesto de Polygon, diseñado para proteger, coordinar y alinear el ecosistema Polygon y potenciar su crecimiento. El diseño propuesto y tokenómica de POL logran los rigurosos objetivos de diseño que definimos. Creamos un modelo para simular los indicadores clave de rendimiento del ecosistema impulsado por POL. proporcionó las entradas del modelo requeridas y analizó los resultados de la simulación. Los resultados confirmó la hipótesis del modelo, derivada de los objetivos de diseño antes mencionados.
Con base en todo lo anterior, concluimos que POL es un activo novedoso de próxima generación que proporciona una base sólida para que Polygon logre su ambiciosa visión.