Emissão e inflação do POL

A emissão de POL é o processo que cria um novo POL após a oferta inicial de 10 bilhões de tokens e direciona os tokens recém-cunhados para o financiamento do validador e para o Tesouro da Comunidade Polygon.

Este tópico também é comumente descrito como inflação de POL, inflação de MATIC, inflação de token Polygon, emissão de POL ou taxa de inflação de POL. Essas frases estão relacionadas, mas não idênticas. Neste guia, emissão significa novo POL cunhado pelo protocolo, enquanto inflação líquida significa o crescimento da oferta resultante após a dedução da queima de tokens. “Inflação MATIC” continua sendo um termo de pesquisa legado comum porque POL substituiu MATIC e herdou sua transição de recompensa do validador, mas o atual sistema de emissão Ethereum cunha POL.

A emissão é uma parte comum do projeto econômico das principais redes da Camada 1, e não algo exclusivo do POL. As redes de prova de aposta usam a emissão de novos tokens para recompensar a participação do validador e apoiar a segurança da rede a longo prazo. Ethereum cunha ETH como recompensas de validador, enquanto Solana distribui emissão SOL inflacionária para validadores e contas de participação delegada. As taxas e regras de distribuição diferem de acordo com a rede, mas o objetivo subjacente é semelhante: financiar os participantes e a infraestrutura que mantêm a rede operando com segurança.

As emissões brutas não determinam por si só o crescimento líquido da oferta. A queima de tokens pode compensar parcial ou totalmente os tokens recém-emitidos:

Net issuance = newly minted tokens - burned tokens

Se a queima for inferior à emissão, a oferta ainda cresce, mas de forma mais lenta. Se a queima exceder a emissão, a emissão líquida será negativa naquele período. Polygon Chain tem sua própria mecânica de roteamento e queima de taxa básica, que POLTRACK mede separadamente da cunhagem. Consulte POL Burn para obter o histórico completo de queima e Polygon Chain Fees para ver a mecânica das taxas de transação.

Este guia separa três coisas que muitas vezes são combinadas incorretamente:

1. a política proposta no white paper POL;
2. o cronograma de emissão efetivamente executado na rede principal Ethereum;
3. cenários futuros que exigiriam uma nova decisão protocolar.

A versão curta é:

• POL lançado em Ethereum com um oferta inicial de 10 bilhões de tokens;
• sua taxa de emissão da rede principal passou de 3% para 2.5% e depois para 2% em PIP-26;
• a actual implementação visa a emissão anual composta de 2%, dividida igualmente entre o StakeManager e o Tesouro Comunitário;
• o contrato acumula emissão continuamente ao longo do tempo, mas os tokens são cunhados nas transações quando mint() é chamado;
• POLTRACK usa 25 de outubro de 2033 como a data final atual da linha de base para a janela de inflação de dez anos publicada;
• Polygon não adotou proposta que defina um ponto final posterior ou uma taxa de emissão pós-2033;
• a interrupção da emissão ainda requer uma mudança deliberada de protocolo porque o contrato ativo não tem data de término automático;
• uma paragem antecipada é tecnicamente possível através dos mesmos controlos contratuais, mas não é o calendário actualmente anunciado;
• o excesso do Tesouro Comunitário POL não é queimado automaticamente. O whitepaper diz que a comunidade poderia decidir separadamente queimar os fundos excedentes.

Acompanhe os números atuais em POLTRACK: Fluxo de valor mostra POL cunhado junto com queima, Tesouro Comunitário e fluxos de validação, enquanto Oferta mostra a oferta circulante, a oferta máxima esperada e a emissão líquida.

Histórico da Mainnet Executado

A implementação atual do 2% não esteve ativa durante todo o histórico do POL. PIP-26 preservou os anos finais do cronograma original de recompensas do validador MATIC antes de fazer a transição para a taxa de validador 1% de longo prazo proposta para POL.

O histórico do proxy EmissionManager registra todas as quatro implementações da rede principal.

v1.0: O design pré-Mainnet 2%

O código v1.0 do repositório implementou o design original do 1% + 1%:

Supply(t) = 10B * 1.02 ^ (elapsed / 365 days)

Esta versão foi usada no trabalho de implantação pré-mainnet. A mainnet Ethereum foi lançada com a v1.1 depois que PIP-26 definiu o cronograma de transição do validador, portanto a v1.0 não era um período de emissão da mainnet.

v1.1: 3% desde o lançamento da Mainnet

Mainnet v1.1 começou em 25 de outubro de 2023 com:

Supply(t)
= 10,000,000,000 * 1.03 ^ (elapsed since launch / 365 days)

Um terço de cada cunhagem foi para o multisig original do Tesouro Comunitário e dois terços financiaram recompensas do validador. Para compatibilidade com versões anteriores, a parte do validador foi enviada por meio do contrato de migração e convertida novamente para MATIC antes de chegar a StakeManager.

A transação de implantação da rede principal instalou a implementação 0x2126E6952C3af75C9D4CF21f63F509195C79ce44 atrás do proxy.

v1.2: 2,5% e uma nova base de cálculo

Em 6 de julho de 2024, o Conselho do Protocolo executou a primeira redução de PIP-26, do financiamento do validador 2% para 1.5%, enquanto a emissão do tesouro permaneceu 1%.

A transação de atualização v1.2 executou uma sequência atômica:

1. chame mint() na v1.1 para realizar todas as emissões atribuídas à antiga curva 3%;
2. atualizar o proxy para implementação 0x5e875267f65537768435C3C6C81cd313a570B422;
3. ligue para reinitialize() na nova implementação;
4. salve o totalSupply resultante como START_SUPPLY_1_2_0;
5. defina startTimestamp para o tempo de bloqueio de atualização.

A base resultante foi:

START_SUPPLY_1_2_0 = 10,208,953,168.522375 POL
startTimestamp     = 2024-07-06 17:47:59 UTC

Supply(t)
= START_SUPPLY_1_2_0 * 1.025 ^ (elapsed / 365 days)

A mesma atualização também redirecionou as ações em tesouraria para a configuração do Tesouro Comunitário introduzida por PIP-40. A sequência e os requisitos de validação estão documentados no [Relatório de Transparência do Conselho PIP-26 / PIP-40] oficial (https://forum.polygon.technology/t/council-transparency-report-pip-26-40/18027).

v1.3: Financiamento direto POL para StakeManager

Em 4 de setembro de 2024, v1.3 alterou o caminho de transferência do validador sem alterar a taxa de emissão, base ou carimbo de data/hora de início.

// Before v1.3: convert the validator share back to MATIC
migration.unmigrateTo(stakeManager, stakeManagerAmt);

// From v1.3: transfer newly minted POL directly
_token.safeTransfer(stakeManager, stakeManagerAmt);

A atualização v1.3 instalou a implementação 0x152442D77E9fB9C210953d583Cbb2da88027fCB9. Não reinicializou a curva de emissão. Isso implementou PIP-41 como parte da transição de staking de MATIC para POL descrita no relatório oficial de transparência.

v1.4: O cronograma atual de 2%

Em 9 de julho de 2025, o Conselho do Protocolo concluiu a transição planejada de PIP-26, reduzindo o financiamento do validador de 1.5% para 1%. A emissão do Tesouro permaneceu 1%.

A transação de atualização v1.4 fechou novamente o período antigo antes de mudar as taxas:

Catch-up mint under old 2.5% curve: 1,168,637.300101 POL
Treasury share:                         467,454.920041 POL
StakeManager share:                     701,182.380061 POL

Em seguida, instalou a implementação 0x282FD46E108E40A45e4CE425bA75f80245e6C2E0 e reinicializou a curva da oferta resultante.

O [Relatório de Transparência do Conselho PIP-26 2025] oficial (https://forum.polygon.technology/t/council-transparency-report-pip-26/21112) especifica explicitamente a antiga chamada mint(), atualização de proxy, reinitialize(), nova oferta inicial e novo carimbo de data/hora.

As seções abaixo explicam os dois fluxos de financiamento e a mecânica contratual por trás desse histórico executado.

Os dois fluxos de emissão

O projeto POL estabelece duas finalidades econômicas para a emissão.

Estes são objectivos políticos distintos, embora a implementação actual calcule uma curva de oferta combinada 2% e divida cada cunhagem ao meio.

O whitepaper descreve cada fluxo como até 1% da oferta crescente de POL e define um período inicial de financiamento de dez anos. POLTRACK, portanto, usa 25 de outubro de 2033, dez anos após o primeiro carimbo de data/hora EmissionManager da rede principal, como o horizonte de planejamento atual para a inflação programada. Nenhum PIP adotado define um ponto final posterior ou uma taxa pós-2033.

A data é um ponto final da apólice e não um prazo automático do contrato. O EmissionManager ativo não possui desligamento integrado, portanto, o encerramento ou redução da emissão em 2033 deve ser implementado por meio de uma mudança de protocolo. Os mesmos controles poderiam tecnicamente interromper a emissão mais cedo, embora nenhuma decisão Polygon publicada atualmente faça uma interrupção antecipada do cronograma do caso base.

Oferta e emissão inicial

Os 10 bilhões iniciais de POL e as emissões posteriores são eventos de token diferentes.

No lançamento, o contrato de token POL cunhou 10 bilhões de POL para o contrato de migração para que os detentores de MATIC pudessem migrar na proporção de 1:1. A migração normal de MATIC para POL move tokens para fora desse pool inicial; não é uma emissão programada.

Nova oferta após o lançamento só pode ser criado por um endereço que contenha o EMISSION_ROLE do contrato de token. Na rede principal, essa função é mantida pelo proxy DefaultEmissionManager.

Initial POL supply = 10,000,000,000 POL

Later gross supply change
= POL minted by the authorized EmissionManager
- any true ERC-20 supply-reducing burn

Transferências para tesouraria, StakeManager, contrato de migração, coletor ou endereço morto não criam tokens. O mint é o token POL Transfer do endereço zero até o EmissionManager.

Como funciona o contrato atual

A implementação atual da rede principal é DefaultEmissionManager v1.4. Ele armazena um suprimento inicial e um carimbo de data e hora inicial, calcula um suprimento alvo dependente do tempo e calcula a diferença entre o alvo e o POL totalSupply atual.

Sua fórmula simplificada é:

TargetSupply(t)
= StartSupply * 1.02 ^ (elapsedSeconds / 365 days)

AmountToMint
= TargetSupply(t) - CurrentTotalSupply

A implementação do Solidity representa o fator anual por meio de exponenciação binária de ponto fixo:

INTEREST_PER_YEAR_LOG2 = log2(1.02)

SupplyFactor
= exp2(INTEREST_PER_YEAR_LOG2 * elapsedSeconds / 365 days)

A base atual v1.4 é:

START_SUPPLY_1_4_0 = 10,466,456,329.199770 POL
startTimestamp     = 2025-07-09 23:03:59 UTC

Cada cunhagem de sucesso é dividida da seguinte forma:

Treasury amount     = AmountToMint / 2
StakeManager amount = AmountToMint - TreasuryAmount

A forma de subtração leve usada para StakeManager garante que o arredondamento de número inteiro não deixe poeira de token no EmissionManager.

A acumulação é contínua; Cunhagem é transacional

A oferta alvo cresce continuamente com o passar dos segundos, mas o contrato de token não é executado a cada segundo. mint() é uma função pública que qualquer endereço Ethereum pode chamar.

Quando alguém solicita, o gestor cunha todas as emissões que foram investidas sob a curva-alvo desde a última atualização da oferta. O chamador não recebe o POL cunhado. Os tokens vão apenas para a tesouraria configurada e destinos StakeManager.

Se ninguém ligar para mint() por vários dias, o valor programado não será perdido. Uma chamada posterior tenta alcançar a oferta até o mesmo alvo baseado em tempo.

O limite de segurança em nível de token

O contrato de token POL não atualizável aplica-se separadamente ao mintPerSecondCap. No momento desta análise, o limite era 13.37 POL per second.

Maximum amount accepted by one token mint
= seconds since the previous token mint * mintPerSecondCap

Este é um limitador de taxa e controle de segurança. Não é um limite de oferta vitalício e não estabelece um oferta máxima de POL. O endereço que contém CAP_MANAGER_ROLE pode atualizá-lo por meio de uma chamada de contrato autorizada.

Por que junho, julho e outubro aparecem

As datas descrevem diferentes conceitos:

Os documentos PIP descrevem os períodos pretendidos da apólice. Os carimbos de data/hora da transação Ethereum identificam quando a implementação realmente mudou. Um cálculo histórico preciso deve usar os carimbos de data/hora executados.

Reconstruindo a emissão executada

O histórico completo executado pode ser representado como uma curva composta por partes:

Period 1: 10B at 3% for 255.3622 days
Period 2: resulting supply at 2.5% for 368.2194 days
Period 3: resulting supply at 2% from July 9, 2025 onward

Para uma projeção exata do aniversário de dez anos do carimbo de data/hora de início original:

10,000,000,000
* 1.03  ^ (255.3622 / 365)
* 1.025 ^ (368.2194 / 365)
* 1.02  ^ (3029.4183 / 365)
= approximately 12,336,136,524.75 POL

Este é um cenário de histórico executado mais contrato atual. Ele pressupõe que a implementação atual da versão 1.4 permaneça inalterada durante o horizonte de dez anos em 25 de outubro de 2033. Não é uma garantia ou um limite máximo. POLTRACK subtrai a queima permanente desta linha de base bruta ao relatar a oferta máxima atual esperado.

Por que as projeções de oferta diferem

Suposições diferentes produzem valores diferentes, mesmo quando são internamente consistentes.

O modelo executado é a linha de base de oferta bruto máximo esperado POLTRACK atual porque reproduz o histórico do contrato. Não é um máximo imutável porque a parada ainda precisa ser implementada no protocolo.

Como as mudanças nas emissões são implementadas

As alterações nas emissões têm uma camada de proposta pública e uma camada de execução onchain.

Alterações publicadas e execução da Mainnet

O EmissionManager não é controlado pelo voto direto dos titulares do POL. Na prática, as alterações nas emissões foram publicadas por meio do repositório de propostas de melhoria Polygon, relatórios do fórum Polygon e transações de contratos públicos, e então implementadas por meio dos controles de administração de contratos do protocolo.

As alterações nas taxas de 2024 e 2025 foram documentadas antes ou juntamente com a execução. Seus relatórios de transparência identificam a implementação, as chamadas, o estado esperado e as verificações de validação, enquanto as transações Ethereum fornecem a evidência final do que foi executado na rede principal. POLTRACK, portanto, trata o PIP ou relatório como contexto de política e o estado do contrato executado como fonte de verdade para cálculos históricos.

Controles de contrato atuais

A atual estrutura de controle da mainnet observada durante esta revisão é:

A taxa atual é compilada na implementação EmissionManager como uma constante. Alterar a curva ou a divisão requer uma nova implementação e atualização de proxy. Separadamente, os administradores autorizados do token podem atualizar o limite por segundo e administrar o endereço que contém EMISSION_ROLE.

O ponto final da política de 2033 e os controles técnicos

O white paper diz que as duas taxas 1% devem permanecer fixas durante o período inicial da apólice de dez anos e podem ser reduzidas ou descontinuadas posteriormente. Nessa base, outubro de 2033 é o atual ponto de referência de POLTRACK para encerrar a inflação programada. Nenhuma proposta adotada define um ponto final posterior ou uma taxa pós-2033.

Os contratos Solidity não contêm um cronômetro imutável de dez anos. Os administradores de contrato autorizados poderiam tecnicamente atualizar o EmissionManager, alterar as funções do token ou alterar o limite máximo antes de 2033. Isso torna possível uma parada antecipada, mas não automática ou atualmente esperada: exigiria uma decisão e implementação explícita do protocolo.

Emissão do Tesouro Comunitário

O fluxo do Tesouro Comunitário é emitido ao mesmo tempo que o financiamento do validador. Na v1.4, metade de cada emissão bem-sucedida é transferida diretamente para o endereço de tesouraria configurado.

O EmissionManager não decide quais subsídios recebem fundos. A alocação e os gastos do Tesouro são administrados separadamente. PIP-40 redirecionou as emissões para os contratos do Tesouro Comunitário e descreve a estrutura do Conselho do Tesouro Comunitário.

Isso cria três questões distintas:

1. Emissões futuras do tesouro: O novo POL deve continuar a ser cunhado para suporte ao ecossistema?
2. Alocação do Tesouro: Como deve ser utilizado o tesouro já cunhado POL?
3. Excesso de tesouraria POL: A tesouraria POL que não é mais necessária deve ser retida, alocada ou queimada?

O whitepaper diz que se o ecossistema amadurecer cedo e o tesouro acumular mais POL do que realmente precisa, a comunidade deve decidir como usar o excesso. Queimá-lo é dado como uma decisão possível. Não é obrigatório e não existe mecanismo de queima automática ou data de validade para o tesouro não gasto POL.

Interromper futuras emissões do Tesouro também não queimaria automaticamente o saldo existente do Tesouro. Estas são duas ações de protocolo independentes.

O financiamento do validador não é igual às recompensas pagas

A metade do validador do EmissionManager é o financiamento enviado para StakeManager. O acúmulo real de recompensas e reivindicações do validador são controlados pela mecânica de staking e checkpoint.

Estas etapas devem ser distinguidas:

POL minted by EmissionManager
-> POL transferred to StakeManager
-> rewards accrued under staking/checkpoint rules
-> rewards claimed by validators and delegators

PIP-78 descobriu que a distribuição real de recompensas do validador após a transição de julho de 2025 estava acima da meta anual pretendida porque a frequência dos pontos de verificação havia mudado. PIP-86 recalibrou ainda mais as recompensas dos checkpoints para tempos de bloqueio mais curtos.

É por isso que uma transferência de EmissionManager para StakeManager deve ser chamada de financiamento de validador, não necessariamente recompensas pagas ou reivindicadas.

Emissão, queima e emissão líquida

A emissão e a queima são fluxos económicos separados.

Gross issuance = newly minted POL
Net issuance   = gross issuance - qualifying burn under a stated methodology

Uma transferência de endereço não reduz o ERC-20 totalSupply. Alguns processos de queima Polygon roteiam POL para coletor ou endereços mortos em vez de chamar uma função ERC-20 _burn. Os analistas devem, portanto, declarar se burn significa:

• uma redução irreversível da oferta total do ERC-20;
• uma transferência para um endereço comprovadamente irrecuperável;
• uma transferência para um coletor de queimaduras designado pela apólice;
• uma exclusão económica utilizada por um rastreador.

As queimaduras não criam uma capa dura. Eles podem compensar economicamente as emissões, mas as emissões brutas futuras permanecem governadas pelo EmissionManager ativo e pelos controles de token.

Para POL cunhado ao vivo e totais de queima, abra Fluxo de valor. Para oferta atual e emissão líquida, abra Suprimento. Para obter as classificações de queima subjacentes e o histórico de roteamento, leia POL Burn; para mecânica de taxas de transação, leia Taxas Polygon Chain.

Perguntas frequentes

A emissão de POL é igual à inflação de POL?

Não exatamente. A emissão de POL é a quantidade bruta de novos POL cunhados por EmissionManager. A inflação POL geralmente se refere ao aumento na oferta após contabilizar a queima. POLTRACK usa net issuance = minted POL - burned POL, portanto a emissão bruta pode ser positiva enquanto a inflação líquida é menor, zero ou negativa para um período selecionado.

MATIC tem inflação ou é POL inflação?

O sistema de emissão ativa cunha POL, não MATIC. A “inflação MATIC” ainda é usada informalmente porque MATIC era o token nativo anterior de Polygon e PIP-26 carregou seu cronograma de recompensa do validador para a transição POL. A migração normal 1:1 de MATIC para POL é separada da emissão e não cria oferta programado adicional.

Por que a oferta de POL está aumentando?

A oferta de POL aumenta quando o EmissionManager autorizado emite novos tokens para financiamento do validador e do Tesouro da Comunidade. A meta atual da versão 1.4 é de 2% de emissões compostas anuais. As queimas compensam parte ou a totalidade dessa emissão bruta ao calcular o crescimento da oferta líquida; consulte Queima POL e Taxas Polygon Chain.

Quanto POL é cunhado a cada ano?

A meta atual é de 2% da base de cálculo crescente por ano, e não de um número permanentemente fixo de POL. O valor aumenta ao longo do tempo, é dividido igualmente entre o financiamento do validador e o Tesouro Comunitário e é realizado em lotes de transações quando mint() é chamado. As taxas históricas foram de 3%, depois de 2,5%, antes de atingir o cronograma atual de 2%.

POL pode se tornar deflacionário?

Sim, durante um período medido, se mais POL for queimado do que cunhado. Isso não desliga a emissão bruta: significa que a queima excedeu a emissão naquele período. POLTRACK, portanto, relata a emissão, a queima e a emissão líquida como métricas separadas.

O POL tem um suprimento máximo rígido?

A oferta inicial foi de 10 bilhões de POL, e os modelos POLTRACK programaram a inflação até 25 de outubro de 2033. No entanto, essa data não é um limite rígido imutável porque o contrato ativo exige uma mudança de protocolo para interromper a emissão. Um número de oferta para 2033 é, portanto, uma projeção sob suposições declaradas, e não um máximo permanentemente codificado.

A inflação POL é exatamente 2% ao ano?

O atual EmissionManager v1.4 visa um crescimento composto anual de 2%, dividido em 1% de financiamento do validador e 1% de financiamento do tesouro. A história da Mainnet era diferente: v1.1 tinha como alvo 3%, v1.2 e v1.3 tinha como alvo 2,5% e v1.4 tinha como alvo 2%.

Quando começou a emissão de POL?

O carimbo de data e hora de início da rede principal EmissionManager é 25 de outubro de 2023 às 09:06:23 UTC. Mainnet foi lançada com a taxa de transição PIP-26 de 3%, não a taxa pré-mainnet v1.0 de 2%.

Por que PIP-26 usa junho enquanto o contrato começou em outubro?

PIP-26 herdou o calendário de junho a junho do cronograma original de recompensas do validador MATIC. O contrato POL começou em outubro de 2023, enquanto as atualizações reais do Ethereum foram executadas em julho de 2024 e julho de 2025. As datas da política e os carimbos de data/hora de execução são, portanto, cronogramas diferentes.

O que significa o período de dez anos?

O whitepaper propôs dez anos de financiamento previsível, após os quais o validador 1% de longo prazo e os fluxos de tesouraria 1% poderiam ser reduzidos ou descontinuados. POLTRACK mapeia esse período de 25 de outubro de 2023 a 25 de outubro de 2033. O contrato não contém contagem regressiva, portanto o final ainda precisa ser implementado na cadeia.

Por que POLTRACK usa 25 de outubro de 2033?

É o aniversário de dez anos do primeiro carimbo de data e hora de início da mainnet EmissionManager. Isto torna esta a data final mais clara para o modelo de dez anos do POLTRACK, e o Polygon não adotou uma proposta que defina um ponto final posterior ou uma taxa pós-2033. O contrato não faz referência direta a 2033, portanto, encerrar a emissão requer uma mudança de implementação.

A emissão de POL pode ser interrompida antes de dez anos?

É tecnicamente possível porque os administradores autorizados podem substituir a implementação EmissionManager, alterar o limite máximo ou alterar a função de emissão. Uma parada anterior exigiria uma decisão explícita de protocolo e execução on-chain; não é automático nem a linha de base atual. O atual ponto de referência continua sendo outubro de 2033.

A emissão de POL pode continuar após dez anos?

Tecnicamente, sim: a fórmula atual v1.4 não tem data de término, portanto continuaria calculando as emissões até que a implementação fosse alterada. Essa alternativa técnica não deve ser apresentada como o plano atual de Polygon. A linha de base do POLTRACK permanece em outubro de 2033; nenhum cronograma pós-2033 foi adotado.

As emissões podem ser reduzidas ou interrompidas após dez anos?

Sim. O white paper diz que a emissão do validador, a emissão do tesouro ou ambas podem ser reduzidas ou completamente descontinuadas após o período inicial da apólice. A implementação desse resultado requer uma mudança de protocolo on-chain porque a divisão e a taxa atuais da v1.4 são compiladas na implementação.

A taxa de emissão pode ser aumentada após dez anos?

O whitepaper afirma que nenhum dos fluxos de longo prazo pode ser aumentado além de 1% ao ano. A taxa anterior de validador de 2% foi uma transição temporária PIP-26 herdada do cronograma de recompensa MATIC. Embora os contratos possam ser alterados através dos seus controles administrativos, um aumento acima dos limites do whitepaper seria uma nova política, em vez de uma continuação do design publicado.

As emissões do Tesouro Comunitário são automaticamente queimadas se não forem gastas?

Não. O Tesouro POL é cunhado e transferido para o endereço do Tesouro. Os tokens não gastos permanecem ativos do tesouro. O whitepaper diz que a comunidade pode decidir queimar o excesso de POL se o tesouro acumular mais do que o ecossistema precisa, mas isso não exige esse resultado e nenhuma queima automática é realizada por EmissionManager.

O que exige a queima do excesso do Tesouro Comunitário POL?

Requer uma decisão separada do Tesouro Comunitário e uma transação executável usando um mecanismo de queima aceito. Reduzir as emissões futuras do tesouro e queimar um saldo de tesouraria existente são ações diferentes.

A emissão do validador e a emissão da tesouraria podem ser alteradas de forma independente?

O whitepaper os trata como fluxos políticos independentes. O contrato v1.4 atual codifica uma curva de 2% e uma divisão 50/50, portanto, alterar apenas um fluxo requer uma nova implementação EmissionManager ou alteração de protocolo equivalente.

Quem pode chamar mint()?

Qualquer um pode chamar a função pública mint() do EmissionManager. O chamador não escolhe o valor nem os destinatários e não recebe nenhuma emissão. Apenas o EmissionManager contém o EMISSION_ROLE do token, portanto, apenas o valor calculado por sua lógica pode ser passado para a função token mint POL.

O que acontece se ninguém chamar mint() por um tempo?

O direito de emissão continua a crescer sob a curva-alvo baseada no tempo. Uma chamada posterior tenta cunhar a diferença acumulada. A emissão é, portanto, calculada continuamente, mas realizada em lotes de transações.

O mintPerSecondCap limita a oferta total de POL?

Não. Ele limita quanto o contrato de token POL aceita em relação ao tempo desde a emissão anterior. É um controle de segurança de taxa, não um suprimento máximo vitalício.

StakeManager recebe exatamente 1% como recompensa paga aos validadores?

StakeManager atualmente recebe metade das moedas EmissionManager, representando o fluxo de financiamento do validador. O acúmulo e a distribuição de recompensas dependem do ponto de verificação, marco, staking e mecânica de reivindicação. PIP-78 e PIP-86 mostram por que o financiamento, as recompensas acumuladas e as recompensas reivindicadas devem ser medidos separadamente.

As transferências de emissões são iguais aos eventos mint?

Não. O ideal é a transferência de endereço zero para EmissionManager. As transferências subsequentes para o tesouro e StakeManager distribuem os tokens recém-criados. Contar as transferências dos destinatários como eventos de cunhagem separados contabilizaria duas vezes o mesmo fluxo económico.

A migração de MATIC para POL cria emissões adicionais?

A migração normal 1:1 usa POL da oferta de migração inicial e não representa emissão programada. A contabilidade de migração e a cunhagem de EmissionManager são sistemas separados.

Por que duas previsões de oferta POL aparentemente corretas podem discordar?

Eles podem usar diferentes datas de início, intervalos anuais, carimbos de data e hora de execução, convenções de composição, suposições de queima ou suposições de protocolo futuro. Uma projeção reproduzível deve publicar seu oferta inicial, carimbo de data/hora inicial, períodos de taxas, fórmula, horizonte e tratamento de futuras alterações de protocolo.

Qual é a maneira mais precisa de descrever o número de outubro de 2033?

Descreva-o como a oferta bruta projetada no atual ponto final de dez anos sob um cenário nomeado. Por exemplo: executed emission history plus continuation of EmissionManager v1.4 through October 25, 2033. Não deve ser chamado de oferta máxima imutável ou limite máximo.

Contratos da Mainnet

• token POL
• Proxy DefaultEmissionManager
• Implementação DefaultEmissionManager v1.4
• ProxyAdmin
• StakeManager
• Tesouro Comunitário
• Proxy de migração de polígono

Referências Primárias

• artigo POL
• Documentos Polygon: token POL
• Repositório oficial de tokens POL
• Fonte DefaultEmissionManager atual
• Fonte do token POL atual
• PIP-17: Token do ecossistema Polygon
• PIP-26: Transição de recompensas do validador MATIC para POL
• PIP-29: Conselho do Protocolo Polygon
• PIP-40: Suporte para Contratos do Tesouro Comunitário
• PIP-41: Habilitar emissões diretas de POL para StakeManager
• PIP-67: Atualização de Membros do Conselho de Protocolo
• PIP-78: Ajuste de CHECKPOINT_REWARD
• PIP-86: Recalibrar CHECKPOINT_REWARD
• Relatório de Transparência do Conselho PIP-26/PIP-40 2024
• Relatório de transparência de migração de MATIC para POL
• Relatório de Transparência do Conselho PIP-26 2025

Páginas relacionadas

• Tokenomia POL
• Perguntas frequentes sobre tokens POL
• Queima POL
• Taxas Polygon Chain
• Validadores e staking
• Metodologia e fontes de dados