Skip to main content
Listar um mercado, mudar o seu estado e retirá-lo são operações de protocolo, e não ações administrativas tomadas algures à parte. Executam dentro de um bloco, no topo da prioridade do bloco, e o seu efeito é observável a uma altura de bloco concreta, em vez de anunciado e aplicado de forma opaca. Isto tem uma consequência prática para quem integra: o estado de um mercado é estado da cadeia e é autoritativo. Um cliente não precisa de ser informado de que um mercado abriu — consegue vê-lo.

Os estados em que um mercado pode estar

Um mercado nunca está simplesmente «ligado» ou «desligado». Tem um estado que determina exatamente que ordens o livro aceita.
Initializingo livro não aceita nada
PreOpenpost-only, só contas autorizadas
Activetudo
PostOnlyas ordens taker são rejeitadas
Pausednada
ReduceOnlysó ordens que reduzem uma posição
FinalSettlementnada — o estado terminal
PostOnly e Paused regressam a Active. ReduceOnly não — é o caminho de encerramento.
O estado de um mercado é estado da cadeia, executado no topo da prioridade do bloco. Um cliente não precisa que lhe digam que um mercado abriu: consegue vê-lo.
Não são níveis de gravidade num mostrador. Cada um é uma resposta diferente a um problema diferente. PreOpen é como um mercado ganha um livro antes de ter uma transação. Os makers autorizados podem cotar e, como só são aceites ordens post-only, nada pode cruzar enquanto o livro está a ser construído. O mercado abre já com os dois lados presentes, em vez de abrir vazio e deixar o primeiro taker definir o preço. PostOnly trava quem consome sem travar quem cota. É o estado para «a descoberta de preço está avariada neste momento» — os makers ainda podem reposicionar-se, mas ninguém pode executar contra uma cotação desatualizada. ReduceOnly deixa toda a gente sair e ninguém entrar. É o estado em que um mercado entra quando está a ser encerrado, ou quando o seu perfil de risco mudou o suficiente para que aumentar a exposição já não seja apropriado.

Como abre um mercado

Uma listagem é uma operação de configuração que escreve a especificação do contrato na cadeia: tick size (incremento mínimo de preço), lot size (incremento mínimo de quantidade), composição do índice, escalões de alavancagem, parâmetros de funding, limites de posição e bandas de preços. Nada do comportamento do mercado vive fora desse registo. A especificação é escrita antes de o mercado aceitar seja o que for e é legível desde o momento em que existe. Um cliente que consulte a lista de mercados vê o novo mercado — com os parâmetros completos — antes de ele ficar negociável, e é essa a janela de que uma integração precisa para se configurar. As operações de listagem podem ficar sujeitas a um requisito de multisig: a operação transporta uma prova que satisfaz um limiar de signatários e, caso contrário, a execução rejeita-a. Isto é imposto pelo protocolo na execução e não por um processo à volta dele, pelo que não é uma política que alguém possa contornar.

Como um mercado é retirado

Uma deslistagem é a sequência inversa e não um interruptor. Um mercado passa a ReduceOnly, para que as posições abertas possam ser fechadas e não se possa criar exposição nova, e só depois a FinalSettlement. A sequência é procedimento operacional e não algo que a máquina de estados imponha por si — mas é a sequência que importa. Desligar um mercado com posições abertas deixaria os seus detentores com exposição de que não conseguem sair através do livro — o que converte uma alteração operacional planeada numa liquidação financeira forçada ao preço que o protocolo escolher. Passar por ReduceOnly dá a cada detentor a hipótese de fechar primeiro a um preço de mercado. O procedimento de liquidação financeira das posições ainda abertas no momento da liquidação final é específico do contrato e é publicado com o aviso de deslistagem, juntamente com o prazo de aviso prévio.
Um aviso de deslistagem é o único anúncio que exige ação. Se tiver uma posição num mercado que entra em ReduceOnly, fechá-la por sua iniciativa a um preço que escolheu é materialmente diferente do que fizer o procedimento de liquidação final. Ver Alterações às regras para saber como funcionam os prazos de aviso prévio.

Contratos pré-mercado

Alguns mercados são listados antes de o ativo subjacente ter um mercado spot líquido — um token antes da sua listagem, uma ação antes da sua oferta pública. Para o kernel são mercados vulgares; para um trader não são. O seu preço do índice tem fontes menos numerosas e mais fracas, o que o torna mais fácil de mover e mais propenso a saltos. As especificações refletem isso com menos alavancagem, limites de funding mais largos e limites de posição mais apertados. Ver Mercados.

Construir para lidar com listagens

Enumere os mercados repetidamente, não uma única vez. Um cliente que lê a lista de mercados no arranque e nunca mais o faz perde silenciosamente tudo o que for listado depois. As listagens são um acontecimento normal e contínuo. Leia as especificações em vez de as guardar. Os tick sizes, os escalões de alavancagem e os limites de funding mudam em mercados ativos. Um cliente com uma cópia desatualizada submete ordens que a rede rejeita, ou dimensiona posições contra limites que já não se aplicam. Trate todos os estados, não só Active. Uma ordem rejeitada por causa do estado do mercado não é um defeito da sua ordem — é o mercado a dizer-lhe o que aceita neste momento. Tratar PostOnly, ReduceOnly e Paused como distintos é a diferença entre uma integração que degrada com elegância e outra que insiste contra uma parede.

Anúncios

O fluxo de anúncios começa com a testnet pública a 20 de setembro de 2026. Até lá, os mercados na testnet privada são listados e alterados sem aviso, porque nada ali tem valor.
Cada aviso de listagem e de deslistagem incluirá: o mercado e a sua especificação completa, o bloco ou a data de entrada em vigor, o prazo de aviso prévio dado e — no caso de uma deslistagem — o procedimento de liquidação das posições ainda abertas.

Para onde ir a seguir

Mercados

O que contém uma especificação de contrato.

Alterações às regras

Prazos de aviso prévio e como as alterações entram em vigor.

Sequenciação de transações

Porque as operações de sistema correm no topo de um bloco.

Changelog do protocolo

O registo datado do que foi lançado.