> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Alterações às regras
> Como mudam as regras de negociação, os parâmetros de risco e o comportamento do protocolo: prazos de aviso prévio, alturas de bloco de entrada em vigor e por que razão as regras de um bloco passado nunca podem ser reescritas.
Chegam três tipos de alteração a uma rede em funcionamento: **alterações de parâmetros** (um limite de risco, uma tabela de comissões, um limite de funding), **alterações de comportamento** (como a própria execução funciona) e **alterações de mercado** ([listagens e deslistagens](/pt/programs/listings)).
Diferem na forma como são anunciadas. Partilham uma propriedade, e é a que importa: uma alteração entra em vigor num **ponto específico da história da cadeia**, e a história anterior a esse ponto não é afetada.
Alterações de parâmetros
Os parâmetros de risco, os escalões de alavancagem, os limites de funding, os limites de posição e as tabelas de comissões são configuração on-chain. Alterar um deles é uma transação de protocolo que executa num bloco, no topo da [prioridade do bloco](/pt/trading/tx-sequencing).
Como o valor é estado da cadeia, a alteração é observável em vez de reportada. Não precisa de que lhe digam que a margem de manutenção de um mercado mudou — pode ler o valor atual, e pode ler também o que vigorava em qualquer bloco passado.
As chaves de configuração são também **versionadas**. Quando muda a forma de um valor e não o seu número, a nova forma é escrita sob uma chave nova e a antiga continua legível. Um cliente que resolve a configuração em direto continua a funcionar ao longo da mudança; um cliente que fixou um caminho de chave no código descobre-o de imediato, em vez de ler silenciosamente algo desatualizado. Ver [Modelo de estado](/pt/protocol/architecture/state/model).
Alterações de comportamento
Mudar o *comportamento* da execução é um problema mais difícil do que mudar um número, porque todos os validadores têm de fazer a mudança exatamente no mesmo momento. Uma alteração que chega a nós diferentes em momentos diferentes não é uma implantação faseada — é um fork.
A Intention resolve isto com **gates on-chain** (interruptores de funcionalidade). Cada gate é uma chave de estado que guarda uma altura de bloco: a altura a partir da qual o novo comportamento começa.
Comportamento novo inativoestá no binário, não ativo
É escrito um gateuma chave de estado com uma altura futura
Todos os validadores leem a mesma altura
O comportamento muda exatamente nesse bloco
A altura tem de estar no futuroUm gate não pode ser definido para uma altura já passada. É essa única regra que torna a alteração simultânea.
Gate ausente significa inativoUm nó que reexecuta a história não lê chave nenhuma nessas alturas e segue o caminho antigo: a reexecução fica correta sem matriz de compatibilidade.
Lido na versão que está a executarNunca de uma cache. Ler um valor atual durante a reexecução de um bloco antigo aplicaria as regras de hoje à história de ontem.
Daqui decorrem três propriedades, e todas são estruturais:
**A altura tem de estar no futuro quando é escrita.** Um gate não pode ser definido para uma altura já passada. É essa única regra que torna a alteração simultânea — todos os validadores chegam a esse bloco com a mesma chave já visível.
**Um gate ausente significa inativo.** Um nó que reexecuta a história não lê nenhuma chave nessas alturas e segue exatamente o caminho de código antigo. A reexecução histórica mantém-se correta sem custo, sem ninguém ter de manter uma matriz de compatibilidade.
**O gate é lido na versão que está a ser executada, nunca a partir de uma cache.** Ler um valor atual durante a reexecução de um bloco antigo aplicaria as regras de hoje à história de ontem e produziria uma raiz do estado diferente. Por isso o valor é sempre lido a partir da vista de execução do bloco em execução.
O mesmo mecanismo suporta a ativação gradual: uma flag pode ser introduzida inativa, verificada contra tráfego real e ligada numa altura agendada — em vez de entregue como uma atualização de binário feita de uma só vez.
Prazos de aviso prévio
O aviso prévio é proporcional ao que uma alteração pode fazer a uma posição que já tenha aberta.
| Alteração | Aviso prévio |
| ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------- |
| **Afeta posições abertas** — requisitos de margem, escalões de alavancagem, limites de funding, deslistagens | Anunciada antes da data de entrada em vigor, com a data indicada |
| **Afeta integrações** — superfície da API, formato das mensagens, disposição das chaves | Anunciada com antecedência, com um caminho de migração |
| **Afeta apenas o custo** — tabelas de comissões, escalões de rebates | Anunciada antes da data de entrada em vigor |
| **Corrige um risco em curso** — um parâmetro apertado em resposta a uma condição de mercado | Pode entrar em vigor de imediato |
A última linha é uma exceção real, não uma brecha. Um limite de posição que tem de esperar uma semana para apertar é um limite de posição que não faz nada exatamente na semana em que era preciso. Quando é usada, a alteração e a sua razão são publicadas com ela.
Uma alteração aos requisitos de margem ou aos escalões de alavancagem muda o preço de liquidação das posições que já tenha abertas. Não fecha nada e não o avisa individualmente. Se mantiver posições ao longo de uma alteração anunciada de parâmetros de risco, recalcule a distância à liquidação com os valores novos, e não com os que vigoravam na abertura. Ver [Alavancagem](/pt/trading/leverage).
O que não pode mudar
As regras que se aplicaram a um bloco já confirmado.
Todas as alterações de regras entram em vigor numa altura que estava no futuro quando foram registadas, pelo que reexecutar um bloco antigo aplica sempre as regras que estavam ativas nessa altura. A pergunta de saber se uma dada regra vigorava numa versão passada tem uma única resposta, e é a mesma hoje e daqui a um ano.
Esta é uma garantia mais forte do que uma política publicada. Não é que o protocolo *não vá* reescrever a história — é que o mecanismo não tem forma de representar uma regra que começou no passado. Ver [Modelo de estado](/pt/protocol/architecture/state/model).
Anúncios
Os compromissos de aviso prévio desta página começam com a **testnet pública a 20 de setembro de 2026**. A [testnet privada](/pt/protocol/architecture/network-status) altera parâmetros e comportamento sem aviso — existe precisamente para os afinar.
A partir do momento em que os prazos de aviso prévio começarem, todas as alterações são registadas no [changelog do protocolo](/pt/protocol/roadmap/changelog) com a data em que entraram em vigor, e anunciadas antes dessa data quando a tabela acima o exigir.
As entradas são datadas pela **data em que a alteração entrou em vigor na rede**, não pela data em que foi anunciada.
Para onde ir a seguir
O registo datado do que foi lançado.
Alterações de mercado e os respetivos prazos de aviso prévio.
Porque as chaves de configuração são versionadas e resolvidas em direto.
O que uma alteração de parâmetros de risco faz a uma posição aberta.