Emissão e inflação do POL

A emissão de POL é o processo de criação de novos POL além da oferta inicial de 10 bilhões de tokens. Os tokens emitidos financiam validadores e o Community Treasury da 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 emitido 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 emite POL.

A emissão é um componente comum do design econômico das principais redes L1, não uma particularidade do POL. Redes Proof-of-Stake emitem tokens para recompensar validadores e sustentar a segurança no longo prazo. Ethereum emite ETH como recompensa de validadores, enquanto Solana distribui a emissão inflacionária de SOL entre validadores e contas delegadas. Taxas e regras variam, mas o objetivo é o mesmo: financiar quem opera e protege a infraestrutura.

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 base fee, que POLTRACK mede separadamente da minting. 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 whitepaper POL;
2. o cronograma de emissão efetivamente executado na Mainnet Ethereum;
3. cenários futuros que exigiriam uma nova decisão protocolar.

A versão curta é:

• POL foi lançado no Ethereum com uma oferta inicial de 10 bilhões de tokens;
• sua taxa de emissão da Mainnet passou de 3% para 2.5% e depois para 2% em PIP-26;
• a atual implementação visa a emissão anual composta de 2%, dividida igualmente entre o StakeManager e o Community Treasury;
• o contrato acumula emissão continuamente ao longo do tempo, mas os tokens são emitidos 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 interrupção antecipada é tecnicamente possível através dos mesmos controles contratuais, mas não é o calendário atualmente anunciado;
• o excesso do Community Treasury 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 emitido junto com queima, Community Treasury e fluxos de validação, enquanto Oferta mostra a oferta circulante, a oferta máxima esperada e a emissão líquida.

Histórico executado na Mainnet

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 Mainnet.

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 minting foi para o multisig original do Community Treasury 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 Mainnet 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 Protocol Council executou a primeira redução de PIP-26, do financiamento do validador 2% para 1.5%, enquanto a emissão do Community Treasury 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 Community Treasury para a configuração do Community Treasury 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 Protocol Council concluiu a transição planejada de PIP-26, reduzindo o financiamento do validador de 1.5% para 1%. A emissão do Community Treasury 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 atual calcule uma curva de oferta combinada 2% e divida cada minting 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 Mainnet, 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 emitiu 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 Mainnet, 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 Community Treasury, StakeManager, contrato de migração, Burn Collector ou dead address 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 Mainnet é DefaultEmissionManager v1.4. Ele armazena uma oferta inicial e um carimbo de data e hora inicial, calcula uma oferta 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 minting 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.

O acúmulo é contínuo; o minting ocorre por transações

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 emite 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 emitido. Os tokens vão apenas para a Community Treasury 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 uma 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 Mainnet. POLTRACK, portanto, trata o PIP ou relatório como contexto de política e o estado do contrato executado como fonte primária de verificação 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 horizonte de 2033 e os controles técnicos

O whitepaper diz que as duas taxas 1% devem permanecer fixas durante o período inicial da política 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 Community Treasury

O fluxo do Community Treasury é 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 Community Treasury configurado.

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

Isso cria três questões distintas:

1. Emissão futura do Community Treasury: O novo POL deve continuar a ser emitido para suporte ao ecossistema?
2. Alocação do Community Treasury: como devem ser utilizados os POL já emitidos para esse fundo?
3. Excesso de Community Treasury POL: A Community Treasury POL que não é mais necessária deve ser retida, alocada ou queimada?

O whitepaper diz que se o ecossistema amadurecer cedo e o Community Treasury 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 os POL não utilizados do Community Treasury.

Interromper futuras emissões do Community Treasury também não queimaria automaticamente o saldo existente do Community Treasury. 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 checkpoints 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 Burn Collector ou dead addresses 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 Burn Collector definido pelo protocolo;
• uma exclusão económica utilizada por um tracker.

As queimas não criam uma hard cap. 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 emitido ao vivo e totais de queima, abra Fluxo de valor. Para oferta atual e emissão líquida, abra Supply. 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 emitidos 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.

A inflação é de MATIC ou de POL?

O sistema de emissão ativa emite 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 programada 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 Community Treasury. 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 é emitido por 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 Community Treasury 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 emitido. 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 hard cap?

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 hard cap 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 EmissionManager v1.4 tem como meta crescimento composto de 2% ao ano: 1% para financiar validadores e 1% para o Community Treasury. O histórico de Mainnet foi diferente: v1.1 tinha meta de 3%; v1.2 e v1.3, de 2,5%; v1.4, de 2%.

Quando começou a emissão de POL?

O carimbo de data e hora de início da Mainnet 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 Community Treasury 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 whitepaper diz que a emissão dos validadores, a emissão do Community Treasury ou ambas podem ser reduzidas ou completamente descontinuadas após o período inicial da política. 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 Community Treasury são automaticamente queimadas se não forem gastas?

Não. O POL destinado ao Community Treasury é emitido e transferido para o endereço do Community Treasury. Os tokens não gastos permanecem ativos do Community Treasury. O whitepaper diz que a comunidade pode decidir queimar o excesso de POL se o Community Treasury 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 Community Treasury POL?

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

A emissão dos validadores e a emissão da Community Treasury 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 de minting do token 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 emitir 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 uma oferta máxima vitalícia.

StakeManager recebe exatamente 1% como recompensa paga aos validadores?

StakeManager atualmente recebe metade das POL emitidos pelo 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 evento de minting é o Transfer da zero address para EmissionManager. As transferências subsequentes para o Community Treasury e StakeManager distribuem os tokens recém-emitidos. Contar as transferências dos destinatários como eventos de minting 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 minting 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 sua 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 nem hard cap.

Contratos da Mainnet

• token POL
• Proxy DefaultEmissionManager
• Implementação DefaultEmissionManager v1.4
• ProxyAdmin
• StakeManager
• Community Treasury
• Proxy de migração de polígono

Fontes 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: Protocol Council Polygon
• PIP-40: Suporte para Contratos do Community Treasury
• PIP-41: Habilitar emissões diretas de POL para StakeManager
• PIP-67: Atualização de Membros do Protocol Council
• 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