Whitepaper do 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.
Resumo
Este artigo propõe POL, o token nativo da arquitetura de protocolo Polygon revisada, comumente referido como Polygon 2.0. Como sucessor do MATIC, o POL deverá se tornar uma ferramenta instrumental para coordenação e crescimento do ecossistema Polygon e o principal impulsionador da visão de Polygon como a camada de valor para a Internet. Começamos por analisar trabalhos relevantes, identificando oportunidades e ameaças e, com base nisso, estabelecer metas de design de POL. Propomos design, utilidade e tokenômica do POL que atinjam todos os objetivos do projeto. Descrevemos o conceito da Staking Layer, um coordenador de cadeia único e alimentado por POL, capaz de suportar um número praticamente ilimitado de cadeias Polygon com recursos arbitrários e configurações. Acreditamos que a introdução da camada de staking e do Polygon 2.0 mais amplo arquitetura pode estabelecer Polygon como o terceiro avanço mais importante e impactante em Web3 (sendo os dois primeiros Bitcoin e Ethereum), dada a magnitude da inovação e adoção que pode facilitar. Apresentamos o Tesouro Comunitário, um fundo protocolado e administrado pela comunidade, projetado para fornecer apoio econômico contínuo para maior desenvolvimento e crescimento do Polygon ecossistema. Descrevemos o processo de migração do MATIC para o POL. Para analisar o projeto proposto, definimos um modelo de simulação econômica e executamos simulações confirmar a hipótese do modelo, derivada dos objetivos de design acima mencionados. Com base em tudo acima, concluímos que o POL é um ativo novo e de próxima geração que fornece uma base sólida para a visão ambiciosa da Camada 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.
Visão
A visão por trás de Polygon como a Camada de Valor da Internet é inaugurar um mundo em que o valor podem ser criados e trocados livre e globalmente, da mesma forma que criamos e trocamos informações hoje. Um mundo que permite novas formas – mais justas, mais inclusivas e mais eficientes das organizações humanas e da governação. Acreditamos firmemente que a concretização desta visão pode avançar significativamente a nossa sociedade. Para tornar esta visão ambiciosa uma realidade, a infraestrutura de Polygon deve melhorar. Especificamente, deve tornar-se exponencialmente mais escalável, sem sacrificar a segurança e a segurança do utilizador. experiência. Para resolver isso, uma arquitetura de protocolo reinventada está sendo introduzida como parte do Polygon Esforço 2.0. Este redesenho radical transforma Polygon em uma rede de cadeias L2 alimentadas por ZK, unificadas através de um novo protocolo de coordenação entre cadeias. A rede pode suportar um número praticamente ilimitado número de cadeias, e as interações entre cadeias podem acontecer de forma contínua e instantânea, sem suposições adicionais de segurança ou confiança. Este design cumpre totalmente o acima mencionado requisito – escalabilidade exponencial sem sacrificar a segurança e a experiência do usuário. Figura 1. Arquitetura do protocolo Polygon Para coordenar, proteger e expandir esta rede poderosa, um protocolo avançado e bem projetado economia e design de mecanismos são necessários. Isso inspirou a criação do 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.
Trabalho relevante
Neste capítulo descrevemos exemplos de design nativos relevantes token, a utilidade que eles atribuem ao token bem como vantagens e desvantagens notáveis. 2.1Bitcoin (BTC) BTC é o token nativo do protocolo Bitcoin e é o primeiro token nativo proeminente implementação. A utilidade do BTC é dupla: ● Recompensas do mineiro: o protocolo emite BTC e o distribui para o protocolo validators, também conhecido como mineiros; ● Taxas de transação: Os usuários pagam taxas em BTC para cada transação, o que evita spam e fornece incentivos adicionais para os mineiros. Uma vantagem do design do BTC é um fornecimento determinístico, ou seja, previsível. Normalmente, tokens com oferta determinística são mais atraentes para os detentores e podem capturar valor melhor do que aqueles com oferta não determinística. Consideramos o BTC um design legado token e argumentamos que suas desvantagens são múltiplas: ● É um ativo improdutivo, não confere aos seus titulares nenhum papel significativo no protocolo nem os incentivos para desempenhar tal função; ● Não aproveita a oportunidade de exigir participação no token nativo para protocolo validators e, em vez disso, exige que eles façam stake, ou seja, invistam recursos externos (mineração equipamentos e eletricidade), tornando o protocolo menos resiliente e autossustentável; ● Reduz gradualmente a emissão de recompensas de mineração até chegar a zero, o que introduz preocupações de sustentabilidade e segurança (não está claro se a segurança pode ser mantida uma vez a taxa de emissão torna-se baixa ou chega a zero); ● Não introduz qualquer tipo de apoio económico ao ecossistema; ● Não confere quaisquer direitos de governança aos detentores, embora se possa argumentar que Layer 1 protocolos como Bitcoin não devem utilizar tokens para governança. 2.2 Ethereum (ETH) ETH é o token nativo do protocolo e ecossistema Ethereum. Com seu design inovador, estabeleceu a próxima geração de protocolos nativos tokens.
A utilidade do ETH é múltipla: ● Validadores staking: O protocolo PoS (Proof-of-Stake) de Ethereum requer validators para apostar ETH para ingressar no pool validator; ● Recompensas do validador: O protocolo emite ETH e distribui para o protocolo validators; ● Taxas de transação: Os usuários pagam taxas em ETH para cada transação, o que evita spam e fornece incentivos adicionais para validators. O design da ETH tem múltiplas vantagens: ● É um ativo produtivo, os seus detentores podem participar na segurança da rede e receber incentivos para fazer isso; ● Ele desincentiva o comportamento malicioso de validators por meio de cortes no protocolo, ou seja, destruindo tokens de validators maliciosos; ● Não introduz preocupações de segurança e sustentabilidade, dado que não tem limite de fornecimento como BTC; ● Fornece apoio económico ao ecossistema através de uma porção predeterminada do investimento inicial. fornecimento atribuído à fundação de gestão. Uma desvantagem potencial do projeto ETH é que ele não possui fornecimento totalmente previsível, dado que a emissão de token para recompensas de validator aumenta à medida que mais tokens são apostados. No entanto, isso é combatido com sucesso pelo mecanismo integrado que queima1 uma porção de cada taxa de transação, contrariando assim o impacto da emissão de token para recompensas de validator. Outro a desvantagem é que o referido apoio económico não pode durar indefinidamente; o inicial token a alocação para a fundação de gestão acabará se esgotando. Por último, não atribuir qualquer direito de governança aos titulares de token, embora, como mencionado acima, possa ser argumentado que os protocolos Layer 1 não devem utilizar tokens para governança. 2.3 Cosmos (ÁTOM) ATOM é o token nativo do hub Cosmos, o blockchain central pretendido do Cosmos ecossistema multicadeia. Possui utilidade múltipla, mas apenas dentro do hub Cosmos: ● Validadores staking; ● Recompensas do validador; ● Taxas de transação; 1https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md● Governança. O design do ATOM tem as seguintes vantagens: ● É um ativo produtivo, seus titulares podem participar na garantia do Cosmos Hub e receber incentivos para fazer isso; ● Não introduz preocupações de segurança e sustentabilidade, dado que não tem limite de abastecimento; ● Fornece apoio económico ao ecossistema através de uma alocação predeterminada para o fundação de administração; ● Concede aos seus titulares direitos de governação através de um modelo de governação abrangente. As desvantagens do design ATOM: ● Ele só tem utilidade no Hub Cosmos; não é usado para executar e proteger outras cadeias no ecossistema, embora existam iniciativas para permitir isso; ● Facilita um modelo de governança apenas token, que exclui outras partes interessadas relevantes do ecossistema (desenvolvedores, contribuidores proeminentes, aplicações, etc.) desde a decisão fazer; ● O apoio económico que facilita não pode durar indefinidamente, uma vez que o tesouro token eventualmente se esgotar. 2.4 Polkadot (DOT) DOT é o token nativo do ecossistema multicadeia Polkadot. Tem a mesma utilidade que o ATOM, mas geralmente em todo o ecossistema Polkadot: ● Validadores staking; ● Recompensas do validador; ● Taxas de transação; ● Governança. O design do DOT tem as seguintes vantagens: ● É um ativo produtivo; ● Não introduz preocupações de segurança e sustentabilidade, dado que não tem limite de abastecimento; ● Fornece apoio económico ao ecossistema através de uma alocação predeterminada para o fundação de administração; ● Concede aos seus titulares direitos de governação através de um modelo de governação abrangente;
● Ele fornece segurança para todo o ecossistema, ou seja, todos os blockchains participantes. As desvantagens são: ● Ele exige o uso de DOT como validator staking token para todas as redes participantes, reduzindo assim as opções arquitetônicas para desenvolvedores de cadeias Polkadot; ● Ele introduz um nível significativo de atrito para desenvolvedores de Polkadot blockchains que estão obrigados a licitar e bloquear quantidades significativas de DOT para que suas cadeias se tornem parte do ecossistema; ● Facilita um modelo de governança apenas token, que exclui outras partes interessadas relevantes do ecossistema desde a tomada de decisões; ● O apoio económico que facilita não pode durar indefinidamente, uma vez que o tesouro token eventualmente se esgotar. 2.5 Aave (Aave) AAVE é o token nativo do Aave, uma plataforma de empréstimo token em rede. Dado que AAVE não é um protocolo mas sim uma aplicação token, não analisamos o seu design, vantagens e desvantagens. A relevância do AAVE para o design do POL é dupla: ● AAVE é o sucessor do LEND, o nativo inicial token do Aave; a comunidade Aave executou uma migração bem-sucedida e benéfica de LEND para AAVE; ● AAVE fornece aos seus titulares direitos de governança por meio de um modelo de governança abrangente.
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.
Metas de design
Com base na análise de trabalhos relevantes, várias oportunidades importantes para o POL beneficiar o Polygon ecossistema foram identificados. Essas oportunidades são apresentadas aqui como POL objetivos de projeto. 1. Segurança do ecossistema. A POL deve ajudar a estabelecer um conjunto altamente descentralizado de validators que podem executar e proteger qualquer cadeia Polygon. Os validadores devem ser incentivados para ingressar e permanecer no pool validator e ajudar a proteger o maior número possível de cadeias, e em ao mesmo tempo, desincentivados a fazer qualquer coisa maliciosa. 2. Escalabilidade infinita. POL deve apoiar o crescimento exponencial do ecossistema Polygon e eventual “hiperbloqueio” do mundo. Primeiramente, deve habilitar o validator pool em escala para suportar milhares de cadeias Polygon.
3. Apoio ao ecossistema. Sendo uma rede global em formação, Polygon exigirá apoio económico para um maior desenvolvimento e crescimento. A POL deverá ajudar a estabelecer uma mecanismo de financiamento autossustentável para essas atividades. Este “veículo” de financiamento deverá ser governado pela comunidade Polygon. 4. Sem atrito. As redes Blockchain geralmente exigem que usuários e desenvolvedores mantenham e apostem ou consumir seus tokens nativos para usar a rede. Isso causa atrito e degrada a experiência do usuário e do desenvolvedor. O POL deve ser concebido de uma forma que não não introduza tal atrito. 5. Propriedade comunitária. Polygon é concebido como uma rede descentralizada governada por sua comunidade. Atribuir direitos de governança aos titulares de POL pode permitir a criação de modelos de governança eficazes nos quais os tomadores de decisão são diretamente incentivados a apoiar propostas que sejam do melhor interesse do ecossistema 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.
Utilitário
POL é o token nativo de Polygon e, como tal, representa a principal ferramenta de coordenação e incentivo de todo o ecossistema Polygon. Possui utilidade multifacetada, a saber: ● Validador staking; ● Recompensas do validador; ● Propriedade comunitária, ou seja, governança. 4.1 Validador staking Polygon validators são obrigados a apostar POL para ingressar no pool validator. O validador staking aumenta a segurança do ecossistema ao: ● Prevenir ataques de Sybil; ● Alinhando validators com o sucesso do ecossistema; ● Habilitando cortes, ou seja, punição de validators maliciosos. Ao staking POL e ingressar no pool validator, validators tornam-se elegíveis para se inscrever para validar qualquer cadeia Polygon. A validação e seus benefícios para validators são explicados com mais detalhes em § 6.3.
4.2 Recompensas do validador A descentralização e o tamanho do pool validator são extremamente importantes para a segurança, resiliência e neutralidade de todo o ecossistema Polygon. Para incentivar a integração e retenção de validator, quantidades predefinidas de POL devem ser distribuídas continuamente para Polygon validators como protocolo recompensas. As recompensas do protocolo devem ser distribuídas aos validators proporcionalmente à quantidade de POL eles apostam. A emissão POL está descrita no § 5.2. As recompensas do protocolo fornecem incentivos básicos para validators e estabelecem condições equitativas para o conjunto validator inteiro. Além disso, validators podem garantir incentivos adicionais validando cadeias Polygon individuais. Incentivos validator adicionais estão descritos em § 6.3. 4.3 Governança Para facilitar eficiente, administrado pela comunidade governação de aspectos importantes do Polygon ecossistema, a POL deve estar tecnicamente capacitada para deter direitos de governação, ou seja, ser utilizada em quadros de governação. Descrever a estrutura de governança Polygon está fora do escopo deste este artigo.
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.
Fornecimento
Aqui cobrimos o fornecimento inicial e a política de emissões da POL e descrevemos a lógica atrás de ambos. 5.1 Fornecimento inicial O fornecimento inicial de POL é de 10 bilhões de tokens. A totalidade do fornecimento inicial deverá ser dedicado para migração, ou seja, token troca de MATIC para POL. Esta migração precisaria levar lugar para que o POL suceda o MATIC como o token nativo do ecossistema Polygon, e é discutido no § 8. A oferta inicial de POL corresponde à oferta de MATIC, o que deverá tornar a migração bastante simples. Assim que a migração estiver concluída, a distribuição do POL corresponderá essencialmente à actual distribuição de MATIC. MATIC já passou por um extenso processo de token distribuição que resultou em mais de 600.000 endereços de titulares2, e provavelmente ainda mais 2 Fonte: https://etherscan.io/token/0x7d1afa7b718fb893db30a3abc0cfc608aacfebb0#balances
detentores reais, dado que os endereços das trocas de criptografia centralizadas e dos protocolos DeFi representam vários usuários. Isto implica que o POL seria amplamente distribuído desde o primeiro dia, o que é fundamental para a descentralização geral e a resiliência do ecossistema. 5.2 Emissão O POL é emitido a uma taxa determinística predefinida para dois propósitos: 1. Recompensas do validador. Para incentivar a integração e retenção de validator, o POL deve ser emitido continuamente a uma taxa predeterminada e distribuído para validators como base, recompensa de protocolo. Propomos uma taxa de emissão anual de 1% do fornecimento de POL para este propósito. A taxa de emissão não seria possível mudar durante os primeiros 10 anos, e após esse período a comunidade pode decidir diminuí-lo de forma arbitrária através do quadro de governação. A taxa de emissão nunca pode ser aumentada além de 1%. 2. Apoio ao ecossistema. Para fornecer apoio contínuo para um maior desenvolvimento e crescimento da o Polygon ecossistema, nós propor para apresentar o Comunidade Tesouro, um fundo ecossistêmico governado pela comunidade, descrito no § 7. Propomos uma emissão anual alíquota de 1% do fornecimento da POL para esse fim. Assim como a emissão para validator recompensas, esta taxa de emissão pode ser reduzida após 10 anos através de uma governança quadro, e nunca poderá ser aumentado para além de 1%. Figura 2. Possíveis cenários de taxas de emissão de POL A justificativa para a emissão proposta e as taxas de emissão é que o ecossistema Polygon e a Web3 em geral precisará de tempo para amadurecer e alcançar a adoção generalizada. Com base nociclos históricos de adoção de plataformas de computação e Internet, a fase de maturidade poderia ser realisticamente esperado que aconteça em cerca de 10-15 anos. Durante esse período, o ecossistema necessitam de apoio económico. Assim que o ecossistema Polygon e a Web3 atingirem a maturidade, taxas de transação e outros incentivos garantido pela validação de cadeias Polygon (descritas em § 6.3) por si só deve gerar suficiente retorna para Polygon validators. Quando isso acontecer, a comunidade pode decidir intervir e reduzir ou descontinuar completamente a emissão de recompensas validator, sem afetar a segurança e descentralização do ecossistema. Da mesma forma, a comunidade pode então decidir diminuir ou interromper também a emissão para o Tesouro Comunitário, dado que o ecossistema não ainda precisam de apoio económico significativo. Obviamente, o ciclo de adoção do Web3 pode parecer um pouco ou completamente diferente. Caso isso aconteça que alcançar a adoção generalizada leva mais tempo e o ecossistema ainda precisa de apoio após 10 anos, a comunidade pode optar por não intervir e a emissão continuará a acontecer pelo tempo que for necessário. Consideramos a política de emissões proposta ótima, pois atinge o equilíbrio entre: ● Suficiente ecossistema suporte. Suficiente, à prova de futuro suporte para o Polygon ecossistema é extremamente importante para a segurança e o sucesso de Polygon. Para validar o hipótese de que as taxas de emissão propostas são de fato suficientes, desenvolvemos um modelo econômico, fez simulações e apresentou resultados no § 9. ● Segurança através de escassez. A escassez de tokens nativos é instrumentalmente importante para blockchain redes; a alta diluição de token pode afetar drasticamente a segurança. Para estimar Escassez de POL, podemos comparar a taxa de emissão proposta com a taxa de emissão do BTC, que está atualmente em ≈1,8%3 e foi significativamente mais elevado no passado. Além disso, embora diminuindo gradualmente, a emissão de BTC é garantida por mais do que outro século, enquanto a emissão de POL poderia ser potencialmente reduzida ou interrompida mesmo após 10 anos. Dado que (i) Bitcoin é considerado um ativo altamente escasso, e (ii) POL total taxa de emissão é comparável (e potencialmente mais rigorosa que) BTC, concluímos que O POL é suficientemente escasso, ou seja, a sua emissão não introduz preocupações de segurança do protocolo. 3 Fonte: https://charts.woobull.com/bitcoin-inflation/
Por último, é importante notar que a política de emissões que propomos tem um elevado grau de previsibilidade. O cronograma de emissões predeterminado torna o fornecimento de POL previsível no longo prazo prazo, mesmo que a comunidade decida intervir. Como explicado, a comunidade só pode diminuir as alíquotas, complementando efetivamente a política de emissões predeterminada e potencialmente aumentando a escassez de POL. Previsibilidade e escassez atraem protocolo e mercado participantes e proporcionam uma sensação de confiabilidade. À medida que o ecossistema Polygon continua a crescer, este deverá contribuir para estabelecer o POL como um ativo digital atraente e confiável, que posteriormente poderia estimular ainda mais a adoção e a confiabilidade, criando assim um 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.
Camada de piquetagem
Realizar a visão da Camada de Valor da Internet exigirá eventualmente a rede Polygon para hospedar bilhões de usuários e milhões de aplicativos Web3. Para permitir este vasto nível de atividade, centenas ou milhares de Polygon cadeias estarão funcionando em paralelo, protegidas por dezenas ou centenas de milhares de validators. Para coordenar todas as cadeias Polygon e validators, a arquitetura do protocolo Polygon redesenhada introduz a camada de piquetagem. O Staking Layer é um protocolo coordenador multicadeia programável único. Por orquestrando todos os Polygon validators e cadeias, permite: ● Escalabilidade ilimitada do ecossistema; ● Acesso simples e automatizado à infraestrutura Web3 dedicada para qualquer projeto Web3. A indústria Web3 foi iniciada por Bitcoin, o primeiro blockchain de sucesso com um único aplicação – moeda digital. À medida que novas aplicações e casos de uso eram propostos, eles normalmente lançavam seus próprios blockchains, que eram lentos e complexos. Isso foi abordado pelo segundo grande avanço da Web3 – Ethereum, um blockchain programável que pode suportar qualquer aplicativo ou caso de uso. Apesar de ser uma enorme mudança de paradigma, o principal A limitação de Ethereum é que ele não é capaz de ser dimensionado para suportar a adoção convencional. Para mitigar esta limitação, a comunidade Ethereum recorreu a Layer 2 cadeias – blockchain arquiteturas que oferecem maior escalabilidade sem sacrificar a segurança. Com a introdução da camada de piquetagem, Polygon torna-se capaz de suportar um número praticamente ilimitado de cadeias Layer 2, cada uma totalmente programável tanto no nível da aplicação quanto no nível de configuração. Acreditamos que isso pode ser o terceiro avanço mais importante desde o início da Web3, dada a magnitude de inovação e adoção que permite.
Descrever e especificar detalhadamente a camada de piqueteamento está fora do escopo deste artigo. Em vez disso, e para obter uma melhor compreensão desta camada alimentada por POL e seu potencial, fornecemos uma visão geral de seus seguintes aspectos: ● Desenho e implementação; ● Polygon gerenciamento de cadeias; ● Gerenciamento de validadores. 6.1 Projeto e implementação Conforme mencionado acima, a Camada de Staking é um coordenador programável de múltiplas cadeias. Ele gerencia dois componentes lógicos principais: 1. Validador registro: Mantém o atualizado registro de validators, com seu participações e cadeias POL correspondentes às quais estão inscritos; 2. Corrente registro: Mantém o registro atualizado das cadeias Polygon, com seus configurações correspondentes. A principal característica que a Camada de Staking exige é total programabilidade; permite-lhe apoiar e coordenada: ● Configurações arbitrárias de cadeias Polygon; ● Todas as operações relacionadas a validator; ● Operações e aplicações de suporte arbitrárias, por ex. staking derivados. A maneira ideal de obter programabilidade é utilizando EVM (Ethereum Máquina Virtual), uma vez que oferece uma série de benefícios: ● Completude de Turing; ● Maturidade do EVM, linguagens de nível superior (por exemplo, Solidity) e ferramentas; ● Base de desenvolvedores etc. Na prática, isso significa que a camada de staking será implementada como um conjunto de EVM inteligentes contratos. Esses smart contracts podem ser implantados em qualquer EVM blockchain, provavelmente em Ethereum ou Polygon zkEVM rollup, visto que ambos oferecem alto nível de segurança. 6.2 Polygon gerenciamento de cadeias A camada de staking pode suportar um número praticamente ilimitado de cadeias Polygon, cada uma com recursos e configurações arbitrários e fornecer-lhes o nível necessário de descentralização.O principal serviço que a Camada de Staking fornece às cadeias Polygon é o gerenciamento de seus validator requisitos e validator conjuntos estabelecidos de acordo com esses requisitos. Os requisitos do validador são especificados em uma configuração smart contract que cada cadeia Polygon implanta para ser iniciado. Este smart contract pode definir requisitos validator arbitrários, incluindo mas não limitado a: ● Número máximo validator: especifica o número máximo de validators da cadeia aceita em seu conjunto validator. ● Número mínimo de validator: O número mínimo de validators necessários para iniciar o cadeia. ● Ofensas cortáveis: Ofensas de validação atribuíveis na cadeia que causam corte do aposta; ● Critérios validadores: O único critério comum para todos os validators no Staking Hub é uma aposta na POL. Podem ser especificados critérios adicionais arbitrários, tais como autorização por um terceiro parte, participação adicional em outros tokens (por exemplo, tokens nativos de cadeias Polygon individuais) etc. Além da capacidade de configurar requisitos validator, as cadeias Polygon podem arbitrariamente configurar todos os outros parâmetros e recursos de sua arquitetura. Estes não estão definidos no Nível de piquetagem da camada, mas em vez disso no código do cliente de cadeias Polygon. Alguns parâmetros notáveis e os recursos são: ● token nativo: Chains podem criar seus tokens nativos que podem ser usados para vários propósitos, por ex. taxas de transação, incentivo ao usuário, etc. ● Gerenciamento de taxas: as redes podem decidir como gerenciar as taxas de transação. Normalmente, taxas de transação seriam repassadas para validators em sua totalidade, mas outras distribuições modelos são possíveis, por ex. queimando uma parte das taxas e repassando o restante para validators. ● Recompensas adicionais: Todos os Polygon validators recebem recompensas de protocolo base (conforme descrito em § 4.2) e normalmente taxas de transação de cadeias Polygon que eles validam. Para atrair mais cadeias validators, Polygon podem oferecer recompensas adicionais além dessas. Estes as recompensas provavelmente estarão frequentemente em tokens nativos dessas redes. ● Tempo e tamanho do bloco: É possível configurar a frequência e tamanho, ou seja, limite de gás de blocos. ● Tempo do ponto de verificação: os conjuntos de validadores fornecem finalidade local rápida para cadeias Polygon. Além disso para isso, todas as cadeias Polygon geram e enviam periodicamente provas de conhecimento zero paraEthereum, aproveitando assim sua alta segurança. A frequência desses pontos de verificação pode ser configurado (por exemplo, a cada 5 minutos). ● Disponibilidade de dados: O modelo de disponibilidade de dados também pode ser especificado. As cadeias podem decidir aproveitar Ethereum (modelo rollup) ou seus próprios conjuntos validator ou outros dados externos serviço de disponibilidade (modelo Validium). Com a estrutura proposta, lançar uma nova cadeia Polygon praticamente se resume a escrever e implantando a configuração mencionada smart contract. Assim que o contrato for implantado no Camada de staking, validators podem começar a assiná-la. Quando o número mínimo necessário de validators é alcançado, a cadeia é lançada. Acreditamos que esta forma simples de configurar e lançar cadeias pode inaugurar uma nova era de inovação e adoção. A decisão de design revolucionária de Ethereum foi não tentar prever quais aplicativos e casos de uso os desenvolvedores desejarão construir. Em vez disso, ofereceu um Ambiente programável Turing completo que pode oferecer suporte a qualquer aplicativo ou caso de uso. Com a camada de staking, Polygon está adotando a mesma abordagem para lançar novas cadeias – ela suporta praticamente qualquer projeto de corrente, de forma programável e sem limitações de escala. 6.3 Gerenciamento do validador A camada de piquetagem pode suportar um número praticamente ilimitado de validators. Ele gerencia validators durante todo o seu ciclo de vida e permite-lhes proteger diferentes tipos de incentivos para a realização de trabalho útil. Existem quatro fases possíveis, ou seja, status, no ciclo de vida validator: 1. Ativação: os validadores são iniciados como parte do pool validator depositando POL no staking contrato na camada de piquetagem. Uma vez iniciado, validators tornam-se elegíveis para receber recompensas de protocolo base (descritas em § 4.2). 2. Assinatura: uma vez iniciada, validators podem se inscrever para validar qualquer Polygon cadeia. 3. Validação: Se um validator atender a todos os critérios da cadeia Polygon que ele assinou, ele torna-se membro do conjunto validator dessa cadeia. Os validadores podem validar múltiplas cadeias, e sua participação no POL é reconhecida em cada uma dessas cadeias. Se um validator for cortado para uma ofensa cortável predefinida em uma das cadeias, seu saldo POL é atualizado e refletido em todas as cadeias que valida. As fases de validação e subscrição podem
sobreposição; um único validator pode estar na fase de assinatura em uma cadeia Polygon e em a fase de validação em outra. 4. Aposentadoria: os validadores podem sair do pool validator a qualquer momento. Assim que a aposentadoria for iniciado, um período de espera predefinido começa, permitindo potenciais pendências cortando. Após o período de espera, validators podem retirar sua aposta POL de o contrato de depósito. Em troca da validação das cadeias Polygon, os validators podem estabelecer pelo menos três fluxos de incentivos: 1. Recompensas de protocolo: conforme descrito acima, cada Polygon validator ativo está recebendo base recompensas de protocolo. A emissão total de POL para recompensas validator (descritas no § 5.2) é distribuído para validators ativos proporcionalmente à sua participação no POL. 2. Taxas de transação: os validadores podem validar qualquer número de cadeias Polygon. Em retorno, essas cadeias normalmente concederão a totalidade ou parte das taxas de transação para validators. 3. Recompensas adicionais: conforme mencionado acima, algumas redes Polygon podem optar por introduza recompensas adicionais para atrair mais validators. Essas recompensas podem ser em qualquer token, incluindo, entre outros, POL, stablecoins ou tokens nativos desses Polygon correntes. Ao descrevermos os incentivos validator, vale a pena notar que o conceito de validação em Polygon é mais ampla do que a definição usual e estreita. Isto melhora ainda mais a proposta de valor do Função validator – além de validar múltiplas cadeias, validators também podem executar múltiplas funções em uma única cadeia. As funções mais comuns provavelmente serão: ● Validação no sentido estrito: Aceitar transações do usuário, determinando sua validade e blocos geradores; ● Prova: Produzindo provas de conhecimento zero da validade da transação; ● Disponibilidade de dados: Fornecer garantias de que os dados da transação serão publicados e publicamente disponível.
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.
Tesouro Comunitário
O ecossistema Polygon e toda a indústria Web3 ainda estão em fase de adoção inicial e pesada fase de desenvolvimento. Para permanecer na atual trajetória de crescimento, o ecossistema Polygon necessitam de apoio económico contínuo nos próximos anos.
Para responder à necessidade de apoio contínuo ao ecossistema, propomos o Tesouro Comunitário, um fundo de ecossistema governado pela comunidade, dentro do protocolo. Introduz pelo menos três grandes benefícios para o ecossistema Polygon: ● Apoio económico contínuo e autossustentável durante o tempo que for necessário; ● Aumento da descentralização através da redução da dependência da Fundação Polygon; ● Alcançando o próximo nível de transparência e inclusão comunitária. Tal como descrito no ponto 5.2, o Tesouro Comunitário é financiado por uma emissão pré-determinada de POL. A taxa de emissão dedicada a este fim é de 1% ao ano, ou ≈100 milhões de POL em valor absoluto prazos e não pode ser alterado por 10 anos. Isto garante um forte apoio ao ecossistema durante este período, crítico para o desenvolvimento, crescimento e posicionamento de Polygon. Assim que o ecossistema Polygon e a Web3 atingirem a maturidade, o ecossistema provavelmente não precisará apoio económico significativo. Nesse ponto, a comunidade deve intervir e diminuir ou interromper a emissão para o Tesouro Comunitário. Num cenário optimista, quando o vencimento for atingido antes de expirar o período de 10 anos de financiamento garantido, o O Tesouro Comunitário pode acabar por ter mais fundos do que o ecossistema necessita realisticamente. Em nesse caso, a comunidade deverá decidir como utilizar este excesso de POL. Por exemplo, uma decisão pode ser feito para queimá-lo. Como foi referido, e como o nome indica, o Tesouro Comunitário deverá ser regido pelo comunidade, através de um processo de governação acordado. O processo de governação e o contexto mais amplo A estrutura de governança Polygon está sendo projetada e estabelecida como parte do Polygon 2.0 esforço, e explicá-los em detalhes está fora do escopo deste artigo. Em vez disso, damos uma breve visão geral de seus dois conceitos prováveis: 1. Polygon Propostas de Financiamento (PFPs): Propostas formais de financiamento ou outras atividades ou melhorias relacionadas com o Tesouro Comunitário. Os PFPs podem ser enviados por qualquer pessoa, e deve estar disponível publicamente e ser discutido. Conceitos semelhantes podem ser observados em outros quadros de governação proeminentes4,5. 2. Obtenção de consenso: O processo de tomada de decisão sobre um PFP específico. O a decisão pode ser tomada de maneira direta, onde cada membro da comunidade pode participar, ou através de delegados que representam a comunidade. Conforme mencionado no § 4.3, POL deve ser tecnicamente habilitado para deter direitos de governança, para que possa ser potencialmente utilizado 5 https://docs.aave.com/governance/ 4 https://uniswap.org/governance
como parte da reunião de consenso ou do processo de eleição de delegados. Os titulares de POL são diretamente incentivados economicamente a aprovar boas propostas e rejeitar as ruins, o que torna o processo de tomada de decisão mais provável de beneficiar o ecossistema. Simulámos as entradas contínuas do Tesouro Comunitário no § 9.
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.
Migração
Dado que o POL está sendo proposto como sucessor do MATIC, o atual token nativo do Polygon, a migração do antigo para o novo token precisaria ocorrer. O fornecimento inicial de POL proposto no § 5.1 corresponde ao fornecimento atual de MATIC e foi propôs simplificar tanto quanto possível o processo de migração. Para autocustódia MATIC titulares, a migração exigiria uma ação simples – trocar de MATIC para POL, usando o trocando smart contract que deveria ser criado para esse fim. O contrato de troca deverá aceite MATIC de qualquer endereço e devolva a quantidade equivalente de POL para o mesmo endereço. Para detentores de MATIC que mantêm seus tokens com exchanges e custodiantes de criptografia centralizados, a migração normalmente seria automática, ou seja, não exigiria nenhuma ação. Todo titular de MATIC deve poder trocar seus tokens por POL, incluindo aqueles que têm MATIC “bloqueado” por vários anos em vários DeFi ou contratos de aquisição, ou os desinformados titulares que descobrirem sobre o POL em algum momento no futuro. Por esta razão, a migração deve ser permitido que aconteça durante um período prolongado de tempo (por exemplo, 4 anos), se não indefinidamente. A migração deve ser voluntária, ou seja, não pode ser forçada. No entanto, se o POL for aceito pelo maioria da comunidade como o novo nativo token, haverá pouca ou nenhuma razão para manter o MATIC em vez de POL. Nesta situação, é razoável esperar que a migração seja praticamente totalmente executado, ou seja, a grande maioria do MATIC será migrada.
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
Com base no projeto do POL e da Camada de Staking, propomos um modelo para simular importantes indicadores de desempenho do ecossistema movido a POL, fornecer os insumos necessários e analisar o resultados de simulações.
9.1 Hipótese O objetivo do modelo é validar a hipótese de que a proposta alimentada por POL ecossistema pode atender simultaneamente aos seguintes objetivos, derivados do § 3º: ● Segurança suficiente do ecossistema: Medimos a segurança através da proporção POL staking, ou seja, porcentagem do fornecimento POL apostado por validators. A proporção mínima satisfatória é 30-40%, aproximadamente equivalente à proporção atual de staking na cadeia PoS Polygon6. ● Incentivos validator suficientes: Para estimar a suficiência de incentivos validator, nós introduzem o Retorno sobre o Trabalho (ROW), a medida dos ganhos totais de validator em relação ao valor do POL apostado. O retorno mínimo satisfatório é de 4-5%; retornos mais baixos não são considerada suficientemente atrativa, considerando o trabalho realizado, os riscos e a custos de oportunidade. ● Apoio ecossistêmico suficiente: Medimos o apoio ecossistêmico por meio de fluxo anual ao Tesouro Comunitário. A entrada mínima satisfatória é de 50 a 100 milhões de dólares e é determinado com base no nível atual de apoio econômico ao ecossistema Polygon necessidades. Definimos explicitamente estes indicadores (rácio staking, retornos validator e entrada de tesouraria) no § 9.3. 9.2 Entradas Neste capítulo descrevemos as entradas necessárias do modelo e estimamos seus valores respeitáveis. Primeiro, definimos três cenários de crescimento, projetando o número abstrato de cadeias no Polygon ecossistema durante o período inicial de 10 anos. Nos referimos ao número de cadeias como abstrato porque não expressa necessariamente o número exato de Polygon cadeias (embora isso pode ser o caso), mas mais o nível cumulativo de atividade, ou seja, transações no ecossistema. 6 Fonte: https://staking.polygon.technology/
Figura 3. Cenários de crescimento de 10 anos A justificativa para os cenários de crescimento baseia-se nos seguintes dados e observações: ● Trajetória atual de crescimento. Desde o início em 2020, o ecossistema Polygon cresceu para milhares de aplicativos e 3 milhões de transações diárias7. Se esta tendência mesmo continua remotamente, os cenários de crescimento propostos parecem realistas. ● Mercados de aplicativos Web2: A App Store hospeda cerca de 1,8 milhão de aplicativos8 e Google Play cerca de 2,7 milhões9; ambos foram introduzidos há cerca de 14 anos. Poderia ser razoável esperar um nível comparável de adoção para Web3 em um ambiente comparável prazo. ● Adoção de Supernets: No momento em que escrevo este artigo, um ano desde a introdução de Supernets, existem mais de 100 projetos candidatos a Supernets, muitos deles em desenvolvimento ativo. Com base nisso, os cenários de crescimento propostos para As Supernets parecem realistas, especialmente tendo em conta que a implantação das Supernets deve tornar-se significativamente mais fácil quando a camada de staking (descrita no § 6) for introduzida. Além disso, é perceptível que a tendência de interesse nas Supernets é mais forte em termos relativos do que um para redes públicas. Por esta razão, estamos assumindo o mesmo para a proposta cenários de crescimento. Para justificar ainda mais isso, um paralelo significativo com o histórico de adoção da Web2 pode ser desenhado. Nos primeiros dias da Web2, hospedagem compartilhada de aplicativos – equivalente à Web2 às redes públicas – era muito mais comum do que hoje. À medida que a indústria amadureceu, 9 Fonte: https://www.appbrain.com/stats/number-of-android-apps 8 Fonte: https://www.apple.com/newsroom/2022/04/report-finds-third-party-apps-see-global-success-on-the-app-st minério/ 7 Fonte: https://polygonscan.com/chart/txhospedagem dedicada – Web2 equivalente a Supernets – tornou-se a norma para todos aplicativo com uma base de usuários e nível de atividade significativos. Novamente, o número de cadeias Polygon é um conceito abstrato em nosso modelo; em conjunto com o número de transações por cadeia, deve refletir principalmente o nível de atividade económica no ecossistema. Da mesma forma, a prevalência, ou seja, a proporção de Supernets em comparação com cadeias públicas, é um suposição abstrata e conservadora. Se descobrisse que as redes públicas são mais populares em relação às Supernets, os resultados da simulação apresentados em § 9.4 seriam semelhantes ou melhor, devido aos seus respectivos níveis de taxas de transação. Para complementar os cenários de crescimento acima mencionados, estimamos os seguintes insumos: ● Fornecimento inicial de 10 mil milhões de POL, conforme descrito no § 5.1; ● Taxa de emissão anual de 1% para incentivos validator, conforme descrito no § 5.2; ● Taxa de emissão anual de 1% para o Tesouro Comunitário, conforme descrito no § 5.2; ● Preço médio do POL de US$ 5 durante o período de 10 anos; ● 38 transações/segundo em média por cadeias públicas, comparável ao atual Polygon Uso da cadeia PoS10; ● 19 transações/segundo ligado média por Super-rede, um estimativa baseado ligado o requisitos de projetos de Supernet; ● Taxa média de transação de US$ 0,01 em redes públicas, uma estimativa baseada na média atual taxas na cadeia PoS Polygon;11 ● Taxa média de transação de US$ 0,001 em Supernets, estimativa conservadora dada abundante blockspace e uma “corrida para o fundo” que provavelmente causará nas taxas de transação; ● 100 validators em média por cadeia pública, equivalente ao tamanho atual do conjunto validator de Polygon PoS; ● 15 validators em média por Supernet, com base em requisitos e necessidades realistas de Candidatos à Supernet; ● Custos operacionais médios de US$ 6.000/ano por validator, equivalente ao PoS atual de Polygon dados, diminuindo gradualmente de acordo com uma versão modificada da Lei de Moore (50% diminuição em 3 anos). Vale ressaltar que o preço do POL, embora seja um dos insumos necessários do modelo, direta e afecta significativamente apenas a entrada do Tesouro Comunitário e não outros factores-chave de desempenho indicadores. Além disso, as estimativas de taxas de transação não levam em conta o custo da disponibilidade de dados em 11 Fonte: 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.
Fonte: https://polygonscan.com/chart/tx
Ethereum para cadeias Polygon que usam o modelo rollup; ignoramos esse custo porque ele é repassado para Ethereum. 9.3 Metodologia Definimos um modelo simples para estimar os principais indicadores de desempenho do ecossistema, e validar a hipótese do § 9.1. Os principais indicadores e a metodologia para determiná-los são os seguintes: ● Proporção de piquetagem ( ): A parte do fornecimento POL apostada por validators. 𝑆𝑟 𝑆𝑟= 𝑆𝑠 / 𝑆𝑡 Onde é o fornecimento apostado, ou seja, quantidade total de POL apostado por validators, e é total 𝑆𝑠 𝑆𝑡 fornecimento, ou seja, fornecimento atual de POL. ● Incentivos de emissão de validadores ( ): Incentivos anuais validator provenientes do POL 𝑉𝑖𝑖 emissão. 𝑉𝑖𝑖= 𝑆𝑡 × 𝐼𝑣 × 𝑃 Onde é a oferta total, é a taxa de emissão anual para recompensas validator e é POL 𝑆𝑡 𝐼𝑣 𝑃 preço. ● Incentivos de taxas do validador ( ): Incentivos anuais validator provenientes de taxas de gás. 𝑉𝑖𝑓 𝑉𝑖𝑓= 𝐶𝑝 × 𝑇𝑝× 𝐹𝑝 + 𝐶𝑠 × 𝑇𝑠× 𝐹𝑠 Onde é o número de redes públicas, é o número de transações por cadeia pública, 𝐶𝑝 𝑇𝑝 𝐹𝑝 é a taxa média de transação por rede pública, é o número de Supernets, é o número de 𝐶𝑠 𝑇𝑠 transações por Supernet e é a taxa média de transação por Supernet. 𝐹𝑠 ● Custos de funcionamento do validador ( ): Custos operacionais anuais acumulados de todos os Polygon validators. 𝑉𝑐 𝑉𝑐= (𝑁𝑝 × 𝐶𝑝+ 𝑁𝑠 × 𝐶𝑠) × 𝑌 Onde é o número de validators por cadeia pública, é o número de redes públicas, é 𝑁𝑝 𝐶𝑝 𝑁𝑠 número de validators por Supernet, é o número de Supernets e estão em execução anual 𝐶𝑠 𝑌 custos para um único validator. ● Retorno do Trabalho ( ): Ganhos totais de validator expressos como uma porcentagem do valor 𝑉𝑟 de POL apostado. 𝑉𝑟= (𝑉𝑖𝑖 + 𝑉𝑖𝑓 − 𝑉𝑐) / (𝑆𝑠 × 𝑃)
Onde são validator incentivos de emissão, são validator incentivos de taxas, são 𝑉𝑖𝑖 𝑉𝑖𝑓 𝑉𝑐 validator custos operacionais, é o fornecimento apostado e é o preço POL. 𝑆𝑠 𝑃 ● Entrada do Tesouro Comunitário ( ): Entrada total anual para o Tesouro Comunitário. 𝑋𝑖 𝑋𝑖= 𝑉𝑖𝑖= 𝑆𝑡 × 𝐼𝑡 × 𝑃 Onde é a oferta total, é a taxa de emissão anual para o Tesouro Comunitário e é 𝑆𝑡 𝐼𝑡 𝑃 Preço POL. 9.4 Resultados O modelo aceita as entradas necessárias e as processa usando a metodologia apresentada. Os resultados para diversos conjuntos de dados podem fornecer insights interessantes sobre o ecossistema e sua dinâmica, incluindo, mas não limitado a: ● A atratividade e sustentabilidade dos incentivos validator; ● O montante e a dinâmica das entradas do Tesouro Comunitário; ● A estrutura dos incentivos validator e suas mudanças ao longo do tempo; ● O efeito do preço em todos os indicadores observados; ● O efeito dos diferentes níveis de adoção para todos os indicadores observados, etc. Aqui executamos o modelo com as entradas fornecidas no § 9.2 e observamos os três indicadores necessário para validar nossa hipótese inicial: relação staking ( ), validator incentivos ( ) e tesouraria 𝑆𝑟 𝑉𝑖 entrada ( ). 𝑋𝑖 Com base nos resultados do modelo, estamos razoavelmente confiantes de que o motor POL descrito ecossistema pode atingir todos os três objetivos descritos no § 9.1: ● Segurança suficiente do ecossistema: corrigimos a proporção staking ( ) em 30% e executei o 𝑆𝑟 modelo. Dado que os restantes dois indicadores – validator incentivos ( ) e tesouraria 𝑉𝑖 entrada ( ) – apresentam valores esperados ou superiores ao esperado, concluímos que o 𝑋𝑖 O índice staking deve manter níveis satisfatórios ou superiores a satisfatórios. ● Incentivos validator suficientes: Os resultados mostram que o Retorno sobre o Trabalho desejado ( ) 𝑉𝑟 de 4-5% é realista de se esperar. Além disso, atinge ≈7% para crescimento médio e ≈10% para cenário de rápido crescimento. Na realidade, isso provavelmente faria com que a proporção staking aumentasse (portanto aumentando ainda mais a segurança do ecossistema), até que o mercado determine o equilíbrio entre a relação staking e os retornos.● Apoio ecossistêmico suficiente: Os resultados mostram que o nível mínimo satisfatório de as entradas do Tesouro Comunitário ( ) de 50-100 milhões de dólares por ano é realista de se esperar. 𝑋𝑖 Além disso, atinge níveis significativamente mais elevados no final do período de 10 anos. No entanto, a entrada do tesouro está directamente relacionada com o preço do POL e, portanto, altamente especulativo. Se o tesouro acabar tendo mais fundos do que o ecossistema, realisticamente necessidades, a comunidade pode decidir queimar o POL excedente, conforme mencionado no § 7. Figura 4. Retorno do Trabalho e entrada do Tesouro Comunitário O modelo completo é de código aberto e pode ser acessado no GitHub e usado para produzir e analisar resultados para conjuntos arbitrários de entradas. 10 Conclusão A visão por trás de Polygon é construir a camada de valor da Internet. Para alcançar esta visão, o a arquitetura de protocolo Polygon redesenhada apresenta um novo, infinitamente escalável e perfeitamente rede interconectada de cadeias Layer 2. Neste artigo, apresentamos POL, o token nativo proposto de Polygon, projetado para proteger, coordenar e alinhar o ecossistema Polygon e impulsionar seu crescimento. O projeto proposto e tokenômica do POL atingem as rigorosas metas de design que definimos. Criamos um modelo para simular os principais indicadores de desempenho do ecossistema alimentado pelo POL, forneceu as informações necessárias do modelo e analisou os resultados da simulação. Os resultados confirmou a hipótese do modelo, derivada dos objetivos de design acima mencionados.
Com base em tudo acima, concluímos que o POL é um ativo novo e de próxima geração que fornece uma base sólida para Polygon alcançar sua visão ambiciosa.