Skip to main content

​
A Intention é uma rede de negociação nativa de IA

Uma rede de negociação, não uma aplicação de negociação. As partes de uma exchange que decidem quem executou contra quem, a que preço e quem deve a quem são executadas pelos próprios validadores da rede, ordenadas por consenso e reproduzíveis por qualquer pessoa que tenha os mesmos blocos. Não há um motor de matching a correr noutro sítio e a reportar o resultado. Nativa de IA, porque é disso que um agente que negoceia em nome de alguém realmente precisa. Uma pessoa consegue vigiar uma plataforma e reagir-lhe. Um agente não consegue — só pode agir sobre aquilo que a plataforma é capaz de provar. Mover o matching, a margem, o funding, a liquidação forçada e a liquidação financeira para dentro do protocolo é o que faz de uma plataforma, em vez de uma contraparte em quem se confia, uma infraestrutura que se pode verificar. Tudo o que costuma ser apresentado como lista de funcionalidades decorre dessa única decisão. Porque a execução corre sobre uma ordenação confirmada pelo consenso, reexecutar um bloco reproduz exatamente o mesmo resultado. Porque o preço é certificado no bloco que o consome, não há ciclo de oráculo a que alguém se possa antecipar. Porque a liquidação forçada e o funding são operações do protocolo e não chamadas a contratos, executam no mesmo passo que a execução que os desencadeou. Porque a máquina de estados emite saída por transação, cada efeito tem um autor.
Uma exchange é mais do que isto. Os front ends, as operações de conta, a listagem de mercados, o apoio ao cliente e as condições comerciais ficam todos à sua volta. O que a rede torna público e verificável é o núcleo crítico para a liquidação financeira — a parte em que uma discrepância custa dinheiro a alguém.

​
As camadas

Quatro camadas, pela ordem em que uma transação passa por elas.
1 · Aplicação — fora do protocolo
2 · Rede
3 · Execução — IntentionKernel
4 · Estado
Gateway web Intention
Front ends · carteiras
Agentes · market makers · clientes API
Mempooladmissão · disseminação
IntentionBFTordenação · preços · definitividade
Matchinglivro · prioridade
Câmara de compensaçãomargem · liquidação · funding
Repositóriovalores por versão
Estado Merkleprovas · acumuladores
transações assinadas
bloco confirmado
escritas · eventos atribuídos
leituras · provas
Um quinto grupo fica ao lado da pilha, e não dentro dela. Os processos da camada de serviços correm ao lado dos validadores e ligam-se em apenas dois pontos: preços e ativos entram na camada de rede, registos confirmados saem na camada de estado.
Transação assinada
Mempoolvalidada antes de ser guardada
Consensoordenação e quórum de preços
Kernelexecução do bloco
Escritas de estadoeventos atribuídos
Confirmaçãoledger e repositórios de estado
O que a sequência produzA ordenação e os preços são confirmados antes de a execução começar, e cada alteração de estado fica ligada à transação que a causou — é isso que permite a qualquer pessoa reexecutar o bloco e obter o mesmo resultado.
Uma transação, ponta a ponta
Camada de aplicação. Tudo aquilo em que pessoas e máquinas realmente tocam: o gateway web da Intention, front ends e carteiras de terceiros e os agentes e market makers que negoceiam programaticamente. Nada disto faz parte do protocolo — é aquilo para que o protocolo existe e é deliberadamente substituível. Dois front ends discordarem sobre quanto vale uma posição é um bug de front end, porque ambos estão a ler o mesmo estado confirmado. Camada de rede. Onde as transações são admitidas, disseminadas e ordenadas. O IntentionBFT confirma uma ordenação e um vetor de preços certificado no mesmo evento de consenso; o mempool governa o que lá chega; a topologia descreve quem corre o quê. Camada de execução. O IntentionKernel executa o bloco confirmado como uma sequência fixa de fases. O seu conjunto de instruções é o conjunto enumerado de operações financeiras de que uma plataforma de derivados precisa — não é uma máquina virtual de uso geral. O matching e a câmara de compensação são fases dentro dele, não sistemas separados. Camada de estado. Estado e armazenamento descreve como os resultados são persistidos, autenticados e servidos: um repositório de valores atuais para leituras, uma estrutura Merkle versionada para provas e acumuladores sobre transações e eventos. Camada de serviços. Processos que correm ao lado dos validadores e não dentro do bloco: o oráculo que alimenta o consenso com preços, o indexador que transforma estado confirmado em dados consultáveis, os serviços de programa que derivam estado de conta a partir do histórico confirmado e o gravam de novo na cadeia através de transações do protocolo, e a ponte que move ativos entre cadeias.

​
Um único bloco

Tudo o que torna verificável o comportamento da plataforma acontece dentro de um único bloco confirmado.
Oráculopreços certificados por ronda
Pontedepósitos e levantamentos
Quatro camadasrede → execução → estado
Indexadorregistos confirmados → histórico consultável
Serviços de programaestado derivado, calculado fora do bloco
gravado de novo na cadeia, lido na execução
A ordenação é fixada antes de a execução começar, e a execução é uma função dessa ordenação e do estado anterior. Dois nós honestos que recebam o mesmo bloco chegam ao mesmo resultado byte a byte — não por política, mas porque nada no caminho de execução pode ler outra coisa. É nessa propriedade que assenta tudo o que vem a jusante: provas, atribuição, reexecução e a capacidade de um agente raciocinar sobre o que uma ordem submetida vai fazer.

​
De onde vêm as garantias da plataforma

Em vez de uma lista de promessas à parte, cada propriedade remete para a camada que a produz.

​
A infraestrutura de mercado que isto substitui

Um local de negociação tradicional é um elo numa cadeia de instituições. Uma operação é cruzada numa bolsa, novada e margeada numa contraparte central, registada na instituição que mantém o livro de quem detém o quê, liquidada através de um sistema de pagamentos e reportada a um repositório de transações. Cinco funções, cinco conjuntos de registos e um processo de reconciliação cujo ofício é descobrir quando deixam de bater certo. Aqui essas cinco são fases de um só bloco, e é isso que torna a sequência uma compensação e liquidação atómicas: confirma-se como uma unidade ou não se confirma de todo. O termo merece precisão. Essa atomicidade cobre o ledger do próprio protocolo — mover colateral para dentro ou para fora pela ponte espera a finalidade de uma cadeia externa e fica fora dessa unidade.
Cinco instituições
Um bloco
Matchinguma bolsa
Compensaruma CCP
Registarum depositário
Liquidarum sistema de pagamentos
Reportarum repositório de transações
Matchingfase de matching
CompensarCâmara de compensação
Registarcamada de estado
Liquidaro mesmo bloco
Reportaratribuição
Quatro intervalos. Em cada um existe uma promessa que ninguém cumpriu ainda — e existe um processo de reconciliação para descobrir quando deixam de bater certo.
As mesmas cinco funções, como uma só unidade de confirmação. Ou aconteceu tudo ou não aconteceu nada, e não há um segundo registo com que reconciliar.
A afirmação não é que isto fique mais barato. É que os intervalos entre aquelas instituições são o sítio onde existe uma promessa que ninguém cumpriu ainda — entre uma execução e um aviso de margem, entre o aviso e a chegada do colateral, entre uma operação e a sua liquidação, entre um acontecimento e o seu reporte. Dobrar as funções em fases de um mesmo bloco não torna as promessas mais fortes. Retira os intervalos em que elas podem ser quebradas. Aqui o matching, a compensação e a liquidação não são três paragens de um pipeline: são o mesmo acontecimento no mesmo bloco. A execução é a liquidação.

​
A rede hoje

A arquitetura acima está a correr agora, numa testnet privada que corre toda a pilha. Ver A rede hoje para a identidade da cadeia, os endpoints ativos e o que esperar antes de o acesso público abrir a 20 de setembro de 2026.

​
Para onde ir a seguir

IntentionKernel

A camada de execução: conjunto de instruções, pipeline de blocos e as fronteiras que a mantêm determinista.

IntentionBFT

Consenso: compromissos de ordenação, quóruns de preços e definitividade.

Câmara de compensação

Margem, liquidação forçada, desalavancagem automática, seguro e funding.

Estado e armazenamento

Como os resultados confirmados são persistidos, autenticados e podados.