Polkadot

Polkadot é um protocolo de rede multi-chain que conecta várias blockchains especializadas (“parachains”) a uma Relay Chain central. A Relay Chain oferece segurança compartilhada, consenso e interoperabilidade entre chains, enquanto as parachains operam em paralelo e se comunicam usando a mensagem cross-consensus do Polkadot (XCM). O objetivo do design é escalabilidade e composabilidade entre chains dentro de uma mesma rede.

Na arquitetura do Polkadot, parachains são chains específicas para aplicações, cujos blocos são produzidos por collators e validados por validadores da Relay Chain. Ao se conectar à Relay Chain, as parachains herdam a segurança econômica do conjunto de validadores e podem trocar mensagens com outras chains via XCM. Pontes também podem conectar Polkadot a redes externas—for exemplo, Ethereum via Snowbridge; a conexão com Bitcoin é feita por parachains como a Interlay, em vez de uma ponte light-client nativa. Para detalhes operacionais da mensagem cross-chain, veja a seção dedicada ao XCM.

DOT é o token nativo da rede na Relay Chain. Na especificação do Polkadot, ele sustenta três funções principais: governança do protocolo, staking para segurança da rede e bonding (mecanismo historicamente usado para adicionar chains).

O modelo de recursos do Polkadot está evoluindo com o “Polkadot 2.0”. Em vez de leilões de slots de longo prazo, projetos acessam o poder computacional da Relay Chain através do coretime (tempo em cores virtuais). O coretime é alocado para chains do sistema pela governança e adquirido por outras chains em mercado aberto.

DOT é o token nativo da Relay Chain do Polkadot. Ele sustenta as funções centrais da rede:

Segurança da rede via staking (NPoS): Detentores de DOT podem nomear validadores ou operar um validador para ajudar a finalizar blocos e manter o sistema íntegro. DOT em staking garante o comportamento dos validadores e gera recompensas; mau comportamento pode ser punido (slashing). Veja: Nominated Proof-of-Stake e Slashing para mecânicas e riscos.

Governança on-chain (OpenGov): DOT é usado para propor e votar referendos em múltiplos “tracks”, delegar poder de voto e participar de upgrades do protocolo e decisões sobre chains do sistema. Veja: OpenGov e Como os usuários podem participar da governança… para detalhes sobre tracks, depósitos e delegação.

Taxas de rede e depósitos obrigatórios: Transações na Relay Chain consomem taxas pagas em DOT, e contas devem manter um saldo mínimo (existential deposit) para permanecerem ativas. Algumas ações on-chain também requerem depósitos em DOT reembolsáveis (ex: identidade). Veja: Quais são as utilidades on-chain do DOT… para tipos de taxas e depósitos.

Aquisicão de poder computacional da Relay Chain (“coretime”) no Polkadot 2.0: Projetos obtêm tempo de execução nos cores da Relay Chain comprando coretime com DOT; estes DOT são queimados. Esse modelo substitui leilões de slots/crowdloans de longo prazo. Veja: O que muda com o Polkadot 2.0… e Como uma equipe pode lançar uma chain… para economia e rotas de deploy.

Financiamento do sistema pelo Tesouro on-chain: Entradas do Tesouro (parte de recompensas de bloco, taxas, gorjetas, penalties) são denominadas em DOT e podem ser gastas—via governança—em propostas aprovadas. Veja: Como o Tesouro on-chain opera… para processo e escopo.

Movimentação cross-chain e uso no ecossistema: DOT pode ser teleportado entre a Relay Chain e parachains do sistema como o Asset Hub via XCM; transferências cross-chain podem incorrer taxas tanto na origem quanto no destino. Algumas parachains/apps aceitam DOT nativamente; outras exigem representações bridge/wrapped. Veja: Asset Hub e Como o DOT interage com outras redes… para detalhes e ressalvas.

Se você busca o modelo de taxas específico, mínimos, depósitos e fluxos de staking, continue em “Quais são as utilidades on-chain do DOT (staking, taxas, governança e depósitos)?”

DOT usa uma emissão anual fixa que começou em ~8% da oferta na ativação e agora é um constante ~120 milhões de DOT por ano, fazendo com que a taxa percentual de inflação caia ao longo do tempo à medida em que a oferta total cresce. De cada emissão anual, 15% é cunhado diretamente para o Tesouro e 85% financiando recompensas de staking (pagas por era). Esses parâmetros foram introduzidos pela OpenGov (Referendo #1139) e implementados no código.

Ritmo e distribuição da emissão: Novos DOT são criados continuamente e contabilizados ao final de cada era (~24h em Polkadot), e então distribuídos a validadores e nominadores conforme o mecanismo de recompensa de staking; a fatia de 15% do Tesouro é cunhada diretamente para a conta sistema. Com o modelo de emissão fixa, essa divisão não depende mais da participação em staking, simplificando as recompensas comparado ao design anterior.

Queimas que compensam a emissão bruta: Dois fatores reduzem o crescimento líquido do fornecimento: compras de coretime (no Polkadot 2.0) são queimadas, e o Tesouro também pode queimar fundos via governança. Assim, a inflação efetiva anual é a emissão fixa (~120M DOT) menos os valores queimados no ano.

Como isso difere do modelo anterior: Antes da mudança de 2024, o Polkadot buscava ~10% de inflação anual, com recompensas moduladas por uma taxa de staking “ideal” e qualquer déficit indo ao Tesouro (“ineficiência de staking”). O novo modelo remove esse ajuste e substitui por uma fatia fixa de 15% para o Tesouro.

Sem hard cap (sujeito à governança): DOT não possui limite máximo de oferta programado. Parâmetros de emissão podem ser alterados via governança on-chain; as atualizações de 2024–2025 foram feitas por esse processo. Para configurações atuais e propostas em andamento, consulte os referendos OpenGov relevantes.

Redenominação de 2020 (apenas mudança de unidade): Em 21 de agosto de 2020 (“Denomination Day”, bloco #1.248.328), o DOT foi redenominado em 1 DOT antigo = 100 DOT novo. Isso foi uma mudança de unidade, não de valor ou propriedade: saldos e preços multiplicaram por 100×, e a unidade base (Planck) por DOT foi de 10¹² para 10¹⁰ Planck. A economia da rede permaneceu inalterada.

Staking (segurança da rede): DOT pode ser bondado para proteger a rede usando o modelo Nominated Proof-of-Stake (NPoS). Detentores podem nomear validadores ou operar um; recompensas são pagas por era, e má conduta pode ser punida (slashing). O conjunto de validadores é eleito por algoritmos baseados em Phragmén, e usuários também podem participar através de pools de nomeação, caso prefiram um caminho mais simples com valores menores. Mecânicas específicas como tempo de unbonding, condições de slashing e detalhes de eleição estão cobertos em NPoS e nas seções de Slashing.

Taxas (pagamento por transações): Na Relay Chain, transações pagam taxas em DOT deduzidas do saldo transferível (não dos fundos em staking). As taxas combinam taxa base, taxa por comprimento, taxa por peso de execução, mais uma gorjeta opcional para aumentar a prioridade de inclusão; um multiplicador pode ajustar taxas de acordo com o congestionamento recente. Na prática, as wallets mostram a taxa estimada antes de assinar.

Ações cross-chain podem envolver taxas tanto na origem quanto no destino. Por exemplo, teleportar DOT entre a Relay Chain e o Asset Hub envolve taxa de destino e não faz a checagem “keep-alive”, então o saldo deve permanecer acima do mínimo do destino para evitar reaping.

Governança (OpenGov): DOT é utilizado para propor e votar referendos no OpenGov. Propostas exigem depósito; votação usa saldos ponderados por convicção (tokens são travados para maior peso de voto). O usuário pode delegar poder de voto, incluindo delegações por track. O operacional (votar, delegar, gerir locks) está nas seções do OpenGov.

Depósitos e saldos mínimos: Polkadot impõe um existential deposit (ED)—saldo mínimo livre para manter uma conta viva. Se cair abaixo, a conta pode ser destruída (“reaped”) e qualquer resto queimado. Atualmente, o ED é de 1 DOT na Relay Chain e 0.01 DOT no Asset Hub (esses valores são específicos de cada chain e sujeitos a mudanças). Checagens keep-alive ajudam a evitar reaping em transferências regulares; teleports não aplicam essa proteção.

Algumas funções requerem depósitos reservados (bonds) que são mantidos enquanto o recurso está ativo e devolvidos ao ser removido. Exemplo: identidade agora gerida na parachain People exige depósito reembolsável e taxa do registrador; ao limpar a identidade, o depósito é liberado (os fundos ficam na People até serem teleportados de volta). Depósitos de governança (ex: depósito de decisão) estão na seção Governança.

A Relay Chain é a chain central do Polkadot. Oferece segurança compartilhada e consenso global, e é intencionalmente mínima em lógica de aplicação: existe para hospedar e coordenar chains paralelas, não para rodar features de usuário final. No design do Polkadot, a Relay Chain assegura uma visão global e consistente do estado entre os shards conectados (“parachains”).

Parachains são chains específicas para aplicações que rodam em paralelo e se conectam à Relay Chain. Mantêm seu próprio estado e lógica, mas herdam segurança do conjunto de validadores da Relay Chain. Nós chamados collators coletam transações e produzem blocos candidatos com provas; validadores da Relay Chain checam disponibilidade e validade antes de aceitar as transições de estado no estado compartilhado. Essa separação permite que parachains se especializem enquanto a Relay Chain cuida de consenso, finalização e coordenação.

Parachains podem se comunicar entre si usando o XCM, com a Relay Chain coordenando o roteamento/validação para troca segura de dados e ativos. Detalhes do XCM estão na seção dedicada.

Polkadot também inclui parachains sistêmicas (chains do sistema) para funções essenciais—ex: Asset Hub para ativos fungíveis ou não fungíveis—levando funcionalidades para fora da Relay Chain mas protegidas pela segurança compartilhada. Essas chains são alocadas pela governança.

No Polkadot 2.0, projetos acessam poder computacional da Relay Chain via cores (“coretime”). Chains do sistema recebem cores por governança; demais chains obtêm coretime em mercado aberto. O relacionamento fundamental continua: parachains executam sua lógica, a Relay Chain valida e finaliza as transições de estado.

XCM (Cross-Consensus Messaging) é a linguagem do Polkadot para enviar mensagens entre sistemas de consenso (Relay Chain, parachains e, via bridges, outras redes). Define o que deve acontecer, independente de módulos específicos. XCMP (Cross-Chain Message Passing) é o protocolo de transporte para mensagens parachain↔parachain; tráfego relay↔parachain usa UMP (upward) e DMP (downward). As mensagens são assíncronas.

Transferências: os dois padrões nativos do XCM

• Teleport: ativos movem diretamente entre locais confiáveis sem guardião de reserva. Usado normalmente para DOT entre Relay Chain e Asset Hub. Requer configuração de confiança mútua entre as chains.
• Transferência por reserva: a chain de reserva do ativo controla o suprimento; a origem trava/queima uma representação, a reserva ajusta o saldo e o destino credita uma representação. É o padrão comum para enviar ativos a parachains que não são as de reserva.

Na prática, transferências por reserva são preferidas por segurança e clareza; teleports são habilitados só para rotas de confiança total (no caso do DOT: Relay Chain ↔ Asset Hub).

Canais e roteamento: Mensagens parachain↔parachain usam canais. Hoje, a maioria usa HRMP (Horizontal Relay-routed Message Passing), que tem a mesma interface do XCMP, mas armazena mensagens na Relay Chain; o XCMP é mais eficiente no estado final. Canais HRMP são unidirecionais; conectividade completa exige um canal em cada direção e ambos precisam abrir/aceitar.

Taxas, peso e execução: Um XCM precisa “comprar execução” na chain de destino (pagar por peso, isto é, computação). Quais ativos são aceitos e quanto peso é requerido são políticas da chain de destino. Extrinsics padrão incluem teleport_assets e reserve_transfer_assets, detalhando destino, beneficiário, ativos e item de taxa.

Comportamento no nível usuário e proteções:

• Existential deposits & keep-alive: teleports não executam checagens keep-alive. O saldo pós-taxa no destino deve ficar acima do ED, ou a conta pode ser destruída. Teleports também incluem taxa na chain de destino.
• Assincronia & ordenação: não entrega instantânea; ordenação só garantida por canal.

Para bridges e DOT wrapped, veja interoperabilidade mais adiante.

Asset Hub é a parachain do sistema Polkadot (antes “Statemint”) para emissão, custódia e transferência de ativos, incluindo tokens fungíveis e NFTs. Projetada como uma chain de bem comum, oferece taxas menores e existential deposit reduzido comparado à Relay Chain, e utiliza DOT como token nativo para taxas e depósitos. No Polkadot Asset Hub o ED é 0.01 DOT (dez vezes menor que na Relay Chain), e ativos podem ser marcados como sufficient (sem exigência de saldo DOT) ou non-sufficient (a conta precisa atingir o ED DOT).

Na prática, Asset Hub serve para criação de ativos, gestão de metadata e transferências; orientações oficiais destacam Asset Hub como local conveniente para lidar com tokens não nativos e NFTs. (O Asset Hub do Kusama permite execução de smart contract; no Polkadot, EVM/PVM nativos estão previstos para o Polkadot Hub, não o Asset Hub.)

Quando faz sentido teleportar DOT?

Teleportar é a rota XCM de confiança entre Relay Chain ↔ Asset Hub para o DOT. Use se precisar de DOT no Asset Hub, por exemplo:

• Para pagar taxas mais baixas ou atingir o ED de 0.01 DOT ao segurar ativos non-sufficient no Asset Hub, ou
• Para usar features e aplicações que rodam no próprio Asset Hub.

Comportamentos importantes antes de um teleport:

• Uma taxa de destino é descontada do valor teleportado; o restante precisa ser ≥ ao ED do destino ou os fundos são perdidos.
• Teleports não verificam “keep-alive”, então saldos pós-taxa devem ficar acima do ED dos dois lados para manter contas ativas.
• Não teleporte direto para um endereço de depósito de exchange (a maioria não detecta teleports).

Para a mecânica de teleports vs transferências por reserva e roteamento cross-chain mais amplo, veja a seção XCM/XCMP. Se houver migração ou manutenção do Asset Hub em andamento, teleports e transferências XCM podem ficar indisponíveis; consulte avisos atuais de Suporte.

Propósito e papel: Polkadot e Kusama são redes independentes com tokens separados (DOT, KSM) e base de código similar. Kusama é a “canary network”: uma rede real, onde features novas chegam primeiro e avançam rápido; Polkadot prioriza estabilidade para implantações de produção.

Ritmo da governança: Ambas executam OpenGov, mas Kusama normalmente aplica prazos mais curtos (dependendo do track) do que Polkadot, permitindo upgrades rápidos; os parâmetros mudam por governança.

Tempo de staking: O período de unbonding é ~28 dias no Polkadot e ~7 no Kusama. Eras (usadas para pagamento de validadores) são ~24h no Polkadot e ~6h no Kusama. Isso afeta ritmo de recompensas e quanto tempo fundos ficam travados.

Saldo mínimo da conta (existential deposit): Para manter ativa, o Polkadot exige 1 DOT; o Kusama exige 0.000333333 KSM (pode mudar por governança). Parachains Asset Hub usam EDs menores ainda.

Caminho de upgrade: Mudanças e features grandes são testadas no Kusama sob condições reais; após aprovadas, chegam ao Polkadot. Isso garante agilidade no Kusama e conservadorismo no Polkadot para operação de longo prazo.

Ambas compartilham o mesmo modelo arquitetural (Relay Chain + parachains) e ferramentas OpenGov; as diferenças refletem metas (velocidade vs estabilidade) e parâmetros operacionais (temporizadores, mínimos), não arquitetura fundamental.

NPoS é o modelo de staking do Polkadot com dois grandes papéis: validadores executam nós que produzem e validam blocos; nominadores apoiam validadores com seus DOT. Ambos compartilham recompensas e risco de penalties se o validador apoiado errar. As eleições escolhem o conjunto de validadores e alocam stake de nominadores a cada era.

Ciclo de eleição e tempo: Em Polkadot, uma era é ~24h. O conjunto de validadores ativos da próxima era é definido no final da atual e aplicado na virada; recompensas então calculadas por era.

Como nominadores participam: Um nominador pode apoiar até 16 validadores. O algoritmo pode alocar o stake só para um subconjunto dessas escolhas, buscando um conjunto equilibrado e bem lastreado; nem todo validador nomeado receberá apoio na solução final.

Como validadores são eleitos (objetivo e algoritmo): As eleições de validadores maximizam (1) o valor total de stake garantindo o conjunto, (2) o menor stake entre eles, e (3) minimizam a variância entre os validadores. Soluções são computadas off-chain e submetidas on-chain via Election Provider (multi-fase), com fases assinadas/não-assinadas e fallback on-chain caso necessário. A rede usa regras derivadas dos estudos de Phragmén, resolvidas off-chain, substituindo abordagens sequenciais anteriores.

Alocação de stake e pagamentos: Após os vencedores, a solução especifica como o stake de nominadores é distribuído entre validadores eleitos. Validadores são pagos por era, e nominadores via seus validadores apoiados. Detalhes operacionais das recompensas estão nas seções de staking.

Responsabilização: Como nominadores apoiam validadores ativamente, podem ser slashed se o validador que ajudaram cometer infrações. Para condições e percentuais, veja a seção dedicada de Slashing.

Para tempos de unbonding, pools e mecânica de recompensas, continue em staking; este item cobre somente eleição e seleção de validadores.

Slashing é uma penalidade on-chain aplicada quando um validador viola as regras de consenso. A penalidade queima um percentual do stake associado àquele slot (autobond do validador mais qualquer stake de nominador alocado). O tamanho depende da infração; fundos slashed vão para o Tesouro do Polkadot. Nominadores só são penalizados se estavam apoiando o validador infrator naquele momento.

Infrações que acionam slashing (exemplos): Polkadot cataloga infrações e associa cada uma a uma resposta típica. Exemplos representativos incluem:

• Equivocation (BABE/GRANDPA/BEEFY): assinar blocos ou votos duplicados. Slashing de 0,01%–100% conforme gravidade e quantos validadores estiverem envolvidos; validador é desativado.
• Apoiar bloco parachain inválido: para-validator apoiou bloco inválido. Slashing de 100%; desativação on-chain.
• Voto ForInvalid: checker secundário votou em bloco inválido. Slashing de 2%; desativação.
• Voto AgainstValid: votou contra bloco válido. 0% de slashing (sem perda), mas desativação.

Indisponibilidade vs slashing: Quedas rotineiras levam a chilling forçado (parada do validador), não slashing. No Polkadot, slashing “offline” só ocorre se um evento de rede acontecer—ex: ≥10% do conjunto ativo fica offline ao mesmo tempo. Suporte indica que “prolongados” offline (tipo 4h) normalmente causam chilling e não slashing.

Quem paga e quanto: A penalidade é percentual sobre o stake exposto (autobond + fração dos nominadores alocada ao validador). Perdas dos nominadores são proporcionais à sua exposição ao infrator. O stake em outros validadores não é afetado. Esse modelo é desenhado para escalar e incentivar apoio diversificado.

Aplicação, atraso e reversão: Muitas penalidades são adiadas por aprox. um período de unbonding (~28 dias). Governança pode cancelar o slashing se foi por bug ou motivo não-faltoso; caso contrário, é aplicado antes do saque pós-unbonding.

Destino dos fundos slashed: Todo DOT slashed é creditado ao Tesouro on-chain, que financia a rede via OpenGov.

Leitura complementar: para seleção de validadores e alocação de stake, veja NPoS; para unbonding e pools, veja staking.

Ao parar o staking, DOTs vinculados ficam como “em desbloqueio” e só podem ser sacados após os 28 dias de unbonding. Você deve então executar Withdraw Unbonded para torná-los transferíveis. (No Kusama, são 7 dias.)

Exceção: Fast Unstake. Se sua conta não apoiou nenhum validador ativo nas últimas 28 eras, você pode usar Fast Unstake e pular a espera de 28 dias. Se houve exposição, é preciso aguardar o ciclo normal.

Staking pools x nomeação direta

Requisito de entrada & elegibilidade a recompensas:

• Nomeação direta (solo): para obter recompensas, o valor em staking deve superar o limite dinâmico mínimo de nomeação; este valor varia com o tempo.
• Pools de nomeação: projetados para possibilitar participação de pequenos detentores; oficial, a partir de apenas 1 DOT já é possível receber recompensas via pools (depende do tamanho e atividade).

Controle & custódia:

• Direto: você mesmo seleciona os validadores.
• Pool: seus DOT permanecem em sua conta (bondados), mas o nominador do pool escolhe validadores; escolhas ruins afetam recompensas e você ainda compartilha risco de slashing.

Operações (entrada, troca, saída):

• Unbonding: ambos têm 28 dias de unbonding no Polkadot. Para sair do pool, a retirada é após 28 dias também.
• Troca de pool: é preciso unbondar antes (28 dias no Polkadot; não há recompensas neste período).
• Rebond durante unbonding: nominadores diretos podem rebondar até terminar o período; membros de pools não podem rebondar.
• Recompensas: ao unbondar do pool, recompensas pendentes vão automaticamente para o saldo transferível. Alguns pools oferecem auto-compound; depende de habilitar.

Atualmente, é possível votar no OpenGov enquanto staked num pool, e juntar-se a pool com tokens já travados para governança. (Mudou das limitações anteriores.)

Para penalidades por comportamento de validadores, veja Slashing.

Existential deposit (ED) e mínimos:

• ED na Relay Chain: 1 DOT é requerido para manter uma conta viva em Polkadot. Se cair abaixo, a conta pode ser destruída (reaped) e qualquer resto é perdido.
• ED no Asset Hub: 0.01 DOT (cada chain define por governança). Ativos lá podem ser sufficient (sem DOT exigido) ou non-sufficient (a conta precisa cumprir o ED DOT).

Proteção keep-alive: Wallets como Polkadot-JS ativam “keep alive” por padrão: transferências que colocariam a conta abaixo do ED são bloqueadas. Dá para desativar e mandar todo saldo, destruindo a conta remetente.

Modelo de taxas na Relay Chain:

O Polkadot usa sistema de taxas por peso. A taxa de uma transação é:

• Componente base (sobrecarga por qualquer extrinsic)
• Taxa por tamanho (escala com bytes)
• Taxa por peso de execução
• Gorjeta opcional (para aumentar prioridade)
• Um multiplicador dinâmico ajusta as taxas conforme saturação recente (congestionamento).

Visualização/estimação de taxas: Wallets e SDKs mostram estimativa antes de assinar (ex: paymentInfo no polkadot.js). Taxas debitadas do saldo transferível (não do bonded).

Notas práticas:

• Reativando conta reaped: basta transferir o ED (ex: 1 DOT na Relay).
• ED por chain: varia por chain; no Asset Hub, é menor que na Relay. Verifique nos docs oficiais.
• Movimentos cross-chain: operações XCM (teleports) também cobram taxa de destino e não aplicam keep-alive; saldo após taxas no destino deve cumprir o ED. Veja a seção XCM para detalhes.

Para mínimos de staking e tempos de unbonding, veja staking; este item cobre taxas e mínimos no nível de conta.

OpenGov é o sistema de governança on-chain do Polkadot. Propostas (“referendos”) são vinculativas: se aprovadas, são automaticamente implementadas on-chain após o período de enactment. Há múltiplos referendos em paralelo.

Tracks e origins: Todo referendo é enviado via um track correspondente a um origin (nível de privilégio exigido). Cada track define: depósito de decisão, janelas de tempo (prepare/decision/confirmation/enactment), curvas de aprovação/suporte (thresholds) e, usualmente, capacidade simultânea de decisões. Tracks de alto privilégio (ex: Root) pedem thresholds mais rígidos e períodos mais longos que tracks de baixo impacto (ex: Small Tipper).

Algumas calls podem ser whitelisted pela Polkadot Fellowship e executadas no track Whitelisted Caller, que tem parâmetros mais rápidos. Comportamentos de track e exemplos estão no guia de origins do OpenGov.

Voto e convicção: Detentores de token votam Aye/Nay/Abstain com DOT. Votos podem aplicar convicção (travar tokens para maior poder de voto); locks começam no fim do referendo e liberam após o período. OpenGov permite diferentes convicções em referendos simultâneos.

Delegação e multi-delegação: Ao invés de votar diretamente, o usuário pode delegar poder de voto. OpenGov suporta delegação por track: você pode delegar valores/convicções diferentes para tracks distintos. Não é possível delegar para um track com votos ativos (ou delegação prévia) até limpar. UIs oficiais mostram seleção de tracks e convicção ao configurar.

Ciclo do referendo (resumido):

• Submissão & período de prepare – o referendo entra no track; votos podem ser enviados, mas não contam até o final do prepare. Depósito de decisão é necessário para que avance para decisão.
• Período de decisão – o item entra em decisão ativa. Aprovação exige atingir as curvas do track.
• Período de confirmação – thresholds devem ser mantidos por janela mínima.
• Período de enactment – após confirmação, a call é agendada e executada on-chain após o atraso do track.

Qualquer detentor de DOT pode participar do OpenGov: você pode submeter propostas (referendos), votar direto ou delegar poder de voto. A atividade ocorre em “tracks” que definem origin (privilégio), depósito, thresholds e janelas de tempo. Parâmetros variam por governança.

Propor (criar um referendo):

1. Escolha o track correto para a ação desejada (ex: Root para calls de alto impacto, Tippers/Spenders para o Tesouro).
2. Submeta o referendo e asse-gure que o depósito de decisão seja feito; esse depósito fica on-chain e é necessário para o item entrar na decisão depois do período de lead-in. Depósitos aparecem por referendo nas UIs e são reembolsáveis conforme as regras do track.

Requisitos: conta Polkadot com DOT suficiente para taxas e depósito do track. Identidade on-chain é opcional mas recomendada para credibilidade; exige depósito reembolsável e taxa do registrador na parachain People.

Votar (participação direta):

• Opções: Aye, Nay, Abstain, Split (divide entre Aye/Nay), ou SplitAbstain (divide entre Aye/Nay/Abstain).
• Conviction voting: opcionalmente trave DOT por mais tempo para multiplicar o poder de voto; locks começam ao final do referendo e expiram conforme escolhido. Locks podem sobrepor; assim o mesmo saldo pode garantir múltiplos votos ou staking. Pode remover voto durante o referendo para liberar imediatamente; expurgar locks vencidos ao final.

DOT staked ou pool também podem votar: OpenGov permite votar mesmo staked ou via pools, após atualizações de runtime.

Delegar (por track, multi-delegação): Caso não queira votar cada item, pode delegar poder de voto. OpenGov aceita multi-delegação por track: escolha delegados distintos, com valores e convicções próprios por track. Não é possível delegar onde já há votos ativos (ou delegação prévia) até limpar. Delegações são gerenciadas nas UIs oficiais (Polkadot-JS, Polkassembly, Nova, PolkaGate).

Ferramentas práticas:

• UI Polkadot-JS: propor, votar, delegar, limpar locks vencidos.
• Polkassembly/Subsquare/Nova/PolkaGate: explorar referendos, votar (Incluindo Split/Abstain) e delegar por track.

Para thresholds, períodos e tamanhos de depósito, consulte o track ao propor ou delegar; esses parâmetros variam por track e mudam por governança.

O Tesouro é um fundo on-chain controlado pelo OpenGov. Recebe entradas automaticamente e só pode gastar fundos em ações aprovadas na governança. Os fundos vivem em conta do sistema; nenhuma conta externa pode movê-los diretamente.

Como o Tesouro é financiado:

• Taxas de transação: 80% de cada taxa vai para o Tesouro; 20% para produtores de bloco.
• Emissão de DOT: 15% da inflação anual vai para o Tesouro.
• Slashing: parte dos stakes penalizados de validadores é creditada ao Tesouro.
• Transferências diretas: usuários podem transferir ativos ao Tesouro (incomum, ex: reembolsos).

Como funciona o gasto:

• Propostas de gasto do Tesouro: governança aprova referendos para liberar fundos a um beneficiário. Pagamentos ocorrem conforme o cronograma do spend period; ao final de cada período, parte dos fundos não gastos é queimada.
• Gorjetas: pagamentos rápidos via tracks Small/Big Tipper.
• Bounties & child bounties: “bounty” reserva fundos para pagamento em tarefas/eventos; curadores depositam, podem receber fee, e gerem os pagamentos dentro do prazo do bounty.

Tracks de governança para gasto: OpenGov gere gastos por seis tracks, cada um com origin e parâmetros: Treasurer, Big/Medium/Small Spender, e Big/Small Tipper. Gastos maiores usam tracks mais rigorosos; gorjetas são para valores pequenos.

Tesouro multi-ativo: Pode segurar e gastar ativos que não sejam DOT (ex: USDT/USDC) se onboardados no Asset Hub e taxa de conversão definida via governança (track Treasurer). Gastos multi-ativos aprovados detalham ativo, chain, valor; gastos por etapas e janelas de saque são suportados.

Sub-tesouros (delegação orçamentária): Governança pode destinar parte do Tesouro a sub-tesouros ligados a coletivos ou chains do sistema. Cada um segue suas próprias regras para liberar fundos, reduzindo a necessidade de muitos referendos na main.

Para criar, votar ou delegar propostas do Tesouro, veja as seções de OpenGov.

A Polkadot Fellowship é um coletivo on-chain de contribuintes técnicos que zelam pelo runtime e padrões técnicos do protocolo. Atua na chain Collectives do Polkadot e coordena trabalho on-chain e em repositórios públicos (ex: RFCs de mudanças). Apesar de manter os runtimes de Polkadot e Kusama, não bloqueia upgrades—qualquer detentor de DOT pode propor upgrades no track Root do OpenGov.

Membros e ranks: Membros têm ranking, e votações internas usam os ranks para pesar responsabilidade e revisão técnica. Dashboards públicos mostram ranks e atividade.

Whitelisting & Whitelisted Caller: Para ações urgentes ou de baixo risco (com releases já auditados), a Fellowship pode whitelistar o hash da call. Isso habilita o track Whitelisted Caller no OpenGov, permitindo despachar aquela call com permissão Root após referendo aprovado. Esse track tem prazos mais curtos e thresholds diferentes que o Root, acelerando ações validadas.

Como upgrades são aplicados: Upgrades de runtime só são feitos por referendo Root ou Whitelisted Caller. O papel da Fellowship é revisar, whitelistar quando apropriado e liberar upgrades pelo track acelerado; caso contrário, upgrades seguem o fluxo Root padrão.

Processo aberto de desenvolvimento: Propostas técnicas são rastreadas no repositório público (RFC); sinais da Fellowship (aprova/nega) e decisões on-chain são visíveis a todos.

Agile Coretime (blockspace como mercado)

Polkadot 2.0 substitui leasing de slots/crowdloans de longo prazo por um mercado de coretime. Projetos adquirem execução em cores da Relay Chain de duas formas:

• Bulk Coretime: região mensal (~28 dias, 5.040 timeslices) vendida em chain dedicada. A posse é um ativo não fungível, podendo ser transferida ou revendida.
• Instantaneous Coretime: bursts curtos comprados de um pool conforme a necessidade (pay-as-you-go).

Vendas usam leilão de preço decrescente (modelo Holandês); o preço regular ajusta ao longo do tempo conforme regras de governança, convergindo à demanda. Há mercado secundário de regiões. A receita das vendas de coretime é queimada conforme RFC da Fellowship. A emissão líquida é emissão bruta menos queimas.

Impacto no custo: times planejam gastos comprando apenas a capacidade necessária, com sinais de preços mais claros e sem travas multi-ano. Leilões/crowdloans foram aposentados.

Async Backing (ganhos de throughput & latência)

Async Backing desacopla a produção de blocos das parachains do último bloco da Relay Chain, permitindo collators pipelar candidatos e sobrepor backing/inclusão. Na prática:

• parachains produzem blocos a cada ~6s (antes, 12s)
• aumenta a janela de execução (~0.5s para ~2s), blocos ~4× maiores
• até ~8× mais throughput (só com async backing); ~10× com PoV-reclaim (provas menores)

Essas novidades vieram em 2024 (Kusama primeiro, depois Polkadot).

Impacto: TPS mais alto e inclusão mais rápida onde ativo; chains que não precisam de mais capacidade podem aderir depois.

Elastic Scaling (múltiplos cores por chain)

Elastic Scaling permite a uma única chain usar múltiplos cores em paralelo (escala vertical), não só um por parachain. Funciona com async backing e novos parâmetros de collator/validador para ainda mais throughput e menor latência. Em agosto/2025, Elastic Scaling está sendo finalizado para mainnet (Kusama primeiro).

Impacto: rollups/parachains de alta demanda podem distribuir carga por vários cores, aumentando capacidade sem precisar dividir a chain.

Resumo dos efeitos:

• Custos & planejamento: coretime previsível e de mercado substitui leases longos; times compram mensal, ou on-demand; receita de coretime é queimada, reduzindo inflação líquida.
• Throughput & latência: async backing aumenta frequência e capacidade de bloco; elastic scaling traz execução multi-core para ganhos extras. Junto, aumentam o throughput real sem mexer no modelo de segurança compartilhada do Polkadot.

1. Construa sua chain:

   • Use o Polkadot SDK (Substrate + Cumulus) começando pelo template de parachain. Isso entrega um runtime baseado em FRAME, nó collator e XCM prontos para customizar.
   • Conecte localmente a uma Relay Chain para validar produção de blocos e XCM; o tutorial oficial mostra como conectar uma parachain local.

2. Teste em testnet & obtenha o ParaID:

   • Prove upgrades e XCM na Paseo (testnet com coretime).
   • Reserve um ParaID na relay chain alvo via registrar: primeiro reserve (paga depósito da chain), depois register com WASM de validação e génesis. Depósitos são configurados por chain (docs mostram nos testnets; em mainnet, valores são definidos por governança).

3. Adquira Coretime (Polkadot 2.0):

   • Bulk Coretime (uma “Região”): compre região de ~28 dias (5.040 timeslices) em core específico, vendido em chain própria. A posse é controlada on-chain e transferível; vendas com leilão de preço decrescente até preço regular.
   • Instantaneous Coretime: capacidade on-demand, em bursts conforme necessidade (não uma região cheia).
   • Contabilidade: receita vai para queima (RFC-0010 Fellowship), então times planejam DOTs para compra; não há crowdloan/lockup.

4. Registre & ative na Relay Chain:

   • Com ParaID, WASM e génesis prontos, envie registro e ative a chain. Em Polkadot, onboarding normal usa o registrar; chains do sistema (Coretime, Asset Hub) entram via OpenGov (track Whitelisted Caller), vide referendo de registro.

5. Opere sua rede:

   • Collators: rode pelo menos dois collators confiáveis; escale e distribua geograficamente conforme demanda. (Validadores estão na Relay Chain; parachains dão collators.)
   • XCM & HRMP: abra canais HRMP (ex: Asset Hub) e configure XCM (ativos aceitos para taxas/reservas). Para roteamento de DOT, siga orientação atual sobre Asset Hub como reserve durante migração.
   • Upgrades: entregues por governança da própria chain; a Relay Chain valida na inclusão. (Parâmetros Relay e OpenGov em governança.)

6. Rollups vs parachains (“rollup” no contexto):

   • Muitas equipes implementam “rollups” como parachains com SDK (liquidação e verificação pela Relay Chain), herdando disponibilidade/validade e XCM. Se fizer rollup-as-a-service numa parachain, coordene com o host e não compre coretime direto; o processo base é o mesmo. (A escolha é da equipe.)

Requisitos mínimos (checklist)

Técnicos:

• Runtime Polkadot SDK (WASM) + chain spec, génesis e ParaID.
• Nós collator, endpoints RPC, telemetria/monitoramento.
• Configuração de XCM e pelo menos um canal HRMP para integração.

Econômicos:

• DOTs para coretime (Bulk ou Instantaneous) e taxas; coretime adquirido é queimado.
• Depósito de registrar para reservar/registrar ParaID (por chain).

Governança:

• Nenhuma para onboarding pelo registrar além da sua própria chain; chains de sistema são onboardadas via OpenGov (exemplo: registro do Coretime).

DOT nativo vs wrapped/derivado:

• DOT nativo vive no Polkadot mesmo (Relay Chain e chains do sistema como Asset Hub). Dentro do Polkadot, DOT circula via XCM, seja teleport (Relay ↔ Asset Hub) ou transferências por reserva quando em outras parachains. A governança está migrando o “reserve location” do DOT do Relay para o Asset Hub, então parachains devem passar a tratar o Asset Hub como reserve oficial.
• DOT wrapped/derivado existe fora do Polkadot (ex: Ethereum) ou como forms ERC-20 compatíveis dentro de parachains EVM. No Moonbeam, DOT aparece como xcDOT, um XC-20: representação ERC-20 compatível, com DOT travado em conta soberana na chain de origem, ficando ERC-20 só localmente.

XCM interno vs bridges externas:

• XCM (no ecossistema): formato de mensagem para mover ativos entre Relay e parachains. Para DOT, teleport está habilitado na rota Relay ↔ Asset Hub; saídas para outras parachains usam transfer por reserva, com a reserve chain contabilizando o supply.
• Bridges (fora do ecossistema): polkadot usa bridges hospedadas no Bridge Hub para unir redes externas como Ethereum. Snowbridge é a bridge oficial light-client Polkadot↔Ethereum. Ela mint tokens ERC-20 no Asset Hub via ForeignAssets, e depois faz transfer XCM ao destino. XCM e bridge trabalham juntos.

EVM via Moonbeam (XC-20s):

• Padrão XC-20: no Moonbeam, ativos cross-chain são apresentados como XC-20s, padrão ERC-20 (e Permit). Para DOT, é o xcDOT. Devs usam ferramentas Ethereum padrão, com o Polkadot mantendo a reserva/conta soberana.
• XC-20 local vs externo: tokens cujo home/reserva é o Moonbeam são “locais”; ativos como DOT são XC-20 externos, com saldo oficial na chain de reserva (Relay/Asset Hub); a interface ERC-20 circula apenas no Moonbeam.

Notas práticas:

• Quando usar o quê: use XCM para movimentos internos (ex: DOT entre Asset Hub e parachains). Use bridge (ex: Snowbridge) para ativos para/fora de redes externas como Ethereum; tokens bridged têm modelos de confiança e risco distintos do DOT nativo.
• Atualizações: a migração da reserve location do DOT (para Asset Hub) é mudança ativa; parachains/apps devem atualizar configs XCM. Orientação de usuário final é divulgada por Suporte e fórum Polkadot.

O Polkadot foi iniciado pela Web3 Foundation (W3F), uma fundação suíça sem fins lucrativos, sendo seu principal projeto. O fundador da W3F é Dr. Gavin Wood, autor do whitepaper original do Polkadot em 2016 que descreve o design multi-chain heterogêneo.

O desenvolvimento do protocolo e runtime foi liderado pela Parity Technologies, equipe de engenharia que trabalhou com a W3F até o mainnet do Polkadot em 2020.

A equipe fundadora do Polkadot inclui Gavin Wood, Robert Habermeier e Peter Czaban. O anúncio oficial cita Robert Habermeier como cofundador e core developer do Polkadot, e Peter Czaban como cofundador do Polkadot e W3F.

A W3F iniciou o lançamento da rede do Polkadot em 26 de maio de 2020, após anos de desenvolvimento; fases subsequentes entregaram o controle aos detentores de tokens e liberaram a emissão de DOT on-chain. A mecânica de oferta e redenominação está destacada nas seções anteriores.