Whitepaper Técnico v2.3
O BlazePhoenix-Dex é um agregador de liquidez on-chain construído sobre uma única afirmação: uma cotação e a sua execução são o mesmo cálculo. A rota é derivada dentro da transacção que a executa, a partir do estado público das pools, por uma biblioteca sem estado que qualquer leitor pode voltar a correr; o número que vincula na liquidação é re-derivado pelo mesmo despachante no quadro em execução. Não há serviço de encaminhamento, não há oráculo de preços, não há keeper e não há caminho de actualização. Este documento especifica os cinco contratos — Core, Hub, Solver, Router, Quoter — e os operadores da Meta-Equação (Meta-Equation): o Despachante Óctuplo Ω (Eightfold Dispatcher Ω), a Derivação Determinística 𝒟 (Deterministic Derivation 𝒟), o piso da Lei de Ferro Φ (Iron-Law floor Φ), o Campo de Vitalidade Ψ (Vitality Field Ψ) e o projector anti-burla Ξ (anti-scam projector Ξ). Por trás deles está uma disciplina, o Desenho Metrológico (Metrological Design): medir todas as coordenadas que podem ser medidas e tornar as restantes monótonas, para que uma entrada falsa só prejudique quem a forneceu. Cada garantia é enunciada com o seu ponto de imposição e o seu limite. O aparelho de verificação é publicado com os seus denominadores: 1,319 de 1,320 testes verdes no perfil de lançamento, 268 de 268 mutantes seleccionados mortos, 14 de 15 mutantes dirigidos a 43 invariantes com estado detectados, covering arrays de força 2 (63 linhas, 258 pares) e 3 (168 linhas, 1,636 triplos), 14 + 5 relações metamórficas, três builds do optimizador em acordo, e um estudo de 240 amostras sobre como uma cotação envelhece. Aquilo que nada disto estabelece é enunciado com o mesmo cuidado. O código descrito é o V2 e não está implantado; a geração implantada é a V1, fixada por codehash para que as duas nunca sejam confundidas.
Estado: o que este documento descreve e o que está implantado
A árvore da Versão 2 que este documento descreve está no repositório e não está implantada; a geração implantada é a Versão 1, fixada por codehash em todas as redes para que as duas nunca sejam confundidas. Todos os números do documento são medidos em main 8949a9d e publicados ao lado do seu denominador; texto integral em português em https://blazephoenix.xyz/whitepaper/pt.md; o original inglês, que prevalece, em https://blazephoenix.xyz/whitepaper.md.
§1 O problema: uma cotação é uma promessa que outra pessoa calculou
Imagine vender um carro numa cidade com vinte concessionários. Um bom corretor visita os vinte, encontra o melhor preço e talvez divida a venda por dois deles. A maioria dos «corretores» on-chain consulta preços na sua própria base de dados — possivelmente desactualizada — e mostra-lhe um resultado. Não pode verificar que olharam para os vinte, nem que lhe mostraram o melhor. Só pode verificar que, até aqui, foram honestos.
§2 A resposta e a disciplina
O BlazePhoenix-Dex tem um ponto de entrada que recebe seis valores — os dois tokens, o montante, o seu mínimo, um destinatário, um prazo — e apura a rota dentro da transacção que a executa, a partir das reservas das pools, que são estado público: que locais de negociação, quanto para cada um, por que ordem. Como a rota foi derivada de estado público por código público, qualquer pessoa a pode voltar a derivar.
§3 A Meta-Equação e o orçamento de dependências
Todo o agregador pode ser lido como a maximização de uma única expressão. Dado um token de entrada t_in, um token de saída t_out e um montante x, o Solver procura, entre as rotas admissíveis, aquela que maximiza o valor líquido recebido, sujeita a um piso de viabilidade e a uma porta anti-burla.
§4 O Despachante Óctuplo Ω (Eightfold Dispatcher Ω)
Em linguagem simples: uma função que sabe cotar todos os tipos de pool. Em rigor: universalQuote(QuoteCtx, amountIn), no Core, é o despachante de cotações para o Solver e para a pré-visualização do Quoter; devolve a saída esperada e uma profundidade denominada em token para o alocador de divisão (Split Allocator), e uma pool que não consiga cotar devolve zero e é descartada antes de se enviar o que quer que seja.
§5 Uniswap V4 de ponta a ponta
O Uniswap V4 não é um novo contrato de pool; é uma nova forma de local de negociação, e invalida quatro pressupostos em que assenta todo o router construído entre 2020 e 2024. As pools não têm endereços — são entradas no armazenamento de um singleton, indexadas por um hash. Corre código arbitrário dentro do swap — um hook executa em pontos definidos da liquidação que o router está a realizar. As taxas não têm de ser constantes. E as pools podem deter a moeda nativa da cadeia, que não tem balanceOf. Esta secção responde estruturalmente às quatro, para que uma perna V4 seja — para o Solver, para os pisos e para o negociante — indistinguível de qualquer outra perna.
§6 O solver Solidly
Algumas invariantes não têm forma fechada suficientemente simples para ser reproduzida com segurança, e reproduzi-las é exactamente o risco de replicação que o protocolo recusa noutros pontos. Para esses locais, o despachante pergunta à pool, pelo canal honesto mais estreito que o local expõe — e mantém uma réplica de reserva para os forks que não respondem.
§7 Derivação Determinística 𝒟 (Deterministic Derivation 𝒟)
Antes de uma pool poder ser cotada, tem de ser encontrada. A resposta da indústria é perguntar: uma chamada à factory do local lê um mapeamento em armazenamento e devolve um endereço, e quem chama aceita a palavra da factory. A BlazePhoenix suporta essa resposta — quatro modos de chamada a factory cobrem os locais cujos deploys não são reproduzíveis — e prefere uma mais forte sempre que a aritmética o permite: calcular o endereço, sem qualquer chamada externa. Um endereço calculado pode ser verificado por qualquer pessoa com os mesmos três dados de entrada; um endereço obtido só pode ser acreditado.
§8 O Monoslot
O armazenamento é o custo dominante de fazer o que quer que seja na EVM: um SLOAD frio custa 2,100 gas, e um registo que espalhasse os atributos de uma pool por slots separados pagá-lo-ia outra vez por cada atributo, por cada pool, em cada rota avaliada. A BlazePhoenix comprime todo o estado de encaminhamento de uma pool numa única palavra de 256 bits — o Monoslot — lida uma só vez e descodificada por aritmética pura.
§9 O Registo Auto-Reparador (Self-Healing Registry) e o Campo de Vitalidade Ψ (Vitality Field Ψ)
A maioria dos agregadores conhece os seus locais porque um keeper indexa pools fora da cadeia e publica listas na cadeia — um processo de confiança, uma janela de desactualização e uma dependência operacional, três coisas que um protocolo que resolve rotas on-chain não pode aceitar. A BlazePhoenix assume a posição oposta: o registo aprende a liquidez negociando-a.
§10 Encaminhamento e o Alocador de Divisão (Split Allocator)
Uma pool de produto constante forma preço por uma só regra: as suas duas reservas, multiplicadas, nunca podem encolher. Injecte Δ com retenção de taxa γ (uma taxa de local de 0.30 % significa γ = 0.997) e recebe yγΔ / (x + γΔ), com a sua própria entrada no denominador: quanto mais empurrar por uma pool, pior paga cada token seguinte. A derrapagem é aritmética, e a sua cura também: dividir a mesma ordem por pools do mesmo par move menos cada pool.
§11 A camada de execução e o piso da Lei de Ferro Φ (Iron-Law floor Φ)
O Solver propõe; o Router dispõe — atomicamente, ou de todo. O Router é o único contrato que move fundos, não detém nenhuns entre transacções e assenta num princípio: um mecanismo por cada preocupação, aplicado universalmente. Não presume nada que possa medir.
§12 Superfícies de cotação, e como uma cotação envelhece
Há dois sítios de onde pode vir um número chamado «a sua cotação», e são caminhos de código diferentes: o Quoter, um contrato de pré-visualização só de leitura que uma interface chama antes de assinar, e o caminho em quadro, onde o Solver e o Router calculam cotações dentro da transacção em execução. O §4.4 deu a verdade por tipo; esta secção dá as superfícies e mede a distância entre elas.
§13 Política de taxas: os dois regimes e a Regra do Excedente (Surplus Rule)
Em linguagem simples: o protocolo cobra 0.28 % uma vez, sobre um montante medido, numa moeda que a tesouraria quer deter, e regista que o fez. Em rigor: PROTOCOL_FEE_BPS = 28 é uma constante de compilação no Core, sem setter algum no bytecode implantado; a taxa é mulDivUp(base, 28, 10,000) — arredondada para cima, pelo que uma taxa nula é inalcançável para qualquer base não nula — repartida em TREASURY1_SHARE = 3,000 bps para a primeira tesouraria e o restante para a segunda (calculado como fee − t1, de modo que as duas somam sempre a taxa, sem pó), com as tesourarias fixadas na construção e congeláveis para sempre pela Porta de Sentido Único (One-Way Door).
§14 Modelo de segurança
Em linguagem simples: o Router não detém nada entre transacções, cada swap é tudo-ou-nada, e cada classe de ataque que este repositório considerou é respondida por uma verificação nomeada ou declarada fora de âmbito. Em rigor: o catálogo de ameaças é docs/assurance/threats.json, 23 classes retiradas do registo público de exploits; cada uma nomeia o símbolo de guarda que a recusa, e um script de CI faz falhar o build se o símbolo sair de src/ ou o teste nomeado sair de test/. A cobertura de um catálogo é um piso sobre o que foi considerado, nunca um tecto sobre o que existe.
§15 O aparelho de verificação, medido
Em linguagem simples: cada número aqui é publicado ao lado do denominador contra o qual foi medido, é recalculado a partir de um checkout limpo por um script ou por um comando forge nomeado (Apêndice C), e é seguido por aquilo que não estabelece. Em rigor: a árvore medida é main em 8949a9d e o ramo que lhe deu origem, no perfil de lançamento (optimizer_runs = 300, via_ir), 2026-09-05.
§16 Arquitectura e tamanhos
Em linguagem simples: cinco contratos, um dos quais é matemática pura importada pelos outros quatro, e nenhuma peça de matemática está definida duas vezes. Em rigor: o Core é uma biblioteca sem estado, sem armazenamento, sem dono e sem caminho de actualização; Hub, Solver, Router e Quoter importam-no e nenhum redefine uma primitiva, pelo que uma auditoria da matemática cobre todos os consumidores.
§17 Desempenho medido
Em linguagem simples: tudo nesta secção foi medido em forks de cadeias reais — locais reais, reservas reais depositadas por desconhecidos, um só bytecode — e está rotulado exactamente como isso. Em rigor: um número só aparece aqui se um harness público do repositório o reproduzir; o harness, a cadeia e a data são publicados ao seu lado. Uma medição em fork é prova sobre comportamento, não um registo de implantação; o registo de implantação é o §19. As medições do §12 e do §15 são de 2026-09-05; a campanha desta secção correu em Agosto de 2026 e os seus harnesses estão em test/fork/.
§18 O DEX, reduzido ao osso
Dezassete secções de mecanismo, reduzidas a uma página. Um só trabalho: receber dois tokens, um montante, o seu mínimo, um destinatário e um prazo, e devolver o máximo que a liquidez pública da rede consegue entregar — ou recusar, com um código que diz porquê. Cinco contratos partilham uma só matemática (Core, Hub, Solver, Router, Quoter); seis tipos de venue são cotados por um só despachante; quatro portas chegam a um só executor; três pisos e o seu próprio mínimo estão por baixo de cada trade; uma taxa de 0,28% está compilada e ninguém a pode mudar.
§19 Estado de implantação
Este documento documenta o repositório, e o repositório é canónico: onde este texto e a fonte discordarem, ganha a fonte. Existem duas gerações e nunca são confundidas.
§20 Token — BZPX
Mil milhões de BZPX, fixos para sempre, como um ERC-20 simples: 18 casas decimais, sem caminho de emissão, sem taxa na transferência, sem rebasing, sem hooks de transferência, sem pausa nem lista negra. Distribuição na versão 2.3: liquidez de mercado 520,000,000 (52%), emissão de staking 180,000,000 (18%), Airdrop e Bounties 130,000,000 (13% — o antigo airdrop de 50,000,000, o antigo fundo de investigação de 50,000,000 e 30,000,000 retirados da liquidez de mercado), equipa 103,000,000 (10.3%), parceiros 60,000,000 (6%), marketing 7,000,000 (0.7%).
§21 Programa de investigação e registo de segurança
Antes de este projecto ter um programa de investigação digno do nome, investigadores independentes leram a fonte de forma hostil — sem lhes ser pedido, sem nada prometido — e divulgaram privadamente o que viram. O código que este documento descreve é o código que sobreviveu a essa leitura. O que cada um reportou, e o que lhe aconteceu, vive onde esses registos devem viver: no SECURITY.md e no SECURITY_HALL_OF_FAME.md do repositório, ao lado do código, onde cada entrada pode ser verificada nos dois sentidos. Esta secção regista quem são, quanto paga a leitura hostil, e a forma daquilo que ela encontrou.
§22 Aquilo em que tem de confiar, e aquilo em que não precisa
Todos os protocolos se dizem sem confiança; quase nenhum consegue enumerar as suas excepções. Aqui está a lista completa, com cada poder enunciado junto à linha que o delimita.
§23 Trabalho relacionado
Encaminhamento. Angeris, Evans, Chitra e Boyd formulam o encaminhamento entre criadores de mercado de função constante como um programa convexo cujo óptimo iguala os preços marginais entre locais; Diamandis, Resnick, Chitra e Angeris dão um algoritmo eficiente de decomposição dual para o resolver.
§24 Conclusão
Propusemo-nos construir um agregador sobre uma disciplina — medir, não acreditar — e mantê-la em todos os pontos em que um número poderia, em vez disso, ter sido aceite sob palavra de alguém: a rota, o preço, o piso, a base da taxa, o conjunto de locais, o par que uma pool afirma negociar, e até o modelo de custo do próprio protocolo.
Questions, a partnership or a bug to report? Contact us or email contact@blazephoenix.xyz